Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger vap...@gentoo.org wrote: On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote: On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: '$(use_enable static-libs static)' themselves. While at it, it may be better to just drop the flag if no other package relies on it and no user has ever requested the static build of that package. I don't see any harm with including IUSE=static-libs for every package that has working/usable static libraries[1]. Why wait for users to request it on bugzilla when it's a near-zero-cost and zero-maintenance to add it to ebuilds? i missed this sentence from Michał's e-mail. unconditionally not building static libraries is against policy. if you install shared libs that get linked against, then you must provide static libraries unconditionally as well or support IUSE=static-libs. maintainers do not get to choose no one has asked for it and no one in the tree is using it thus my ebuild isnt going to. -mike Where is that policy? AFAIK the policy was to 'follow upstream' which usually means 'shared only'. I really don't see a reason to build static libtorrent as upstream even doesn't support static linking. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] euscan proof of concept (like debian's uscan)
On Mon, Sep 19, 2011 at 00:27, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Okay, I think this is pretty cool and we should find it a new home in the Gentoo infrastructure. I was thinking about http://qa-reports.gentoo.org/ with the repo at http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=summary I can act as a proxy committer and reviewer for that code. Could you break it up into some smaller parts (preferably backend first) and send to me for review (if you're interested)? How long does it take to generate the reports? +1 I think it would be good to run this on Gentoo infra, and I wouldn't mind helping out. Bikeshedding: not sure reports is the best name for this, as reports implies something more static? Also not sure how much it has to do with QA. How much of it constitutes the backend, in your opinion? It seems there are two parts, right now: 1. euscan script, to find new versions for a single package 2. the django www app, including storage for the version data IMO it would be nice to have a somewhat generic REST-style service exposing the data, and build a simple UI on top of that. In particular, I have different ideas about what the UI should look like, so it would be nice if different people could experiment (and/or integrate in other services like znurt.org). Cheers, Dirkjan
Re: [gentoo-dev] udev and /usr
On 09/15/2011 10:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. What is systemd again? Yes, some of us live in a tiny box filled with non-x86 hardware, and don't always get out to see the Daystar. Is it an init replacement? If sowhy? Or to quote an Admiral from Hunt for the Red October: Admiral Josh Painter: This business will get out of control. It will get out of control and we'll be lucky to live through it. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev and /usr
The 18/09/11, Duncan wrote: I don't see any added benefit from using DBUS on my servers. Insterstingly, Duncan just answered your question... Interesting question. I hadn't seen the suggestion until this thread, either, and it bothered me too. From here: With a moment's thought, I decided I could probably return to a semi- static dev setup reasonably easily. I'd potentially turn on the early-dev option in the kernel that I still have off, ATM, which presumably would mount a tmpfs on dev and populate it with the earliest devices. After that, if necessary, I'd copy the existing udev-created nodes out to a persistent state dir, and copy them back in with a little init-time script of my own. As long as the device ordering remains stable, this could include by-label, etc, symlinks, or I could simply kill the by- label, by-uid stuff in fstab, and go back to traditional devices there, too. Either that, or simply go back to a static /dev entirely. People with dynamic ordered devices may have to devise their own scripts, tho, or perhaps more likely, fork off udev from the pre-union state. ...to here. But it's also possible that's far enough in the future that we can't really answer the question now, since technology will have changed enough to make an answer now look senseless, then. Consider trying to answer the question in terms of the kernel devfs back before udev. The tech simply changed and those answers wouldn't really work, today. Upstream changes the init process is done. So, you're free to either: stick to upstream (with best long term support); or fork off upstream (requires knowledges, manpower and time); or go back to 1960 with a full/partial static /dev (asking to manually maintain the crap). See the benenfit, now? -- Nicolas Sebrecht
Re: [gentoo-dev] udev and /usr
On 09/18/2011 13:26, Nirbheek Chauhan wrote:
I don't see how this is relevant to the problem of udev and /usr at
all. Unless you want to go back to the days of devfs and lots of
manual configuration. :)
Me either (somewhat). But I do see is this: If udev is going to make it a
requirement that one or more paritions be available at udevd start time,
then maybe going back to devfs might not be such a bad idea after all.
I use plain vanilla setups on almost any Linux box I build. For x86, LILO
(yes, that thing), a simple kernel, most hardware built in, some extraneous
stuff built as modules. sysvinit for the init package, /{usr,home,var,tmp}
on separate partitions, no X11, no gnome, no KDE, no Xfce, no fluxbox, no
IRIS Indigo, no aewm++, no CDE, no DBUS, no audio support (the machine
doesn't even have an audio card), headless (except with it messes up, which
is very rare), etc. I.e., I run my box like a server.
My MIPS systems (the working ones, anyways) are even more vanilla. I
netboot each of them off my x86 box versus using a bootloader, they have
what amounts to a minimal Gentoo install, system + plus other utilities,
definitely no X11, etc.
These setups are pretty much plain vanilla Linux/UNIX setups, and it's what
has worked for years, so I don't see a need to change it with a permanence.
If other distros want to create alternatives, that is fine. But *I* should
retain the choice to use or not to use those alternatives. That means, udev
needs to be configurable enough to allow me to make it _not_ require /usr
being available. Let the default be the other way -- that's fine.
But if udev upstream is taking *away* choice, and making /usr mandatory
(especially if it's because some other distro has this offbeat, utopian,
überDesktop concept), then that's a bug and someone needs to write a patch
and send it upstream.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 03:59:43 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/15/2011 10:33, Joost Roeleveld wrote: Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. What is systemd again? Yes, some of us live in a tiny box filled with non-x86 hardware, and don't always get out to see the Daystar. Is it an init replacement? If sowhy? Because noone actually used init, rather forked few processes out of it and let it rot. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 1:15 AM, Joshua Kinard ku...@gentoo.org wrote:
On 09/18/2011 13:26, Nirbheek Chauhan wrote:
I don't see how this is relevant to the problem of udev and /usr at
all. Unless you want to go back to the days of devfs and lots of
manual configuration. :)
Me either (somewhat). But I do see is this: If udev is going to make it a
requirement that one or more paritions be available at udevd start time,
then maybe going back to devfs might not be such a bad idea after all.
I use plain vanilla setups on almost any Linux box I build. For x86, LILO
(yes, that thing), a simple kernel, most hardware built in, some extraneous
stuff built as modules. sysvinit for the init package, /{usr,home,var,tmp}
on separate partitions, no X11, no gnome, no KDE, no Xfce, no fluxbox, no
IRIS Indigo, no aewm++, no CDE, no DBUS, no audio support (the machine
doesn't even have an audio card), headless (except with it messes up, which
is very rare), etc. I.e., I run my box like a server.
My MIPS systems (the working ones, anyways) are even more vanilla. I
netboot each of them off my x86 box versus using a bootloader, they have
what amounts to a minimal Gentoo install, system + plus other utilities,
definitely no X11, etc.
These setups are pretty much plain vanilla Linux/UNIX setups, and it's what
has worked for years, so I don't see a need to change it with a permanence.
If other distros want to create alternatives, that is fine. But *I* should
retain the choice to use or not to use those alternatives. That means, udev
needs to be configurable enough to allow me to make it _not_ require /usr
being available. Let the default be the other way -- that's fine.
But if udev upstream is taking *away* choice, and making /usr mandatory
(especially if it's because some other distro has this offbeat, utopian,
überDesktop concept), then that's a bug and someone needs to write a patch
and send it upstream.
I think the list you want is
linux-hotplug-de...@lists.sourceforge.net; the gentoo-dev list is not
for udev development. If 'someone' needs to write a patch then I
assume you will volunteer?
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible
in-between.
--Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: udev and /usr
On 09/16/2011 14:06, Duncan wrote: Careful with the extreme. As you no doubt realize by now, the udev folks apparently consider anyone wanting a separate /usr but not an initr* extreme. That'd certainly apply double if said admin (since no simple user cares about such stuff, in this view) had /usr on lvm. I'd say the udev folks need their coffee/tea checked. If this logic stems from some requirement for a window manager/desktop environment on some other distro, then we need to make sure that becomes a configurable item in Gento or not support that package. This is the exact setup I use, and it's worked great since 2003. No, it's not the setup for everyone, so I don't think it should be mandatory for everyone, either. I expect the same for other approaches to have a use for some segment of users, but not to code it in as a hard-set default. Gentoo's about choice. Why else do we have more USE flags than the entirety of the IPv6 address space? (okay, I'm stretching that last a sentence a fair bit ...) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 04:15:02 -0400 Joshua Kinard ku...@gentoo.org wrote: But if udev upstream is taking *away* choice, and making /usr mandatory (especially if it's because some other distro has this offbeat, utopian, überDesktop concept), then that's a bug and someone needs to write a patch and send it upstream. Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] euscan proof of concept (like debian's uscan)
On Mon, Sep 19, 2011 at 9:35 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Mon, Sep 19, 2011 at 00:27, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
Okay, I think this is pretty cool and we should find it a new home in
the Gentoo infrastructure.
I was thinking about http://qa-reports.gentoo.org/ with the repo at
http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=summary
I can act as a proxy committer and reviewer for that code. Could you
break it up into some smaller parts (preferably backend first) and send
to me for review (if you're interested)?
How long does it take to generate the reports?
+1 I think it would be good to run this on Gentoo infra, and I
wouldn't mind helping out.
Bikeshedding: not sure reports is the best name for this, as reports
implies something more static?
Here is how it works, each week I launch this script on lt server.
I've got ~30 trees installed with layman. The server is an AMD X2
4600+ with 4GB of RAM and two 80GB HD in raid1 using ext4. My network
bandwidth is 20Mbps down 1Mbps up.
#!/bin/sh
## Setup some vars to use local portage tree
export PATH=${HOME}/euscan/bin:${PATH}
export PYTHONPATH=${HOME}/euscan/pym:${PYTHONPATH}
export PORTAGE_CONFIGROOT=${HOME}/local
export ROOT=${HOME}/local
export EIX_CACHEFILE=${HOME}/local/var/cache/eix
## Go to euscanwww dir
cd ${HOME}/euscan/euscanwww/
## Update local trees
## Bottleneck: disk and network bandwidth
## Time: less than 30mn
emerge --sync --root=${ROOT} --config-root=${PORTAGE_CONFIGROOT}
ROOT=/ layman -S --config=${ROOT}/etc/layman/layman.cfg
## Also update eix database, because we use eix internaly
## Bottleneck: disk and cpu
##Time: 30mn ~ 1h
eix-update
## Scan portage (packages, versions)
## Bottleneck: disk and cpu
## Time: 15mn
## Note: this script uses eix to get a list of packages and versions
python manage.py scan-portage --all --purge-versions --purge-packages
## Scan metadata (herds, maintainers, homepages, ...)
## Bottleneck: disk
## Time: 1h ~ 1h30
## Note: this script uses gentoolkit to fetch metadata
python manage.py scan-metadata --all --progress
## Scan uptsream packages
## Bottleneck: disk, network bandwidth and latency, cpu
## Time: up to 6h
## Note: euscan is called on each package. euscan has a slow startup
caused by gentoolkit/portage.
## gparallel is used here to limit the load caused by euscan,
and to launch up to 16 euscan instances at a time on this machine
## this part is the longest, but scale very well
eix --only-names -x | gparallel --load 4 --jobs 800% euscan
${HOME}/logs/euscan-upstream.log
python manage.py scan-upstream --feed --purge-versions
${HOME}/logs/euscan-upstream.log
## Update counters (6)
## Time: some minutes
## Bottleneck: cpu
## Note: this script could probably be implemented faster using raw SQL queries
python manage.py update-counters
Also not sure how much it has to do
with QA.
How much of it constitutes the backend, in your opinion? It seems
there are two parts, right now:
1. euscan script, to find new versions for a single package
2. the django www app, including storage for the version data
Yes, exactly. Here is how the tree is structured currently:
euscan script
bin/ -- contains the euscan python binary
pym/ -- contains most of the code used by the euscan script
pym/euscan/handlers -- contains specific site handlers (rubygems,
pypi, pecl, pear, ..)
euscanwww django app
euscanwww/ -- contains all the stuff for the django application, all
the django application needs is a working portage tree and euscan
available in the $PATH
IMO it would be nice to have a somewhat generic REST-style service
exposing the data, and build a simple UI on top of that. In
particular, I have different ideas about what the UI should look like,
so it would be nice if different people could experiment (and/or
integrate in other services like znurt.org).
I already added some very dummy json formating (note that it also
exposes internal key id, which is bad, but I just wanted to
experiment).
All you need is to append /json to an url. For example:
- http://euscan.iksaif.net/maintainers/4/json
- http://euscan.iksaif.net/package/app-accessibility/brltty/json
This could be a lot better, we just need to define an API and the
implementation will be easy.
A first step would be to make an ebuild for euscan, and another for
euscanwww so that anyone can easilly install it and play with it.
Feel free to ping me on irc, I'm on #gentoo-sunrise, my nickname is iksaif.
--
Corentin Chary
http://xf.iksaif.net
[gentoo-dev] install-mask -- a tool for all the 'I don't want this file' complainers
Hello all, Just a quick note -- I've just committed install-mask-0.0.1 to gx86. You can use it to quickly set and apply INSTALL_MASK setting so that you can get rid of the all files you don't want. The tool is very simple to use. It comes with a few pre-set locations so you don't need to type in exact paths. To add a path to INSTALL_MASK use -a: install-mask -a systemd install-mask -a bash-completion install-mask -a /foo/bar Removal is done through -d, info can be printed using -i (this will explain preset names as well). It can also generate rebuild list to apply INSTALL_MASK changes. After adding new masks, you can do: emerge -1v $(install-mask -r) to rebuild all affected packages. You can also manually 'rm -r' respective paths -- 'install-mask -r' will not complain about non-existing files. Sadly, due to bug #364633 [1] doing the opposite is not possible right now. When it's fixed, it will require specifying the paths manually (at least in this version): emerge -1v $(install-mask -r bash-completion) [1]:https://bugs.gentoo.org/show_bug.cgi?id=364633 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 04:25, Alec Warner wrote: If 'someone' needs to write a patch then I assume you will volunteer? My C is getting better. Don't tempt me... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] euscan proof of concept (like debian's uscan)
On Mon, 19 Sep 2011 10:39:11 +0200
Corentin Chary corentin.ch...@gmail.com wrote:
## Also update eix database, because we use eix internaly
## Bottleneck: disk and cpu
##Time: 30mn ~ 1h
eix-update
Using egencache to keep caches for overlays will make eix updates much
faster.
Here's my code for it (it uses overlays in /usr/portage/local):
cd /usr/portage/local \
for O in */; do
echo ${O}
egencache --jobs=8 --update --update-use-local-desc --rsync \
--repo=$(cat ${O}profiles/repo_name)
done
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 04:33, Michał Górny wrote: Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. Per our original discussion, isn't the only file udev is looking for pci.ids? If so, I honestly see no reason why that cannot exist in /etc. It fits in perfectly with other files like /etc/DIR_COLORS. If udev hardcodes the path too /usr/share, that's an easy patch then. And that's just one option. We can maintain a minimal pci.ids consisting only of disk drivers if need be in /etc, or find some other clever solution. We've got enough people here; someone oughta be able to figure something out. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, 19 Sep 2011 04:57:10 -0400 Joshua Kinard ku...@gentoo.org wrote: On 09/19/2011 04:33, Michał Górny wrote: Does the patch involve moving even more stuff to rootfs? If I'm going to see /share directory or even more /usr/share files in /lib, then I'm probably going to fork something too. Per our original discussion, isn't the only file udev is looking for pci.ids? If so, I honestly see no reason why that cannot exist in /etc. It fits in perfectly with other files like /etc/DIR_COLORS. If udev hardcodes the path too /usr/share, that's an easy patch then. Could we stop putting random stuff in random dirs because 'it will work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all. And that's just one option. We can maintain a minimal pci.ids consisting only of disk drivers if need be in /etc, or find some other clever solution. We've got enough people here; someone oughta be able to figure something out. As I see it, the simplest solution would be to lay out the minimal initramfs contents to rootfs and make it mount /usr and stuff before starting actual rc. This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
Michał Górny wrote: This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. Not all the complaints. Dale :-) :-)
Re: [gentoo-dev] udev and /usr
On 09/19/2011 05:10, Michał Górny wrote: Could we stop putting random stuff in random dirs because 'it will work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all. The best answer is for someone to look into udev and see what it needs exactly from /usr. Does it really need pci.ids? Or is it just the fact that random udev rules might rely on a tool/lib in /usr? Former, yes, pci.ids is perfectly valid to go into /etc. It specifies a mapping of PCI ID numbers to device strings used in udev rules. In the latter case, maybe rules specifically required for booting up enough to mount disks need to be isolated into their own file and udev pointed there, then re-pointed to the bigger file after /usr is made available. If that is even possible. Note: I'm brainstorming here. Anyone else? As I see it, the simplest solution would be to lay out the minimal initramfs contents to rootfs and make it mount /usr and stuff before starting actual rc. This should cut all the complaints and possibly let us move some stuff back to /usr where it belongs. Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 19 September 2011 16:07, Joshua Kinard ku...@gentoo.org wrote: [...] Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a host-specific / vs host-independent /usr. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] euscan proof of concept (like debian's uscan)
On Mon, Sep 19, 2011 at 10:53 AM, Michał Górny mgo...@gentoo.org wrote:
On Mon, 19 Sep 2011 10:39:11 +0200
Corentin Chary corentin.ch...@gmail.com wrote:
## Also update eix database, because we use eix internaly
## Bottleneck: disk and cpu
##Time: 30mn ~ 1h
eix-update
Using egencache to keep caches for overlays will make eix updates much
faster.
Here's my code for it (it uses overlays in /usr/portage/local):
cd /usr/portage/local \
for O in */; do
echo ${O}
egencache --jobs=8 --update --update-use-local-desc --rsync \
--repo=$(cat ${O}profiles/repo_name)
done
Thanks, I'll try that.
--
Corentin Chary
http://xf.iksaif.net
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Monday, September 19, 2011 03:10:45 Michał Górny wrote: On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote: On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote: On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: '$(use_enable static-libs static)' themselves. While at it, it may be better to just drop the flag if no other package relies on it and no user has ever requested the static build of that package. I don't see any harm with including IUSE=static-libs for every package that has working/usable static libraries[1]. Why wait for users to request it on bugzilla when it's a near-zero-cost and zero-maintenance to add it to ebuilds? i missed this sentence from Michał's e-mail. unconditionally not building static libraries is against policy. if you install shared libs that get linked against, then you must provide static libraries unconditionally as well or support IUSE=static-libs. maintainers do not get to choose no one has asked for it and no one in the tree is using it thus my ebuild isnt going to. Where is that policy? this policy predates much of the documentation process and is missed by the developer handbook. it is however mentioned explicitly in the devmanual. AFAIK the policy was to 'follow upstream' which usually means 'shared only'. I really don't see a reason to build static libtorrent as upstream even doesn't support static linking. by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Mon, 19 Sep 2011 10:43:04 -0400 Mike Frysinger vap...@gentoo.org wrote: On Monday, September 19, 2011 03:10:45 Michał Górny wrote: On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote: On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote: On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: '$(use_enable static-libs static)' themselves. While at it, it may be better to just drop the flag if no other package relies on it and no user has ever requested the static build of that package. I don't see any harm with including IUSE=static-libs for every package that has working/usable static libraries[1]. Why wait for users to request it on bugzilla when it's a near-zero-cost and zero-maintenance to add it to ebuilds? i missed this sentence from Michał's e-mail. unconditionally not building static libraries is against policy. if you install shared libs that get linked against, then you must provide static libraries unconditionally as well or support IUSE=static-libs. maintainers do not get to choose no one has asked for it and no one in the tree is using it thus my ebuild isnt going to. Where is that policy? this policy predates much of the documentation process and is missed by the developer handbook. it is however mentioned explicitly in the devmanual. So, it a policy which even QA doesn't recall. It seems worth changing as there is really no reason to randomly install every possible static library out there if system does support and use shared linking. AFAIK the policy was to 'follow upstream' which usually means 'shared only'. I really don't see a reason to build static libtorrent as upstream even doesn't support static linking. by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Monday, September 19, 2011 10:57:30 Michał Górny wrote: On Mon, 19 Sep 2011 10:43:04 -0400 Mike Frysinger wrote: On Monday, September 19, 2011 03:10:45 Michał Górny wrote: On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote: On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote: On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: '$(use_enable static-libs static)' themselves. While at it, it may be better to just drop the flag if no other package relies on it and no user has ever requested the static build of that package. I don't see any harm with including IUSE=static-libs for every package that has working/usable static libraries[1]. Why wait for users to request it on bugzilla when it's a near-zero-cost and zero-maintenance to add it to ebuilds? i missed this sentence from Michał's e-mail. unconditionally not building static libraries is against policy. if you install shared libs that get linked against, then you must provide static libraries unconditionally as well or support IUSE=static-libs. maintainers do not get to choose no one has asked for it and no one in the tree is using it thus my ebuild isnt going to. Where is that policy? this policy predates much of the documentation process and is missed by the developer handbook. it is however mentioned explicitly in the devmanual. So, it a policy which even QA doesn't recall. i cant speak for random developers who either (a) haven't been around (b) formed their own opinion (c) don't care (d) are forgetful or (e) some list of the above or other items. it doesn't change the policy which long predates the existence of the QA team. It seems worth changing as there is really no reason to randomly install every possible static library out there if system does support and use shared linking. just because you don't care about static linking doesn't matter. many people do, many packages rely on it, and the overhead to support it is trivial. if you dislike static libraries in your packages, then update them to respect USE=static-libs. AFAIK the policy was to 'follow upstream' which usually means 'shared only'. I really don't see a reason to build static libtorrent as upstream even doesn't support static linking. by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger vap...@gentoo.org wrote: by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. -mike Hm, I seem to fail to notice other static binaries than busybox. And I don't think I use any specific configuration which makes me need static binaries; I'm following the _original_ *nix idea of keeping it simple. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Monday, September 19, 2011 11:35:09 Michał Górny wrote: On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. Hm, I seem to fail to notice other static binaries than busybox. And I don't think I use any specific configuration which makes me need static binaries; by default, tools that are needed to easily recover a system (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that goes into initramfs is statically linked. I'm following the _original_ *nix idea of keeping it simple. you're confusing the notion of tradeoffs. the amount of tooling that shared libraries take to work at all let alone being stable is significantly higher than a single static binary. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] finding reverse dependencies for arch testing (and other purposes)
I uploaded my script for finding reverse dependencies here: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary Advantages over existing solutions (browsing to websites like tinderbox or qa-reports): - only prints stable packages when run on a stable system (no need to manually filter out things) - takes a list of packages as input, making it more effective for a batch workflow (we're short on time, batching is often critical) - produces output that can be fed to emerge after stripping comment lines (no junk after package names); again this is for the batch workflow It is still reasonably fast. On my machine it completes within 30 seconds. Comments welcome. I'd be very happy to adapt this to your needs. My main goal is to share those little scripts I use with others so we can all become more productive (and have more time for other things). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 06:37:49AM -0400, Joshua Kinard wrote:
On 09/19/2011 05:10, Michał Górny wrote:
Could we stop putting random stuff in random dirs because 'it will
work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all.
The best answer is for someone to look into udev and see what it needs
exactly from /usr. Does it really need pci.ids? Or is it just the fact
that random udev rules might rely on a tool/lib in /usr?
Oh come on people, please do some basic research and read what has been
posted about this numerous times in the past instead of just guessing.
Former, yes, pci.ids is perfectly valid to go into /etc. It specifies a
mapping of PCI ID numbers to device strings used in udev rules.
In the latter case, maybe rules specifically required for booting up enough
to mount disks need to be isolated into their own file and udev pointed
there, then re-pointed to the bigger file after /usr is made available. If
that is even possible.
Note: I'm brainstorming here. Anyone else?
It's as if people are just totally ignoring what has already been
discussed here, why should we even pay attention to this anymore?
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
Re: [gentoo-dev] finding reverse dependencies for arch testing (and other purposes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/19/11 20:30, Paweł Hajdan, Jr. wrote: I uploaded my script for finding reverse dependencies here: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary Advantages over existing solutions (browsing to websites like tinderbox or qa-reports): - only prints stable packages when run on a stable system (no need to manually filter out things) - takes a list of packages as input, making it more effective for a batch workflow (we're short on time, batching is often critical) - produces output that can be fed to emerge after stripping comment lines (no junk after package names); again this is for the batch workflow It is still reasonably fast. On my machine it completes within 30 seconds. Comments welcome. I'd be very happy to adapt this to your needs. My main goal is to share those little scripts I use with others so we can all become more productive (and have more time for other things). Paweł Maybe it is about time to gather all the arch-testing scripts we have around, package them as a single tarball and create an ebuild for that? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOd38FAAoJEPqDWhW0r/LCiIYQAJN5PJE0cF3TptFJWnCuRMKe Ul3rWcBaH46GE0oZpeRyTNcnWZmNoNKEx+50OQ7vl7G0Q8Dtg5gvXRpxO7SrfKIj JAspqX9RN3CO3Y5JRXL28SoJkPX3lLwX/FkejBARETRRKgZjJVOX3w5GOi/o7gm3 65NQ7W5EHp6j0ooGdsXucqVRQ2o8WbbRMHC0h2FR8SAC79pO/aEPh5OGkHOGcvLw KSMKEaLsTucmyt+D5xh3bXQXR8e/xVTKzVEA3Yb8eic85CjglzxCDixnLA6EFWaX bqcqyTPzbczZIF1yfyy8O8YfQdFlWH5OGxfu/kh7kBfkkjtJHubBJpoAdTvCHAot GH7s1vMvITeCkpX6y9k1Cy0YLE/ebSM/iL4T7WnDQAy4nVApjI8k8770Gckr18NM LCflW2aebKVT4QoWjgdxA3ABuisfqpPJhcpARjjzDTFcKeJQfySZRO5MFotIMgGK ZTFeQOgpAupwjZswwtWQ19zqc6pDSa4u4RQZs5MZvB9eOWIwXs5xWLzZlqfOf6yv 7wILhX60FOxan+Qb/PU8+AnIytq4gqALGOnjExoe9M8Uk70vI6R4hokoxQJUrbxW szG1jhq9gQQQTEQ5FGa7/erI//vLXIpdpdjwVCtp7j7CkRUmQH1sHATWoLhiUNOv 7VoMY3ocrF/+DOc7C0xP =Vh0j -END PGP SIGNATURE-
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 1:36 PM, Greg KH gre...@gentoo.org wrote: Note: I'm brainstorming here. Anyone else? It's as if people are just totally ignoring what has already been discussed here, why should we even pay attention to this anymore? I agree that this is getting a bit off-topic. If anybody wants to brainstorm about how udev ought to work, I'd suggest finding their mailing list and posting it there. Gentoo is a distro. We take the stuff other people make and make it work nicely together. Our value add comes from the source-based concept and the fact that we do support a pretty wide variety of configurations, within the confines of what the upstream projects allow. If your favorite webapp supports mysql, postgres, or sqlite for the backend chances are you'll find that Gentoo supports all three. However, if your favorite webapp only supports mysql then chances are that we won't write a full postgres integration layer simply because mysql is for losers. If you want more options - then somebody has to write them so that we can integrate them. Rich
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wed, 2011-08-31 at 15:41 +0200, Corentin Chary wrote: Hi, some news about euscan (still available at http://euscan.iksaif.net) - New design (yay !) - Atom feeds available for each herd/category/maintainer/package (http://euscan.iksaif.net/maintainers/59/feed/) - Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD ). Now, maybe we should find a way to integrate that with the GSoC statistic project and with http://packages.gentoo.org/ (like done at http://packages.qa.debian.org/p/php-net-ipv4.html ). A quick way would be to host euscan on a gentoo server, and add some webservices to publish the data in json or xml, then packages.gentoo.org and others could parse that and display it. One integration that might also be useful is what we track on the ruby wiki currently: https://overlays.gentoo.org/proj/ruby/wiki/PendingBumps which is a collection of quick notes on problems encountered while bumping packages. The ability to attach notes to packages and to acknowledge version bumps (and e.g. make them yellow instead of red) could help with larger lists for herds. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] udev and /usr
On 19/09/2011 19:36, Greg KH wrote:
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
I'm wondering is if devtmpfs covers what is needed to mount /usr so the
new and grand udev can do all its stuff...
Going around upstream asking to provide init.d files themselves might be
useful btw.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
[gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
EAPI in profiles and the -live version suffix are some of the improvements many people would like to see in the tree. Unfortunately, the risk of breaking systems with old versions of portage has been too high, holding evolution back. I've been thinking about a way to solve this that would be easy to implement, without any significant compromises and one thing comes to mind: Manipulation of the SYNC variable (i.e. rsync module), combined with tree snapshots. At the moment, all systems have a SYNC line similar to this: SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and clone it into a revbumped rsync module, i.e. SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage-r1 That way the last update provided by the old tree will be the updated portage package, which will be aware of the SYNC change. After the user installs that update, every subsequent emerge run will print a fat red warning telling the user that the tree has been revbumped. It will then provide instructions on how to update the make.conf/SYNC and a Y/N prompt to fix it itself. It could even do it automatically, but that's debatable. By doing this we can be sure that any user using the revbumped SYNC have an up-to-date portage (if they cheated, well, that's their problem), allowing us to use all the new features provided by the latest version of portage. For the above to work, we would require at least - support for multiple rsync modules pointing to different trees [also in mirrors] - a way to freeze the current state of the tree for the current rsync module and push future updates to a revbumped rsync module. - update our portage-snapshot tools to use the latest rsync module. - other things I'm probably forgetting right now I'm not sure how much work would be required to make our current infrastructure support this, the infra people could shed some light on this. The idea is to use this system sparingly, only when we need to push big changes that can't be supplied through an EAPI. Another example would be a change that would break the upgrade path. By freezing the tree at the right moment, we can be sure that the users will follow a known upgrade path that works. Please keep in mind that my solution isn't trying to be the best thing possible. Instead, I'm aiming for something that would do the job and would be implemented in a realistic timeframe. What do you guys think? -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
[gentoo-dev] Re: Please don't use IUSE=static-libs unless really necessary
Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted: On Monday, September 19, 2011 11:35:09 Michał Górny wrote: On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. Hm, I seem to fail to notice other static binaries than busybox. And I don't think I use any specific configuration which makes me need static binaries; by default, tools that are needed to easily recover a system (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that goes into initramfs is statically linked. By default? That's begging the question (logic sense) and consequently does not properly support your blanket your system is using static binaries right now statement. That doesn't mean the statement is incorrect. I may well be using static binaries of some sort, but I'm not aware of any (save for grub-static, since I run amd64/no-multilib), and I'd love to know more about which binaries they are, and whether static linking is really necessary for them. Feel free to post a link as I've a feeling this is reasonably basic, but evidently I'm not the only one who would find such info educational and likely useful. FWIW, no busybox here. It wouldn't build when I installed back in 2004, so I package.provided it for later. I tried it again a couple times but by then it was quite clear that it really was NOT needed, so eventually I decided I had better things to do than tilt at that windmill. (I use a second root image, updated AND TESTED when the system appears to be working well, as my emergency recovery solution, thus don't need busybox.) I run (partitioned) md/raid because I can feed appropriate assemble instructions on the kernel command line, no initr* needed. I do NOT use lvm because it would require either an initr* for the root and root- backup images or keeping them separate, needlessly increasing complexity now that md/raid handles partitions transparently, and triggering an answer I simply was not not comfortable with to the Am I comfortable enough with my setup to be reasonably sure I can recover it without fat- fingering and breaking it instead, under the far higher stresses of a recovery situation? question. USE=-static -static-libs, no package.use exceptions for them. So what sort of static binaries am I running (other than the pre-packaged grub-static as already mentioned), and are they really necessarily so? I'm following the _original_ *nix idea of keeping it simple. you're confusing the notion of tradeoffs. the amount of tooling that shared libraries take to work at all let alone being stable is significantly higher than a single static binary. Point well taken. There are indeed tradeoffs. I'm choosing ease of administration and a second root image, partly in a deliberate attempt to avoid unnecessarily increasing my chance of fat- fingering a recovery, over the rather more straightforward for the computer, but significantly more complex for the admin, static linking and limited recovery tools strategy. I guess I trust that the computer side, once a backup is tested and found to work, is far more reliable than the human/admin side under stressful-for-humans recovery scenarios, so am deliberately choosing my tradeoffs. -- 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] udev and /usr
On Mon, Sep 19, 2011 at 11:46:39PM +0200, Luca Barbato wrote:
On 19/09/2011 19:36, Greg KH wrote:
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
greg sick of it all k-h
I'm wondering is if devtmpfs covers what is needed to mount /usr so the
new and grand udev can do all its stuff...
You are kidding me, right?
Going around upstream asking to provide init.d files themselves might be
useful btw.
I have no idea what in the world you are talking about here.
Gibberish, that's all it is these days, gibberish.
Oh wait, this all is a joke on me, right? Ok, that makes more sense,
hahaha, you all got me, good one.
Sorry, I was being slow here, next time I'll get it quicker, nice one
people.
greg k-h
p.s. and yes, this is the only reasonable explanation for this whole
thread, especially given the fact that this whole thing is explained in
extreme detail on the freedesktop.org site, and it has been beaten to
death on this very mailing list in the past. Otherwise what other
reason could this whole thing have been...
[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted: At the moment, all systems have a SYNC line similar to this: SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and clone it into a revbumped rsync module, i.e. SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage-r1 That way the last update provided by the old tree will be the updated portage package, which will be aware of the SYNC change. After the user installs that update, every subsequent emerge run will print a fat red warning telling the user that the tree has been revbumped. At least an initial read suggests that you just multiplied the mirror space requirements by however many times you use this trick. I don't believe infra's going to go for that. A workaround may be to eventually store the frozen tree snapshot in only one location, with a path change for the bump and a transparent redirect (does rsync handle redirects?) on the others, so those that haven't updated yet don't get broken. (If rsync doesn't handle redirects, they'll simply get an rsync error until they investigate, and point at the single location for that final update before switching.) But that's not going to work well for the initial surge, so some sort of transition plan will need to be implemented. One relatively simplistic possibility that would at least limit the mirrors space required to 2X, for a limited time, would be to specify no more than one such upgrade in flight at once on the mirror network, with older ones in the single- location archive, limiting the in-flight time to say two months. However, while that limits the space requirements to 2X and only requires that for a limited time, that's still a significant requirement that's unlikely to go over particularly well, so a rather more complex, or at least different, proposal seems necessary. Please consider this in your proposal, and/or point out where I missed it, if indeed I did. =:^\ -- 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] udev and /usr
On Tue, Sep 20, 2011 at 4:10 AM, Greg KH gre...@gentoo.org wrote: p.s. and yes, this is the only reasonable explanation for this whole thread, especially given the fact that this whole thing is explained in extreme detail on the freedesktop.org site, and it has been beaten to death on this very mailing list in the past. Otherwise what other reason could this whole thing have been... For reference, these are (some of?) the pages: http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On 09/19/2011 07:17, Arun Raghavan wrote: On 19 September 2011 16:07, Joshua Kinard ku...@gentoo.org wrote: [...] Yes, but some of us don't even want to have that initramfs built into our kernels. And no one, other than freedesktop.org* and a few people on linux-hotplug-devel*, said everything belongs in /usr. FHS clearly defines the roles for /, /bin, /sbin, /lib*, /usr, /var, /home, /tmp and the virtual fses. Plus others. http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://marc.info/?l=linux-hotplugm=131206447302056w=2 Really, MacOS's filesystem layout is not something anyone in their right mind should deign to mimic/copy. I didn't get that from either of the links you posted. Seems to me the systemd developers are looking at the split as a host-specific / vs host-independent /usr. From: http://marc.info/?l=linux-hotplugm=131206447302056w=2 Kay Sievers writes: What's not needed today is stuff in /. We can think of /usr a /System. The entire system is installed in one single directory, and that can be mounted r/o, or even shared between many hosts/guest. The stuff on the rootfs is always host-only then. It is from this that I derive the concept of a few folks wanting everything in /usr, as-if to brand /usr the new / (where the 'old' / has just directory stubs and a few symlinks, maybe some minor bits in /etc). That's also where my Mac comment stems from, in that /System hides most of the details of the BSD-nature of MacOS X, and tries to dissuade the user from ever having to go in there. Host-specific / and host-independent /usr is not itself a bad idea. I can envision quite a few useful scenarios for this. But on a single box, why? And for those of us with differing architectures, how would this add any benefit? Is this more of a detail for future RHEL releases (since Fedora is a type of proving ground for RH) so that sysadmins have an easier time managing them? Nothing wrong with it, but it needs to be a configurable choice by the end-user. I'll admit I may not be as informed as I oughta to be, but what I have read indicates that some people think this is the direction to go in, for various reasons. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On 09/19/2011 13:36, Greg KH wrote:
On Mon, Sep 19, 2011 at 06:37:49AM -0400, Joshua Kinard wrote:
On 09/19/2011 05:10, Michał Górny wrote:
Could we stop putting random stuff in random dirs because 'it will
work'? /etc is _SYSCONFDIR_. I don't see how PCI IDs are config at all.
The best answer is for someone to look into udev and see what it needs
exactly from /usr. Does it really need pci.ids? Or is it just the fact
that random udev rules might rely on a tool/lib in /usr?
Oh come on people, please do some basic research and read what has been
posted about this numerous times in the past instead of just guessing.
I'll admit that I do need to read more. But it seems this discussion goes
back a few months and there's no clear starting point on what began this. I
don't always have time to keep tabs on every diverging trend in the Linux
world, so I missed this back when it started. Any references you can point
me to?
And for those udev/systemd haters, you all do know about devtmpfs,
right? If not, {sigh}, I don't even know why I care anymore...
I'm not a hater of systemd or udev. I just don't use systemd, because basic
init and the OpenRC setup work for my installs. Maybe not everyone's, so
systemd (and others) fill those gaps.
With udev, I don't pay a lot of attention to it -- it JustWorks(TM). No
need to really fiddle with something that isn't broken.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] x32 fun pants
On 09/15/2011 16:33, Mike Frysinger wrote: the sizeof(long) and sizeof(void*) are the same between x86 and x32. however, that's about the only thing. for example, x32 gets access to 64bit registers when working with 64bit types (long long) and the tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to amd64 than x32. -mike Virtually the exact same for MIPS n32 ABI. Needs a 64bit kernel, needs a mips64-*-linux-gnu toolchain, but the output is a hybrid 32bit/64bit binary. I wonder if procps ever resolved that PAGE_SIZE mess internally when we brought the o32/n32/n64 mess to light with its author? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x32 fun pants
On 09/16/2011 09:36, Donnie Berkholz wrote: For anyone interested how the performance compares to amd64 in more comprehensive tests, check out the slides from the Linux Plumbers Conference (particularly 14-21): http://linuxplumbersconf.org/2011/ocw/proposals/531 In summary, on those benchmarks it looks like a small global win (maybe 5%) on integer calculations with a few huge wins of ≥25%, but a net loss around 5% pretty much globally for floating-point calculations. Most people probably do a lot more integer calculations unless they're science geeks like me, plus it should have lower memory use, so my understanding is that it probably makes sense to switch to x32 no matter what you're using now (x86 or amd64). Mike, would you agree? Again, extremely similar to MIPS cases from a few years ago. While even n32 is fairly stable in Linux (last few years, at least), the idea was always that in an ideal multilib scenario, you'd use pure 32bits (MIPS o32) in very limited cases (programs that just didn't work in either n32 or n64), n32 for a majority of the system, and pure 64bit (n64) for specific applications, like databases, crypto, or science applications. That's supposed to provide the balance so that float-intensive apps can use pure 64bit w/o penalty, but things that simply don't need 64bits' full power can make use of n32/x32. And yeah, lower memory use because the size of codewords is smaller in memory overall. Anyone wanting to compare x32 and n32 can see the old n32 ABI guide here: ftp://ftp.linux-mips.org/pub/linux/mips/doc/ABI2/MIPS-N32-ABI-Handbook.pdf -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 7:19 PM, Joshua Kinard ku...@gentoo.org wrote: Host-specific / and host-independent /usr is not itself a bad idea. I can envision quite a few useful scenarios for this. But on a single box, why? And for those of us with differing architectures, how would this add any benefit? Is this more of a detail for future RHEL releases (since Fedora is a type of proving ground for RH) so that sysadmins have an easier time managing them? Nothing wrong with it, but it needs to be a configurable choice by the end-user. I'll admit I may not be as informed as I oughta to be, but what I have read indicates that some people think this is the direction to go in, for various reasons. See: http://fedoraproject.org/wiki/Features/UsrMove That is some of the rationale for Fedora. It isn't a bad idea both for destop-oriented and server-oriented setups. It especially makes sense for a more traditional distro with versioned releases (basicaly you just drop in a new /usr and you're done minus a few /etc updates - and if you make /etc nothing but overrides from defaults then it would itself be almost empty and not need updates much). Sure, we're not really planning to do that with Gentoo, but that is the pressure upstream is under. When you have big distros pushing all the major projects in a particular direction we need to be really selective about where we push back. The sky isn't falling though - nobody is looking to go out of their way to break non-root /usr, and we are looking to have a minimal initramfs even for those cases where it breaks a little. Rich
Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
On Mon, Sep 19, 2011 at 6:53 PM, Duncan 1i5t5.dun...@cox.net wrote: At least an initial read suggests that you just multiplied the mirror space requirements by however many times you use this trick. I don't believe infra's going to go for that. Yup - and everybody needs to mirror all the BINDISTs using all those older trees. I don't think this is a good option all-around. For most changes, honestly, I think the cleanest option is to use binary packages. If you build a generic set of @system binary packages then you can emerge -K them and get a bootstrappable system no matter how out-of-date you are. Then you can do an emerge -uDN world, or maybe just an emerge -e world. The only real gotcha is if portage is so old that it can't handle the binary packages. However, to get around that we really just need a set of step-wise binary updates for portage itself so that you can sequence it up to something that can install the rest. That will work as long as portage doesn't strictly need a newer dependency. If it needs a newer python or something then we might need to keep a binary package of that lying around - maybe statically linked so that it doesn't go further than a few packages. Something like that really just needs a few tarballs and then an up-to-date set of binary stage3 packages. The binary packages could be built at the same time the stage3s are made. And, this is really just a contingency plan so we don't need to mirror all that stuff - we could even just make it torrent-only or something. Or we could do what was proposed in the past and say 1 year and you're done. That slows us down a little, but has zero overhead. Rich
Re: [gentoo-dev] Re: Please don't use IUSE=static-libs unless really necessary
On Monday, September 19, 2011 18:25:36 Duncan wrote: Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted: On Monday, September 19, 2011 11:35:09 Michał Górny wrote: On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: by that token, i'll go ahead and remove glibc's static libraries since upstream doesn't even support static linking I'm probably ignorant so you'd have to elaborate more on that to make me see a problem there. think about it a little bit. your system is using static binaries right now, and considering you like to push systemd + initramfs so much, i would have thought you'd realize the implications more quickly. Hm, I seem to fail to notice other static binaries than busybox. And I don't think I use any specific configuration which makes me need static binaries; by default, tools that are needed to easily recover a system (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that goes into initramfs is statically linked. By default? That's begging the question (logic sense) and consequently does not properly support your blanket your system is using static binaries right now statement. busybox always produces static binaries since it's the rescue shell. the rest are just by default. glibc itself installs static binaries (ldconfig much?). so i'm comfortable with my previous statement. So what sort of static binaries am I running (other than the pre-packaged grub-static as already mentioned), and are they really necessarily so? it depends on the configuration. yours would seem to not need it. but there are many which include it. FWIW, no busybox here. It wouldn't build when I installed back in 2004, so I package.provided it for later. I tried it again a couple times but by then it was quite clear that it really was NOT needed, so eventually I decided I had better things to do than tilt at that windmill. (I use a second root image, updated AND TESTED when the system appears to be working well, as my emergency recovery solution, thus don't need busybox.) that's fine. Gentoo has always included a static rescue shell as part of its system and i don't see a need to change that now. but if you have something that works better for you, then all the more power to you. that's the reason we have these knobs like package.provided. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Please don't use IUSE=static-libs unless really necessary
On Monday, September 19, 2011 20:58:41 Mike Frysinger wrote: On Monday, September 19, 2011 18:25:36 Duncan wrote: By default? That's begging the question (logic sense) and consequently does not properly support your blanket your system is using static binaries right now statement. busybox always produces static binaries since it's the rescue shell. the rest are just by default. glibc itself installs static binaries (ldconfig much?). so i'm comfortable with my previous statement. and prelink -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Rich Freeman posted on Mon, 19 Sep 2011 20:46:10 -0400 as excerpted: For most changes, honestly, I think the cleanest option is to use binary packages. If you build a generic set of @system binary packages then you can emerge -K them and get a bootstrappable system no matter how out-of-date you are. Then you can do an emerge -uDN world, or maybe just an emerge -e world. That sounds an awful lot like simply starting from a new stage-3, in a chroot initially, either from the existing system or from install media. Except the new stage-3 route bypasses the old portage/toolchain issue below. The only real gotcha is if portage is so old that it can't handle the binary packages. However, to get around that we really just need a set of step-wise binary updates for portage itself so that you can sequence it up to something that can install the rest. That will work as long as portage doesn't strictly need a newer dependency. If it needs a newer python or something then we might need to keep a binary package of that lying around - maybe statically linked so that it doesn't go further than a few packages. Talking about statically linked... but that's a different thread. =:^) Something like that really just needs a few tarballs and then an up-to-date set of binary stage3 packages. The binary packages could be built at the same time the stage3s are made. And, this is really just a contingency plan so we don't need to mirror all that stuff - we could even just make it torrent-only or something. Or we could do what was proposed in the past and say 1 year and you're done. That slows us down a little, but has zero overhead. Really, that's the practical limit anyway. I've done 8-month updates on the 32-bit build-image chroot I use for my netbook, and it can be pretty hairy even at that, and even with doing regular updates on my main system so I've been thru most of it before by the time I deal with the netbook build-image. I'd say trying to keep it at a year (but recognizing even that's going to be somewhat buggy and have various issues in practice, a year by policy, tho, and six to seven months should actually be practical) is a reasonable goal. Beyond that, the new stage-3 thing should remain the supported upgrade path. Gentoo isn't magic, and if a year's too short for someone and they can't accept the stage-3 method beyond that, they really should be considering whether Gentoo's the best distro for them in any case. That doesn't mean we can't work on ways to shorten the incompatible turn- around time to 1 year, but it does provide a reasonable worst-case time- focus window, since by policy we don't need to worry about anything beyond a year, anyway. Now we're simply talking about ways to shorten the turn-around time to less than a year while keeping the year's supported upgrades policy. -- 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
[gentoo-dev] Re: Please don't use IUSE=static-libs unless really necessary
Mike Frysinger posted on Mon, 19 Sep 2011 20:58:41 -0400 as excerpted: glibc itself installs static binaries (ldconfig much?). so i'm comfortable with my previous statement. Thanks. That's actually the bit I was hoping to get confirmed as I've seen allusions to it before but don't understand it. But I was hoping to be steered toward a bit more detail, or at least some useful suggestions on narrowing down the google search domain toward that end... Hint, hint. =:^) -- 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] udev and /usr
On 09/19/2011 20:29, Rich Freeman wrote: See: http://fedoraproject.org/wiki/Features/UsrMove That is some of the rationale for Fedora. It isn't a bad idea both for destop-oriented and server-oriented setups. It especially makes sense for a more traditional distro with versioned releases (basicaly you just drop in a new /usr and you're done minus a few /etc updates - and if you make /etc nothing but overrides from defaults then it would itself be almost empty and not need updates much). Sure, we're not really planning to do that with Gentoo, but that is the pressure upstream is under. When you have big distros pushing all the major projects in a particular direction we need to be really selective about where we push back. The sky isn't falling though - nobody is looking to go out of their way to break non-root /usr, and we are looking to have a minimal initramfs even for those cases where it breaks a little. Rich Good info, thanks! It definitely seems like something RH is cooking up for future releases of RHEL, where their primary customer base is going to be installing clusters and a ton of VMs. I understand this, but I still disagree with them pushing for this to be the default in a way to influence major projects. Regardless if Gentoo goes in that direction or not, if enough core software adopts this, we'll essentially have no choice but to adopt the same. That's what I take issue with -- the whims of a commercial enterprise ultimately deciding, at some possible, future point, what path we take. In other words, those of us not running cluster farms shouldn't have to change things, even slightly (like using an initramfs if needed) for those that do. Linux's greatest asset is its extreme configurability -- a single source tree can be compiled to run on super computers or cable boxes. And I see yet another reference to MacOS's /System in that link, too... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Mon, Sep 19, 2011 at 7:08 PM, Joshua Kinard ku...@gentoo.org wrote: That's what I take issue with -- the whims of a commercial enterprise ultimately deciding, at some possible, future point, what path we take. In other words, those of us not running cluster farms shouldn't have to change things, even slightly (like using an initramfs if needed) for those that do. Linux's greatest asset is its extreme configurability -- a single source tree can be compiled to run on super computers or cable boxes. For what it's worth, I've got a simple alternative to the initramfs approach, that may be handy for people like you. The idea is to enable CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y in the kernel, pass something like init=/sbin/linuxrc as a kernel parameter via the bootloader, and have /sbin/linuxrc be a simple shell script that mounts /proc, /sys, and /usr before calling 'exec /sbin/init'. You can use whatever shell you want for /sbin/linuxrc, as long as it doesn't have some kind of dependency on /usr. For example, if you want your script to run using a really minimal shell with the fewest possible dependencies, you can put '#!/sbin/busybox ash' in the shebang so that it will use your statically linked busybox. Something like this should do the trick in /sbin/linuxrc: #!/sbin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys mount /usr exec /sbin/init -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On 09/19/2011 03:40 PM, Greg KH wrote: Oh wait, this all is a joke on me, right? Ok, that makes more sense, hahaha, you all got me, good one. Yes, very funny indeed. It's good to keep your sense of humor. Sorry, I was being slow here, next time I'll get it quicker, nice one people. Now you've earned the right to subscribe to the secret mailing list where we think up gags like this one. greg k-h p.s. and yes, this is the only reasonable explanation for this whole thread, especially given the fact that this whole thing is explained in extreme detail on the freedesktop.org site, and it has been beaten to death on this very mailing list in the past. Otherwise what other reason could this whole thing have been... One explanation for life itself is that it's a way for the cosmos play a joke on itself. Going with that explanation, this thread is just a microcosm of a cosmic joke. -- Thanks, Zac
[gentoo-dev] Re: [RFC] obs eclasses
Joshua Kinard wrote:
On 09/13/2011 07:24, Amadeusz Żołnowski wrote:
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
Also, you can usually be more succinct with [[ $var ]] || { some code; } for
the empty case (as opposed to [[ $var ]] { something else; } for code run
when var is non-empty.)
What about other comparisons, like -f, -e, or -d? Bash's manpage only
says
[[ expression ]] -- it doesn't seem to go into the level of detail (at
least not in the section that I quickly perused) about what flag
operators are necessary or not.
As Amadeusz said, you can't omit the other ones.
Also, is this a bash4-only thing, or bash3 and/or bash2 as well?
It was definitely around in all bash-3 versions, from experience, and it's
also a defined behaviour for POSIX sh test or [, tho only guaranteed for XSI
systems[1] so I'd be surprised if it weren't in bash-2.
If yes to above, we should get this edited and fixed up, then, because it
uses -z/-n inside [[ ]]:
http://devmanual.gentoo.org/tools-reference/bash/index.html
As Michal said, it doesn't do any harm. imo it'd be better just to add that
[[ $var ]] is the same as [[ -n $var ]]. [[ ! $var ]] doesn't seem better
than [[ -z $var ]] to my eyes; the latter is clearer imo.
(Decrufting ${var} to $var would be more of a help for learners imo; you
only need to wrap a simple variable expansion in {} when it's immediately
followed by an alphanumeric or underscore character, which would get
interpreted as part of its name, which any syntax highlighting editor will
show you. In several years of BASH scripting I've only once had an issue
with that, in some complex text output.)
Oh, forgot, it won't break initscripts, will it?
Well you wouldn't use [[ in a sh-compatible initscript in any case. There
it'd be safest to stick to [ -n $var ] (or -z ofc.)
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
