Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-10 Thread Enrico Weigelt
* Micha?? Górny mgo...@gentoo.org schrieb:

 Does working hard involve compiling even more packages statically?

I guess, he means keeping udev in / ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-07 Thread Enrico Weigelt
* Walter Dnes waltd...@waltdnes.org schrieb:
 On Fri, Jan 06, 2012 at 07:41:27PM +0100, Enrico Weigelt wrote
 
  This is just our donation, I'm hoping others will join in.
  For the actual development, half of the resources should be
  fine, but testing dozens of uncommon scenarios will eat up
  a multiple of that.
 
   I'm not a C programmer, bash is my forte.  I'm retired, and I have a
 spare machine to play around with for testing.  Contact me offline if
 I can help.

Great. Perhaps you could create some unusual setups (perhaps in a
full-VM), so we can build an test platform on it.

IIRC the main problem are scenarios where /usr is not available
at boot, eg. has to be mounted from somewhere else (eg. NFS).
So, our test platform should have such setups.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* William Hubbs willi...@gentoo.org schrieb:

Hi folks,

 a significant change is taking place with several upstreams that will affect
 us in gentoo, so I wanted to bring it to the list for discussion.
 
 Udev, kmod (which is a replacement for module-init-tools which will be needed
 by =udev-176), systemd, and soon others, are advocating a major change
 to the locations where binaries and libraries are stored on linux
 systems.
 
 The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
 understanding is that they want to move software that is installed in
 /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
 everything from /lib to /usr/lib.

Yep, the same issue alreay came up a few weeks ago on @debian.

I don't want to repeat all the arguments, why these Windows-imitator
guys are completely wrong, anymore. (IMHO already been said in this
thread).

If upstream really wants to stick in that silly chance, it's time for
a fork. We're already allocating about 20..30hrs per week beginning
with 2012/2 for such a project in our resource plan. This stupidity
can become really dangerous thousands of systems around the world,
so it needs to be stopped.

BTW: the original argument (AFAIK) is that moving everything to
/usr should somehow make maintenance easier. Well, how actually ?
Perhaps for people who are too lazy to backup a few more directories ?
Silly.

Actually, at this point, I'd raise the question why not dropping
/usr instead (in little steps). The impact is practically the
same (well, replaces the risk of unbootable system by the risk
of filling up separated / filesystems) but would remove an
then obsolete additional directory. ;-O



cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* Olivier Cr?te tes...@gentoo.org schrieb:

 You clearly have failed to realize that d-bus is a now the bus for
 system messaging and is as much part of the system as syslog or bash.
 Probably even more so, for example, in Fedora 17, you'll be able to boot
 without syslog or bash, but you need d-bus.

That's one of the reasons why Fedora is so bad, that I must
refuse to use it in critical enterprise systems (same as RHEL).
It already was ugly about 5 years ago (while SuSE is ranking 1
you-really-dont-wanna-use-it distros since about 10 years)

Please, don't let Gentoo become as bad as Fedora, RHEL or SLES.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* Olivier Cr?te tes...@gentoo.org schrieb:

 d-bus is not high-level stuff... For example, you can't use bluetooth
 without d-bus. Even Android has it..

really sad, that so many important packages are depending on
that misdesigned bloat.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* Patrick Lauer patr...@gentoo.org schrieb:

 Please don't try to bring the GnomeOS vision of having MacOS without
 paying for it to my computing experience ...

+10


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* Micha?? G?rny mgo...@gentoo.org schrieb:

  I don't want to repeat all the arguments, why these Windows-imitator
  guys are completely wrong, anymore. (IMHO already been said in this
  thread).
 
 Yes, having a single locations for all applications is so-windows. We
 should go the other way then, and create a separate prefix for every
 application. I wonder why we removed that awesome /usr/X11R6.

I was talking about other things, like giving up the typical
unix-style separation of subsystems, all the bloating happening
in certain DE's and then pulling down that bloat to the system
level (just starting w/ dbus)

  If upstream really wants to stick in that silly chance, it's time for
  a fork. We're already allocating about 20..30hrs per week beginning
  with 2012/2 for such a project in our resource plan. This stupidity
  can become really dangerous thousands of systems around the world,
  so it needs to be stopped.
 
 Wow, an enterprise fork taking 20-30 hrs per week to reimplement hacks
 necessary for running applications randomly spread over filesystems?

This is just our donation, I'm hoping others will join in.
For the actual development, half of the resources should be
fine, but testing dozens of uncommon scenarios will eat up
a multiple of that.

  BTW: the original argument (AFAIK) is that moving everything to
  /usr should somehow make maintenance easier. Well, how actually ?
  Perhaps for people who are too lazy to backup a few more directories ?
  Silly.
 
 Enjoy sharing those few more directories over NFS.

Yes, what's the big deal ? Done that with thousands of nodes.

  Actually, at this point, I'd raise the question why not dropping
  /usr instead (in little steps). The impact is practically the
  same (well, replaces the risk of unbootable system by the risk
  of filling up separated / filesystems) but would remove an
  then obsolete additional directory. ;-O
 
 That's because people would like to get rid of additional directories
 in /, not introduce additional ones.

Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o
(hmm, some mindless jerks really could pick up that silly idea...)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] rfc: locations of binaries and separate /usr

2012-01-06 Thread Enrico Weigelt
* Micha?? G?rny mgo...@gentoo.org schrieb:

  I was talking about other things, like giving up the typical
  unix-style separation of subsystems, all the bloating happening
  in certain DE's and then pulling down that bloat to the system
  level (just starting w/ dbus)
 
 Yes, three arguments and just a one, silly example which is basically
 incorrect assuming noone obliges you to use systemd.

IIRC, systemd is not the only system-level package depending on dbus.

  Yes, what's the big deal ? Done that with thousands of nodes.
 
 Without initramfs?

Yes. Using PXE and nfsroot.

 Syncing rootfs over and over again or just updating
 packages installing into it once a year?

Regularily updating packages, but with quite conservative policy.
Of course, this required proper service restarts, etc,
but thats an topic on its own ...

   That's because people would like to get rid of additional
   directories in /, not introduce additional ones.
  
  Aha. Then why not also moving /home, /etc and /var to /usr, too ? ;-o
  (hmm, some mindless jerks really could pick up that silly idea...)
 
 You should consider taking like 1 or 2 hours of your precious time to
 read about the use and meaning of various directories in the filesystem.

I studied FHS and its purpose somewhat 15 years ago, and I don't
want to repeat all the arguments. My argument was just: if you
wanna move /bin+co to /usr for easier maintenance, you could also
put /usr/* to / for quite the same reasons.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-26 Thread Enrico Weigelt
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

2011-02-26 Thread Enrico Weigelt
* Enrico Weigelt weig...@metux.de schrieb:

  pretty please force every consumer to hardcode the version
  because i know people that want to do this ?
 
 No, they should use pkg-config at buildtime and do the version
 selection there (eg. the eselect-way).

Oh, it gets a bit tricker: the dependencies of the installed
packages will have to be fixed to the actually used version/slot.

hmm, maybe this also could be done via some eclass, that adds
an useflag for libpng version selection ?

I could imagine a way like that:

* libpng15 is installed in a way that it doesnt conflict with existing
  libpng14 (different locations, pkg-config name, slotted, etc)
* pass pkg-config calls through a wrapper that automatically
  chooses the right .pc file on some environment variable etc.
* each libpng-using package that should be buildable against libpng15
  is changed to use the new eclass (that does all the switching magic)

IMHO this should allow keeping the (runtime) dependencies intact
(no revdep-rebuild required) and allow an smooth upgrade. When
everything had been rebuilt against libpng15 one day, --depclean
would kick off old libpng14.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

2011-02-26 Thread Enrico Weigelt
* Diego Elio Pettenò flamee...@gmail.com schrieb:

 What I had in mind was something that would work for upstreams as well,
 mostly by having fallback; so if a package supported up to libpng 1.4 it
 would search for -lpng14, then -lpng12, then -lpng (and in Gentoo would
 hit -lpng14); while one supporting 1.5 as well would go -lpng15 -lpng14
 -lpng12 -lpng ...

In case of multiple versions are installed, that would make the
dependency tracking unstable - the package management doesn't
know which version had been chosen.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-25 Thread Enrico Weigelt
* Ed W li...@wildgooses.com schrieb:

 I maintain a, likely much smaller, number of VMs using linux vservers.  
 The approach here is to almost cut each machine down to a chroot that 
 runs only one (or thereabouts) interesting service.

I'm working in a similar way: my dedicated boxes are VM hosts
(currently ovz, but later lguest or lxc), each of them running
only specific services (eg. one for nginx-based front proxy,
several other for backend webservers, RDBMs'es, mailservers, etc).

But, for me, even a trimmed-down Gentoo is still too large
(has to contain the whole base packages, from portage to
toolchain, includes, etc). I'd prefer having only the essential
runtime stuff within the containers.

For this we need a different approach (strictly separating build
and production environments). Binary distros (eg. Debian) might
be one option, but they're lacking the configurability and mostly
are still too large. So I'm going a different route using my own
buildsystem - called Briegel - which originally was designed for
embedded/small-device targets.

For now I didn't have the spare time to port all the packages
required for complete server systems (most of it is making
them all cleanly crosscompile'able, as this is a fundamental
concept of Briegel). But maybe you'd like to join in and try it :)

 Using something like git would probably be perfect

I'm using git'ed portage trees in production for several month now
(I sometimes had to touch some eclasses, which _IMHO_ doesn't via
overlays). The repos are configured to rebase on pull and everything
runs automatically :)

 The still missing step is configuration management across the machine 
 types, eg I want to upgrade all my Apache-WWW class machines and merge 
 in all changes in /etc in a certain way... At the moment I just run 
 dispatch-conf across all machines, but it can be quite boring merging 20 
 instances of sshd.conf...  Seems like Puppet/Chef could be a solution 
 here, but the step up and investment to make it work seems pretty large?

I haven't used puppet yet, but several collegues have made good
experiences with it. If you're maintaining dozens of very similar
systems (mine tend to be very different from each other), it likely
worth investigating.

 It does appear like managing large numbers of virtual machines is one 
 are that gentoo could score very well?  Interested to see any chatter on 
 how others solve this problem, or any general advocacy?  Probably we 
 should start a new thread though...

I'm not sure if Gentoo really is the right distro for that purpose,
as it's targeted to very different systems (i.g. Gentoo boxes are
expected to be quite unique, beginning with different per-package
useflags, even down to cflags, etc). But it might still be a good
basis for building specific system images (let's call them stage5 ;-))

An setup for 100 equal webserver vm's could look like this:

* run a normal Gentoo vm (tailored for the webserver appliance),
  where do you do regular updates (emerge, revdep-rebuild, etc, etc)
* from time to time take a snapshot, strip off the buildtime-only
  stuff (hmm, could turn out to be a bit tricky ;-o)
* this stripped snapshot now goes into testing vm's
* when approved, the individual production vm's are switched over
  to the new image (maybe using some mount magic, unionfs, etc)


At this point I've got a question for to the other folks here:

emerge has an --root option which allows to (un)merge in a separate
system image. So it should be possible to unmerge a lot of system
packages which are just required for updating/building (even
portage itself), but this still will be manual - what about 
dependency handling ?

Is there some way to drop at least parts of the standard system set,
so eg. portage, python, gcc, etc, etc get unmerged by --depclean
if nobody else (in world set) doesn't explicitly require them ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

2011-02-24 Thread Enrico Weigelt
* Alexis Ballier aball...@gentoo.org schrieb:

  so why dont you ask the libpng upstream people ?
 
 ask what ?
 pretty please dont install libpng.pc/.so, 

Exactly that.

And it's exactly what I'm going to fix in OSS-QM when I'm adding
libpng-1.5 in a few days.

 pretty please force every consumer to hardcode the version
 because i know people that want to do this ?

No, they should use pkg-config at buildtime and do the version
selection there (eg. the eselect-way).

 Thanks, I'm fine with having it non slotted.

And ending up with largely broken systems once again (and again,
and again, with coming releases) ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] automated testing framework for Gentoo on Supercell at the OSL

2011-02-20 Thread Enrico Weigelt
* Tim Harder radher...@gentoo.org schrieb:

 Is anyone interested in getting some type of automated Gentoo testing
 framework setup on the new Supercell infrastructure [1] at the OSUOSL?
 In a nutshell, Supercell allows projects to spin up their own VMs on
 demand using Ganeti Web Manager [2].

Sounds great, I'd like to use it for my Briegel buildsystem
(not Gentoo related, somewhat similar to portage, but more for
embedded targets) running mass-buildtests.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-20 Thread Enrico Weigelt
* Markos Chandras hwoar...@gentoo.org schrieb:

 My suggestion, as I said to fosdem, is to freeze, or take a
 snapshot if you like, of the current tree, stabilize what you
 need to stabilize, test the whole tree ( at least compile wise )
 for a couple of weeks and then replace the existing stable tree. 

hmm, would it make sense to add a new masking for the testing
tree, so users could decide which stability grade vs they wish ?
or perhaps use overlays for that ?

For example, I'd like to have the critical packages (everything
that's needed to bootup and do basic remote maintenance) from
the new frozen-stable tree, but other things should stay as
they are.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: avoiding urgent stabilizations

2011-02-20 Thread Enrico Weigelt
* Duncan 1i5t5.dun...@cox.net schrieb:

 The above suggestion sounds to me like increasing the bureaucracy and 
 hassle of stabilizing packages even more.  We already have trouble with 
 outdated stable, especially on some archs.  Do we /really/ want the 
 reputation of competing with Debian-stal^hble for staleness?

Well, I often have cases where the stable tree breaks something
or requires deeper manual intervention. That doesn't make fun when
maintaining dozens of systems. So a more-stable tree (hmm, perhaps
call it 'mature' ;-)) would be a big win.

I could also imagine doing that on per-package basis.
Lets say, somehow automatically export the last time of unresolved
bugs per ebuild to some sane place in the portage tree (eg. some
new file in the per-package subdirs) so people could script up
something that automatically maintains package.mask ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-20 Thread Enrico Weigelt
* Fabian Groffen grob...@gentoo.org schrieb:

 Hmmm, odd.  I experience amd64 (stable) as being pretty stable on my
 servers.  Last breakage which really got me upset was php, but that's
 already some time ago.

the ini file issue ?

 With Gentoo you should update on fairly regular intervals, and have the
 time inbetween as short as possible, but 2 or 3 weeks appears to be
 fine.  I myself have a cronjob that syncs every night, and mails me the
 output of emerge -Dupv world.  When this list gets too large, it's
 typically about time to do some updating.

I've automatized even a bit more: my cron script also automatically
rebuilds the packages I have explicitly whitelisted in my
/etc/portage/package.autoupdate file.

Let me know if anyone likes to have it.

 I have masked new major releases of PostgreSQL and MySQL for instance,
 and of course Python 3. 

/me too.

Perhaps we can find a way to make the update safe (so eg. new
postmaster is installed along the old one) and provide some
migration tool ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-20 Thread Enrico Weigelt
* Pawe?? Hajdan, Jr. phajdan...@gentoo.org schrieb:

 By the way, to turn this thread into some action: what testing do we
 currently perform for auto-generated stages? It'd be cool to at least
 compile-test that the stage can emerge -e world itself, and emerge
 some common packages (with FEATURES=test so that we run at least some
 of the produced code).

If we have enough VM's, we could also collect configs and perhaps
even example workloads from users which run their updates with
~arch automatically and look whether they still run properly.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: On hosting self-produced distfiles

2011-01-30 Thread Enrico Weigelt
* Diego Elio Pettenò flamee...@gmail.com schrieb:

 GitHub _used_ to be broken and provide non-stable downloads, but they
 have since fixed that and the download of a tag will always have the
 same SHA512 digest, so it's just fine.

That's great. How exactly did they do that ?

IIRC one of the problems is/was that both tar and gz might not
be strictly deterministic (same input content might produce
differing tarball output) - am I wrong here ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] making revdep-rebuild (partially) obsolete

2011-01-02 Thread Enrico Weigelt
* Mike Frysinger vap...@gentoo.org schrieb:

 although portage has long been generating the NEEDED files in vdb.  even 
 stable portage generates these files.

Ah, okay, I wasn't aware of that.

What's the difference between NEEEDED and NEEDED.2 ? Multiarch ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

2011-01-02 Thread Enrico Weigelt
* Rich Freeman ri...@gentoo.org schrieb:

 Something I've done when I've really borked up my system is to just
 save /etc, backup, etc, and then extract a stage3 over my root
 filesystem.  That gets all of my system packages into a working state.
  Sure, some packages may not work, but many still will.  Then an
 emerge -e world or whatever will clean things up.

Assuming there are no circular deps which can only be resolved
by temporarily changing some useflags ... ;-o


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] making revdep-rebuild (partially) obsolete

2011-01-01 Thread Enrico Weigelt
* Micha?? Górny mgo...@gentoo.org schrieb:

  What do you think about this idea ?
 
 You mean what do we think about portage-2.2 and preserved-libs?

Well, I'm still using portage-2.1, so I wans't aware of whats going
on there. For now it seems the preservation is still done explicitly
(preserve_old_lib calls in certain ebuilds ?). My proposal is to
record the necessary information (eg. which so some executable/so
is linked against) automatically - does portage-2.2 do that ?

BTW: several blog/maillist postings talked about the problem that
even on recompile, older library versions could be linked in even
on recompile. Somebody suggested to move away preserved libs to
another directly (which is then added to ld.so.conf). What do you
think about that ?

Another approach could be building everything in an separate,
minimal sysroot or chroot. (I admit, I have no idea how complex
it would be to implement that in portage - my Briegel buildsystem
does always does this)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] epatch: reject patches with relative paths

2010-12-31 Thread Enrico Weigelt
* Mike Frysinger vap...@gentoo.org schrieb:

 sounds like overkill.  people will file bugs and they'll get fixed.  once it 
 goes fatal, people will fix even faster.  i dont plan on making it fatal 
 anytime soon.

An option to make it fatal would be helpful.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

2010-12-31 Thread Enrico Weigelt
* Enrico Weigelt weig...@metux.de schrieb:

Sorry, forgot the attachement ;-o


-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
#!/bin/bash

TREE=/usr/portage

warn_eapi_missing() {
echo $1: missing EAPI= line
true
}

warn_eapi_unquoted() {
echo $1: EAPI= line not quoted
true
}

warn_eapi_deprecated() {
echo $1: EAPI $2 deprecated
true
}

check_eapi() {
while read f ; do
if ! grep EAPI= $f /dev/null ; then
warn_eapi_missing $f
elif ! grep EAPI=\ $f /dev/null ; then
warn_eapi_unquoted $f
elif grep -E EAPI\=(0|\0\) $f /dev/null; then
warn_eapi_deprecated $f 0
elif grep -e EAPI\=(1|\1\) $f /dev/null; then
warn_eapi_deprecated $f 1
#   elif grep -E EAPI\=(2|\2\) $f /dev/null; then
#   warn_eapi_deprecated $f 2
#   elif grep -E EAPI\=(3|\3\) $f /dev/null; then
#   warn_eapi_deprecated $f 3
#   elif grep -E EAPI\=(4|\4\) $f /dev/null; then
#   warn_eapi_deprecated $f 4
else
true
fi
done
}

find $TREE -name *.ebuild | check_eapi


Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

2010-12-31 Thread Enrico Weigelt
* Ulrich Mueller u...@gentoo.org schrieb:
 Hi,
 
 after approval of EAPI 4, there are now 5 different EAPIs available,
 and it's hard to remember what features are offered by which EAPI.
 
 So maybe it's about time that we deprecate EAPIs 0 and 1 for new
 ebuilds. As a first step, a warning could be added to repoman that
 would be triggered whenever a new ebuild with an EAPI less than 2 is
 committed.

Is there a way to scan automatically for ebuilds with older EAPIs
w/o actually running emerge ? Is grep'ing sufficient ?

Just hacked up a little scan script ... see attachement.

 At a later time, the warning could be changed to an error. When most
 of the tree has been updated to EAPI 2 or newer, we could also think
 about actively converting the remaining ebuilds. (Currently this
 doesn't look feasible though, as about half of the tree is still at
 EAPI=0. [1])

IMHO, when an EAPI is declared depcreated, new or changed ebuilds
should not use it anymore. Deprecation should not happen as long
as base packages still use it.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] epatch: reject patches with relative paths

2010-12-31 Thread Enrico Weigelt
* Mike Frysinger vap...@gentoo.org schrieb:
 On Friday, December 31, 2010 09:16:27 Enrico Weigelt wrote:
  * Mike Frysinger vap...@gentoo.org schrieb:
   sounds like overkill.  people will file bugs and they'll get fixed.  once
   it goes fatal, people will fix even faster.  i dont plan on making it
   fatal anytime soon.
  
  An option to make it fatal would be helpful.
 
 no, it wouldnt

Dont you wanna let users decide themselfes whether they want it ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] making revdep-rebuild (partially) obsolete

2010-12-31 Thread Enrico Weigelt

Hi folks,


just a little braindump, how revdep-rebuild could be made
(partially) obsolete in future:

Today it might happen that on an library update an old .so file
gets unmerged while still used by somebody - that's what revdep-
rebuild scans for. While it should catch those cases, we still
have some downtime for certain packages (in bad cases, when it
broke somewhere deep in the dependency chain, rebuild might take
quite a lot of time).

The main problem IMHO is that portage doesn't record which libraries
some package links in, so it doesn't know which ones have to be
protected from unmerge (unless explicitly stated somewhere).
So I'd propose to add record that information. On next merge,
this information can be used for an automatic library-protect.
This would also record which libraries have been protected from
removal and for whom. Subsequent merges will update this that,
and once all importers have been unmerged, depclean can clean
up the leftover dirt.


What do you think about this idea ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] epatch: reject patches with relative paths

2010-12-30 Thread Enrico Weigelt
* Robin H. Johnson robb...@gentoo.org schrieb:
 On Thu, Dec 30, 2010 at 07:04:25PM -0500, Mike Frysinger wrote:
  epatch was changed to auto-skip the first path element when it is absolute
  (starts with a slash).  the reason was to avoid issues with patches touching
  files outside of $PWD (which is bad if sandbox is disabled).
 +1 from me, but can we have a QA prefix on the ewarn output?

IMHO, in longer terms, all patches should normalized, created w/
diff -ruN and applied w/ -p1. Thats how most people do it, so
a kind of semi-standard.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] epatch: reject patches with relative paths

2010-12-30 Thread Enrico Weigelt
* Mike Frysinger vap...@gentoo.org schrieb:
 On Thursday, December 30, 2010 20:05:01 Enrico Weigelt wrote:
  IMHO, in longer terms, all patches should normalized, created w/
  diff -ruN and applied w/ -p1. Thats how most people do it, so
  a kind of semi-standard.
 
 not worth developer's time to force it since it poses no practical positive 
 benefit to us

It makes it easier for everyone who'll want to work on these
patches (eg. people besides the actual ebuild maintainers).

BTW: I'm not proposing to rework all the patches right now,
just set a policy for new ones.

Even you might not like to hear this, Debian is much better at this
point - they a patchqueue per each package, which can be applied
fully automatically (w/o additional code in the invididual package
descriptors). This allows easy importing into other systems
(like I'm doing w/ my normalized git repositories within the 
oss-qm project).


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] Removing .la files

2010-10-24 Thread Enrico Weigelt

Hi folks,


I'm doing some investigation on which .la files are still needed
and which are not. In general, .la files only are in use by very
few packages which use them to load plugins (I've seen no package
which actually requires them for compile-time importing in
production).

For net-im/pidgin (and its various plugins) I can now confirm
that .la files are not needed here, so we could remove them here.

I'll check more packages on that.


BTW: is there a way to teach revdep-rebuild to ignore .la files ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: .la files and their future on Gentoo

2010-10-07 Thread Enrico Weigelt
* David Leverton levert...@googlemail.com schrieb:

  And for Distros, it doesnt make sense to try to support anything imaginable.
 
 Not breaking things that already work would be a decent compromise.

Any concerete example on what would break if .la files aren't 
installed anymore ?

  I'm now working in embedded area (where static linking is quite common)
  for about 10yrs, and pkg-config has proven quite well here. (packages
  that dont provide .pc-descriptor yet, simply have to be fixed to do
  so ;-p). Libtool, on the other hand, always had been a nightmare.
 
 What about things that don't use pkg-config? 

As said above: fix them.

 If you say we don't support that, modify it to use pkg-config, 
 does that mean you're willing to make Gentoo incompatible with
 Linux in general? 

This doesn't have to do anything w/ Linux - it's an purely userland
(and build-time only) issue, applicable to dozens of platforms.

When it comes to Gentoo (and maybe other distros) we only have to 
fix a few packages which don't use or support pkg-config yet,
but do libtool-based imports. In recent years, those became quite rare.

 (That question isn't just about .la files, it applies to any change
 versus upstream that affects interfaces between components.)

Are you sure, these .la files are really part of the interface for
most packages, but not just an side effect of using libtool ?

 Just to reiterate, I'm not trying to block anything here.  I'm just
 asking for a small override so people with use-cases you (in general,
 not a specific person) haven't thought of can be happy. 

In this case you'd need some kind of switch. Okay, let's just
introduce some make.conf variable for that and tell everybody
that there's no support for it whatsoever.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: .la files and their future on Gentoo

2010-10-05 Thread Enrico Weigelt
* Diego Elio Pettenò flamee...@gmail.com schrieb:

 http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

ACK.

IMHO, removing the .la files should be under invididual ebuild
(or eclass) control, and we also should try to get it fixed 
at the source (if possible).

 Also, I would like to ask again that if you're going to argue you never
 know who might use them, you're going to have to actually understand
 _what_ the files are used for, _which_ software uses them, and come up
 with a use case for them, not a vague oh there might be a project that
 use them.

That whole you'll never know who might use them-idea is a bad idea,
IMHO. By that doctrine you can never get rid of old crap. Sometimes
an cut has to be made.

And for Distros, it doesnt make sense to try to support anything imaginable.
Instead there's limited (yet large) set of packages that are supported.
We can track the dependencies and so know who's using some particular
package (inside the distro). So we can actually test if removing la-files
from one invidual package will break anything. Maybe it's even worth
to make an automatic testsuite.

 From my point of view, the only points worth to be raised are Nirbheek's
 (even though I disagree, as I said), Rémi's (which I don't think he
 either considers showstoppers at this point) and those not-yet-spoken
 off by Prefix (they might support architectures where .la files are
 worth something).

Are there any platforms where .la files are really worth anything ?
(in Gentoo's scope) ? And *if* there're some - could there be better
solutions ?

BTW: In general, the idea of having a metadata file per library is
quite nice. (if done well, even better than the pkg-config approach).
But libtool implements this particular bad - it doesnt have a proper
abstraction (actually, libtool is not an abstraction at all, as eg.
unitool does, but just an command line filter doing mysterious things).

*If* someone here really likes the per-library-metadata idea, then
let's start an own project for that (knowing that'll be just reasearch
and not production-grade for quite some time). But that yet goes far
off-scope of distros (until a reasonable amount of packages adopted it).

  - is it okay to drop them from stable? my personal opinion here is to
 side with Samuli and say yes; on the other hand, since by the looks of
 it, and the status report Zac gave us, we're going to need just one
 extra month before just telling users install lafilefixer and update to
 stable portage 2.1.9.13, I think we can avoid doing any more of those
 changes till then ??? in stable that is; this includes both non-revbumps
 and stable requests of packages dropping them;

Admitting I've not fully followed this thread, but IMHO portage changes
aren't needed here - just put the la-skipping/-removal into individual
ebuilds. Portage can provide generic functions for that later, which
then can be used by newer ebuilds, but doesnt need to.

  - what about Rémi's 2b concern? Sincerely I have worked for a long time
 with static linking on my job and I don't see libtool files being so
 excessively necessary; the only problem comes with transitive
 dependencies, but most packages already take care of that; even if you
 do not use pkg-config, you have other means to recover it.

I'm now working in embedded area (where static linking is quite common)
for about 10yrs, and pkg-config has proven quite well here. (packages
that dont provide .pc-descriptor yet, simply have to be fixed to do
so ;-p). Libtool, on the other hand, always had been a nightmare.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] omitting redirecting man pages from compression

2010-09-24 Thread Enrico Weigelt
* Peter Volkov p...@gentoo.org schrieb:
 ?? ??, 19/09/2010 ?? 19:43 -0400, Mike Frysinger ??:
  many man pages exist merely as a redirect to another man page:
  $ xzcat /usr/share/man/man1/zcat.1.xz
  .so man1/gzip.1
  
  compressing these tiny (always?) results in a larger file.  that means we
  arent saving space, and we're adding overhead at runtime.
 
 Isn't it better to skip compression on all tiny files (not only man
 pages)? In such case some other functions will need to be updated too
 (e.g. ecompress --suffix)...

Maybe it would be even better to mount some compressing filesystem 
on /usr/share/man and /usr/share/info (or perhaps even the whole
/usr/share ?), leave off the explicit compression at all and 
replace the link files by symlinks ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: OSS-QM again ...

2010-08-20 Thread Enrico Weigelt
* Enrico Weigelt weig...@metux.de schrieb:
 * Duncan 1i5t5.dun...@cox.net schrieb:
 
  FWIW, you (Enrico) might get more traction if you go a more official 
  route.  Do the whole FLOSS PR bulletin thing, announcing thru LWN, 
  LinuxMag, LXer, etc.  Slashdot and the like wouldn't be bad, either. 
 
 Thanks for the tip, but I'm not actually good at PR and lacking
 time for that ;-o

Okay, I've now created an sf.net project w/o bugtracker, maillist,
etc: http://sourceforge.net/p/oss-qm/home/


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-08-18 Thread Enrico Weigelt
* Jacob Godserv jacobgods...@gmail.com schrieb:
 On Tue, 17 Aug 2010 19:04:03 +0200
 Enrico Weigelt weig...@metux.de wrote:
 
  Meanwhile I've reworked my Briegel buildsystem [1] to support
  direct git checkouts (including a repo cache). Next step will be
  a mechanism to check tag signatures.
 
 You have a footnote, but no link, and I'm curious. :)

ups, I probably thinking and typing got out of sync ;-O

http://www.metux.de/index.php/en/component/content/article/57.html


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] Re: OSS-QM again ...

2010-08-18 Thread Enrico Weigelt
* Duncan 1i5t5.dun...@cox.net schrieb:

 FWIW, you (Enrico) might get more traction if you go a more official 
 route.  Do the whole FLOSS PR bulletin thing, announcing thru LWN, 
 LinuxMag, LXer, etc.  Slashdot and the like wouldn't be bad, either. 

Thanks for the tip, but I'm not actually good at PR and lacking
time for that ;-o

I better concetrate on talking directly to responsible people.
For example, when posting my changes to upstream, I point them
to the git repo/ref instead of text-based patches and add some
notes about the oss-qm project.

 Get a couple projects using it and it may well take itself from there.

That's actually the intention of this thread ;-p

 I mean, what would it look like if Gentoo did start using it, and 
 then it got compromised somehow? 

My ideology that distro people (eg. from Gentoo) not just use it
(as dumb downstream), but instead actively take part in it.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] OSS-QM again ...

2010-08-17 Thread Enrico Weigelt

Hi folks,


perhaps you remember the discussion of oss-qm + git-repos several
weeks ago. Just to add another point:

I'm going to add an automatic notification system on new changes,
so upstreams and other parties can notified automatically, w/o
additional manual intervention.

That's yet another reason why I'd like package maintainers to 
push their changes into the oss-qm repo. That would be a great
help for others having to deal with the same package.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-08-17 Thread Enrico Weigelt
* Brian Harring ferri...@gmail.com schrieb:

  hmm, I'm exclusively using bzip2 and never had these problems
  yet. maybe it depends on the compressor type.
 
 http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail
 
 Note also that bzip2 had another change in output after that 
 release- my memory is failing me a bit, but it was roughly a 
 a reduction of their hash size to fix a CVE- either way, same thing, 
 differing output.

Okay, you've convinced me :)

Meanwhile I've reworked my Briegel buildsystem [1] to support
direct git checkouts (including a repo cache). Next step will be
a mechanism to check tag signatures.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] Re: [gentoo-user] FYI: Rules for distro-friendly packages

2010-08-17 Thread Enrico Weigelt
* Alan McKinnon alan.mckin...@gmail.com schrieb:

 My biggest beef by far when packaging apps is automagic dependencies.
 
 e17 is full of them - if package A is present, the app will configure itself 
 to use it. Usually you cannot switch this kind of thing off even if you have 
 valid reasons to do so.

That's one of the reasons I'm building everything by a sysroot'ed
crosscompiler (when not using Gentoo ;-)). This way these things
(normally) can't happen.

 I want explicit --enable-package features in the ./configure step for 
 everything that might be optional. Because I often do have that lib on my 
 system and the app's usage of it is buggy, so I should be able to disable 
 that 
 support.

Can you live with the current formulation ?
http://www.metux.de/index.php/de/component/content/article/57.html

(see and of the text)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-15 Thread Enrico Weigelt
, if you propose benefits w/o a change of workflow,
 I'm sure many more people will be interested. 

The major benefit is that changesets can be easily shared between
various distros and upstreams, up to fully notifications, etc.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-11 Thread Enrico Weigelt
* Hans de Graaff gra...@gentoo.org schrieb:

 I do understand the response, because part of the strategy mentioned
 *is* not to provide plain-text patches, but instead manage them,
 possibly jointly with other distributions, in a midstream repository.

Exactly.

The point is: I have to maintain lots of packages for different distros, 
as well as for my own build system. I cannot do this manually for each 
single distro, so I prefer doing _generic_ fixes and let the distro 
buildfiles only do the plain standard build process 
(eg. ./autogen.sh  ./configure  make  make install). 


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-11 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:

 If I understand your system correctly, you essentially maintain clones
 of upstream repos, with all the various distro patches applied on top,
 and release tarballs as well. 

Yes. And if some upstream does not provide suitable vcs access
(or doesnt even have one), I make an pseudo-upstream branch by
committing the release source trees.

 I don't see how these various distros can be made to agree with 
 each other and I certainly can't see them using a common tarball 
 source. 

Thats not even necessary. They just should use the infrastructure,
as described in my paper. So everyone can easily set up automatic
notifications, cherry-pick, etc, etc.

 On a technical level, it's got serious security, trust, and 
 redundancy problems.

Git makes that very easy ;-p

 It is extremely important that distros collaborate in some form 
 when it comes to patches that *can* be shared, 

If we're doing a good job (my generic fixes instead of distro-
specfic dirty hacks) about 99% can be shared ;-p

 but the solution you have devised is fundamentally flawed.

If it's really flawed, then just for pure social reasons, no
serious technical ones.

 A practical solution to the problem of patch sharing is to 
 have a website with a search interface for upstream source 
 tarballs, which can display all the patches that various 
 distros apply, as well as a download link for the patchsets 
 (hotlinked to the distro files where possible). 

Too complicated, and actually would not help me a single bit.
What I could offer is an (semi-)automatic import mechanism 
(assuming certain package managers dont do such insane things 
like directly sed'ing sources etc) - there's still a bunch of
work to do for that, but its possible.

 Distro packagers are much more comfortable with downloading 
 patchsets from a foreign source than complete tarballs. 

man git-format-patch ;-p

Maybe I could set up an git webfrontend (or automatically push
to some public service). 

 I know you have spent a lot of time on this already, but please
 understand it from where we stand. We're short on manpower, and
 there's no real benefits of shifting our tarball source; OTOH there
 are major disadvantages too unless we pitch in with manpower
 ourselves. And honestly speaking, that manpower is better spent making
 stuff work locally.

Well, Gentoo is short of manpower ? hmm, perhaps some should think
about why so many folks are resigning and so few fresh coming in
(at least according to this lists traffic) ;-O

 Please consider the patch-website idea above. We definitely need
 someone to code it up, gather the source-package to distro patches
 mappings, and advertise it.

Actually, I once had somehing in that area, called comprehensive
source database, but unfurtinately it got lost in an disk array
crash a few years ago, and I didnt find the time to rewrite it yet.

Meanwhile I dont need it anymore, since I gave up maintaining
plaintext patches in favour of git. And that makes my daily works
_much_ easier.

Oh, btw: I'm announcing my oss-qm releases via twitter:

http://twitter.com/oss_qm


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-11 Thread Enrico Weigelt
 tarballs.
(the worst srcpkg I've ever seen is Debian's mysql-5.0.32 ...)

And even *if* we assume, that everyone's just doing patches, we
still need to transform the everbody's strange (often not even
linear) versioning schemes. One of OSS-QMs primary goals is to
use a strictly normalized/canonical naming/versioning scheme in 
the primay source repository.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-11 Thread Enrico Weigelt
* Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org schrieb:

 just because you decided to offer some service, it in no way forces
 us to accept it.

No, it does not. I never claimed that.

And so really I dont understand that fundamentalistic kind of
argumentation (which is really near to ranting).

 With your proposal, you're expecting us (distro maintainers) to put our
 trust and our users safety in you and your service - what made you think
 we would or should do it? 

Not at all, please refer to my other answer (some minutes earlier).

  Well, Gentoo is short of manpower ? hmm, perhaps some should think
  about why so many folks are resigning and so few fresh coming in
  (at least according to this lists traffic) ;-O
 
 This type of argument when you're trying to convince others to use your
 service is in the least a disservice to your purpose.

That particular argument is not about the OSS-QM project, but the 
general social climate @Gentoo. Actually, when talking to collegues,
most of them share this. The most commonly used term I've heared 
from them about Gentoo devs is total lack of social competence.
(to be fair: this also applies to lots of other OSS projects).


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-10 Thread Enrico Weigelt
* Robin H. Johnson robb...@gentoo.org schrieb:

Hi,

  It's an improved version of procmail, which automatically creates
  missing maildir directories.
 Stock procmail does this already.
 
 From procmailrc:
 If the mailbox is specified to be an MH folder or maildir folder,
 procmail will create the necessary directories if they don't exist,
 rather than treat the mail??? box as a non-existent filename.

Only applies to maildir mailboxes, not mbox. The problem is: if
you have mbox'es in subdirs which dont exist yet, procmail fails.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] svga useflag (media-libs/svgalib)

2010-07-10 Thread Enrico Weigelt
* Tomá?? Chvátal scarab...@gentoo.org schrieb:

Hi,

 there are few left packages that still have svga useflag and depend on
 svgalib.
 
 To my best knowledge that stuff has been deprecated to not be used. So
 my question is which one of the following we should start:

Well, if there still are packages where libsvga stuff works, it IMHO 
should stay. Nobody knows who's still using it. But it probably doesnt
have to be a global useflag.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-10 Thread Enrico Weigelt
* Samuli Suominen ssuomi...@gentoo.org schrieb:
 On 07/08/2010 01:56 AM, Enrico Weigelt wrote:
  
  Hi folks,
  
  
  YFYI: yet another of my ebuilds kicked-down.
  
  It's an improved version of procmail, which automatically creates
  missing maildir directories.
 
 Provide your patches as plain/text attachments like everyone else does,

I've already explained the strategy behind the git repo (and not 
doing plaintext patches). Please refer to my paper, and my other
mails posted recently on this list.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] RFC: making revdep-rebuild more quiet

2010-07-10 Thread Enrico Weigelt

Hi folks,


i'd like to suggest an option for making revdep-rebuild more silent:

Passing -q twice should make it output only if it really has 
something to do (found broken stuff and wants to emerge), so we can 
simply put it into an crontab entry to get a mail when something
really happens. 

What do you think about this ?


(I admit, I didnt have the time to dive into portage codebase yet
and hack up something ... ;-o)


cu 
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



[gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-07 Thread Enrico Weigelt

Hi folks,


YFYI: yet another of my ebuilds kicked-down.

It's an improved version of procmail, which automatically creates
missing maildir directories.


cu

- Forwarded message from bugzilla-dae...@gentoo.org -

From: bugzilla-dae...@gentoo.org
Subject: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs
To: weig...@metux.de
Reply-To: DO NOT REPLY devn...@localhost.invalid
Date: Wed,  7 Jul 2010 20:06:53 + (UTC)

DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:

Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=322157
Secure: https://bugs.gentoo.org/show_bug.cgi?id=322157


ssuomi...@gentoo.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Comment #2 from ssuomi...@gentoo.org  2010-07-07 20:06  ---
The SRC_URI is pointing to something unofficial, so this is a WONTFIX.

-- 
Configure bugmail: https://bugs.gentoo.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.

- End forwarded message -

-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--



Re: [gentoo-dev] zlib ebuild from OSS-QM

2010-07-06 Thread Enrico Weigelt
* Sebastian Pipping sp...@gentoo.org schrieb:

  While I may lacking understanding that the zlib maintainers in Gentoo do
  have, your changes look self-explaining to me.
 
 ^ do not missing, sorry.

Which changes dont you understand ?
I'll be happy to answer all questions :)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] zlib ebuild from OSS-QM

2010-07-06 Thread Enrico Weigelt
* Jeremy Olexa darks...@gentoo.org schrieb:
 On Mon, 5 Jul 2010 18:48:43 +0200, Enrico Weigelt weig...@metux.de
 wrote:
  Hi folks,
  snip
  please refer my recent postings on details what the oss-qm
  project is all about. just a few words: the main idea is to
  snip
 
 Enrico, There are actually so many 404s on your homepage (including
 both links in your email signature) that it quickly loses my attention
 span.

Which ones ?
(I know, some old stuff is broken, I didnt have the time to 
clean it all up yet ;-o)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 326991] Testing release of sys-libs/zlib-1.2.5.3 from unofficial sources (???)]

2010-07-06 Thread Enrico Weigelt
* Peter Volkov p...@gentoo.org schrieb:

 Enrico I don't see why we may need to maintain separate ebuilds for
 programs with patches scheduled upstream. 

This all is part of a bigger strategy, we've already discussed here.
See: http://www.metux.de/download/oss-qm-project-2010050101.pdf

 Submit important patches separately or, better, 

The whole idea is getting rid of individual patches, instead use a 
modern VCS. If you don't like to take the METUX.* branches, I'll be 
lucky to open (and even maintain) separate GENTOO.* branches.

 work with upstream so we'll get everything with next upstream release.

Actually, I'm already doing so for quite some time now.
But often cannot/doesnt want to apply hotfixes ad-hoc. That's what
OSS-QM for: provide downstream branches for distros, embedded 
maintainers, etc.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] zlib ebuild from OSS-QM

2010-07-06 Thread Enrico Weigelt
* Sebastian Pipping sp...@gentoo.org schrieb:
 On 07/06/10 22:04, Enrico Weigelt wrote:
  Enrico, There are actually so many 404s on your homepage (including
  both links in your email signature) that it quickly loses my attention
  span.
  
  Which ones ?
  (I know, some old stuff is broken, I didnt have the time to 
  clean it all up yet ;-o)
 
 Take the two embedded to your signature, for example.
 I reported this to you two months ago.
 Re-checked now, still broken.

ups, I forgot that I've still configured this ancient signature
for this list ;-o


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] creating git repos via ebuild

2010-07-06 Thread Enrico Weigelt

Hi folks,


I'm looking for a way for transforming ebuild's src_prepare 
actions into git commits. I guess it would involve tweaking
epatch to do git-apply calls etc.

Did anyone else already work in this area ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo

2010-07-05 Thread Enrico Weigelt
* Brian Harring ferri...@gmail.com schrieb:

 Requiring policykit, let alone networkmanager and dbus as a default is 
 not something I'd personally agree with as a sane choice.  If you're 
 trying to build *just* a desktop distro, sure, it's sane.  We're not 
 however, thus invalidating those options from where I'm sitting.

ACK. I'd never put any system into production which requires dbus,
no change.

Maybe I'll find some time to rewrite systemd w/ dbus. 
The overall concepts seem very promising to me - quite the same
direction I'm planning to go into.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo

2010-07-05 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:

 What you are saying makes sense for desktop users since they will
 likely already have consolekit/policykit/nm-applet installed, and
 hence using NetworkManager for all network management makes sense.

Actually, I've got several Gentoo-based desktop systems, none of 
them uses any these packages.

 From what I can see, we have three options:
 (a) Make our existing openrc network code + openrc configuration files
 work with systemd, and move to systemd by default
 (b) Make systemd work with openrc+NM configuration files[1], make NM
 work w/o PK/CK[2], add command line tools to NM, and move to systemd
 by default.
 (c) Support systemd as an alternative init system for use by desktop users.

  (d) Fix systemd to get rid of dependencies to dbus, etc.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] zlib ebuild from OSS-QM

2010-07-05 Thread Enrico Weigelt
Hi folks,


here's an ebuild for zlib, which takes a fixed source from the
oss-qm project. it contains several fixes and cleans up ugly
hacks in the current ebuild (eg. directly sed'ing sources ;-o).

please refer my recent postings on details what the oss-qm
project is all about. just a few words: the main idea is to
solve problems at the source, provide generic downstream 
branches (which get rebased onto upstream) instead of single 
(often unncessarily distro-bound) patches.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/zlib/zlib-1.2.5.ebuild,v 1.2 
2010/04/20 20:34:54 vapier Exp $

inherit eutils toolchain-funcs

DESCRIPTION=Standard (de)compression library
HOMEPAGE=http://www.zlib.net/;
SRC_URI=http://pubgit.metux.de/download/oss-qm/zlib/METUX.zlib-${PV}.tar.bz2;

LICENSE=ZLIB
SLOT=0
KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh 
~sparc ~x86 ~sparc-fbsd ~x86-fbsd
IUSE=

RDEPEND=!dev-libs/libxml2-2.7.7 #309623

src_compile() {
cd `find -maxdepth 1 -type d -not -name .` || die
case ${CHOST} in
*-mingw*|mingw*)
cp zconf.h.in zconf.h
emake -f win32/Makefile.gcc prefix=/usr STRIP=true 
PREFIX=${CHOST}- || die
;;
*)  # not an autoconf script, so cant use econf
./configure --shared --prefix=/usr --libdir=/usr/$(get_libdir) 
|| die
emake || die
;;
esac
}

src_install() {
cd `find -maxdepth 1 -type d -not -name .` || die
case ${CHOST} in
*-mingw*|mingw*)
emake -f win32/Makefile.gcc prefix=/usr install DESTDIR=${D} 
|| die
dodoc FAQ README ChangeLog doc/*.txt
dobin zlib1.dll || die
dolib libz.dll.a || die
;;
*)
emake install DESTDIR=${D} || die
dodoc FAQ README ChangeLog doc/*.txt
gen_usr_ldscript -a z
;;
esac
}


[gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 326991] Testing release of sys-libs/zlib-1.2.5.3 from unofficial sources (???)]

2010-07-05 Thread Enrico Weigelt

Hi folks,


does he speak for all of you ?


- Forwarded message from bugzilla-dae...@gentoo.org -

From: bugzilla-dae...@gentoo.org
Subject: [Bug 326991] Testing release of sys-libs/zlib-1.2.5.3 from unofficial 
sources (???)
To: weig...@metux.de
Reply-To: DO NOT REPLY devn...@localhost.invalid
Date: Mon,  5 Jul 2010 19:39:48 + (UTC)

DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
whose email is mentioned below. To comment on this bug, please visit:

Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=326991
Secure: https://bugs.gentoo.org/show_bug.cgi?id=326991





--- Comment #4 from vap...@gentoo.org  2010-07-05 19:39  ---
lemme clarify further: dont bother submitting ebuilds for any package in
OSS-QM.  we arent interested.

-- 
Configure bugmail: https://bugs.gentoo.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.

- End forwarded message -

-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-28 Thread Enrico Weigelt
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:

 PHP and mplayer both have 100 USE flags. There's not enough 
 CPU power in the world.

We don't have to try *all* possible combinations, but only those
differing in interfaces (eg. if some libfoo changes its exported
interface on a userflag, the clients have to be built against
that two versions). It involves some interface analysis and a bit
of graph theory. Should be possible to do it incrementally. 


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:

 Or if they generate the tarball on-the-fly with no caching, which
 results in differing timestamps each time. Hence, each time you fetch
 it, you get a tarball with a different hash.

Does portage check the timestamps ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
 On Sat, 26 Jun 2010 22:09:09 +0200
 Enrico Weigelt weig...@metux.de wrote:
  Well, with git this works. (I'll yet have to run some automatic
  stress tests, but at all my manual tests worked really fine).
 
 You assume that, given the same input and program options, a
 compression program will always produce the same output. This is not
 the case.

Well, at least for tar, I've experienced no problem here yet.
But: true, it might change between tar versions.

A more sophisticated approach, IMHO, would be: directly fetching
from the VCS, but that would probably mean a major design change.
(my Briegel buildsystem goes this way ... it doesnt even patch
on itself anymore, thats done entirely in git)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Nikos Chantziaras rea...@arcor.de schrieb:

 Did it actually occur to anyone that warnings are not errors?  You can 
 have them for correct code.  A warning means you might want to look at 
 the code to check whether there's some real error there.  It doesn't 
 mean the code is broken.

In my personal experience, most times a warning comes it, the
code *is* broken (but *might* work in most situations).
So, developers should always enable it and think ten times
if some warning is acceptable.

But: you all conviced me. These flags should be controlled by the 
distro buildsystem, not the individual package. Developers just
should take care that there're no preventable warnings.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Sergei Trofimovich sly...@gentoo.org schrieb:

 I suggest you to try latest available dev-lang/icc (11.1.072).
 This thing is really paranoid:
 
 remark #2259: non-pointer conversion from int to unsigned char may lose 
 significant bits
   unsigned char BlinkerPhase = 0;
   ...
   BlinkerPhase = (BlinkerPhase + 1)  3;

In this case, the compiler is wrong: it should convert to
int and back to char here ;-p

 remark #981: operands are evaluated in unspecified order (tons of them)
   return strcmp( left.c_str(), right.c_str() )  0;

I'm not sure if this really qualifies an warning, since - AFAIK -
C spec never said, that there is an evaluation order for 
function parameters.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Rémi Cardona r...@gentoo.org schrieb:

 We currently offer 11 different slots of GCC, 3 of gcc-apple, each with
 multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7
 versions of icc, so in all 26 *major* versions. You do well know that
 each compiler prints out different warnings for the *same* code...

hmm, perhaps I'll hack some little scripts which create a jail/container
for each compiler version and triggers emerge within them.

 We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions
 of klibc. Each version may have header bugs, so may trigger warnings for
 perfectly good code.

Well, if there're header bugs, shouldn't they get fixed before these
libs are stabelized ? ;-O

 And finally we offer 5 unmasked versions of binutils (newer ones even
 have a brand new linker - gold) and 5 versions of binutils-apple. Again,
 different tools, different warnings...

Okay, adds *10 to the test matrix. Still not yet an too complex 
problem (still linear complexity).

 -Werror is a perfectly fine *developer* feature. For example, Gnome
 autoconf macros enable it for development snapshots, but never ever
 enable it for stable releases.

Okay, aggreed. I've reworked my rule, now:

package build systems MUST NOT enable -Wall -Werror (unless explicitly 
asked), but developers SHOULD use them for their test builds


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:

  Well, at least for tar, I've experienced no problem here yet.
  But: true, it might change between tar versions.
 
 The main offender is the compression program, not tar.

hmm, I'm exclusively using bzip2 and never had these problems
yet. maybe it depends on the compressor type.
 
  A more sophisticated approach, IMHO, would be: directly fetching
  from the VCS
 
 Yes, upstreams are going to love you for that...

Why ? Because of traffic ? Of course, distros should work 
from their own clones (yes, yes, I'm assuming modern VCS'es, 
not toys like svn ;-p)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages

2010-06-27 Thread Enrico Weigelt
* Harald van D??k true...@gentoo.org schrieb:

 The compiler is not totally free to ignore the register keyword. Both
 the C and the C++ standards require that the compiler complain when
 taking the address of a register variable. Other compilers will issue a
 hard error for it. Fixing the code to not declare the variable as
 register would be the correct thing to do.

BTW: is the register keyword still so useful nowadays ?
Shouldn't a modern (optimizing) compiler be clever enough to 
find out when it can use registers instead of RAM ?

 Make sure you *understand* warnings, and then you can decide whether to
 fix the code, if there is anything to fix, or to ignore.

hmm, is there a (portable) way to prevent a specific warning
in an specific place ? (some kind of #pragma ?)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Krzysztof Pawlik nelch...@gentoo.org schrieb:

 Take a look at this page:
 http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is 
 Java
 specific mostly, but some general points can be reused :)

Hmm, this document suggests something, I just forgot to prohibit:

Release the source archives along with whatever binary archives you may have.
^

cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Alistair Bush ali_b...@gentoo.org schrieb:

 Is this language specific?  

I'll try to separate it into generic and language specific 
rules step by step (same for various build systems, etc).

 would you be interested in comments about java, ruby, python, 
 etc, etc, etc or are you only interested in good old C/C++, etc

Just give me everything you've got :)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Petteri Räty betelge...@gentoo.org schrieb:

 There should be useful stuff here:
 http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv

#1 he says nothing about that - if upstream has a VCS (and properly 
uses it ;-o) - the distros should use it, so eg. set their branches 
ontop the upstream's release tags instead of manually maintaining
patches against tarballs ...

#2 One point i don't agree is the dont add -Werror rule. actually,
i'm thinking of making -Wall and -Werror mandatory. if some
package doenst build fine, it's simply broken. period.

#3 When he's talking about disabling dependencies, he most likely
has the totally wrong concept in mind (as probably most Gentoo
folks ;-p): you naturally dont want to enable/disable dependencies,
but features (which then imply certain dependencies). Once you 
use terms like zlib support, you're already on the wrong path.

#4 The discussion about how to be a good downstream (started by
the ffmpeg guy) is quite interesting ... that's exactly the 
kind of situations what the OSS-QM (see my recent posts) is for.
(and all goes sooo easy w/ tools like git ;-p)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Krzysztof Pawlik nelch...@gentoo.org schrieb:

  Hmm, this document suggests something, I just forgot to prohibit:
  
  Release the source archives along with whatever binary archives you may 
  have.
  ^
 
 You intend to prohibit releasing binary packages for upstream? 

No, I'm talking about precompiled stuff within the source tree.
Such things should _never ever_ happen.

In Java world it seems to be quite common to bundle precompiled 
imported libraries within the source tree. Needless to say that
this can easily get hell for any package-based distro.
(actually, that mostly comes from the windows front, where 
concepts like package management are quite unknown ... ;-o)

 What's important in quoted sentence is: Release the source archives along 
 with
 binary archives - the with is very important - in short: don't release only
 binary versions and force us to grab them from VCS.

Okay, perhaps I misunderstood this sentence.

BTW: if upstream has an proper VCS and an canonical tagging 
scheme, they don't actually have to create release tarballs,
just hack up a little script which creates them on-the-fly
from an canonical URL scheme (eg. oss-qm does exactly that).


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
 On Sat, 26 Jun 2010 21:39:15 +0200
 Enrico Weigelt weig...@metux.de wrote:
  #2 One point i don't agree is the dont add -Werror rule. actually,
  i'm thinking of making -Wall and -Werror mandatory. if some
  package doenst build fine, it's simply broken. period.
 
 Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if
 you -Wall.

Warn on what exactly ? Which compilers do that ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Krzysztof Pawlik nelch...@gentoo.org schrieb:

  Down that path lies madness. There's no guarantee that you'll get the
  same tarball if you request the same URL twice in a row, particularly
  if you're using one of those new-fangled new compression schemes.
 
 I agree with Ciaran here, to add one more thing: tags can be mutable.

Thats a matter of proper VCS configuration (hooks, etc)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-26 Thread Enrico Weigelt
* Ciaran McCreesh ciaran.mccre...@googlemail.com schrieb:
 On Sat, 26 Jun 2010 21:46:39 +0200
 Enrico Weigelt weig...@metux.de wrote:
  BTW: if upstream has an proper VCS and an canonical tagging 
  scheme, they don't actually have to create release tarballs,
  just hack up a little script which creates them on-the-fly
  from an canonical URL scheme (eg. oss-qm does exactly that).
 
 Down that path lies madness. There's no guarantee that you'll get the
 same tarball if you request the same URL twice in a row, particularly
 if you're using one of those new-fangled new compression schemes.

Well, with git this works. (I'll yet have to run some automatic
stress tests, but at all my manual tests worked really fine).
*If* this might not work somewhere, the little generator script
could create the tarball only once (on first request) and use
it all the time. Or add some commit/push hook, etc, etc.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-25 Thread Enrico Weigelt

Hi folks,


I'm currently collecting a set of rules which upstream developers
should follow to make distro maintainer's life easier.

Comments welcomed :)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] paper on oss-qm project

2010-05-16 Thread Enrico Weigelt
* Sebastian Pipping sp...@gentoo.org schrieb:

Hi,

  what problems do you see w/ licensing ?
  
  IMHO, each branch simply has to follow the upstream's license.
 
 i have yet to see easy cases with licensing.
 i haven't thought about it in detail yet, tough, to be honest.

well, let's just see if the first realworld case happens and then
think about it ;-p
  
  simply normalize: don't use letters but numbers.
 
 i don't believe in simple normalization before i have seen it.

well, the right normalization scheme always depends on the upstream's
versioning scheme. most packages already have some consistent scheme,
which can be mapped directly. the few really complicated cases
(actually don't have any at the tip of my head right now) have
to be done manually. remember that we only take stable releases,
since we're in the dist maintainer role - not the upstream dev one
(so, alpha's etc dont matter here)

  b) it's not really a release but just a development snapshot - 
 that doesnt belong into the main oss-qm repository
 
 why doesn't it belong in there?

because it's not ready to use. that's the primary distinction:
snapshots are for devs (and maybe testers), not for production use.

  I've chosen that scheme to make the borders more clear (also for
  automatic filtering, etc). In my concept, the vendor is the major
  point of distinction, package comes at second, ... 
 
 i guess we agree to disagree then.
 i don't think the current scheme promotes cooperation well.

why exactly ?

BTW: if you dont like that scheme, you could add some filter for
automatically rewrites the refnames ;-p

  Well, the term vendor here is defined as a party which provides
  packages in certain variants. UPSTREAM is a kind of meta vendor,
  describing the upstreams. Vendor is IMHO more generic, since there
  may be vendors who aren't actually a real distro. For example, I 
  myself don't publish a complete distro, but a foundation for clean
  building especially for special embedded devices or appliances.
 
 yes, that's why i proposed downstream as a replacement.
 you don't consider yourself downstream?

*I* am downstream, right. But the UPSTREAM+* branches are what's 
coming from the upstream. Upstream's a special kind of (meta-)vendor,
where everybody else (downstreams) forkes from.

  Yes, that's still an open topic. I've chosen to use one big repo
  for easier maintenance, but I'm aware of the problem that the
  repo might become very fat some day.
 
 my point is not about size, only about users.

In which way does my current approach make trouble here ?
What would be the better approach ? 

  I see two options:
  
  a) split it off into several ones, eg. on per-package basis
 and create a system for (semi-)automatic mass-repo maintenance
 (not completely trivial when using free git hosters as mirrors)
 
 are you aware that splitting it up will reduce the savings in space?
 say if they all had byte-identical GPLv3 COPYING files that would be one
 blob atm and N blobs in split mode.

Right, that's the tradeoff here. But the few COPYING files shouldnt be
the big issue ...

  b) add an selective filtering system. AFIAK current stable git
 doesnt provide that yet - I've added an little patch for that:
 
  http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.git.master
 
 while i'm not sure about this in detail yet, could it be this loop
 misses to filter the very first entry?
 
 +   while (walk  (walk-next))
 +   {
 +   if (_filter_remote_ref(transport, walk-next))
 +   walk-next = walk-next-next;
 +   else
 +   walk = walk-next;
 +   }
 +

you missed the previous lines ;-P

+   while ((transport-remote_refs)  (_filter_remote_ref(transport, 
transport-remote_refs)))
+   transport-remote_refs = transport-remote_refs-next;
+

cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] paper on oss-qm project

2010-05-08 Thread Enrico Weigelt
* Sebastian Pipping sp...@gentoo.org schrieb:

Hi,

 interesting concept.  i'd like to comment on a few details:
 
  - licensing seems not be addressed, yet.
licensing can kill everything, it needs consideration.

what problems do you see w/ licensing ?

IMHO, each branch simply has to follow the upstream's license.

  - branch and tag namespaces as currently defined have a few problems:
 
- versioning:
 
  - the A.B.C.D scheme won't be fun to gentoo, both
due to no-letters-in-here and because of no-pre-releases.
while at that keeping pre-releases does not seem helpful to me.

simply normalize: don't use letters but numbers. and I actually don't
see any need for pre-releases: 

a) it' an real release - then it has to fit into the (linear) 
   versioning scheme
b) it's not really a release but just a development snapshot - 
   that doesnt belong into the main oss-qm repository
 
- vendor concept:
 
  - uppercase vendor names look rather odd, especially with project
names in lowercase.
 
  - having the vendor first makes no sense to me.
a package.vendor.subbranch keeps all zlibs together,
instead of all gentoo stuff.  if the project is about
packages, that makes more sense to me.

I've chosen that scheme to make the borders more clear (also for
automatic filtering, etc). In my concept, the vendor is the major
point of distinction, package comes at second, ... 

  - renaming the concept to downstream would make it
fit better.  gentoo is not a vendor to me.

Well, the term vendor here is defined as a party which provides
packages in certain variants. UPSTREAM is a kind of meta vendor,
describing the upstreams. Vendor is IMHO more generic, since there
may be vendors who aren't actually a real distro. For example, I 
myself don't publish a complete distro, but a foundation for clean
building especially for special embedded devices or appliances.

  - with one git repo used for many packages people
will need to know how to clone single branches only.
most git users probably won't, you will need to teach them.
the PDF seems a good place to do that.

Yes, that's still an open topic. I've chosen to use one big repo
for easier maintenance, but I'm aware of the problem that the
repo might become very fat some day. I see two options:

a) split it off into several ones, eg. on per-package basis
   and create a system for (semi-)automatic mass-repo maintenance
   (not completely trivial when using free git hosters as mirrors)

b) add an selective filtering system. AFIAK current stable git
   doesnt provide that yet - I've added an little patch for that:
   http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.git.master
   

cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] A policy to support random superuser account names

2010-05-02 Thread Enrico Weigelt
* Alec Warner anta...@gentoo.org schrieb:

 Except as stated they are not fixed (as Fabian pointed out).  I'm
 happy to support something like setting ROOT_UID and ROOT_GID in
 gentoo-x86 profiles and using those.  Then if you want to do something
 utterly ridiculous to your system you can just set the appropriate
 variables.

ACK. But it should also be possible to specify names here 
(not just numerical IDs), just in case the underlying kernel
doesnt have numerical UIDs at all ...


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] A policy to support random superuser account names

2010-05-02 Thread Enrico Weigelt
* Krzysztof Pawlik nelch...@gentoo.org schrieb:

 Interesting... to me that's not only stupid but also kinda useless - there's 
 no
 difference between brute-forcing a password for user named 'foo' or 'root' -
 user name doesn't matter much. Actually according to my ssh logs attackers
 usually don't even try root, they try other user account names way more often.

ACK. And if you're really frightened of someone cracking the user root's 
password/key, you simply could lock that account and add another superuser.

Keep in mind, these BSI guys are beaurocrats, not hackers. If they were
hackers, they'd prefer source distros over binary ones to add more randomness
to the overall installed machine code ... 


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] paper on oss-qm project

2010-05-02 Thread Enrico Weigelt
hi folks,

just in case anybody's interested:

I've written a little paper on the OSS-QM project, which aims to
provide fixed sourcetrees to many packages+versions and so offload
much of the QM/patching work from individual distros to a common
place:

http://www.metux.de/download/oss-qm-project-2010050101.pdf

cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] A policy to support random superuser account names

2010-05-02 Thread Enrico Weigelt
* Stefan Behte cr...@gentoo.org schrieb:

 in some environments you have to rename root to something else, just
 to be compliant to a (maybe dumb) security policy. This might be the
 case for PCI, and as far as I remember, it is necessary (not just
 recommended) for a BSI Grundschutz certification (meaning something
 like basic security protection) [1]. Unfortunately I didn't find the
 exact link.

Well, the BSI probably isn't such a good reference point. They officially
approved secure infrastructures for govermental crimes ... ;-o


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files

2010-04-30 Thread Enrico Weigelt
* Daniel Pielmeier bil...@gentoo.org schrieb:

 What about searching the complete file system but using an exclude file where
 you can put directories and files which should not be searched. It is tedious 
 to
 tell every path on the command-line. Also for instance if you specify /lib it
 will also search under /lib/modules and I am sure you do not consider all
 contents there as unneeded.

hmm, perhaps there's some way to assign these files to some package ?
 
 You also need to consider that your tool will return other false positives 
 like
 byte compiled python modules and perl header files. In general everything an
 ebuild does in phases where it adds files to file-system but files are not
 stored to CONTENTS (pkg_{pre,post}inst). At this point the files are needed 
 but
 not recognized by the package manager. If the ebuild does not take care of 
 this
 files when removing (pkg_{pre,post}rm) the package they will remain on the
 file-system and are now unneeded.

Assuming these files are not optional/temporary (aka: can be regenerated on
the fly), I see a generic design problem here: everything belonging to some
package (excluding content data and configs, of course) should be assigned
to the package.

The big Q: how can we achieve this ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel

2010-04-30 Thread Enrico Weigelt
* Luca Barbato lu_z...@gentoo.org schrieb:

 I wonder if that case shouldn't be handled better with an huge ewarn so
 people concerned would really run it in a benchmark environment, alone.

ewarns should be circumvented (make it work w/o them), IMHO.

I can imagine I'm not the only person who doenst want to keep
an close eye on each single build/merge.

In this concrete example, the package's build system is misdesigned.
They shouldn't rely on runtime benchmarks for build time decisions
in the first place - this is unpredictable. But this is not an
issues distros should have to cope with.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-04-07 Thread Enrico Weigelt
* Maciej Mrozowski reave...@gmail.com schrieb:

Hi,

 Apart from PDEPEND, one change needed as well in cups ebuilds:
 --with-pdftops pdftops
 needs to be replaced with
 --with-pdftops=/usr/bin/pdftops
 
 as otherwise it will fail during configure phase (giving absolute path 
 disables autodetection)

Hardcodig a pathname is not a good idea, IMHO.
If ./configure really insists on autodetection when given name is
not absolute, we should fix the source ;-p

 cups can use either poppler or ghostscript as pdf-to-ps filter, 
 so given the fact that ghostscript is already a dep of cups, 
 maybe --with-pdftops=gs could be used instead to avoid poppler 
 dependency completely, but that's up to cups maintainers to 
 determine whether it's safe/desired.

hmm, does it _really_ need gs, even when pdftops is used ?

maybe we could move out this whole issue to an wrapper script
(configurable via eselect) ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-04-07 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:
 On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot yng...@gentoo.org wrote:
  Would it be possible to make cups a PDEPEND in gtk+ or is it really
  needed at compile time?
 
 
 cups is definitely needed at compile-time

Does anyone know what exactly for ?
Didnt have the time for an deeper investigation, but if an widget
toolkit requires an printing service, something really strange
is happening, IMHO ... ;-o


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-04-07 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:

 If it turns out there is no easier way of properly fixing this, 
 we may have to split poppler-utils out from poppler. 

ACK. Having separate packages for public libraries and utils
which just happen to use these libs should be the default case.
Not just because of circular deps - which, in 99.99% have 
absolutely _no_ technical reason, beside certain people's mental 
lazyness (at least that's what my about 20yrs swe experience 
shows up ;-o) - but also a matter of clean sw design.

This should start at the source, so if upstream doesnt want to
fix this, let's fork. (i'm hereby volunteering as maintainer).


cu

PS: please no we're not debian-flamewars ;-o
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-04-07 Thread Enrico Weigelt
* Ben de Groot yng...@gentoo.org schrieb:

 Or maybe the gtk+ maintainers want to split up their package... 

Actually, that would be a big step forward ...


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-04-07 Thread Enrico Weigelt
* Nirbheek Chauhan nirbh...@gentoo.org schrieb:

  Does anyone know what exactly for ?
  Didnt have the time for an deeper investigation, but if an widget
  toolkit requires an printing service, something really strange
  is happening, IMHO ... ;-o
 
 
 Download the gtk+ tarball and take a peek inside ./modules/printbackends/cups
 
 You'll find your answer there.

Yes, sometimes answers you'd even wouldn't like to know ;-o

Folks, these gtk guys are on bad drugs (well, that's not sucha
new enlightenment ;-o) ...

a) gtk-printer backends are separate *shared* libraries, which
   are loaded somewhere at runtime. absolutely no need to ship
   and build them within the gtk+ tree
 
b) the whole gtk-printer api might be a nice thing (even i just
   have a dozen of better solutions at the tip of my head ;-o),
   but I can't see any technical reasons for having that all
   within a widget toolkit, instead of a separate library.


hmm, time for a fork ? ;-)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] midnight commander - which screen library

2009-02-07 Thread Enrico Weigelt

Hi folks,


@mc.o (*1) we're currently discussing which screen library to keep.
Either ncurses or slang will be dropped (bundled slang will anyway)
Both have their pros and cons, so we haven't decided yet.

What do you suggest, which screen library to keep ? 

BTW: 4.6.2 is soon coming (only 1 bug left) :)


cu

[1] http://www.midnight-commander.org/
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



[gentoo-dev] Announce: red5 overlay available for testing

2008-10-23 Thread Enrico Weigelt

Hi folks,


YFYI, I've written a bunch of ebuilds for red5 and its deps:

svn://anonymous:[EMAIL PROTECTED]/public/red5/gentoo-overlay


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-



Re: [gentoo-dev] Re: Re: Multislot dependencies

2008-07-01 Thread Enrico Weigelt
* Gilles Dartiguelongue [EMAIL PROTECTED] schrieb:
 Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit :
  big_snip
  
  Funny, how you all manage to make simple things complicated ;-o
  
  I guess nobody considered an trivial solutions like an useflag ...
 
 no, this is not the proper solution. Just consider how bad gtk/gtk2
 useflag was and that was with only 1 package with 2 slots. 

Well, some of you might still remember what I said about gtk and
slots long time ago. Just to summarize my point:

* the use of slots should be MINIMIZED. IMHO, the kernel is one
  of the few valid uses, gtk is NOT (1.* and 2.* are *different* 
  packages and so should be treated differently). 

* at runtime an most packages need that variant/slot they were
  built for (and gtk1'ed package needs gtk-1.x, NOT gtk-2.* and
  vice versa)
  
* often the slots are just necessary because the upstream's 
  bad code design. IMHO, if a package doesn't have *clean* 
  dependency tree, it's simply not a package, but just a 
  bunch of code ;-P
  
 Now think about say db (berkeleydb) or gtkhtml (and I'm still 
 probably overlooking the most important point).

What's exactly the problem with that packages ?


BTW: maybe many things would be easier, if portage itself could
differenciate between source and binary packages, but that might
be a too big step ;-o


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: RFC: Installation of static libraries, USE=static-libs proposal

2008-07-01 Thread Enrico Weigelt
Hi,

snip

I'm really curious to know why a new (global) useflag couldn't
do the trick.

Let's say, we introduce a new useflag called static-libs and
enable it by defaulin all profiles. Then we can have a look at
the lib packages step by step and add support when it seems 
useful there and test out carefully. There's no presure to this
for the whole distro at once.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Multislot dependencies

2008-06-30 Thread Enrico Weigelt

big_snip

Funny, how you all manage to make simple things complicated ;-o

I guess nobody considered an trivial solutions like an useflag ...


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Removing .la files...

2008-06-20 Thread Enrico Weigelt

Hi folks,

why not just introducing an staticlib useflag:
when disabling this, all the static library stuff is kicked off.

For those libs where the static stuff is needed, just leave it 
enabled. And packages which really depend on static libs could
check for the proper useflags.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary

2008-06-09 Thread Enrico Weigelt
* Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] schrieb:

Hi,

 Upstream doesn't always know better for our setup (it may try to second

there are also a lot of other things, upstream tends not to know ;-P

 guess our settings by looking for particular automake/autoconf
 versions), it will show to the user information we don't care about,

ah, don't forget those upstreams (eg. mozilla) who are too lazy for
fixing their stoneage'd configure.in's for a more recent autoconf 
version, instead invest enormous amounts of time in writing whole 
books about why they're unwilling to have a look at ready-to-run
and well tested patches.

 almost all the bootstrap scripts I've seen don't even try to catch when
 a step in the rebuild fails, they mask the need for autotools, and as
 you don't inherit autotools eclass for running them, you usually forget
 to add the autoconf/automake dependencies. And it makes very difficult
 to track down which ebuilds do actually use autotools to track down if
 there are changes to do.

hmm, isn't it obvious that these scripts are just for the (upstream)
devs themselves ?

they belong into my (manual ;-)) veryclean stage when starting to
work on some package, same as ./configure, aclocal.m4, etc, etc ;-P
(for a clean start, I normally wipe out *everything* that's autogenerated)

 Let's not even start to talk about bootstrap scritps that run
 ./configure by themselves, those are just plainly evil.

ACK. We should instead ask the upstream for cleaned-up releases ;-)

Actually, I wouldn't even take the shipped ./configure scripts - 
I *always* run the whole autoreconf chain on a fresh tree.

 Please note that sometimes the bootstrap script is used to add extra m4
 search directories and options like --foreign to automake. Well, here's
 the deal:
 
 - AT_M4DIR is the variable to use to pass extra m4 search directory to
   aclocal, no need for the bootstrap script;
 - eautomake takes care by itself to identify the cases where --foreign
   is needed (this usually means when some of the standard documentation
   files are missign);

I prefer to fix these broken configure.in's ;-P

 Also make sure that autotools gets not rebuilt through maintainer mode,
 that will make the configure run twice, wasting users' time, and is
 usually evil if you are using unpack to check for the generated
 configure (yes it happened to me a couple of time).

That strange maintainer mode is one of the things on my to-rip-off 
list, along with the rules for regenerating the configure script.
(which sometimes tends to loop forever) ;-o



cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] merging two packages - upgrade path?

2008-06-09 Thread Enrico Weigelt
* Matthias Schwarzott [EMAIL PROTECTED] schrieb:

 Well, upstream is just one file/package: vdr-streamdev-0.3.4.tgz

What I suspected.

Actually, I'm not interested in that package. Otherwise there
already would be a fork which keeps that separation.

 But we want to revert this now, because splitting leads to more 
 maintainance effort as both ebuilds are almost the same.

If upstream would do it's homework, there would be almost
no ebuild maintenance work at all ;-P


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: lzma tarball usage

2008-05-17 Thread Enrico Weigelt
* Mart Raudsepp [EMAIL PROTECTED] schrieb:

big_snip /

IMHO, lzma is far from being mature enough from being suited as 
packaging format for production systems. And actually, I don't 
see the benefit over well-approved tar+(gz|bz2). 

So my vote is to NOT use it for gentoo source packages.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: lzma tarball usage

2008-05-07 Thread Enrico Weigelt

Hi,


I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to 
save a few bytes IMHO isn't worth it.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] RFC: qemu - add gcc-3.x dependency

2008-05-05 Thread Enrico Weigelt

Hi folks,


I'm just installing qemu, which requires gcc-3.x for building. 
The current breaks are very ugly, IMHO. 

So I'm proposing to add the old gcc-3.x as depedency to qemu,
at least as long as it doesn't build w/ newer gcc. 

What do you think about this ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: qemu - add gcc-3.x dependency

2008-05-05 Thread Enrico Weigelt
* Peter Volkov [EMAIL PROTECTED] schrieb:
 ?? ??, 04/05/2008 ?? 21:48 +0200, Enrico Weigelt ??:
  I'm just installing qemu, which requires gcc-3.x for building. 
  The current breaks are very ugly, IMHO. 
  
  So I'm proposing to add the old gcc-3.x as depedency to qemu,
  at least as long as it doesn't build w/ newer gcc. 
  
  What do you think about this ?
 
 How do you suppose to change gcc version portage uses on-the-fly?

* add an small gcc3-wrapper script/symlink (eg. /usr/bin/gcc-3)
* rewrite the qemu ebuild to properly set $CC, etc.

 Please, answer trough bugzilla where most bug reports/feature requests
 should normally go.

Is there already an open bug on this ?


BTW: even with gcc-3.x qemu fails to build. this has been reported
multiple times, but none of the suggestions worked :(


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Automagic dependencies in gegl

2008-05-02 Thread Enrico Weigelt
* Luca Barbato [EMAIL PROTECTED] schrieb:

Hi,

 Now, gegl has 13 optional dependencies that could be use-flagged. The pity 
 is, it has no configure-option for most of them, they are autodetected.

A good example for miserable design ;-P
That's why I everything should be entirely built in sysroot.

 My experience with the gimp developers in the past was that they weren't 
 very pleased by bugs about automagic deps and I assume if I post them 
 without patches, they'll get closed immediately. Now I always avoided to 
 dig too deep into autotools, so I don't feel skilled enough for this task.
 
 Ping me and we could work out something, probably the best way would be 
 hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig 
 does+ adding the --enable option.

I strongly advise against this. The clean way is to fix the package.
(it's build scripts). I'm doing so in the OSS-QM project, eg. for
Mozilla ...

This actually is one of the typical situations what I invented 
OSS-QM for: the upstream produces crap and is even learning resistent.
Doing those cleanups within individual distros is not the right thing,
because a) too much work for the distro maintainer and b) too much
duplicate work, if every distro does it by it's own.

I'd like to invite you to the OSS-QM project - let's do all the
cleanups there and provide overlay by patch, so all distros now
just have to pick their right configure args.

http://oss-qm.metux.de/


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
-- 
gentoo-dev@lists.gentoo.org mailing list



  1   2   3   >