Re: [Mageia-dev] [bugs] [Bug 8230] Too short timeout
Le mercredi 28 novembre 2012 23:21:38, Frank Griffin a écrit : > On 11/28/2012 02:57 PM, Pierre Jarillon wrote: > > Le mercredi 28 novembre 2012 20:13:35, Frank Griffin a écrit : > >> Anyway, IIRC the help for Kill Timer is right on the screen. > > > > We are not testing the same distro :-( > > F1 Help is ont the bottom left and the content is not understandable for > > most > > > people even if they understand english: > Well, I'm not going to reboot just to test this, but when I said "on the > screen" I meant that literally. Isn't there a keymap guide at the > bottom of the boot choice screen that says Esc - Kill Timer, or some > such ? No F1 needed. There is nothing saying to press a key or F2 to select the language and nothing saying that install is starting in N seconds... -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org Microsoft est à l'informatique ce que McDonald est à la gastronomie
Re: [Mageia-dev] cauldron state, and dependencies handling
Le 28/11/12 21:17,Florent Monnier nous adresse ces quelques mots : > 2012/11/28, Thierry Vignaud : >> On 28 November 2012 21:35, Florent Monnier >> wrote: >>> but maybe rpm is my friend and I'm just not aware of it. >>> >>> Is there an rpm command line option to get the list of the dependents >>> of a given lib? >> >> eg for glibc-devel: >> urpmf --requires glibc-devel >> >> Now you may have to look for 'pkgconfig(foobar)' too. eg: >> urpmf --requires --literal 'pkgconfig(glibc)' > > > It seems it don't work for ocaml libs, > there's not xtmpl in the results: > > $ urpmf --requires ocaml-xmlm > ocaml-xmlm-devel:ocaml-xmlm[== 1.0.2-1.mga2] > ocaml-xmlm:ocaml > > $ urpmf --requires --literal 'pkgconfig(ocaml-xmlm)' > > >>> (Those in BuildRequire, not only Require) >> >> just add and enable source media prior to running above commands. > > could you give a wiki link that explains how to do this? > > with a search I found: > urpmi.update --no-ignore "Core Updates Testing" > but nothing with the name "Sources" in it. > >> But I think it's just better to look at what actually use those libs >> (if not statically linked), aka for LLVM: >> urpmf --requires libLLVM-3.1.so > > urpmf --requires /usr/lib/ocaml/xmlm/* > > no "xtmpl" in the answer too You need to define a Source media for the SRPMS, then urpmf --requires ocaml --media Source would give you all packages with ocaml as BuildRequires -- Malo
Re: [Mageia-dev] [bugs] [Bug 8230] Too short timeout
On 11/28/2012 02:57 PM, Pierre Jarillon wrote: Le mercredi 28 novembre 2012 20:13:35, Frank Griffin a écrit : Anyway, IIRC the help for Kill Timer is right on the screen. We are not testing the same distro :-( F1 Help is ont the bottom left and the content is not understandable for most people even if they understand english: Well, I'm not going to reboot just to test this, but when I said "on the screen" I meant that literally. Isn't there a keymap guide at the bottom of the boot choice screen that says Esc - Kill Timer, or some such ? No F1 needed.
Re: [Mageia-dev] NetworkManager vs initscripts
Colin Guthrie writes: > I thought the default had flipped to being "if the NM_CONTROLLED does > not exist, then assume it's true" before mga2 came out. > > I'm maybe mis-remembering tho'. Blino can you correct me?? It looks to be the case in network-functions from initscripts, but is this the case in NetworkManager ifcfg plugin? -- Olivier Blin - blino
Re: [Mageia-dev] cauldron state, and dependencies handling
2012/11/28, Thierry Vignaud : > On 28 November 2012 21:35, Florent Monnier > wrote: >> but maybe rpm is my friend and I'm just not aware of it. >> >> Is there an rpm command line option to get the list of the dependents >> of a given lib? > > eg for glibc-devel: > urpmf --requires glibc-devel > > Now you may have to look for 'pkgconfig(foobar)' too. eg: > urpmf --requires --literal 'pkgconfig(glibc)' It seems it don't work for ocaml libs, there's not xtmpl in the results: $ urpmf --requires ocaml-xmlm ocaml-xmlm-devel:ocaml-xmlm[== 1.0.2-1.mga2] ocaml-xmlm:ocaml $ urpmf --requires --literal 'pkgconfig(ocaml-xmlm)' >> (Those in BuildRequire, not only Require) > > just add and enable source media prior to running above commands. could you give a wiki link that explains how to do this? with a search I found: urpmi.update --no-ignore "Core Updates Testing" but nothing with the name "Sources" in it. > But I think it's just better to look at what actually use those libs > (if not statically linked), aka for LLVM: > urpmf --requires libLLVM-3.1.so urpmf --requires /usr/lib/ocaml/xmlm/* no "xtmpl" in the answer too --
Re: [Mageia-dev] cauldron state, and dependencies handling
On 28 November 2012 21:35, Florent Monnier wrote: > but maybe rpm is my friend and I'm just not aware of it. > > Is there an rpm command line option to get the list of the dependents > of a given lib? eg for glibc-devel: urpmf --requires glibc-devel Now you may have to look for 'pkgconfig(foobar)' too. eg: urpmf --requires --literal 'pkgconfig(glibc)' > (Those in BuildRequire, not only Require) just add and enable source media prior to running above commands. But I think it's just better to look at what actually use those libs (if not statically linked), aka for LLVM: urpmf --requires libLLVM-3.1.so
Re: [Mageia-dev] cauldron state, and dependencies handling
>> In case that's bad, I'm wondering how I should handle this. >> - I can just icrem the mkrel of all ocaml libs. >> (I can write the script to do this in 5 minutes.) >> > > That's normally what happends when deps are updated (for example several > libs has this effect) > > The dependent packages should be rebuilt as soon as possible to keep > the breakage minimal. It will then be easier for other needing to > use / rely on the packages [...] >> - I can create a dependency graph, so when I rebuilt xmlm 3 months >> ago, I can use the dependcy graph to know the exhaustive list of >> dependents that also need to be rebuild. >> (I can write the script to do this in maybe 1 evening) No, I mean there are 2 possible ways to do what you want me to do. 1) I could just send ALL the ocaml libs, when only some needs to be sent. 2) I could also only send those that need to 1) is not hard to do 2) is more difficult
Re: [Mageia-dev] cauldron state, and dependencies handling
Florent Monnier skrev 28.11.2012 21:59: So it should have been: - rebuild for new xmlm Yep. I do have a question related to this issue: Should ocaml libs in Cauldron be maintained usable? Yep. we want cauldron to stay in as good condition as possible, to catch bugs early... For example if I've rebuild xmlm 3 months ago, there is nothing to change in xtmpl, so currently I just wait before Mageia's release to rebuild all that needs to be. That means that during these 3 months, xtmpls didn't worked in Cauldron. Is that bad? Yes, thats bad. It should be as usable as possible all the time to catch bugs early. and we have a BS that is capable of handling the load = In case that's bad, I'm wondering how I should handle this. - I can just icrem the mkrel of all ocaml libs. (I can write the script to do this in 5 minutes.) That's normally what happends when deps are updated (for example several libs has this effect) The dependent packages should be rebuilt as soon as possible to keep the breakage minimal. It will then be easier for other needing to use / rely on the packages - I can create a dependency graph, so when I rebuilt xmlm 3 months ago, I can use the dependcy graph to know the exhaustive list of dependents that also need to be rebuild. (I can write the script to do this in maybe 1 evening) -- Thomas
Re: [Mageia-dev] cauldron state, and dependencies handling
2012/11/28, Thomas Backlund : > Florent Monnier skrev 28.11.2012 20:39: >> 2012/11/28, Thierry Vignaud : >>> On 28 November 2012 15:44, blue_prawn >>> wrote: blue_prawn 0.3-5.mga3: + Revision: 322631 - no change, only a rebuild >>> >>> Please tell why you rebuild >>> eg: "rebuild for new ocaml" or whatever instead of "no change..." >> >> malo (other ocaml packager) suggests me to put "rebuild for Beta 1" >> >> but this is the goal, not the origine, >> the reason is because a dependency was rebuild. >> in ocaml if a dependency is rebuild, all the dependents and >> sub-dependents have to be rebuild. >> >> So which log message would you prefer: >> >> - rebuild for Beta 1 > > this one: > >> - rebuild because dependency rebuilt > > as it's the real reason. > > or more like: > > - rebuild for new ocaml > > (or wichever package "triggered" the need for rebuild) So it should have been: - rebuild for new xmlm I do have a question related to this issue: Should ocaml libs in Cauldron be maintained usable? For example if I've rebuild xmlm 3 months ago, there is nothing to change in xtmpl, so currently I just wait before Mageia's release to rebuild all that needs to be. That means that during these 3 months, xtmpls didn't worked in Cauldron. Is that bad? = In case that's bad, I'm wondering how I should handle this. - I can just icrem the mkrel of all ocaml libs. (I can write the script to do this in 5 minutes.) - I can create a dependency graph, so when I rebuilt xmlm 3 months ago, I can use the dependcy graph to know the exhaustive list of dependents that also need to be rebuild. (I can write the script to do this in maybe 1 evening) -- Cheers
Re: [Mageia-dev] [bugs] [Bug 8230] Too short timeout
Le mercredi 28 novembre 2012 20:13:35, Frank Griffin a écrit : > On 11/28/2012 02:10 PM, Pierre Jarillon wrote: > > https://bugs.mageia.org/show_bug.cgi?id=8230 > Anyway, IIRC the help for Kill Timer is right on the screen. We are not testing the same distro :-( F1 Help is ont the bottom left and the content is not understandable for most people even if they understand english: * splash -- influence the behevior of the splash screen * apm -- toggle power management * acpi -- advanced configuration and power interface * idle -- control the ide subsystem -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org Microsoft est à l'informatique ce que McDonald est à la gastronomie
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release fluidsynth-1.1.5-3.mga3
On 28 November 2012 20:36, shikamaru wrote: > shikamaru 1.1.5-3.mga3: > + Revision: 322704 > - bump rel and fix RPM Group You don't have to "bump rel" since every one has to do so before uploading a package. "fix RPM Group" is enough
Re: [Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
On 28 November 2012 17:23, Colin Guthrie wrote: >> I have the same feeling with regardds to my computers. >> What I do in these situations is to install the debug packages, run the >> application in gdb, record the debug info, and then uninstall the debug >> packages. >> >> You don't have to keep the debug packages installed after you've collected >> the debug info. > > Longer term it would be nice to be able to have a service to upload the > core files and then generate the backtrace remotely. libreport and the associated packages do that... But that's less needed now that we have minidebug info. What's more, even without debug packages, gdb will got a useful backtrace
Re: [Mageia-dev] forkbomb protection
On Wed, 28 Nov 2012 13:00:05 -0500, Johnny A. Solbu wrote: On Wednesday 28. November 2012 17.53, David Walser wrote: Their pam package has a /etc/security/limits.d/90-nproc.conf file that has: *softnproc1024 As the last comment on the bug says, it's a bit confusing that it's in limits.d/ and not the limits.conf file itself, His point is that any limits set in «/etc/security/limits.d/» overrides the «limits.conf» file. and in fact I'm not sure what is responsible for processing limits.d/* as limits.conf says nothing about it (Fedora's is the exact same as ours). We should add some comments in «/etc/security/limits.conf» about it. Anyway, one way or another it would be nice to have this limit set by default on Mageia, IMHO. WDYT? I think we should have this. This is also being discussed in the usenet newsgroup alt.os.linux.mageia. I've confirmed the forkbomb will kill my Mageia 2 x86-64 system, with the default value for nprocs of 127910. Interestingly, it doesn't kill the system if I run the forkbomb right after rebooting, only if it's been in use for a while. This is a quad core with 16GB of ram. I've added a line to /etc/security/limits.conf on my system, with * hardnproc 1 The forkbomb no longer has impact, except for the need to kill all of the user's bash processes. # ps -A|wc -l 218 I think 1 should be more than adequate, yet low enough to stop the bomb from killing the system. Regards, Dave Hodgins
Re: [Mageia-dev] [bugs] [Bug 8230] Too short timeout
On 28 November 2012 19:13, Frank Griffin wrote: > On 11/28/2012 02:10 PM, Pierre Jarillon wrote: >> >> https://bugs.mageia.org/show_bug.cgi?id=8230 >> >> --- Comment #2 from Pierre Jarillon 2012-11-28 20:10:35 >> CET --- >> Yes, I know! But have you ever see some newbies? A newbie needs more than >> 10s >> to read and to understand the first screen. More, the choice of the >> language >> should be the first step. >> You are an advanced user, I am an advanced user too but the aim of Mageia >> is to >> be easy for new users. Never forget this. >> To set the timeout to 0 (infinite) is a very good solution for everybody. >> > Hardly, as it prevents unattended rebooting. :-) > > Anyway, IIRC the help for Kill Timer is right on the screen. Also in the rare case of a keyboard not working having a timeout is useful to allow the install system to proceed.
Re: [Mageia-dev] [bugs] [Bug 8230] Too short timeout
On 11/28/2012 02:10 PM, Pierre Jarillon wrote: https://bugs.mageia.org/show_bug.cgi?id=8230 --- Comment #2 from Pierre Jarillon 2012-11-28 20:10:35 CET --- Yes, I know! But have you ever see some newbies? A newbie needs more than 10s to read and to understand the first screen. More, the choice of the language should be the first step. You are an advanced user, I am an advanced user too but the aim of Mageia is to be easy for new users. Never forget this. To set the timeout to 0 (infinite) is a very good solution for everybody. Hardly, as it prevents unattended rebooting. :-) Anyway, IIRC the help for Kill Timer is right on the screen.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release ocaml-xtmpl-0.3-5.mga3
Florent Monnier skrev 28.11.2012 20:39: 2012/11/28, Thierry Vignaud : On 28 November 2012 15:44, blue_prawn wrote: blue_prawn 0.3-5.mga3: + Revision: 322631 - no change, only a rebuild Please tell why you rebuild eg: "rebuild for new ocaml" or whatever instead of "no change..." malo (other ocaml packager) suggests me to put "rebuild for Beta 1" but this is the goal, not the origine, the reason is because a dependency was rebuild. in ocaml if a dependency is rebuild, all the dependents and sub-dependents have to be rebuild. So which log message would you prefer: - rebuild for Beta 1 this one: - rebuild because dependency rebuilt as it's the real reason. or more like: - rebuild for new ocaml (or wichever package "triggered" the need for rebuild) -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release ocaml-xtmpl-0.3-5.mga3
2012/11/28, Thierry Vignaud : > On 28 November 2012 15:44, blue_prawn > wrote: >> blue_prawn 0.3-5.mga3: >> + Revision: 322631 >> - no change, only a rebuild > > Please tell why you rebuild > eg: "rebuild for new ocaml" or whatever instead of "no change..." malo (other ocaml packager) suggests me to put "rebuild for Beta 1" but this is the goal, not the origine, the reason is because a dependency was rebuild. in ocaml if a dependency is rebuild, all the dependents and sub-dependents have to be rebuild. So which log message would you prefer: - rebuild for Beta 1 - rebuild because dependency rebuilt ?
Re: [Mageia-dev] forkbomb protection
On Wednesday 28. November 2012 17.53, David Walser wrote: > Their pam package has a /etc/security/limits.d/90-nproc.conf file that has: > *softnproc1024 > > As the last comment on the bug says, it's a bit confusing that it's in > limits.d/ and not the limits.conf file itself, His point is that any limits set in «/etc/security/limits.d/» overrides the «limits.conf» file. > and in fact I'm not sure what is responsible for processing limits.d/* as > limits.conf says nothing about it (Fedora's is the exact same as ours). We should add some comments in «/etc/security/limits.conf» about it. > Anyway, one way or another it would be nice to have this limit set by default > on Mageia, IMHO. WDYT? I think we should have this. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
[Mageia-dev] forkbomb protection
I saw an article this morning on LinuxToday that reminded me of the famous shell forkbomb that most of you are probably aware of (I became aware of it several years ago from someone's e-mail signature on a mailing list): http://cyberarms.wordpress.com/2012/11/26/an-eleven-character-linux-denial-of-service-attack-how-to-defend-against-it/ This also reminded me that we don't have protection against this out of the box in Mageia. I checked on Fedora, and it turns out they do, as described here: https://bugzilla.redhat.com/show_bug.cgi?id=432903 Their pam package has a /etc/security/limits.d/90-nproc.conf file that has: # Default limit for number of user's processes to prevent # accidental fork bombs. # See rhbz #432903 for reasoning. * soft nproc 1024 As the last comment on the bug says, it's a bit confusing that it's in limits.d/ and not the limits.conf file itself, and in fact I'm not sure what is responsible for processing limits.d/* as limits.conf says nothing about it (Fedora's is the exact same as ours). Anyway, one way or another it would be nice to have this limit set by default on Mageia, IMHO. WDYT?
Re: [Mageia-dev] Utter frustration
On 11/26/2012 08:33 AM, Anne Wilson wrote: Perfect. The 'find' returns /usr/lib/libpowerdevilcore.so.0.1.0 /usr/lib/packagekitd /usr/lib/libpolkit-qt-core-1.so.1.103.0 /usr/bin/xdm /usr/bin/gnome-session I'd say these are the only candidates for a runtime error. Rerun the find on /usr/lib and /usr/bin with the full filename that was being looked for (org.freedesktop.ConsoleKit), or you could just use the strings command on each of these guys and pipe the result into grep to see who's looking for org.freedesktop.ConsoleKit.
Re: [Mageia-dev] NetworkManager vs initscripts
'Twas brillig, and Frank Griffin at 28/11/12 13:33 did gyre and gimble: > On 11/28/2012 08:23 AM, Johnny A. Solbu wrote: >> On Wednesday 28. November 2012 14.17, Frank Griffin wrote: >>> NM doesn't need ifcfg files >> But udev or some other proccess does. My point was to add the line to >> the ifcfg files in order to prevent the other proccesses from fighting >> with NM for controll over the network interfaces, when the interface >> is beeing setup with NM. >> >> > It's kind of backwards. NM expects to be in control of everything by > default rather than to coexist with initscripts. If it was, there'd be > no ifcfg files. If it sees an ifcfg file and it contains > NM_CONTROLLED=NO, then it leaves the interface alone. > > At the time udev runs, it doesn't have any way to know that an interface > is controlled by NM unless someone has created an ifcfg file with > NM_CONTROLLED=YES. With no file there, creating a file containing YES > would be useless because with no file there at all, NM will grab the > interface anyway. > > It's sort of a catch-22. udev is assuming that ifplugd is the default > because on MGA3 that is true. NM is assuming that *it* is the default > because that's how it was designed. I thought the default had flipped to being "if the NM_CONTROLLED does not exist, then assume it's true" before mga2 came out. I'm maybe mis-remembering tho'. Blino can you correct me?? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
'Twas brillig, and Johnny A. Solbu at 28/11/12 13:14 did gyre and gimble: > On Wednesday 28. November 2012 13.39, Robert Fox wrote: >> normally I try to avoid loading -debug packages on my work laptop > > I have the same feeling with regardds to my computers. > What I do in these situations is to install the debug packages, run the > application in gdb, record the debug info, and then uninstall the debug > packages. > > You don't have to keep the debug packages installed after you've collected > the debug info. Longer term it would be nice to be able to have a service to upload the core files and then generate the backtrace remotely. Easy enough for stable releases, but not so much for cauldron with it's rolling state. It should also become easier when we have the journal more integrated as it can store core files for us and be integrated nicely with automatic uploads etc. All pie in the sky for now tho'. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] NetworkManager vs initscripts
Le 28/11/2012 14:05, Johnny A. Solbu a écrit : On Wednesday 28. November 2012 12.44, Olivier Blin wrote: You can just set NM_CONTROLLED=yes in the generated ifcfg files. If the interface is configured using NetworkManager, why doesn't NM itself create the file, if it doesn't exist, and add the line, to prevent this? Perhaps a checkbox could be added to make it happen. Because the GUI tools and the installer always create this file. Except hackers, no one removes it, ans MCC adds NM_CONTROLLED=yes if you check the box in the GUI!
Re: [Mageia-dev] Utter frustration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/11/12 13:33, Anne Wilson wrote: > On 25/11/12 17:22, Liam R E Quin wrote: >> On Sun, 2012-11-25 at 14:01 +, Anne Wilson wrote: > Since there's no identification in the message, all I could suggest is a brute-force search of all files on the root or /usr partitons for the string "ConsoleKit", which appears in the error message. Then, identify the package which owns the file using rpmdrake. >>> Makes sense. The only problem is I don't know how to do that. >>> I tried to use a combination of cat and grep, but there is no >>> recursive flag, so that won't work. How would you do it? > >> (1) grep -l -r ConsoleKit . this is easiest; -r is "recursive" >> But it will cross file system boundaries, so if you do it from / >> it will go into /use and /media and anywhere else it can find! > >> (2) find / /usr -type f -xdev -print0 | xargs -0 grep -l >> ConsoleKit This is the usual "find" approach. -type f means only >> print names of files, not directories, symbolic links or device >> files... -xdev means don't stray into other filesystems like >> /home -print0 is the same as -print (prints each matching name) >> but prints the filenames with a NUL (character 0, hence the 0 in >> -print0) after each name, instead of putting each file on a >> separate line. This is needed because of filenames containing >> spaces or newlines. > >> xargs reads a list of files, one per line, or, with -0 (again the >> digit zero) separated by NUL bytes; it runs the command on each >> of the files > >> The -l option to grep says to print just the filename, needed in >> case there are binaries that contain the string. > > Perfect. The 'find' returns > > /usr/lib/libpowerdevilcore.so.0.1.0 /usr/lib/packagekitd > /usr/lib/libpolkit-qt-core-1.so.1.103.0 /usr/bin/xdm > /usr/bin/gnome-session /usr/share/doc/nautilus/NEWS > /usr/share/doc/dbus/NEWS > /usr/share/doc/networkmanager-applet/ChangeLog > /usr/share/doc/sane-backends-1.0.23/ChangeLog > /usr/share/doc/gnome-power-manager/NEWS > /usr/share/gtk-doc/html/gio/gdbus.html > /usr/share/gtk-doc/html/NetworkManager/ref-migrating.html > /root/.bash_history /var/lib/mlocate/mlocate.db > /var/lib/rpm/Providename /var/run.runmove~/ConsoleKit/database > /var/log/journal/2d49f2c66f3a45939d7973a4109a2e81/system@0004cf2cec30ebaa-f4cbcc04fef75c0b.journal~ > > /var/log/journal/2d49f2c66f3a45939d7973a4109a2e81/system@0004ce3e93292fec-435b91656aa64987.journal~ > /etc/security/msec/perm.netbook /etc/security/msec/perm.standard > /etc/security/msec/perm.webserver > /etc/security/msec/perm.fileserver /etc/security/msec/perm.secure > /usr/lib/libpowerdevilcore.so.0.1.0 /usr/lib/packagekitd > /usr/lib/libpolkit-qt-core-1.so.1.103.0 /usr/bin/xdm > /usr/bin/gnome-session /usr/share/doc/nautilus/NEWS > /usr/share/doc/dbus/NEWS > /usr/share/doc/networkmanager-applet/ChangeLog > /usr/share/doc/sane-backends-1.0.23/ChangeLog > /usr/share/doc/gnome-power-manager/NEWS > /usr/share/gtk-doc/html/gio/gdbus.html > /usr/share/gtk-doc/html/NetworkManager/ref-migrating.html > No-one able to help? Anne - -- Need KDE help? Try http://userbase.kde.org or http://forum.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC2GtYACgkQj93fyh4cnBeFvACeO3Mgb3rbxVxS18+qc2Nsroey /S4Ani6uASgxrqwV+TVzFDA/jsb8w09c =UcVv -END PGP SIGNATURE-
Re: [Mageia-dev] NetworkManager vs initscripts
On 11/28/2012 08:23 AM, Johnny A. Solbu wrote: On Wednesday 28. November 2012 14.17, Frank Griffin wrote: NM doesn't need ifcfg files But udev or some other proccess does. My point was to add the line to the ifcfg files in order to prevent the other proccesses from fighting with NM for controll over the network interfaces, when the interface is beeing setup with NM. It's kind of backwards. NM expects to be in control of everything by default rather than to coexist with initscripts. If it was, there'd be no ifcfg files. If it sees an ifcfg file and it contains NM_CONTROLLED=NO, then it leaves the interface alone. At the time udev runs, it doesn't have any way to know that an interface is controlled by NM unless someone has created an ifcfg file with NM_CONTROLLED=YES. With no file there, creating a file containing YES would be useless because with no file there at all, NM will grab the interface anyway. It's sort of a catch-22. udev is assuming that ifplugd is the default because on MGA3 that is true. NM is assuming that *it* is the default because that's how it was designed.
Re: [Mageia-dev] NetworkManager vs initscripts
On Wednesday 28. November 2012 14.17, Frank Griffin wrote: > NM doesn't need ifcfg files But udev or some other proccess does. My point was to add the line to the ifcfg files in order to prevent the other proccesses from fighting with NM for controll over the network interfaces, when the interface is beeing setup with NM. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] NetworkManager vs initscripts
On 11/28/2012 08:05 AM, Johnny A. Solbu wrote: If the interface is configured using NetworkManager, why doesn't NM itself create the file, if it doesn't exist, and add the line, to prevent this? Perhaps a checkbox could be added to make it happen. Just thinking out loud. NM doesn't need ifcfg files, and without the file being there, udev has no way of knowing that NM is controlling the interface.
Re: [Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
On Wednesday 28. November 2012 13.39, Robert Fox wrote: > normally I try to avoid loading -debug packages on my work laptop I have the same feeling with regardds to my computers. What I do in these situations is to install the debug packages, run the application in gdb, record the debug info, and then uninstall the debug packages. You don't have to keep the debug packages installed after you've collected the debug info. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] NetworkManager vs initscripts
On Wednesday 28. November 2012 12.44, Olivier Blin wrote: > You can just set NM_CONTROLLED=yes in the generated ifcfg files. If the interface is configured using NetworkManager, why doesn't NM itself create the file, if it doesn't exist, and add the line, to prevent this? Perhaps a checkbox could be added to make it happen. Just thinking out loud. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
On Wed, 2012-11-28 at 12:31 +, Pascal Terjan wrote: > On Wed, Nov 28, 2012 at 12:21 PM, Robert Fox wrote: > > > > Nov 28 13:17:33 ThinkFox kernel: evolution[11598]: segfault at 74 ip > > 7f81c6342533 sp 7fff9be95c08 error 4 in > > libwebkitgtk-3.0.so.0.17.4[7f81c5c7c000+17cd000] > > Nov 28 13:17:53 ThinkFox kernel: traps: evolution[11958] general > > protection ip:7fb7414405a1 sp:7fffde035338 error:0 in > > libwebkitgtk-3.0.so.0.17.4[7fb740d7a000+17cd000] > > > > Is this an Evolution issue or libwebkitgtk-3.0.so.0.17.4 issue? > > > probably libwebkitgtk unless evolution calls it with strange parameters > > > Should i file a bug? > > > Yes, and please: > - Install webkit-debug and evolution-debug from Debug media > - Run evolution inside gdb: > * run "gdb evolution" in a terminal > * type "run" and enter > * after the crash type "set logging on" to enable logging to file and > then "thread apply all bt full" > - Attach gdb.txt to the bug report > > Thanks I will see what I can do - I am a bit pressed for time now with a new project underway . . . and normally I try to avoid loading -debug packages on my work laptop . . . Cheers, R.Fox
Re: [Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
On Wed, Nov 28, 2012 at 12:21 PM, Robert Fox wrote: > > Nov 28 13:17:33 ThinkFox kernel: evolution[11598]: segfault at 74 ip > 7f81c6342533 sp 7fff9be95c08 error 4 in > libwebkitgtk-3.0.so.0.17.4[7f81c5c7c000+17cd000] > Nov 28 13:17:53 ThinkFox kernel: traps: evolution[11958] general > protection ip:7fb7414405a1 sp:7fffde035338 error:0 in > libwebkitgtk-3.0.so.0.17.4[7fb740d7a000+17cd000] > > Is this an Evolution issue or libwebkitgtk-3.0.so.0.17.4 issue? probably libwebkitgtk unless evolution calls it with strange parameters > Should i file a bug? Yes, and please: - Install webkit-debug and evolution-debug from Debug media - Run evolution inside gdb: * run "gdb evolution" in a terminal * type "run" and enter * after the crash type "set logging on" to enable logging to file and then "thread apply all bt full" - Attach gdb.txt to the bug report Thanks
[Mageia-dev] Evolution segfaults when trying to confirm a calendar invite
Nov 28 13:17:33 ThinkFox kernel: evolution[11598]: segfault at 74 ip 7f81c6342533 sp 7fff9be95c08 error 4 in libwebkitgtk-3.0.so.0.17.4[7f81c5c7c000+17cd000] Nov 28 13:17:53 ThinkFox kernel: traps: evolution[11958] general protection ip:7fb7414405a1 sp:7fffde035338 error:0 in libwebkitgtk-3.0.so.0.17.4[7fb740d7a000+17cd000] Is this an Evolution issue or libwebkitgtk-3.0.so.0.17.4 issue? Should i file a bug? Thx, R.Fox
Re: [Mageia-dev] NetworkManager vs initscripts
JA Magallón writes: > Network starts and stops ok, but on reboot, some process inists on creating > a ifcfg-eth0 file, with this setup: > > DEVICE=eth0 > BOOTPROTO=dhcp > ONBOOT=yes > > which breaks networking on systems that have a fixed IP, and works by chance > if you use DHCP. > > Who creates that ? This is created by udev rules. > How can I kill it ? You can just set NM_CONTROLLED=yes in the generated ifcfg files. -- Olivier Blin - blino
