Re: [gentoo-dev] Stability of /sys api
On 15/05/12 21:07, Arun Raghavan wrote: >> 1) Did you sleep through the /usr and initramfs flamewars? >> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > You seem to have missed the bit that this has nothing at all to do with > systemd. > I guess the systemd in the url might be have people consider it a sort of tell-tale. It could had been http://bluez.org/known_issue/separate-usr-problems Maybe. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] latest commits to dev-lang/go
On 05/15/2012 08:54 PM, William Hubbs wrote: > On Tue, May 15, 2012 at 10:15:28PM -0400, Matt Turner wrote: >> On Tue, May 15, 2012 at 9:07 PM, William Hubbs wrote: >>> On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote: All, I know my latest commits to dev-lang/go haven't updated the ChangeLog. I got into the habbit of using repoman commit -[Mm] to do that, but for some reason that stopped working. I will use echangelog from this ponit until I hear that repoman commit has been fixed. >>> >>> Thanks to Zac's quick assistance on irc, I found that this was an issue >>> with my repository, not repoman. >>> >>> William >>> >> >> So that others don't have the same problem -- what was the issue? > > it had to do with the timestamp of the ChangeLog file being wrong. I just > fixed it by doing > > cvs up ChangeLog > > while I was in the dev-lang/go directory in my cvs checkout of the > portage repo. > > William To explain in some more depth: If the ChangeLog timestamp differs from the one that's recorded in CVS/Entries, then repoman thinks you've modified the ChangeLog manually (or with echangelog), and it assumes that it shouldn't try to generate an entry. You can use repoman --echangelog=force to force repoman to generate a ChangeLog entry in this case. -- Thanks, Zac
Re: [gentoo-dev] Stability of /sys api
On 16 May 2012 05:21, Walter Dnes wrote: > On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote >> On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: >> > On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote >> > > What specifically is your objection to udev today? Is it doing things >> > > you don't like? Too big? Something else? >> > >> > Today, it requires an initramfs if /usr is not physically on /. That >> > is due in large part to the fact that it has been rolled into the >> > systemd tarball, and inherited some of systemd's code and limitations, >> > despite the fact that udev is still a separate binary. >> >> This is absolutely and definitely false. Where did you hear such >> nonsense ? > > 1) Did you sleep through the /usr and initramfs flamewars? > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken You seem to have missed the bit that this has nothing at all to do with systemd. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] latest commits to dev-lang/go
On Tue, May 15, 2012 at 10:15:28PM -0400, Matt Turner wrote: > On Tue, May 15, 2012 at 9:07 PM, William Hubbs wrote: > > On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote: > >> All, > >> > >> I know my latest commits to dev-lang/go haven't updated the ChangeLog. > >> > >> I got into the habbit of using repoman commit -[Mm] to do that, but for > >> some reason that stopped working. > >> > >> I will use echangelog from this ponit until I hear that repoman commit > >> has been fixed. > > > > Thanks to Zac's quick assistance on irc, I found that this was an issue > > with my repository, not repoman. > > > > William > > > > So that others don't have the same problem -- what was the issue? it had to do with the timestamp of the ChangeLog file being wrong. I just fixed it by doing cvs up ChangeLog while I was in the dev-lang/go directory in my cvs checkout of the portage repo. William pgplwFqGWTVA1.pgp Description: PGP signature
Re: [gentoo-dev] latest commits to dev-lang/go
On Tue, May 15, 2012 at 9:07 PM, William Hubbs wrote: > On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote: >> All, >> >> I know my latest commits to dev-lang/go haven't updated the ChangeLog. >> >> I got into the habbit of using repoman commit -[Mm] to do that, but for >> some reason that stopped working. >> >> I will use echangelog from this ponit until I hear that repoman commit >> has been fixed. > > Thanks to Zac's quick assistance on irc, I found that this was an issue > with my repository, not repoman. > > William > So that others don't have the same problem -- what was the issue?
[gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
Zac Medico posted on Tue, 15 May 2012 15:24:53 -0700 as excerpted: > Hi, > > In case you aren't familiar with it, here's the description from the > make.conf(5) man page: > > This causes the CONFIG_PROTECT behavior to be skipped for files that > have not been modified since they were installed. > > I think it would be a good idea to enable this by default, but I thought > I'd ask here first, in case anyone has objections. I've been using this for awhile now (tho IIRC it wasn't /that/ long ago that I saw it popup as new in the portage changelog =:^), and have been rather happy with it indeed! =:^) Among other things, I used to get prompted at I think every update for a whole slew of mc theme and hotkey file updates, when I never touched those files. Now I don't have to worry about 'em! =:^) Same thing (different files of course) with openrc, where I use the - live-git version and normally update once or twice a week to better track changes that sometimes negatively affect me. The best thing about it is not having to worry about missing an important change in a file I DO change, due to all the noise from files I don't touch. So yes, definitely ++ to making it the default, from here! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 07:51:03PM -0400, Walter Dnes wrote: > On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote > > On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: > > > On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote > > > > What specifically is your objection to udev today? Is it doing things > > > > you don't like? Too big? Something else? > > > > > > Today, it requires an initramfs if /usr is not physically on /. That > > > is due in large part to the fact that it has been rolled into the > > > systemd tarball, and inherited some of systemd's code and limitations, > > > despite the fact that udev is still a separate binary. > > > > This is absolutely and definitely false. Where did you hear such > > nonsense ? > > 1) Did you sleep through the /usr and initramfs flamewars? > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > 2) The udev sources have merged into the systemd tarball. See... > http://article.gmane.org/gmane.linux.hotplug.devel/17392 And note > the date is April 3rd, not April 1st. If they were really as worried > about compatability as they claim, you wouldn't need to use initramfs If you saw my last message on this subject, there is no need to use initramfs if you don't want to use it. See the sep-usr use flag on the ~arch version of busybox and the instructions you get when you turn that on. William pgpHlUscQM0LF.pgp Description: PGP signature
Re: [gentoo-dev] latest commits to dev-lang/go
On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote: > All, > > I know my latest commits to dev-lang/go haven't updated the ChangeLog. > > I got into the habbit of using repoman commit -[Mm] to do that, but for > some reason that stopped working. > > I will use echangelog from this ponit until I hear that repoman commit > has been fixed. Thanks to Zac's quick assistance on irc, I found that this was an issue with my repository, not repoman. William pgpMNBwFatqWE.pgp Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
I asked what I thought was a simple developer-type question. I don't want this to become a public flamewar. If anybody wants to discuss the issue with me further, please email directly to me and not the list. -- Walter Dnes
Re: [gentoo-dev] Stability of /sys api
On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote > On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: > > On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote > > > What specifically is your objection to udev today? Is it doing things > > > you don't like? Too big? Something else? > > > > Today, it requires an initramfs if /usr is not physically on /. That > > is due in large part to the fact that it has been rolled into the > > systemd tarball, and inherited some of systemd's code and limitations, > > despite the fact that udev is still a separate binary. > > This is absolutely and definitely false. Where did you hear such > nonsense ? 1) Did you sleep through the /usr and initramfs flamewars? http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken 2) The udev sources have merged into the systemd tarball. See... http://article.gmane.org/gmane.linux.hotplug.devel/17392 And note the date is April 3rd, not April 1st. If they were really as worried about compatability as they claim, you wouldn't need to use initramfs for udev with a separate /usr. -- Walter Dnes
[gentoo-dev] latest commits to dev-lang/go
All, I know my latest commits to dev-lang/go haven't updated the ChangeLog. I got into the habbit of using repoman commit -[Mm] to do that, but for some reason that stopped working. I will use echangelog from this ponit until I hear that repoman commit has been fixed. Thanks, William pgppTTapnoBvd.pgp Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: > On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote > > What specifically is your objection to udev today? Is it doing things > > you don't like? Too big? Something else? > > Today, it requires an initramfs if /usr is not physically on /. That > is due in large part to the fact that it has been rolled into the > systemd tarball, and inherited some of systemd's code and limitations, > despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote > On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: > > > > After some more Google-searching. it looks like the "official > > channels" way is via /etc/mdev.conf. Note that this is on a system with > > busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of > > "mdev rules" abilities, and most importantly, it can also call external > > executables (scripts/programs/whatever). On my mdev based machines... > > > > $ cat /proc/sys/kernel/hotplug > > /sbin/mdev > > Oh my, don't do that. Please. It will slow your machine down, and on > some systems, and devices, cause fork-bombs causing your box to come to > a crawl and potentially die. There's also ordering issues that the > called program needs to resolve to get things right that add lots of > logic and slowdowns at times. I really want to get rid of that entry > and option from the kernel entirely, but need to keep it due to legacy > systems and API issues. > > But really, don't do that, it's not a good idea at all. During bootup, mdev is invoked as "mdev -s", and in hotplug mode it's simply "mdev". In hotplug mode, mdev returns some environmental variables, specifically "ACTION", which are not returned by "mdev -s". Any scripts launched by mdev can easily figure out whether they've been called at bootup or in response to a hotplug event, and act accordingly. A Google search turns up many hits about instructions for automounting under mdev, and it appears relatively easy. > What specifically is your objection to udev today? Is it doing things > you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. That's today. How long before it becomes part of the systemd binary? -- Walter Dnes
[gentoo-dev] RFC: Enable FEATURES=config-protect-if-modified by default?
Hi, In case you aren't familiar with it, here's the description from the make.conf(5) man page: This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed. I think it would be a good idea to enable this by default, but I thought I'd ask here first, in case anyone has objections. -- Thanks, Zac
Re: [gentoo-dev] Stability of /sys api
On Wed, May 16, 2012 at 1:59 AM, Walter Dnes wrote: > On Tue, May 15, 2012 at 02:32:57AM -0400, Olivier Cr?te wrote >> On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: >> > I *DON'T WANT* "a serious framework", I want a lightweight device >> > manager... period... end of story. Stick with the unix principle of one >> > app doing one thing well. mdev is enough for the vast majority of people. >> >> For the people who don't want to easily use USB sticks or digital >> cameras or gsm dongles or really any modern hardware, I'm sure mdev is >> fine. A static /dev is even fine for you probably. > > Huh!?!?!? USB sticks work just fine, thank you, with mdev. I also > regularly backup my mdev-based machine via rsync to an external drive > via USB. And yes my camera does show up as a USB mass storage device. > Ditto for my HTC Desire. > "Those who don't understand UNI^H^H^Hsoftware are condemned to reinvent it, poorly." -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 02:32:57AM -0400, Olivier Cr?te wrote > On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: > > I *DON'T WANT* "a serious framework", I want a lightweight device > > manager... period... end of story. Stick with the unix principle of one > > app doing one thing well. mdev is enough for the vast majority of people. > > For the people who don't want to easily use USB sticks or digital > cameras or gsm dongles or really any modern hardware, I'm sure mdev is > fine. A static /dev is even fine for you probably. Huh!?!?!? USB sticks work just fine, thank you, with mdev. I also regularly backup my mdev-based machine via rsync to an external drive via USB. And yes my camera does show up as a USB mass storage device. Ditto for my HTC Desire. -- Walter Dnes
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 9:21 PM, Greg KH wrote: > I know of no such problem with udisks, have you reported them to the > upstream developers? As I said, it's just what I hear — perhaps it's the usual retrograde whining. I should probably just try udisks-glue, the only issue I see is that it depends on UDisks 1. > You can stall the whole hotplug path, causing issues and overruns. Note that the script I mentioned immediately forks, and only updates autofs mapping entries — it doesn't actually mount anything. > Right there, if that's all you need, and it's what most embedded systems > need, udev isn't even needed, just use devtmpfs and all is fine. Perhaps I wasn't expressing myself clearly — the point was to show that mdev is not needed. I used mdev in initramfs previously, but now rely on devtmpfs and the one-liner /sbin/hotplug for loading modules. Incidentally, turning off mdev resulted in Busybox executable size change of precisely 0, which I guess shows how much mdev actually does. > I really want to get rid of that entry and option from the kernel entirely Please don't — it's useful in Busybox-based initramfs. Dracut-like inclusion of udev and its dependencies DAG is usually unnecessary and an overkill. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 01:05:57AM -0400, Walter Dnes wrote:
> On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote
>
> > I don't know at what state udev was 3 or 4 years ago, but mdev can:
> >
> > 1. Populate /dev (now unnecessary due to devtmpfs).
> > 2. Handle ownership, permissions and symlinks to /dev nodes once they
> > appear, according to simple rules (can be probably done with inotify).
> > 3. Act as /sbin/hotplug, typically doing something equivalent to this
> > one-liner:
> >[ "${ACTION}" = add -a -n "${MODALIAS}" ] && modprobe -qb "${MODALIAS}"
>
> That's *EXACTLY* what I want and need. To borrow an old emacs joke,
> udev is a mediocre OS that lacks a lightweight device manager.
Huh? How is udev not "lightweight"? What does it have in it that makes
it "heavy"? I see lots of things in mdev that make it heavier and
slower than udev :)
> > I don't think mdev can do anything else. Building any serious
> > framework on top of mdev seems pointless to me, since it will probably
> > end up as a small subset of udev core reimplemented with scripts.
>
> I *DON'T WANT* "a serious framework", I want a lightweight device
> manager... period... end of story. Stick with the unix principle of one
> app doing one thing well. mdev is enough for the vast majority of people.
I don't see how udev isn't a "do one thing really well" program and pass
off to others, piping data to programs that can do other things to it if
wanted/needed. Can you explain how it violates this Unix maxium?
thanks,
greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: > On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote > > > So you need to implement stuff such that you are not dependant on the > > bus type. If you see a new disk, act on it, it's that simple. > > > > But note, please do not be automounting disks from uevents directly. > > After some more Google-searching. it looks like the "official > channels" way is via /etc/mdev.conf. Note that this is on a system with > busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of > "mdev rules" abilities, and most importantly, it can also call external > executables (scripts/programs/whatever). On my mdev based machines... > > $ cat /proc/sys/kernel/hotplug > /sbin/mdev Oh my, don't do that. Please. It will slow your machine down, and on some systems, and devices, cause fork-bombs causing your box to come to a crawl and potentially die. There's also ordering issues that the called program needs to resolve to get things right that add lots of logic and slowdowns at times. I really want to get rid of that entry and option from the kernel entirely, but need to keep it due to legacy systems and API issues. But really, don't do that, it's not a good idea at all. > > Actually with all the hype about mdev these days, why not just use a 3 > > year old version of udev (or maybe 4), that is probably what mdev is at > > as far as functionality goes. Why not just fork udev from then and go > > forward from that? What exactly are you not liking in udev that makes > > you want to get rid of it so badly? What is it doing that bothers > > people so much? > > Unfortunately, I am not a C programmer, so forking udev is only a > dream. As Maxim has pointed out, mdev does what most people need. As does udev. And udev is faster, and I'd bet, the same size. > The busybox people do the maintenance. Given their target audience > (embedded and lightweight systems), we can be certain that mdev won't > grow into a monstrosity. Even if I could do it, why reinvent the > wheel? We have a perfectly usable alternative right now in mdev. mdev is the reinvention, but hey, if you want it, that's fine. Embedded and "lightweight" systems don't even need mdev or udev, they just use the kernel-provided devtmpfs and all is good. But it's your choice, and that's great, but please be aware of the tradeoffs you are choosing, and again, my worry about using a /sbin/hotplug executable is real and should be resolved. What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? thanks, greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote:
> On Tue, May 15, 2012 at 4:23 AM, Greg KH wrote:
> > We learned that this is not a good idea at all, and should be left to
> > userspace helper applications
> > that listen for dbus messages.
>
> Could you perhaps expand a bit on those reasons? E.g., I had good
> experience with the following short script for coupling udev events
> with autofs:
> https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/ps-mount.
> Gentoo wiki has a similar tutorial as well. Granted, it is a
> single-user setup, but I can imagine it being extended to work with
> ConsoleKit. One obvious problem is mounting encrypted volumes. I
> thought about moving to e.g., udisks-glue (as a more standard
> solution), but from what I hear there are too many bugs with udisks at
> the moment.
I know of no such problem with udisks, have you reported them to the
upstream developers?
Yes, encrypted disks are one such problem, other bad things happen when
you hit a disk with bad sectors, and other "fun" things. You can stall
the whole hotplug path, causing issues and overruns.
For more details as to why this is a bad idea, see the linux-hotplug
mailing list archives, it was covered in detail there a few years ago.
> > Actually with all the hype about mdev these days, why not just use a 3
> > year old version of udev (or maybe 4), that is probably what mdev is at
> > as far as functionality goes.
>
> I don't know at what state udev was 3 or 4 years ago, but mdev can:
>
> 1. Populate /dev (now unnecessary due to devtmpfs).
udev can't even do that these days (see, udev got smaller), as devtmpfs
is what needs to do this.
Right there, if that's all you need, and it's what most embedded systems
need, udev isn't even needed, just use devtmpfs and all is fine.
> 2. Handle ownership, permissions and symlinks to /dev nodes once they
> appear, according to simple rules (can be probably done with inotify).
Careful about user ownerships of multi-user machines, that gets tricky.
> 3. Act as /sbin/hotplug, typically doing something equivalent to this
> one-liner:
>[ "${ACTION}" = add -a -n "${MODALIAS}" ] && modprobe -qb "${MODALIAS}"
Oh wow. Your /proc/sys/kernel/hotplug file should be set to "" if you
want any chance to have a fast boot process.
So, using mdev you slow your boot down, and slow down the response time
from uevents. I don't think that's what you really want for a
"lightweight" system :)
> I don't think mdev can do anything else. Building any serious
> framework on top of mdev seems pointless to me, since it will probably
> end up as a small subset of udev core reimplemented with scripts.
Again, what's wrong with just using udev for this as-is? What benifit
can mdev provide you over udev? Is it somehow smaller? How small?
It's obviously not faster due to the forking required from
/sbin/hotplug, so that can't be a good reason to prefer it.
thanks,
greg k-h
Re: [gentoo-dev] Packages up for grabs due gmsoft concentrating in hppa work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/15/2012 12:33 PM, Pacho Ramos wrote: > [..] net-misc/dibbler I will take it - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPsp59AAoJEPqDWhW0r/LC+jsP/0Cq9G42VbvaDfciKwvJCHGS Au38ig6YtvRJVyeX8F7LE/8JtzbfPUmu+8VY78W0NSisakzQ5xdWaRusIqQgl8LE O6VuiKpwneGVMf63SFUFipa1gNI5NtHKeIVrFflbVJG+LRuAeyWuMdR47nFNJpVI MJOvw6vhlD+ycs+Z5ZVNIPsFA7Rnsjg8ZP83ZVhHOdbAfkoBb0Y6fu0LkQt2pWmG OMgEPtB7oizsb0YId5//wpB3ixBd63dWbH9qT/OANj3iXm6PCC5AgnPCV6LyqX/D t8eR/4Q69irnKMnVghvxmvNtPBC/BW6UE88jfNlKDSgH44POYxVGxm1noEKKvVcv 2YleeSpJvxgSdtqqrBI68psVEYFzuQ2OrLyAS8hEJjZpO+HsXOE1JxFh0w9bm7XE am22WrD0hU00SEGwiKxIzqYM049ucsd5UGkPuBXzEn4odtgxsXbYfnuaWmKt1tsC zoEsDvvJgjav2ja+WKwQlvPyLMMKPcw6UWVKae76rS0jlNC64HrUZS6u/w13dLOR +nGklNCPYaGJya4eoyfu7pbmDNc+h+w3emiHik/UPK+683uR+7gP3VHKJ1M0aiZG R+8x3RAevo4wglP4feQNsNYnQm3aT5kT1w24ODBmR/pGFO3t2pYyaF9stA1+shsR BRIiWD97wwa9G4928X9n =SHUQ -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs due gmsoft concentrating in hppa work
Excerpts from Pacho Ramos's message of 2012-05-15 13:33:04 +0200: > net-misc/aiccu I can take this one. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] -Werror unwanted?
On Tuesday 15 May 2012 07:29:36 Tony "Chainsaw" Vroon wrote: > On 14/05/12 16:44, hasufell wrote: > > However, I don't see references to ebuild policy (in devmanual or > > howtos) how to handle Werror. > > As can be judged by the title of my patches on the subject, I consider > -Werror to be short-sighted at best and idiotic at worst. The next GCC > version, which will add *loads* of warnings to anything that compiled > cleanly before, is going to kill you. to clarify, having -Werror in upstream packages and getting enabled by default when doing development is not short-sighted or idiotic at all, but in fact makes a lot of sense for a lot of setups. shipping it enabled by default in a release could be considered those things though. a good compromise is what toolchain (and a few other) packages do: provide a configure flag like --disable-werror. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] -Werror unwanted?
On 15.05.2012 13:29, Tony "Chainsaw" Vroon wrote: > On 14/05/12 16:44, hasufell wrote: >> However, I don't see references to ebuild policy (in devmanual or >> howtos) how to handle Werror. > > As can be judged by the title of my patches on the subject, I consider > -Werror to be short-sighted at best and idiotic at worst. The next GCC > version, which will add *loads* of warnings to anything that compiled > cleanly before, is going to kill you. > Remove it from the build system. It is one of those patches that will > probably live downstream until the end of time, but that is acceptable. That's why IMHO the best way to fix those bugs is to make -Werror optional. It the hardest path, but both upstream and downstream should be satisfied. Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] FYI: The default in ~arch is UDisks2 instead of UDisks1 for gvfs, and thus, GNOME and Xfce (/media vs. /run/media/$user)
What has changed: make.defaults of targets/desktop/ is enabling USE="udisks upower" and NOT enabling USE="gdu" package.use of targets/desktop/ is enabling USE="gdu" for older gnome-base/gvfs versions (as in, stable versions) What it means: >=gnome-base/gvfs-1.12 will use UDisks2 instead of UDisks1 by default /run/media/$user is used instead of /media new kernel options are required to be enabled, and they will appear with CONFIG_CHECK when you emerge sys-fs/udisks:2 No need to reply to this, I just wanted to keep you informed. Not trying to spawn another debate or flamewar. - Samuli
[gentoo-dev] Packages up for grabs due gmsoft concentrating in hppa work
As talked with him via mail, he will concentrate in hppa work and won't have time to take care of the following packages: net-misc/dibbler net-misc/aiccu Feel free to get them Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] -Werror unwanted?
On 14/05/12 16:44, hasufell wrote: > However, I don't see references to ebuild policy (in devmanual or > howtos) how to handle Werror. As can be judged by the title of my patches on the subject, I consider -Werror to be short-sighted at best and idiotic at worst. The next GCC version, which will add *loads* of warnings to anything that compiled cleanly before, is going to kill you. Remove it from the build system. It is one of those patches that will probably live downstream until the end of time, but that is acceptable. Regards, Tony V.
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 1:32 AM, Olivier Crête wrote: > On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: >> I *DON'T WANT* "a serious framework", I want a lightweight device >> manager... period... end of story. Stick with the unix principle of one >> app doing one thing well. mdev is enough for the vast majority of people. > > For the people who don't want to easily use USB sticks or digital > cameras or gsm dongles or really any modern hardware, I'm sure mdev is > fine. A static /dev is even fine for you probably. I agree. And I don't believe people "who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware" qualify as "the vast majority of people". Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
