Re: [Mageia-dev] i586 tainted stalled?
On Fri, Mar 2, 2012 at 7:21 AM, Funda Wang wrote: > Hello, > > Is there any problem with i586 tainted repository? The build of ffmpeg > and gstreamer0.10-plugins-bad has been stalled for hours. > > Thanks. it fails because of this error : Installation failed, some files are missing: http://repository.mageia.org/distrib/cauldron/i586/media/tainted/release/libfreetype6-2.4.8-2.mga2.tainted.i586.rpm You may need to update your urpmi database. seems some rpms are missing ( there is no libfreetype6-2.4.8-2.mga2.tainted.i586.rpm ). I just pushed a new rpm of freetype in tainted.
Re: [Mageia-dev] i586 tainted stalled?
The problem is, if BuildRequires are failed to install, will iurt try it forever? 2012/3/2 D.Morgan : > On Fri, Mar 2, 2012 at 7:21 AM, Funda Wang wrote: >> Hello, >> >> Is there any problem with i586 tainted repository? The build of ffmpeg >> and gstreamer0.10-plugins-bad has been stalled for hours. >> >> Thanks. > it fails because of this error : > > Installation failed, some files are missing: > > http://repository.mageia.org/distrib/cauldron/i586/media/tainted/release/libfreetype6-2.4.8-2.mga2.tainted.i586.rpm > You may need to update your urpmi database. > > seems some rpms are missing ( there is no > libfreetype6-2.4.8-2.mga2.tainted.i586.rpm ). > > I just pushed a new rpm of freetype in tainted.
Re: [Mageia-dev] i586 tainted stalled?
On Fri, Mar 2, 2012 at 9:15 AM, Funda Wang wrote: > The problem is, if BuildRequires are failed to install, will iurt try > it forever? shouldn't, seems we have an issue here that we need to fix ( i though it was supposed to test 3 times ( or something like this ). Pascal , any idea on this ?
Re: [Mageia-dev] i586 tainted stalled?
On Fri, Mar 2, 2012 at 9:17 AM, D.Morgan wrote: > On Fri, Mar 2, 2012 at 9:15 AM, Funda Wang wrote: >> The problem is, if BuildRequires are failed to install, will iurt try >> it forever? > > shouldn't, seems we have an issue here that we need to fix ( i though > it was supposed to test 3 times ( or something like this ). seems liblame-devel is missing too
[Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. checking in dmesg - I see that the nouveau driver grabs the card before the nvidia driver can - but trying to remove the nouveau driver wants to remove over 800 packages! How can I get the nvidia proprietary driver back?? [ 53.253035] [drm] nouveau :04:00.0: Attempting to load BIOS image from PRAMIN [ 53.298983] [drm] nouveau :04:00.0: ... appears to be valid [ 53.298987] [drm] nouveau :04:00.0: BIT BIOS found [ 53.298990] [drm] nouveau :04:00.0: Bios version 62.94.20.00 [ 53.298993] [drm] nouveau :04:00.0: TMDS table version 2.0 [ 53.298996] [drm] nouveau :04:00.0: Found Display Configuration Block version 4.0 [ 53.298998] [drm] nouveau :04:00.0: Raw DCB entry 0: 02000300 0028 [ 53.299013] [drm] nouveau :04:00.0: Raw DCB entry 1: 01000302 00020030 [ 53.299015] [drm] nouveau :04:00.0: Raw DCB entry 2: 04011310 0028 [ 53.299019] [drm] nouveau :04:00.0: Raw DCB entry 3: 02022332 00020010 [ 53.299024] [drm] nouveau :04:00.0: Raw DCB entry 4: 000e [ 53.299029] [drm] nouveau :04:00.0: DCB connector table: VHER 0x40 5 16 4 [ 53.299039] [drm] nouveau :04:00.0: 0: 0x1030: type 0x30 idx 0 tag 0x07 [ 53.299052] [drm] nouveau :04:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [ 53.299062] [drm] nouveau :04:00.0: 2: 0x2261: type 0x61 idx 2 tag 0x08 [ 53.299069] [drm] nouveau :04:00.0: Parsing VBIOS init table 0 at offset 0xD21E [ 53.324438] [drm] nouveau :04:00.0: Parsing VBIOS init table 1 at offset 0xD633 [ 53.327051] [drm] nouveau :04:00.0: Parsing VBIOS init table 2 at offset 0xE624 [ 53.327058] [drm] nouveau :04:00.0: Parsing VBIOS init table 3 at offset 0xE76D [ 53.328136] [drm] nouveau :04:00.0: Parsing VBIOS init table 4 at offset 0xE9A9 [ 53.328140] [drm] nouveau :04:00.0: Parsing VBIOS init table at offset 0xEA0E [ 53.348146] [drm] nouveau :04:00.0: 0xEA0E: Condition still not met after 20ms, skipping following opcodes [ 53.366853] [drm] nouveau :04:00.0: 1 available performance level(s) [ 53.366858] [drm] nouveau :04:00.0: 3: core 500MHz shader 1250MHz memory 500MHz voltage 1100mV fanspeed 100% [ 53.366873] [drm] nouveau :04:00.0: c: core 500MHz shader 1250MHz memory 499MHz voltage 1100mV [ 53.368881] [TTM] Zone kernel: Available graphics memory: 1543414 kiB. [ 53.368884] [TTM] Initializing pool allocator. [ 53.368894] [drm] nouveau :04:00.0: Detected 768MiB VRAM [ 53.372117] [drm] nouveau :04:00.0: 512 MiB GART (aperture) [ 53.397649] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 53.397652] [drm] No driver support for vblank timestamp query. [ 53.656361] [drm] nouveau :04:00.0: allocated 1680x1050 fb: 0x31, bo 8800b1df9400 [ 53.656475] fbcon: nouveaufb (fb0) is primary device [ 53.656688] Console: switching to colour frame buffer device 210x65 [ 53.656694] fb0: nouveaufb frame buffer device [ 53.656696] drm: registered panic notifier [ 53.656703] [drm] Initialized nouveau 0.0.16 20090420 for :04:00.0 on minor 0 [ 56.018019] eth0: no IPv6 routers present [ 112.967128] 2:2:1: cannot get freq at ep 0x4 [ 113.975124] 2:3:1: cannot get freq at ep 0x83 [ 115.031128] 2:3:1: cannot get freq at ep 0x83 [ 116.041124] 2:2:1: cannot get freq at ep 0x4 [ 117.054141] 2:3:1: cannot get freq at ep 0x83 [ 123.675318] process `skype' is using obsolete setsockopt SO_BSDCOMPAT [ 243.059920] NVRM: The NVIDIA probe routine was not called for 1 device(s). [ 243.059923] NVRM: This can occur when a driver such as nouveau, rivafb, [ 243.059924] NVRM: nvidiafb, or rivatv was loaded and obtained ownership of [ 243.059925] NVRM: the NVIDIA device(s). [ 243.059927] NVRM: Try unloading the conflicting kernel module (and/or [ 243.059928] NVRM: reconfigure your kernel without the conflicting [ 243.059929] NVRM: driver(s)), then try loading the NVIDIA kernel module [ 243.059929] NVRM: again. [ 243.059931] NVRM: No NVIDIA graphics adapter probed! [ 566.999504] NVRM: The NVIDIA probe routine was not called for 1 device(s). [ 566.999507] NVRM: This can occur when a driver such as nouveau, rivafb, [ 566.999508] NVRM: nvidiafb, or rivatv was loaded and obtained ownership of [ 566.999509] NVRM: the NVIDIA device(s). [ 566.999511] NVRM: Try unloading the conflicting kernel module (and/or [ 566.999512] NVRM: reconfigure your kernel without the conflicting [ 566.999512] NVRM: driver(s)), then try loading the NVIDIA kernel module [ 566.999513] NVRM: again. [ 566.999515] NVRM: No NVIDIA graphics adapter probed! Thx, R.Fox
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
On 02/03/12 09:38, Robert Fox wrote: Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. +1 Recurrent pb for me as well. Did you try to add nokmsboot in the boot arguments? chris.
Re: [Mageia-dev] fatback - can we distribute it?
On 02/03/12 06:17, Johnny A. Solbu wrote: On Friday 02 March 2012 06:52, Charles A Edwards wrote: Did you look at COPYING? I did, yes. As a header above the GPLv2 license: And in the AUTHORS file it is written that the rest of the program is written by Nicholas Harbour of the DoD (Department of Defence) Computer Forensics Lab. E.G. the US Government. Meaning, it is copyrighted by the US government. But there is no copyright /protection/ on the software, because it is the US government which holds the copyrights. I tend to agree, there should be no restriction on distribution, only a possible question over it's use maybe in the USA. But that is down to users to decide, just as with tainted etc. I have corrected the GPL version - thanks - no idea how that happened ;) I will await more comments.
[Mageia-dev] Versions freeze
Hey! According to https://wiki.mageia.org/en/Mageia_2_development we are going to hit versions freeze pretty soon. Is it confirmed that it will be March 7th? In this case we have the last weekend before freeze. And weekend is for many packagers the only time to work on their packages. Such dates should be announced in advance. -- Sander
Re: [Mageia-dev] Versions freeze
On 02.03.2012 14:52, Sander Lepik wrote: Hey! According to https://wiki.mageia.org/en/Mageia_2_development we are going to hit versions freeze pretty soon. Is it confirmed that it will be March 7th? In this case we have the last weekend before freeze. And weekend is for many packagers the only time to work on their packages. Such dates should be announced in advance. -- Sander Is this hour 0:00 or 23:59 ? Paris time zone?
Re: [Mageia-dev] Versions freeze
Am 02.03.2012 15:03, schrieb Kamil Rytarowski: On 02.03.2012 14:52, Sander Lepik wrote: Hey! According to https://wiki.mageia.org/en/Mageia_2_development we are going to hit versions freeze pretty soon. Is it confirmed that it will be March 7th? In this case we have the last weekend before freeze. And weekend is for many packagers the only time to work on their packages. Such dates should be announced in advance. -- Sander Is this hour 0:00 or 23:59 ? Paris time zone? Last year it was at the end of the packager meeting, meaning something between 21.00 UTC and 21.30 UTC. And please people, it was announced as we did announce the whole development planing months ago, didn't we? Oliver
Re: [Mageia-dev] Versions freeze
02.03.2012 16:07, Oliver Burger kirjoitti: > Am 02.03.2012 15:03, schrieb Kamil Rytarowski: >> On 02.03.2012 14:52, Sander Lepik wrote: >>> Hey! >>> >>> According to https://wiki.mageia.org/en/Mageia_2_development we are >>> going to hit versions freeze pretty soon. Is it confirmed that it will >>> be March 7th? In this case we have the last weekend before freeze. And >>> weekend is for many packagers the only time to work on their packages. >>> >>> Such dates should be announced in advance. >>> -- >>> Sander >> Is this hour 0:00 or 23:59 ? Paris time zone? > Last year it was at the end of the packager meeting, meaning something > between 21.00 UTC and 21.30 UTC. > > And please people, it was announced as we did announce the whole > development planing months ago, didn't we? Yes, I think Sander just meant there should be a reminder (which he now did). -- Anssi Hannula
Re: [Mageia-dev] Versions freeze
On Fri, Mar 2, 2012 at 14:07, Oliver Burger wrote: > Am 02.03.2012 15:03, schrieb Kamil Rytarowski: > >> On 02.03.2012 14:52, Sander Lepik wrote: >>> >>> Hey! >>> >>> According to https://wiki.mageia.org/en/Mageia_2_development we are >>> going to hit versions freeze pretty soon. Is it confirmed that it will >>> be March 7th? In this case we have the last weekend before freeze. And >>> weekend is for many packagers the only time to work on their packages. >>> >>> Such dates should be announced in advance. >>> -- >>> Sander >> >> Is this hour 0:00 or 23:59 ? Paris time zone? > > Last year it was at the end of the packager meeting, meaning something > between 21.00 UTC and 21.30 UTC. > > And please people, it was announced as we did announce the whole development > planing months ago, didn't we? And I saw it reminded in several places recently (like in some mail before the beta)
Re: [Mageia-dev] executable libraries
02.03.2012 00:17, Maarten Vanraes kirjoitti: > Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: > [...] >>> does this mean debug info fails for these? >> >> I'm not immediately sure (I never remember how the debug/stripping stuff >> works exactly), but I think either a) debug symbols extraction and thus >> -debug packaging, b) stripping, or c) both will fail with non-executable >> shared libs. > > in that case i guess we would need a policy or bs check to make sure we don't > fail some libraries debug and strip > Possibly. Interestingly, Debian policy disallows executable permission on shared libs: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime "Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump." -- Anssi Hannula
Re: [Mageia-dev] Versions freeze
On Fri, Mar 2, 2012 at 14:21, Pascal Terjan wrote: > On Fri, Mar 2, 2012 at 14:07, Oliver Burger wrote: >> Am 02.03.2012 15:03, schrieb Kamil Rytarowski: >> >>> On 02.03.2012 14:52, Sander Lepik wrote: Hey! According to https://wiki.mageia.org/en/Mageia_2_development we are going to hit versions freeze pretty soon. Is it confirmed that it will be March 7th? In this case we have the last weekend before freeze. And weekend is for many packagers the only time to work on their packages. Such dates should be announced in advance. -- Sander >>> >>> Is this hour 0:00 or 23:59 ? Paris time zone? >> >> Last year it was at the end of the packager meeting, meaning something >> between 21.00 UTC and 21.30 UTC. >> >> And please people, it was announced as we did announce the whole development >> planing months ago, didn't we? > > And I saw it reminded in several places recently (like in some mail > before the beta) https://www.mageia.org/pipermail/mageia-dev/2012-February/011914.html
Re: [Mageia-dev] Versions freeze
2012/3/2 Oliver Burger : > Am 02.03.2012 15:03, schrieb Kamil Rytarowski: > >> On 02.03.2012 14:52, Sander Lepik wrote: >>> >>> Hey! >>> >>> According to https://wiki.mageia.org/en/Mageia_2_development we are >>> going to hit versions freeze pretty soon. Is it confirmed that it will >>> be March 7th? In this case we have the last weekend before freeze. And >>> weekend is for many packagers the only time to work on their packages. >>> >>> Such dates should be announced in advance. >>> -- >>> Sander >> >> Is this hour 0:00 or 23:59 ? Paris time zone? > > Last year it was at the end of the packager meeting, meaning something > between 21.00 UTC and 21.30 UTC. > > And please people, it was announced as we did announce the whole development > planing months ago, didn't we? > Back in my school days when we had to do a home work project of 1 month our teacher used to remind us the day before scheduled deadline - for people like me it meant to start working on the project! Some people may be like me... -- wobo
Re: [Mageia-dev] Versions freeze
On Friday 02 March 2012 15:31, Wolfgang Bornath wrote: > Back in my school days when we had to do a home work project of 1 > month our teacher used to remind us the day before scheduled deadline > - for people like me it meant to start working on the project! > > Some people may be like me... Maybe we should have a policy on when to remind developers on version freezes. Say, one or two weeks before the freeze, so they get a chance to submit final changes. Or do we have such a policy already? -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/2 EatDirt : > On 02/03/12 09:38, Robert Fox wrote: >> >> Since last Cauldron kernel update, I have two nvidia based system which >> now fallback to nouveau when starting X - stating nvidia cannot be >> loaded. >> > > +1 > Recurrent pb for me as well. Did you try to add > > nokmsboot > > in the boot arguments? Same pb here, xorg.conf was changed (display driver changed to "nouveau"). Re-changed the display driver to "nvidia" and added nokmsboot to the boot args, next boot same pb again. -- wobo
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
On Fri, 2012-03-02 at 16:44 +0100, Wolfgang Bornath wrote: > 2012/3/2 EatDirt : > > On 02/03/12 09:38, Robert Fox wrote: > >> > >> Since last Cauldron kernel update, I have two nvidia based system which > >> now fallback to nouveau when starting X - stating nvidia cannot be > >> loaded. > >> > > > > +1 > > Recurrent pb for me as well. Did you try to add > > > > nokmsboot > > > > in the boot arguments? > > Same pb here, xorg.conf was changed (display driver changed to "nouveau"). > Re-changed the display driver to "nvidia" and added nokmsboot to the > boot args, next boot same pb again. > I will file a bug report . . .
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
02.03.2012 18:18, Robert Fox skrev: > On Fri, 2012-03-02 at 16:44 +0100, Wolfgang Bornath wrote: >> 2012/3/2 EatDirt : >>> On 02/03/12 09:38, Robert Fox wrote: Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. >>> >>> +1 >>> Recurrent pb for me as well. Did you try to add >>> >>> nokmsboot >>> >>> in the boot arguments? >> >> Same pb here, xorg.conf was changed (display driver changed to "nouveau"). >> Re-changed the display driver to "nvidia" and added nokmsboot to the >> boot args, next boot same pb again. >> > > I will file a bug report . . . > No need, there is already a report... And I'm looking into it... -- Thomas
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
Le 02/03/2012 16:44, Wolfgang Bornath a écrit : > 2012/3/2 EatDirt : >> On 02/03/12 09:38, Robert Fox wrote: >>> Since last Cauldron kernel update, I have two nvidia based system which >>> now fallback to nouveau when starting X - stating nvidia cannot be >>> loaded. >>> >> +1 >> Recurrent pb for me as well. Did you try to add >> >> nokmsboot >> >> in the boot arguments? > Same pb here, xorg.conf was changed (display driver changed to "nouveau"). > Re-changed the display driver to "nvidia" and added nokmsboot to the > boot args, next boot same pb again. +1 Xavier >
[Mageia-dev] udisks not running?
In bug #4635 I described how wifi keeps connecting/disconnecting continuously - by dmesg I found out that it seems to be related to udisks (pls don't ask me how it may be related). Today I booted into that same Beta1 installation and wifi behaved correctly (coming up, staying up). A check with ping proved that internet was accessibly. Then I did a 'urpmi --auto-update' which failed with the message, that "service udisks (udisks-daemon) is not running or not ready". If my assumption in the first line of this mail is correct, then not having udisks running brings stable wifi connection but prevents me from using urpmi, udisks running lets me use urpmi (via cable connection) but not wifi. Sorry for all the assumptions - without more technical info I did not bring this to bugzilla. -- wobo
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
and I think both nvidia and fglrx tickets are the same problem Xavier Le 02/03/2012 17:27, Bertaux Xavier a écrit : > Le 02/03/2012 16:44, Wolfgang Bornath a écrit : >> 2012/3/2 EatDirt : >>> On 02/03/12 09:38, Robert Fox wrote: Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. >>> +1 >>> Recurrent pb for me as well. Did you try to add >>> >>> nokmsboot >>> >>> in the boot arguments? >> Same pb here, xorg.conf was changed (display driver changed to "nouveau"). >> Re-changed the display driver to "nvidia" and added nokmsboot to the >> boot args, next boot same pb again. > +1 > > Xavier
Re: [Mageia-dev] Versions freeze
Le vendredi 2 mars 2012 16:06:48, Johnny A. Solbu a écrit : > Maybe we should have a policy on when to remind developers on version > freezes. Say, one or two weeks before the freeze, so they get a chance to > submit final changes. > > Or do we have such a policy already? And then a policy on when to update the policy?
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
On 02/03/12 16:31, Bertaux Xavier wrote: and I think both nvidia and fglrx tickets are the same problem Xavier Le 02/03/2012 17:27, Bertaux Xavier a écrit : Le 02/03/2012 16:44, Wolfgang Bornath a écrit : 2012/3/2 EatDirt: On 02/03/12 09:38, Robert Fox wrote: Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. +1 Recurrent pb for me as well. Did you try to add nokmsboot in the boot arguments? Same pb here, xorg.conf was changed (display driver changed to "nouveau"). Re-changed the display driver to "nvidia" and added nokmsboot to the boot args, next boot same pb again. +1 Xavier IIANM this is now the default behavior when the x11-server version is updated to a version not supported by the current proprietary nvidia driver. It avoids a boot failure which would otherwise be the scenario. Barry
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/2 Barry Jackson : > On 02/03/12 16:31, Bertaux Xavier wrote: >> >> and I think both nvidia and fglrx tickets are the same problem >> >> Xavier >> >> Le 02/03/2012 17:27, Bertaux Xavier a écrit : >>> >>> Le 02/03/2012 16:44, Wolfgang Bornath a écrit : 2012/3/2 EatDirt: > > On 02/03/12 09:38, Robert Fox wrote: >> >> Since last Cauldron kernel update, I have two nvidia based system >> which >> now fallback to nouveau when starting X - stating nvidia cannot be >> loaded. >> > +1 > Recurrent pb for me as well. Did you try to add > > nokmsboot > > in the boot arguments? Same pb here, xorg.conf was changed (display driver changed to "nouveau"). Re-changed the display driver to "nvidia" and added nokmsboot to the boot args, next boot same pb again. >>> >>> +1 >>> >>> Xavier >> >> > IIANM this is now the default behavior when the x11-server version is > updated to a version not supported by the current proprietary nvidia driver. > It avoids a boot failure which would otherwise be the scenario. Reasonable behavior, so to avoid this the x11-server should always match the current proprietary driver. In other words: either one whould be fixed with coming updates. -- wobo
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/2 Wolfgang Bornath : > whould be fixed with coming updates. should be fixed Sorry. -- wobo
Re: [Mageia-dev] udisks not running?
2012/3/2 Wolfgang Bornath : > In bug #4635 I described how wifi keeps connecting/disconnecting > continuously - by dmesg I found out that it seems to be related to > udisks (pls don't ask me how it may be related). > > Today I booted into that same Beta1 installation and wifi behaved > correctly (coming up, staying up). A check with ping proved that > internet was accessibly. > > Then I did a 'urpmi --auto-update' which failed with the message, that > "service udisks (udisks-daemon) is not running or not ready". > > If my assumption in the first line of this mail is correct, then not > having udisks running brings stable wifi connection but prevents me > from using urpmi, udisks running lets me use urpmi (via cable > connection) but not wifi. > > Sorry for all the assumptions - without more technical info I did not > bring this to bugzilla. Sorry for this - it was an assumprion and a wrong one. I forgot to remove the cdrom media from urpmi's list, so urpmi wanted to read the cdrom but couldn't. Pls forget this dumb one -- wobo
Re: [Mageia-dev] Versions freeze
On Fri, Mar 02, 2012 at 04:20:53PM +0200, Anssi Hannula wrote: > Yes, I think Sander just meant there should be a reminder (which he now > did). GNOME has some really crappy schedule related scripts. One of them deals with sending reminder emails: http://git.gnome.org/browse/releng/tree/tools/schedule/ Everything in GNOME revolves around weeks, and the scripts assume that things always happen on a Mon. Still, could be useful. The reminders go to release-team, who then use it as a template to mail the developers (automatic mails are often ignored, we try and make things a bit more personal). Example reminder mail: https://mail.gnome.org/archives/release-team/2012-March/msg3.html -- Regards, Olav
Re: [Mageia-dev] rpm read locks issue.
01.03.2012 21:21, Colin Guthrie kirjoitti: > Hi, > > Recently (last couple days) I've been seeing this kind of error/debug > when running rpm manually from the command line: > > Freeing read locks for locker 0x809: 23048/140698330855168 > > It's generally repeated over and over. > > Anyone else see this? No, but I've just seen the below. "Muistin varaaminen ei onnistu" ~= "Unable to allocate memory" "Pakettitietokantaa ei voida avata" ~= "Unable to open rpmdb" > $ free > total used free sharedbuffers cached > Mem: 80388087899056 139752 0 373561002064 > -/+ buffers/cache:68596361179172 > Swap: 838860437314204657184 Should be enough, no? [... console scrollback was completely filled with these lines ...] virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Group avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Triggername avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Dirnames avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Installtid avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Sigmd5 avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Sha1header avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/fglrx-kernel-desktop-latest-8.930-1.mga2.nonfree.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/nvidia-current-kernel-3.2.9-desktop-1.mga2-290.10-15.mga2.nonfree.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/fglrx-control-center-8.930-2.mga2.nonfree.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/nvidia-current-kernel-desktop-latest-290.10-15.mga2.nonfree.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/x11-driver-video-fglrx-8.930-2.mga2.nonfree.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/nonfree/release/nvidia173-kernel-desktop-latest-173.14.31-15.mga2.nonfree.x86_64.rpm virhe: rpmdb: Lock table is out of available locker entries virhe: indeksin Packages avaus db4:llä ei onnistu - Muistin varaaminen ei onnistu (12) virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/tainted/release/vlc-plugin-libnotify-2.0.0-1.mga2.tainted.x86_64.rpm http://10.0.0.1/mirror/misc/mageia/cauldron/x86_64/media/tainted/release/vlc-2.0.0-1.mga2.tainted.x86_64.rpm virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe: Pakettitietokantaa /var/lib/rpm ei voida avata virhe: rpmdb: Lock table is out of available locker entries virhe:
Re: [Mageia-dev] rpm read locks issue.
02.03.2012 20:17, Anssi Hannula skrev: > 01.03.2012 21:21, Colin Guthrie kirjoitti: >> Hi, >> >> Recently (last couple days) I've been seeing this kind of error/debug >> when running rpm manually from the command line: >> >> Freeing read locks for locker 0x809: 23048/140698330855168 >> >> It's generally repeated over and over. >> >> Anyone else see this? > > No, but I've just seen the below. > > > "Muistin varaaminen ei onnistu" ~= "Unable to allocate memory" > "Pakettitietokantaa ei voida avata" ~= "Unable to open rpmdb" > >> $ free >> total used free sharedbuffers cached >> Mem: 80388087899056 139752 0 373561002064 >> -/+ buffers/cache:68596361179172 >> Swap: 838860437314204657184 > > Should be enough, no? > > [... console scrollback was completely filled with these lines ...] > virhe: rpmdb: Lock table is out of available locker entries > virhe: rpmdb: Lock table is out of available locker entries > virhe: rpmdb: Lock table is out of available locker entries > virhe: rpmdb: Lock table is out of available locker entries > virhe: rpmdb: Lock table is out of available locker entries > virhe: indeksin Group avaus db4:llä ei onnistu - Muistin varaaminen ei > onnistu (12) I wonder, could it be because of: tv 1:4.9.1.2-17.mga2: + Revision: 215717 - patch 5000: switch back to former, much smaller BDB memory pool size (RhBug:752897)
[Mageia-dev] qt3-devel
Hello! Is possible to ship qt3-devel with Mageia? Half of the the Polish community is demanding it, and because of lack of qt3-devel people can't switch from other Well Known Distros to Mageia.
Re: [Mageia-dev] executable libraries
Den 23:05 1. mars 2012 skrev Anssi Hannula følgende:
> 02.03.2012 00:03, Maarten Vanraes kirjoitti:
>> Op donderdag 01 maart 2012 22:54:59 schreef Anssi Hannula:
>>> 01.03.2012 23:36, Pascal Terjan kirjoitti:
I would say it doesn't matter and would not spend any time on it
>>>
>>> /usr/lib/rpm/mageia/find-debuginfo.sh:
>>>
>>> # Strip ELF binaries
>>> find "$RPM_BUILD_ROOT" ! -path "${debugdir}/*.debug" -type f \
>>> \( -perm -0100 -or -perm -0010 -or -perm -0001 \) \
>>> ^
>>> -print |
>>> file -N -f - | sed -n -e 's/^\(.*\):[ ]*.*ELF.*, not stripped/\1/p' |
>>> xargs --no-run-if-empty stat -c '%h %D_%i %n' |
>>> while read nlinks inum f; do
>>>
>>>
>>> Looks like debug packages and/or stripping won't work for non-executable
>>> shared libraries.
>>
>> hmm, there's a '!' there, so isn't it reverse then?
>
> It reverses the -path rule only.
>
>> but if this only works with executable libraries, (kind of weird imho), there
>> are at least 34 libraries on my system not marked as executable...
>>
>> does this mean debug info fails for these?
>
> I'm not immediately sure (I never remember how the debug/stripping stuff
> works exactly), but I think either a) debug symbols extraction and thus
> -debug packaging, b) stripping, or c) both will fail with non-executable
> shared libs.
If using the internal dependency generator, rpm won't generate dependencies for
the library either btw.
I've just implemented a rpmlint shared-lib-not-executable check :
http://svn.mandriva.com/viewvc/packages/cooker/rpmlint/current/SOURCES/rpmlint-1.4-shared-lib-not-executable.patch?view=log
--
Regards,
Per Øyvind
Re: [Mageia-dev] qt3-devel
02.03.2012 20:49, Kamil Rytarowski skrev: > Hello! > > Is possible to ship qt3-devel with Mageia? Half of the the Polish > community is demanding it, and because of lack of qt3-devel people can't > switch from other Well Known Distros to Mageia. > NO. As stated a million times before... qt3 is obsolete The only reason we have some qt3 runtime support is because of LSB Any stuff needed should be ported to qt4. -- Thomas
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
02.03.2012 10:38, Robert Fox kirjoitti: > Since last Cauldron kernel update, I have two nvidia based system which > now fallback to nouveau when starting X - stating nvidia cannot be > loaded. Fixed in harddrake-13.89.1. The previous versions do not handle XZ compressed proprietary driver modules properly. -- Anssi Hannula
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/2 Anssi Hannula : > 02.03.2012 10:38, Robert Fox kirjoitti: >> Since last Cauldron kernel update, I have two nvidia based system which >> now fallback to nouveau when starting X - stating nvidia cannot be >> loaded. > > Fixed in harddrake-13.89.1. The previous versions do not handle XZ > compressed proprietary driver modules properly. Which means, as soon as we get the new harddrake version in updates the issue is (should be) gone? -- wobo
Re: [Mageia-dev] Versions freeze
Besides... GNOME 3.4 is going to be released on March 28 - does that mean that we won't be able to ship it with Mageia 2? Mitya
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
02.03.2012 21:06, Wolfgang Bornath kirjoitti: > 2012/3/2 Anssi Hannula : >> 02.03.2012 10:38, Robert Fox kirjoitti: >>> Since last Cauldron kernel update, I have two nvidia based system which >>> now fallback to nouveau when starting X - stating nvidia cannot be >>> loaded. >> >> Fixed in harddrake-13.89.1. The previous versions do not handle XZ >> compressed proprietary driver modules properly. > > Which means, as soon as we get the new harddrake version in updates > the issue is (should be) gone? Yes, except that you have to switch back to the proprietary driver yourself with XFdrake. -- Anssi Hannula
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
02.03.2012 21:06, Wolfgang Bornath skrev: > 2012/3/2 Anssi Hannula : >> 02.03.2012 10:38, Robert Fox kirjoitti: >>> Since last Cauldron kernel update, I have two nvidia based system which >>> now fallback to nouveau when starting X - stating nvidia cannot be >>> loaded. >> >> Fixed in harddrake-13.89.1. The previous versions do not handle XZ >> compressed proprietary driver modules properly. > > Which means, as soon as we get the new harddrake version in updates > the issue is (should be) gone? > AFAIK you need to reconfigure your system to use the proprietary modules... -- Thomas
Re: [Mageia-dev] Versions freeze
02.03.2012 21:08, Dimitri Jakov skrev: > Besides... GNOME 3.4 is going to be released on March 28 - does that Yes we know... > mean that we won't be able to ship it with Mageia 2? > Nope, we have that as an exception to the freeze... (that's why we already run 3.3.x) we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 -- Thomas
Re: [Mageia-dev] Versions freeze
Am 02.03.2012 20:08, schrieb Dimitri Jakov: Besides... GNOME 3.4 is going to be released on March 28 - does that mean that we won't be able to ship it with Mageia 2? No, we explicitely pushed the final release date from April (as planned originally) to May, so we could have GNOME 3.4. In addition, there are always exceptions to every rule. Oliver
Re: [Mageia-dev] qt3-devel
On 02.03.2012 19:55, Thomas Backlund wrote: 02.03.2012 20:49, Kamil Rytarowski skrev: Hello! Is possible to ship qt3-devel with Mageia? Half of the the Polish community is demanding it, and because of lack of qt3-devel people can't switch from other Well Known Distros to Mageia. NO. As stated a million times before... qt3 is obsolete The only reason we have some qt3 runtime support is because of LSB Sad.. Any stuff needed should be ported to qt4. Actually this is not true. One of our Mageia users (who introduced Mageia on a dozen of machines) can't switch the next dozen because of lacking Rivendell Radio Broadcasting software ( http://www.rivendellaudio.org/index.shtml ), the other can't use his favourite qt3 apps, and a few others (including RH employee) are forced to use Fedora or KDE4. If the "obsolete" part is the only reason, then it's not too strong.. the package is maintained and there is *upstream*. As of the 3.5.13 release the Trinity project has taken over maintenance of Qt3. This means we are the new "upstream" location for up-to-date Qt3 source code. Since there have been no updates or stable releases from Nokia/Trolltech in many years and there are literally hundreds patches floating around, there was a significant need for a central location. By maintaining Qt3 it will allow us to continue to improve Qt3 outside the scope of Trinity. It will also provide a central location for Linux distributions to build packages from, and contributers to submit code to. For obvious reasons any Qt3 version released by this project is licensed under the GPL only; holders of Trolltech Qt licenses may not use these versions in their proprietary projects. http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13#Qt3 Trinity is currently packaged for Mandriva, OpenSUSE and available for the main distros. -- Thomas BTW. Your statement trigged outcry to start forking Mga :)
Re: [Mageia-dev] Versions freeze
Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: > 02.03.2012 21:08, Dimitri Jakov skrev: > > Besides... GNOME 3.4 is going to be released on March 28 - does that > > Yes we know... > > > mean that we won't be able to ship it with Mageia 2? > > Nope, we have that as an exception to the freeze... > (that's why we already run 3.3.x) > > we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the alpha version; beta will come quite soon, then the rc and finals follow pretty fast and these only contain bugfixes)
Re: [Mageia-dev] executable libraries
Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: > 02.03.2012 00:17, Maarten Vanraes kirjoitti: > > Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: > > [...] > > > >>> does this mean debug info fails for these? > >> > >> I'm not immediately sure (I never remember how the debug/stripping stuff > >> works exactly), but I think either a) debug symbols extraction and thus > >> -debug packaging, b) stripping, or c) both will fail with non-executable > >> shared libs. > > > > in that case i guess we would need a policy or bs check to make sure we > > don't fail some libraries debug and strip > > Possibly. > > Interestingly, Debian policy disallows executable permission on shared > libs: > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-ru > ntime > > "Shared libraries should not be installed executable, since the dynamic > linker does not require this and trying to execute a shared library > usually results in a core dump." which is sort of strange, since libc is actually executable by design. i see where they are coming from but i guess the first part of this is, why is there a find with executable restrictions for the code relating to stripped binaries and debug? is it because it's also used for real executables?
Re: [Mageia-dev] executable libraries
02.03.2012 21:57, Maarten Vanraes kirjoitti: > Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: >> 02.03.2012 00:17, Maarten Vanraes kirjoitti: >>> Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: >>> [...] >>> > does this mean debug info fails for these? I'm not immediately sure (I never remember how the debug/stripping stuff works exactly), but I think either a) debug symbols extraction and thus -debug packaging, b) stripping, or c) both will fail with non-executable shared libs. >>> >>> in that case i guess we would need a policy or bs check to make sure we >>> don't fail some libraries debug and strip >> >> Possibly. >> >> Interestingly, Debian policy disallows executable permission on shared >> libs: >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-ru >> ntime >> >> "Shared libraries should not be installed executable, since the dynamic >> linker does not require this and trying to execute a shared library >> usually results in a core dump." > > which is sort of strange, since libc is actually executable by design. > > i see where they are coming from > > but i guess the first part of this is, why is there a find with executable > restrictions for the code relating to stripped binaries and debug? > > is it because it's also used for real executables? I guess it is there just to speed up the process, otherwise it would have to run 'file' for every file in the package (and many packages have lots of files). -- Anssi Hannula
[Mageia-dev] Version freeze: 2012/03/07
What is a version freeze? Let's take an example: abiword-2.9.2-5.mga2.src.rpm 2.9.2 is version -5 is release Version freeze happens when no more version changes are allowed ( unless exception ). On Mageia 2 planning, it will happen on 7th of march. That's in 5 days, for people that do not look their calendar. Reasons for a freeze - We start the freeze in order to focus now on fixing pending bugs and stabilize general state of distribution in order to prepare the release of Mageia 2 on 3rd of may. The version freeze will be followed by a release freeze on 7th of april, and a freeze for release. The main goal is that bugs are caused by general changes, so to reduce bugs count, we should focus on just fixing them. It avoids edge effects because of last minute updates. What it changes in practice if a package is a different version from the previous one, youri ( our package upload tool ) will block the upload, unless you are in a special group ( see end of mail for the list ). So while non version change can be uploaded without problem ( so people can still add patches, etc ), version changes should be submitted by autorized person. How to ask for an exception - - First, try to build the rpm locally, test it, see if it installs and works fine. Check that the changes are minimal enough, on Provides and Requires tags, on file location, etc - Do not commit in the main branch for now ( you can use branch if you want ) - If unsure, please ask first for a freeze break on mageia-dev, with reasons. Please keep in mind that only bugfixes should be accepted. - Once the break is accepted, please commit and then ask for submitting Criteria for accepting updates -- Since we aim for stability, the criteria would be near the ones of updates. For example, if this is upgrade to a stable release when the rc was here ( like for gnome ), this should be ok. If that fixes an important bugfix, or a security issue this should be ok, provided there is not much breakage, and that it doesn't require to rebuild half of the distribution. Please explain clearly if there is an important bug, give url, etc. While we should have discussed this before a little bit more ( as said in meeting ), we will take the following list for now, with people who should be both avliable and experienced enough. List of authorized people to submit new version - misc - ennael - tmb - anssi - boklm http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-02-15-20.13.log.html#l-75 Cheers ennael & misc
Re: [Mageia-dev] executable libraries
Op vrijdag 02 maart 2012 21:29:05 schreef Anssi Hannula: > 02.03.2012 21:57, Maarten Vanraes kirjoitti: > > Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: > >> 02.03.2012 00:17, Maarten Vanraes kirjoitti: > >>> Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: > >>> [...] > >>> > > does this mean debug info fails for these? > > I'm not immediately sure (I never remember how the debug/stripping > stuff works exactly), but I think either a) debug symbols extraction > and thus -debug packaging, b) stripping, or c) both will fail with > non-executable shared libs. > >>> > >>> in that case i guess we would need a policy or bs check to make sure we > >>> don't fail some libraries debug and strip > >> > >> Possibly. > >> > >> Interestingly, Debian policy disallows executable permission on shared > >> libs: > >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs- > >> ru ntime > >> > >> "Shared libraries should not be installed executable, since the dynamic > >> linker does not require this and trying to execute a shared library > >> usually results in a core dump." > > > > which is sort of strange, since libc is actually executable by design. > > > > i see where they are coming from > > > > but i guess the first part of this is, why is there a find with > > executable restrictions for the code relating to stripped binaries and > > debug? > > > > is it because it's also used for real executables? > > I guess it is there just to speed up the process, otherwise it would > have to run 'file' for every file in the package (and many packages have > lots of files). still, it seems kind of weird, there are rpmlint checks for unstripped libraries, but i do have 34 libraries not marked as executable, while the stripping+ debug seems to target only executables? i wonder if we should make another check library unset as executable or even check what happened with these libraries not marked as executable?
Re: [Mageia-dev] executable libraries
Den 21:51 2. mars 2012 skrev Maarten Vanraes følgende: > Op vrijdag 02 maart 2012 21:29:05 schreef Anssi Hannula: >> 02.03.2012 21:57, Maarten Vanraes kirjoitti: >> > Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: >> >> 02.03.2012 00:17, Maarten Vanraes kirjoitti: >> >>> Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: >> >>> [...] >> >>> >> > does this mean debug info fails for these? >> >> I'm not immediately sure (I never remember how the debug/stripping >> stuff works exactly), but I think either a) debug symbols extraction >> and thus -debug packaging, b) stripping, or c) both will fail with >> non-executable shared libs. >> >>> >> >>> in that case i guess we would need a policy or bs check to make sure we >> >>> don't fail some libraries debug and strip >> >> >> >> Possibly. >> >> >> >> Interestingly, Debian policy disallows executable permission on shared >> >> libs: >> >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs- >> >> ru ntime >> >> >> >> "Shared libraries should not be installed executable, since the dynamic >> >> linker does not require this and trying to execute a shared library >> >> usually results in a core dump." >> > >> > which is sort of strange, since libc is actually executable by design. >> > >> > i see where they are coming from >> > >> > but i guess the first part of this is, why is there a find with >> > executable restrictions for the code relating to stripped binaries and >> > debug? >> > >> > is it because it's also used for real executables? >> >> I guess it is there just to speed up the process, otherwise it would >> have to run 'file' for every file in the package (and many packages have >> lots of files). > > still, it seems kind of weird, there are rpmlint checks for unstripped > libraries, but i do have 34 libraries not marked as executable, while the > stripping+ debug seems to target only executables? > > i wonder if we should make another check library unset as executable or even > check what happened with these libraries not marked as executable? I posted a link to a rpmlint patch implementing such a check to this thread two hours ago.. :p -- Regards, Per Øyvind
Re: [Mageia-dev] Version freeze: 2012/03/07
On Fri, Mar 02, 2012 at 09:39:59PM +0100, Anne nicolas wrote: > On Mageia 2 planning, it will happen on 7th of march. That's in 5 > days, for people that do not look their calendar. What exact time? I have a bot to automatically upload new ftp.gnome.org packages. I won't be around for a bit, so I need to teach it not to do anything after a certain date and time. For now, I'll teach it 2012-03-07 23:59 UTC. -- Regards, Olav
[Mageia-dev] Updating the lm_sensors package with a new "sensors-detect" script without a new lm_sensors version
Hello, Bug 4095 ( https://bugs.mageia.org/show_bug.cgi?id=4095) asks that we update the version of the "sensors-detect" script in the lm_sensors package. I have checked with the lm_sensors people (Jean Delvare) and this should be safe. They are working on a new version of the lm_sensors code, but were "delayed by a last minute bug (not in sensors-detect.)" I would normally prefer to wait for the new version, but Jean is busy with other issues at the moment and I know we're coming up on version freeze. Any thoughts? Thank you, Jeff
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/2 Thomas Backlund : > 02.03.2012 21:06, Wolfgang Bornath skrev: >> 2012/3/2 Anssi Hannula : >>> 02.03.2012 10:38, Robert Fox kirjoitti: Since last Cauldron kernel update, I have two nvidia based system which now fallback to nouveau when starting X - stating nvidia cannot be loaded. >>> >>> Fixed in harddrake-13.89.1. The previous versions do not handle XZ >>> compressed proprietary driver modules properly. >> >> Which means, as soon as we get the new harddrake version in updates >> the issue is (should be) gone? >> > > AFAIK you need to reconfigure your system to use the proprietary modules... Yes, that's to be expected anyway. Thx -- wobo
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
On 02/03/12 16:53, Wolfgang Bornath wrote: 2012/3/2 Wolfgang Bornath: whould be fixed with coming updates. should be fixed Sorry. Seems this was not the problem for you, but my FX series card has had no nvidia available since x11 was updated before Christmas. I think I need a new graphic card :(
Re: [Mageia-dev] NVidia fallback to Nouveau after latest Kernel updates
2012/3/3 Barry Jackson : > On 02/03/12 16:53, Wolfgang Bornath wrote: >> >> 2012/3/2 Wolfgang Bornath: >>> >>> whould be fixed with coming updates. >> >> >> should be fixed >> Sorry. >> > Seems this was not the problem for you, but my FX series card has had no > nvidia available since x11 was updated before Christmas. > I think I need a new graphic card :( Well, I don't know, but after last update tonight (mirror sync status 23:01 Paris time) the complete system which was working fine is now hosed anyway. 1. Nouveau driver still there (although I tried with XFdrake to get the nvidia re-installed), but that did not make my system unusable before 2. wifi connection totally lost (not possible to get a connection, whichever way I tried) 3. After system start the system now displays a message that it can not start Gnome 3 because my graphic system is possibly not able to run in normal Gnome 3, so it starts in a somehow "compatibility mode". /etc/X11/xorg.conf shows that the nouveau driver is working, which never had problems with Gnome 3. 4. I switched to tty2, and was presented with my keyboard now writing in black! Trying to write 'asdf' does not show any character but hitting enter returns 'asdf: command not found" Points 2, 3, 4 occurred at reboot after the update. I'll call it a day... -- wobo
[Mageia-dev] oce (opencascade) license issues
I have been working on oce, but need help deciding on where to put it and with what license. Oce is the OPENCascade Community Edition. Earlier versions are/were packaged by Mdv and Fedora, and recently Deb has included it. It seems from OPENCascade's own license literature to be LGPL-like with differences. (but rpmlint is not happy with that). Fedora consider it non-free, but since all the source is available and redistributable I don't know why, so ignore my comment on line 1 of the spec. There are links in the spec to license references. Barry
[Mageia-dev] Problems with systemd and /media.
Since systemd puts /media on tmpfs, specifically in /lib/systemd/system/media.mount, it's causing problems on upgrade of a system with fstab entries that have mount points in /media. https://bugs.mageia.org/show_bug.cgi?id=3550 At present, we have an errata entry regarding this https://wiki.mageia.org/en/Mageia_2_Errata#Base_system Currently the bug is assigned to the installer, with the idea that those fstab entries should be automatically removed. I've since been thinking, it might be better if either systemd, or dracut could parse /etc/fstab, and automatically recreate any mountpoints under /media. Opinions? Regards, Dave Hodgins
Re: [Mageia-dev] rpm read locks issue.
On Fri, Mar 2, 2012 at 7:45 PM, Thomas Backlund wrote: > 02.03.2012 20:17, Anssi Hannula skrev: >> 01.03.2012 21:21, Colin Guthrie kirjoitti: >>> Hi, >>> >>> Recently (last couple days) I've been seeing this kind of error/debug >>> when running rpm manually from the command line: >>> >>> Freeing read locks for locker 0x809: 23048/140698330855168 >>> >>> It's generally repeated over and over. >>> >>> Anyone else see this? >> >> No, but I've just seen the below. >> >> >> "Muistin varaaminen ei onnistu" ~= "Unable to allocate memory" >> "Pakettitietokantaa ei voida avata" ~= "Unable to open rpmdb" >> >>> $ free >>> total used free shared buffers cached >>> Mem: 8038808 7899056 139752 0 37356 1002064 >>> -/+ buffers/cache: 6859636 1179172 >>> Swap: 8388604 3731420 4657184 >> >> Should be enough, no? >> >> [... console scrollback was completely filled with these lines ...] >> virhe: rpmdb: Lock table is out of available locker entries >> virhe: rpmdb: Lock table is out of available locker entries >> virhe: rpmdb: Lock table is out of available locker entries >> virhe: rpmdb: Lock table is out of available locker entries >> virhe: rpmdb: Lock table is out of available locker entries >> virhe: indeksin Group avaus db4:llä ei onnistu - Muistin varaaminen ei >> onnistu (12) > > I wonder, could it be because of: > > tv 1:4.9.1.2-17.mga2: > + Revision: 215717 > - patch 5000: switch back to former, much smaller BDB memory pool size > (RhBug:752897) > i tried to remove it for testing purpose but we still have the issue. Thierry do you see what may be the culprit for this ?
Re: [Mageia-dev] Problems with systemd and /media.
On Fri, 2012-03-02 at 19:38 -0500, David W. Hodgins wrote: [...] > I've since been thinking, it might be better if either > systemd, or dracut could parse /etc/fstab, and automatically > recreate any mountpoints under /media. +1 Or at worst comment them out, but not remove them - most users will have clue how to create a uuid-based mount for example. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org
