September 2013 - openSUSE Factory - openSUSE Mailing Lists

Re: [opensuse-factory] BtrFS as default fs?
by Ken 04 Sep '13

04 Sep '13

It's not up to me to set them when I am using the list server. If YOU have a problem with how the list is set up talk to Henne. Besides I have no access to the list server to set anything. Ludwig Nussel <ludwig.nussel(a)suse.de> wrote: >Ken Schneider - openSUSE wrote: >> CAN WE PLEASE KEEP ALL REPLIES ON THE LIST ONLY (NO PM REPLIES). >> MULTIPLE COPIES ARE NOT NEEDED! > >You didn't set Mail-Followup-To in the mail headers so you didn't >specify any preference. Set Mail-Followup-To if you don't like >copies. If you still get copies then you can blame the MUA used. >There is no need to yell at people. > >http://www.leptonite.org/mft/ > >cu >Ludwig -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] vdr anyone?
by Ludwig Nussel 04 Sep '13

04 Sep '13

Hi, VDR version 2.0 was released quite some time ago but we still have 1.6. I'm still the maintainer but in reality I don't have a use case for vdr anymore so I won't be able to take care of updating it. Anyone want to take over? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] Openvas 6 to replace the dead v4 ??
by johann Luce 04 Sep '13

04 Sep '13

Hi packaged the openvas last stable version (v6) here: https://build.opensuse.org/project/show/security:OpenVAS:UNSTABLE:v6 i want to submit it in factory because the v4 support is dead and it is the factory version when i submited it it was declined: security:OpenVAS:STABLE:v4/gsd' is the devel package, submission is from 'security:OpenVAS:UNSTABLE:v6' or something like: 'security:OpenVAS:UNSTABLE:v6' is not a valid devel project of openSUSE:Factory - please pick one of the existent any ideas ?? thanks for your answer regards jluce -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] systemd sshguard.service question
by Joop Boonen 04 Sep '13

04 Sep '13

Hi all, I'm currently writing the sshguard.service file. Most of it is more or less straightforward. I found a problem I cant resolved,this are snippets of the system v files. for _logs in $MONITORED_LOGS; do cmdline="$cmdline -l $_logs" done and test -n "$WHITELIST" && cmdline="$cmdline -w $WHITELIST" How can this be resolved in the sshguard.service file? Regards, Joop. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Re: [opensuse-kernel] BtrFS as default fs?
by Cristian Rodríguez 04 Sep '13

04 Sep '13

El 03/09/13 11:53, Jeff Mahoney escribió: > As I said then, the point isn't to take away functionality from anyone. > If we have the ability to enable it in YaST (with a warning) or do it > automatically (with a warning) if the features are already enabled on an > older file system, nobody's lost anything. The point is that it will > prevent users from losing their file systems using a feature set that > hasn't been well tested. > > It's great that you want to try features out that we don't consider safe > yet. That's how we get bug reports that we can use to improve and > further gauge the quality of a particular feature set. I just don't > think that /all/ openSUSE users want to have that particular experience > without knowing what's up beforehand. Jeff, I do not object to the idea of warning people that certain features are unstable or dangerous a log message: "btrfs warning: FOOBAR is unstable".. will suffice in achiving this result. what I do strongly object is this pervasive tendency to add SUSE specific flags that are not documented anywhere else other than probably a wiki page or the openSUSE documentation, has distribution specific semantics,is not in upstream plus will cause confusion and increase the load of volunteers that answer questions in mailing list and the forums. This makes sense for SLE where you only want to support things known to be production quality and therefore reducing the number of support incidents. in the openSUSE land will only cause confusion (pretty much like the "unsupported module flag") -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] Is there enough time to have kernel 3.11 for openSUSE 13.1
by Roman Bysh 03 Sep '13

03 Sep '13

Hello Listmates, Now that Linus has released 3.11 over the Labor Day weekend. Is there enough time to have kernel 3.11 for openSUSE 13.1? -- Cheers! Roman ------------------------------------------- openSUSE -- Get it! Discover it! Share it! ------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] [Tumbleweed] Kernel crash in graphics driver
by Achim Gratz 03 Sep '13

03 Sep '13

Just had the kernel crash on me twice in a row: Sep 3 21:35:24 Linux kernel: [ 459.123704] [TTM] Failed to find memory space for buffer 0xdea1302c eviction Sep 3 21:35:24 Linux kernel: [ 459.123714] [TTM] No space for dea1302c (10207 pages, 40828K, 39M) Sep 3 21:35:24 Linux kernel: [ 459.123717] [TTM] placement[0]=0x00040002 (1) Sep 3 21:35:24 Linux kernel: [ 459.123719] [TTM] has_type: 1 Sep 3 21:35:24 Linux kernel: [ 459.123720] [TTM] use_type: 1 Sep 3 21:35:24 Linux kernel: [ 459.123721] [TTM] flags: 0x00000002 Sep 3 21:35:24 Linux kernel: [ 459.123723] [TTM] gpu_offset: 0xF8000000 Sep 3 21:35:24 Linux kernel: [ 459.123724] [TTM] size: 16384 Sep 3 21:35:24 Linux kernel: [ 459.123726] [TTM] available_caching: 0x00060000 Sep 3 21:35:24 Linux kernel: [ 459.123727] [TTM] default_caching: 0x00040000 Sep 3 21:35:26 Linux kernel: [ 459.123774] ------------[ cut here ]------------ Sep 3 21:35:26 Linux kernel: [ 459.124020] kernel BUG at /home/abuild/rpmbuild/BUILD/kernel-pae-3.10.10/linux-3.10/include/drm/drm_mm.h:100! Sep 3 21:35:26 Linux kernel: [ 459.124020] invalid opcode: 0000 [#1] SMP Sep 3 21:35:26 Linux kernel: [ 459.124020] Modules linked in: fuse bridge stp llc af_packet binfmt_misc w83627hf hwmon_vid snd_emu10k1 snd_via82xx_ modem snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mpu401 snd_util_mem snd_mpu401_uart snd_rawmidi snd_hwdep snd_seq snd_timer snd_seq_ device ppdev snd_mixer_oss parport_pc parport 8139too snd shpchp sg sr_mod snd_page_alloc powernow_k8 8139cp button floppy cdrom soundcore ns558 emu10 k1_gp gameport k8temp serio_raw ehci_pci pcspkr i2c_viapro autofs4 uhci_hcd ehci_hcd radeon ttm drm_kms_helper drm i2c_algo_bit processor usbcore usb_ common scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh edd fan thermal_sys ata_generic sata_via pata_via Sep 3 21:35:26 Linux kernel: [ 459.124020] CPU: 0 PID: 2806 Comm: kwin Not tainted 3.10.10-25.g8038aea-pae #1 Sep 3 21:35:26 Linux kernel: [ 459.124020] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./K8V-X, BIOS 1012.004 10/14/2005 Sep 3 21:35:26 Linux kernel: [ 459.124020] task: f217c570 ti: f217a000 task.ti: f217a000 Sep 3 21:35:26 Linux kernel: [ 459.124020] EIP: 0060:[<f7bd6a9e>] EFLAGS: 00210246 CPU: 0 Sep 3 21:35:26 Linux kernel: [ 459.124020] EIP is at drm_mm_hole_node_start.part.3+0x0/0x562 [drm] Sep 3 21:35:26 Linux kernel: [ 459.124020] EAX: f58acdc0 EBX: f58acdc0 ECX: 00000030 EDX: f7bab4f6 Sep 3 21:35:26 Linux kernel: [ 459.124020] ESI: f7bab4f6 EDI: 00000001 EBP: f58acdc0 ESP: f217bb80 Sep 3 21:35:26 Linux kernel: [ 459.124020] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Sep 3 21:35:26 Linux kernel: [ 459.124020] CR0: 8005003b CR2: 8e408000 CR3: 35388000 CR4: 000007f0 Sep 3 21:35:26 Linux kernel: [ 459.124020] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Sep 3 21:35:26 Linux kernel: [ 459.124020] DR6: ffff0ff0 DR7: 00000400 Sep 3 21:35:26 Linux kernel: [ 459.124020] Stack: Sep 3 21:35:26 Linux kernel: [ 459.124020] f7bca211 00200246 00000000 c0bab322 dea1302c 00000000 00000001 f35e8550 Sep 3 21:35:26 Linux kernel: [ 459.124020] f58acdc0 f7bab4f6 00000001 f35e8550 f7ba8fb0 dea1302c 00000000 f7ba4148 Sep 3 21:35:26 Linux kernel: [ 459.124020] f7baa81c 00040000 00000000 00000001 00000027 fffffff4 dea13050 00000000 Sep 3 21:35:26 Linux kernel: [ 459.124020] Call Trace: Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7bca211>] drm_mm_debug_table+0x71/0x120 [drm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7ba8fb0>] ttm_bo_man_debug+0x20/0x30 [ttm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7ba4148>] ttm_mem_evict_first+0x3e8/0x420 [ttm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7ba484c>] ttm_bo_mem_space+0x2ac/0x350 [ttm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7ba49b0>] ttm_bo_move_buffer+0xc0/0x120 [ttm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7ba4a87>] ttm_bo_validate+0x77/0xf0 [ttm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7d20f17>] radeon_bo_list_validate+0x47/0xd0 [radeon] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7d356f1>] radeon_cs_ioctl+0x441/0x830 [radeon] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<f7bc0d5e>] drm_ioctl+0x44e/0x4f0 [drm] Sep 3 21:35:26 Linux kernel: [ 459.124020] [<c03598a7>] do_vfs_ioctl+0x77/0x560 Sep 3 21:35:26 Linux kernel: [ 459.124020] [<c0359e18>] SyS_ioctl+0x88/0xa0 Sep 3 21:35:26 Linux kernel: [ 459.124020] [<c06ffd97>] syscall_call+0x7/0xb Sep 3 21:35:26 Linux kernel: [ 459.124020] [<b74c2aa4>] 0xb74c2aa3 Sep 3 21:35:26 Linux kernel: [ 459.124020] Code: 06 83 c8 e8 d5 2c ff ff 31 d2 b8 e2 00 00 00 b9 00 01 00 00 c7 04 24 ee 18 be f7 e8 8d 6f 77 c8 b8 54 c8 be f7 5a e9 92 ff 89 c8 <0f> 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sep 3 21:35:26 Linux kernel: [ 459.124020] EIP: [<f7bd6a9e>] drm_mm_hole_node_start.part.3+0x0/0x562 [drm] SS:ESP 0068:f217bb80 Sep 3 21:35:26 Linux kernel: [ 459.425145] ---[ end trace f13dfff712dbb3c3 ]--- The first crash was actually on the 3.10.9 kernel (I hadn't rebooted yet): Sep 3 21:25:04 Rainer kernel: [ 9627.326800] CPU: 0 PID: 2435 Comm: X Tainted: G W 3.10.9-24.ga0841e3-pae #1 […] But otherwise it's been exactly the same crash, while visiting the same page in Firefox. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 1

[opensuse-factory] Is there enough time to have kernel 3.11 for openSUSE 13.1?
by Roman Bysh 03 Sep '13

03 Sep '13

Hello Listmates, Now that Linus has released 3.11 over the Labor Day weekend. Is there enough time to have kernel 3.11 for openSUSE 13.1? -- Cheers! Roman ------------------------------------------- openSUSE -- Get it! Discover it! Share it! ------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Please expect an OBS downtime on thursday
by Adrian Schröter 03 Sep '13

03 Sep '13

Heya, please expect a bit longer downtime of OBS on thursday. We are about to install a second binary backend server to handle the increasing number of builds, repository state calculations and storage needs. So we will do a final sync of all home:* projects to the new server on thursday before we can become productive again. We do not expect any technical problems due to the split though. A distributed OBS instance is running inside of SUSE for quite some time already. -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] pax is not tar
by Felix Miata 03 Sep '13

03 Sep '13

In 13.1M4, I did tar -cvf /mnt/usb/stuff.tar file1.ts file2.ts file3.ts On /mnt/usb was a NTFS formatted USB stick. The object of tarring was to preserve all native file attributes while transversing the foreign formatted media. After ejecting, I put it into a USB port on a Linux STB running busybox v1.0. After it automounted, I changed to the desired destination for extraction, and then tar -xvf <mountpoint>/stuff.tar . That gave me $SUBJECT. Apparently busybox tar isn't very smart. I've done this before successfully, making me believe something about tar in 13.1 is different. Is it? Is it a bug? Since I'm dealing with huge media files, experimenting is a lengthy process. I can't tell from the 13.1 tar man page what option might make busybox tar able to extract from a 13.1 tar file. Anyone know what's going on here? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

12 46