Re: [gentoo-dev] Real multilib support for Gentoo
Am Saturday 04 April 2009 14:59:22 schrieb Thomas Sachau: > Hi folks, > > > i would like to hear about other opinions about real multilib support > within our tree and package managers. From what i know, there are mainly 2 > different ideas: > > 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and > the package has x86 keyword, the package manager adds a lib32 useflag, > which would additionally install the 32bit variant of that package together > with the normal 64bit install). > > pro: -much lesser work for package maintainers > > contra: -needs addition in PMS and support in the pms, which will need > some > work on their side > > 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass > multilib-native.eclass, any ebuild with 32bit support would then need > adaption and of course inheriting that eclass) > > For reference, there are some users in #gentoo-multilib-overlay, which try > to implement this option in an git based overlay. > > the arguments are more or less the reverse of above: > > pro: -no need for PMS/PM support > -could be started and improved at any time > > contra: -needs much additional work since many ebuilds need to be changed > and adapted > > > Which option do you prefer? Or does anyone have another option? Which > additional arguments are there for those options? If it's feasible, I'd say go with option #1 as it would impose much less work in longer terms. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] About time to unify "cdda" and "cdaudio" USE flags and make the remaining one global?
Hi list, while finally doing some bug-wrangling again, I stumbled about [1] where a user requested to unify "cdda" and "cdaudio" USE flags. After leaving a request for further opinions about this in #-bugs I only got one reply: 14:11:28 <+Poly-C_atwork> Any idea what to do about bug #274818? Is there some real distinction between cdaudio and cdda? If no would it be worth to request the removal of one of these two flags in favor of the other one? ... 16:16:25 <+yngwin> Poly-C_atwork: looks to me that cdda and cdaudio are indeed the same 16:16:38 <+yngwin> and together they are used in 8 packages 16:16:46 <+yngwin> so it's time for a global use flag 16:17:04 <+yngwin> as cdda is the official term, that has my preference So what do you think? Should we convert the bug into a tracker and open bugs for any package using the USE-flag that should be converted into the other one? [1] https://bugs.gentoo.org/274818 -- Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] net-irc/xchat
Hey list,
I'm planning to lastrite net-irc/xchat in the next couple of weeks.
Unfortunately my hope that upstream development would be resumed didn't come
true. As the code becomes more and more outdated, open unfixed security bugs
are present[1][2] and at some point in the future =x11-libs/gtk+-2* will
vanish from the tree I don't see any other option than removing xchat from the
tree.
I don't see this as a big drama as we already have a drop-in replacement in
form of the net-irc/hexchat fork.
I checked this today and all people have to do is emerge hexchat and then copy
over the xchat config:
mkdir ${HOME}/.config ; cp -a ${HOME}/.xchat2 ${HOME}/.config/hexchat
I'd like to see your opinion on this matter as long as you have one you'd like
to share with me ;)
Furthermore I would shift my attention from the xchat package to hexchat
seeing that it currently gets proxy maintained. If there's no objection I'd
like to become the new contact of the person currently maintaining the package
in portage.
I also planned to release a news through the portage news system as soon as I
lastrite xchat so people know how to move over to hexchat. As I never did this
before I'd like to have some help concerning this matter. Is there some
documentation about portage news?
Regards
[1] https://bugs.gentoo.org/394657
[2] https://bugs.gentoo.org/257006
--
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] net-irc/xchat
Am Sonntag 25 November 2012, 22:03:03 schrieb hasufell:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/25/2012 09:27 PM, Lars Wendler wrote:
> > Hey list,
> >
> > I'm planning to lastrite net-irc/xchat in the next couple of
> > weeks. Unfortunately my hope that upstream development would be
> > resumed didn't come true. As the code becomes more and more
> > outdated, open unfixed security bugs are present[1][2] and at some
> > point in the future =x11-libs/gtk+-2* will vanish from the tree I
> > don't see any other option than removing xchat from the tree. I
> > don't see this as a big drama as we already have a drop-in
> > replacement in form of the net-irc/hexchat fork. I checked this
> > today and all people have to do is emerge hexchat and then copy
> > over the xchat config: mkdir ${HOME}/.config ; cp -a
> > ${HOME}/.xchat2 ${HOME}/.config/hexchat
> >
> > I'd like to see your opinion on this matter as long as you have one
> > you'd like to share with me ;) Furthermore I would shift my
> > attention from the xchat package to hexchat seeing that it
> > currently gets proxy maintained. If there's no objection I'd like
> > to become the new contact of the person currently maintaining the
> > package in portage.
> >
> > I also planned to release a news through the portage news system as
> > soon as I lastrite xchat so people know how to move over to
> > hexchat. As I never did this before I'd like to have some help
> > concerning this matter. Is there some documentation about portage
> > news?
> >
> > Regards
> >
> >
> > [1] https://bugs.gentoo.org/394657 [2]
> > https://bugs.gentoo.org/257006
>
> That's a pity. I was just about to step forward to rescue
> net-irc/xchat-xsys from treecleaning.
How about migrating xchat-xsys to hexchat?
> Do xchat plugins work in hexchat?
That's something for me to find out as well. I maintain the xchat-otr plugin
which I would like to continue using in hexchat.
> Maybe we could just hardmask it. I see some ebuilds in the tree being
> hardmasked due to security bugs, but not removed which is ok to me.
--
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] net-irc/xchat
Am Sonntag 25 November 2012, 17:26:30 schrieb Mike Gilbert: > On Sun, Nov 25, 2012 at 5:04 PM, Mike Frysinger wrote: > > On Sun, Nov 25, 2012 at 3:27 PM, Lars Wendler wrote: > >> I also planned to release a news through the portage news system as soon > >> as I lastrite xchat so people know how to move over to hexchat. As I > >> never did this before I'd like to have some help concerning this matter. > >> Is there some documentation about portage news? > > > > use profiles/updates/ to move xchat to hexchat ... > > -mike > > I don't think a package move is appropriate since the two packages > install different files. The installed files would not be updated, > just the vdb. Indeed. I also think that a pkg-move cannot be done here. -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] virtualbox packages will get its hardened support removed within one week.
Hello all, due to some really ugly circumstances I will remove hardened support and all hardened related patches from virtualbox packages within one week unless some Gentoo dev steps up and starts maintaining the hardended support in those virtualbox packages. I never used hardened myself and do not have the intention to do so just for a single group of packages I maintain. It turns out that the hardened patches for virtualbox packages tend to break every other new virtualbox release and I don't think it's fair for our hardened users to pretend those packages work on a hardened environment when they in fact more often do not. I know this might upset a couple of devs and users but I have to draw a line somewhere and I decided I draw it here. Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpxPM7AbVuJu.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote: >On 02/03/2017 10:10 AM, Benda Xu wrote: >> William Hubbs writes: >> >>> I have been looking at the meson build system [1] [2], and I like >>> what I see. >>> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to >>> the meson build system [3]. >>> >>> As I said on the bug, the downside is the addition of py3 and ninja >>> as build time dependencies, but I think the upside (a build system >>> where we don't have to worry about parallel make issues or >>> portability) outweighs that. >>> >>> What do folks think here? >> >> I would discourage it. Making OpenRC build-depend on python >> introduces unnecessary complexity that will undermine the >> portability of OpenRC sooner or later. >> >> After all OpenRC is a small program easy to build with a hand-written >> Makefile. >> >> Parallel make issues? No problem let's just solve it. >> >> >> Please, keep it simple. > >I'm adding my support to this sentiment > > +1 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpEkZOYA01EV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Printer drivers and net-print
Hi, On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote: >Hey all, > >1) Putting printer drivers into "net-print" is silly. > >Something that converts format a to device-specific format b has >absolutely nothing to do with network. >So, a new category "sys-print", emphasizing that it's hardware >drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense. Like I said in IRC, I'm all in favor of this. "media-print" seems reasonable as I don't consider printing related packages being system-relevant (and thus no sys-print). >2) After introducing that, however, "net-print" becomes nearly empty. > >On a quick glance, the only *network*-specific packages in there are >cups and lprng. Maybe one or two more which I dont recognize. > >So move cups and lprng to "net-misc" and drop "net-print"? >Or move them to new "sys-print" as well? > >What do you think? > >Cheers, >Andreas > Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpCDWMR5hBp6.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 19:59:19 + Robin H. Johnson wrote: >On Sat, Feb 25, 2017 at 03:05:09PM +0100, Ulrich Mueller wrote: >> As the council has decided in its 2014-10-14 meeting (and confirmed >> again in the 2016-11-13 meeting), CVS headers should be removed after >> the migration to Git. >The 2014-10-14 meeting did NOT specify what CVS headers were in >question, and it was later decided that this was $Header$, not $Id$. > >> Until recently, this was blocked by repoman still checking for the >> $Id$ line. The latter is now fixed in the stable repoman version. >> >> Therefore, I am going to remove the remaining CVS headers throughout >> the tree (except for patches, of course) in two days from now. >This was also discussed in August 2015: >Subject: 'Infra plans regarding $Id$ - official answer...' >https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e > >$Id$ is used by Git as well, and I was a strong advocate that expansion >of $Id$ should be ENABLED in the rsync exports, because it allowed >tracing what version of a file was actually in use. > >In the case of Git, $Id$ expands to the blob hash, which can be traced >to a commit trivially, and several of the council members in the 2015 >thread did agree it was useful in that format (but I see no formal vote >was ever taken). > And that's exactly for what I use the $Id$ header. I am completely against removal of this header line. It does _not_ do any harm and I don't understand why people want it to be removed so badly. Now QA again wants to do a questionable action _without_ any approval from neither infra nor council. Sorry guys but this is not how things work. The official answer from infra regarding $Id$ gives enough good examples why this header line should be kept. This $Id$ header line is the only way how I can safely keep official ebuilds and ebuilds from my overlay in sync. I don't like getting my workflows sabotaged and I consider this a pure act of sabotage... How about QA finally starts acting on useful issues or at least do actions that make sense? -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpXlAc1_vLo2.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 21:24:38 +0100 Andreas K. Huettel wrote: >Am Sonntag, 26. Februar 2017, 21:16:28 CET schrieb Lars Wendler: >> I am completely against removal of this header line. It does _not_ do >> any harm and I don't understand why people want it to be removed so >> badly. >> Now QA again wants to do a questionable action _without_ any approval >> from neither infra nor council. >[snip] > >October 2014 council meeting: > >Can we drop CVS headers post-migration? >Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, >radhermit, rich0, williamh > > > > $Id$ is _NOT_ the CVS header. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpL6ISAlDEuc.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 15:32:56 -0500 Rich Freeman wrote: >On Sun, Feb 26, 2017 at 3:27 PM, Lars Wendler > wrote: >> On Sun, 26 Feb 2017 21:24:38 +0100 Andreas K. Huettel wrote: >> >>>Am Sonntag, 26. Februar 2017, 21:16:28 CET schrieb Lars Wendler: >>>> I am completely against removal of this header line. It does _not_ >>>> do any harm and I don't understand why people want it to be >>>> removed so badly. >>>> Now QA again wants to do a questionable action _without_ any >>>> approval from neither infra nor council. >>>[snip] >>> >>>October 2014 council meeting: >>> >>>Can we drop CVS headers post-migration? >>>Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, >>>radhermit, rich0, williamh >>> >> >> $Id$ is _NOT_ the CVS header. >> > >Do we really need to put it on the Council agenda just so that the >same group of people can approve it again? > Yes please. I'd like to raise my concerns if this is really the only way to keep this header. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgp0Mxy1KfT5m.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 22:07:48 +0100 Ulrich Mueller wrote: >>>>>> On Sun, 26 Feb 2017, Robin H Johnson wrote: > >> The 2014-10-14 meeting did NOT specify what CVS headers were in >> question, and it was later decided that this was $Header$, not >> $Id$. > >When and by whom was that decided? The unanimous council decision was >to remove "CVS headers" and the obvious understanding is that this >includes all Header, Id, Date, and so on. Quoting the actual agenda >item (which was submitted by another infra member, BTW): > ># 3. CVS Headers ># ># The hateful thing. We could supposedly somehow fill them in rsync ># but that's complex and very dangerous (think of all the broken patch ># files currently in gx86). I think we should kill them. ># ># And while at it, I think it'd be good to actually remove most of ># them from our files -- changing header templates and so on. While ># not strictly useful, it decreases the size of the repo a bit and ># avoids any future nightmares :). > >Then in the summary of the 2016-11-13 council meeting we have this: > >- Bug 579460 "please make repoman ignore a missing "# $Id$" header >line": > Implemented in repoman-2.3.0, but not yet in stable. Once this is > done, CVS headers can be removed as per 2014-10-14 council decision. > >Note that it explicitly mentions $Id$, and until today nobody had >raised any objections against its revoval. Well, here is my objection now. And it seems like nobody at the council seems to have understood the intention of this $Id$ header in git. See https://git-scm.com/docs/gitattributes and search for "ident". >> This was also discussed in August 2015: >> Subject: 'Infra plans regarding $Id$ - official answer...' >> https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e >> > >> $Id$ is used by Git as well, and I was a strong advocate that >> expansion of $Id$ should be ENABLED in the rsync exports, because it >> allowed tracing what version of a file was actually in use. > >I don't see any expansion of $Id$ in rsync as of today, 18 months >after the Git conversion. If it wasn't missed for 18 months, one can >hardly claim that it would be an important feature. > >Also I suspect that it is too late to enable it now, because it will >potentially break patches that have been added after the conversion to >Git. There is no need to enable it by default. But it is a very nice way to verify ebuild changes if being enabled locally on a git clone of the tree. Ever since portage was migrated to git I had this line in my .git/info/attributes file on my dev box: *.ebuild ident This is a very useful feature and should not be removed only because council was told that it's a mere CVS migration cruft. It is not! -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpBNWn6sTwOy.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 16:42:59 -0500 Mike Gilbert wrote: >On Sun, Feb 26, 2017 at 4:16 PM, Lars Wendler > wrote: >> On Sun, 26 Feb 2017 22:07:48 +0100 Ulrich Mueller wrote: >> >>>>>>>> On Sun, 26 Feb 2017, Robin H Johnson wrote: >>> >>>> The 2014-10-14 meeting did NOT specify what CVS headers were in >>>> question, and it was later decided that this was $Header$, not >>>> $Id$. >>> >>>When and by whom was that decided? The unanimous council decision was >>>to remove "CVS headers" and the obvious understanding is that this >>>includes all Header, Id, Date, and so on. Quoting the actual agenda >>>item (which was submitted by another infra member, BTW): >>> >>># 3. CVS Headers >>># >>># The hateful thing. We could supposedly somehow fill them in rsync >>># but that's complex and very dangerous (think of all the broken >>>patch # files currently in gx86). I think we should kill them. >>># >>># And while at it, I think it'd be good to actually remove most of >>># them from our files -- changing header templates and so on. While >>># not strictly useful, it decreases the size of the repo a bit and >>># avoids any future nightmares :). >>> >>>Then in the summary of the 2016-11-13 council meeting we have this: >>> >>>- Bug 579460 "please make repoman ignore a missing "# $Id$" header >>>line": >>> Implemented in repoman-2.3.0, but not yet in stable. Once this is >>> done, CVS headers can be removed as per 2014-10-14 council >>> decision. >>> >>>Note that it explicitly mentions $Id$, and until today nobody had >>>raised any objections against its revoval. >> >> Well, here is my objection now. And it seems like nobody at the >> council seems to have understood the intention of this $Id$ header in >> git. >> See https://git-scm.com/docs/gitattributes and search for "ident". >> >>>> This was also discussed in August 2015: >>>> Subject: 'Infra plans regarding $Id$ - official answer...' >>>> https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e >>>> >>> >>>> $Id$ is used by Git as well, and I was a strong advocate that >>>> expansion of $Id$ should be ENABLED in the rsync exports, because >>>> it allowed tracing what version of a file was actually in use. >>> >>>I don't see any expansion of $Id$ in rsync as of today, 18 months >>>after the Git conversion. If it wasn't missed for 18 months, one can >>>hardly claim that it would be an important feature. >>> >>>Also I suspect that it is too late to enable it now, because it will >>>potentially break patches that have been added after the conversion >>>to Git. >> >> There is no need to enable it by default. But it is a very nice way >> to verify ebuild changes if being enabled locally on a git clone of >> the tree. Ever since portage was migrated to git I had this line in >> my .git/info/attributes file on my dev box: >> >> *.ebuild ident >> >> This is a very useful feature and should not be removed only because >> council was told that it's a mere CVS migration cruft. It is not! > >If this is about keeping ebuilds in your overlay in sync, you could >alternatively use the output of git ls-tree to keep track of changes >using the same blob ids. This is not the same. git's ident mechanism doesn't use the commit blob hash but creates a hash from the file's content. And as I am not using VCS for my overlay, git ls-tree is no useful replacement solution here. >It may not be as immediately convenient for you, but it would >ultimately be more reliable in the long run; there are already several >ebuilds in the gentoo repo that are missing the $Id$ header. Even if >we restore the repoman check, I'm sure they will creep in. Which then could be a perfect opportunity for QA to finally do something useful. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpIk_Z6QkF3c.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 23:30:25 +0100 Michał Górny wrote: >W dniu 26.02.2017, nie o godzinie 21∶16 +0100, użytkownik Lars Wendler >napisał: >> On Sun, 26 Feb 2017 19:59:19 + Robin H. Johnson wrote: >> >> > On Sat, Feb 25, 2017 at 03:05:09PM +0100, Ulrich Mueller wrote: >> > > As the council has decided in its 2014-10-14 meeting (and >> > > confirmed again in the 2016-11-13 meeting), CVS headers should >> > > be removed after the migration to Git. >> > >> > The 2014-10-14 meeting did NOT specify what CVS headers were in >> > question, and it was later decided that this was $Header$, not >> > $Id$. >> > > Until recently, this was blocked by repoman still checking for >> > > the $Id$ line. The latter is now fixed in the stable repoman >> > > version. >> > > >> > > Therefore, I am going to remove the remaining CVS headers >> > > throughout the tree (except for patches, of course) in two days >> > > from now. >> > >> > This was also discussed in August 2015: >> > Subject: 'Infra plans regarding $Id$ - official answer...' >> > https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e >> > >> > $Id$ is used by Git as well, and I was a strong advocate that >> > expansion of $Id$ should be ENABLED in the rsync exports, because >> > it allowed tracing what version of a file was actually in use. >> > >> > In the case of Git, $Id$ expands to the blob hash, which can be >> > traced to a commit trivially, and several of the council members >> > in the 2015 thread did agree it was useful in that format (but I >> > see no formal vote was ever taken). >> > >> >> And that's exactly for what I use the $Id$ header. >> I am completely against removal of this header line. It does _not_ do >> any harm and I don't understand why people want it to be removed so >> badly. >> Now QA again wants to do a questionable action _without_ any approval >> from neither infra nor council. Sorry guys but this is not how things >> work. The official answer from infra regarding $Id$ gives enough good >> examples why this header line should be kept. >> This $Id$ header line is the only way how I can safely keep official >> ebuilds and ebuilds from my overlay in sync. I don't like getting my >> workflows sabotaged and I consider this a pure act of sabotage... >> >> How about QA finally starts acting on useful issues or at least do >> actions that make sense? > >How about you give some respect to your fellow developers who simply >try to do stuff to improve Gentoo, instead of attributing malice and >taking it as personal attack on you? Wow, getting that from the perhaps most rude dev with the least amount of social skills we might have currently... Everytime I think you can't do worse you prove me wrong... >As far as I'm concerned, we could tell as well that the Council decided >on header removal, then Infra went rogue and replaced the header with >another one, and now it claims that the decision was about $Header$ >and not $Id$. Does that sound nice to you? Does it motivate you to work >more on Gentoo? Nice conspiracy plot... here, have a tin hat. >Of course, we can dispute that Infra might one day actually start >expanding $Id$. And not break random files in the process. And not >break Manifest thickening and signing in the process. > No real need to do that expansion for everybody. Just keep the $Id$ header field for those who want to make use of git's ident attribute feature. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgp8WPRCrYCRc.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] [PATCH] xorg-2.eclass: Enable verbose build logs.
Hi,
On Sat, 4 Mar 2017 11:13:08 -0800 Matt Turner wrote:
>From: Agostino Sarubbo
>
>Bug: https://bugs.gentoo.org/458000
>---
> eclass/xorg-2.eclass | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
>index 1af1705..fe44658 100644
>--- a/eclass/xorg-2.eclass
>+++ b/eclass/xorg-2.eclass
>@@ -472,9 +472,15 @@ xorg-2_src_configure() {
> local selective_werror="--disable-selective-werror"
> fi
>
>+ # Check if package supports a verbose build
>+ if grep -q -s "disable-silent-rules"
>${ECONF_SOURCE:-.}/configure; then
>+ local no_silent="--disable-silent-rules"
>+ fi
>+
> local myeconfargs=(
> ${dep_track}
> ${selective_werror}
>+ ${no_silent}
> ${FONT_OPTIONS}
> "${xorgconfadd[@]}"
> )
very unlikely scenario but what happens if configure does not provide
"disable-silent-rules" but "${no_silent} was defined somewhere in the
environment?
Lars
--
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39
Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html
pgpIK0ozg8wio.pgp
Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Bugzilla package list editing
Hi, On Tue, 2 May 2017 13:05:38 +0200 Chí-Thanh Christopher Nguyễn wrote: >Paweł Hajdan, Jr. schrieb: > >>>> Please stop editing package lists when you are not the maintainer >>>> and arches are already CCed. >>> +1 >>> >>> Please stop it. >>> And yes that's also true for arch team members. >>> >>> Package list is maintainer territory. >> Curious, what are the reasons and what changes people make that they >> shouldn't? >> >> I'm wondering if there's some solution to these issues (maybe better >> documentation, or an alternative way of accomplishing what these >> people try to do). > >As dilfridge pur jer in CC, I guess that some of jer's changes to bugs >were not welcomed by maintainers. > >One recent example of non-maintainer activity in the package list >field is bug 613104, where he just removed the entire package list >(and then marked the bug WONTFIX). >Also very common is that he changes fully qualified package names >(which is the correct syntax per [1]) into fully qualified package >atoms (which is the legacy syntax). Bug 616260 is one such example. I must admit that I did the same (changing full package names to full package atoms). IIRC when these package lists were introduced this was the only valid syntax and stable bot complained if it was not a package atom. >Best regards, >Chí-Thanh Christopher Nguyễn > >[1] https://bugs.gentoo.org/page.cgi?id=fields.html > Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgp4jLNV_asn2.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] taking a break from arches stabilization
On Mon, 10 Jul 2017 19:22:20 +0200 Agostino Sarubbo wrote: >Hi all. > >every time that I attach my tmux session to see what happens on irc, I >always see the same discussion about the 'minor' arches status. >Since I joined gentoo(2011) I worked on all arches except hppa, I put >more effort in amd64 and less where I saw other people work on it >(arm,alpha) But every time the magic phrase is that those arches are >unmaintained. > >Now, since I work on these arches just to help, i.e. I don't have any >business and I do non have any installation of those arches and the >work I'm doing is not appreciated at all I decided to stop for now. >If your dream is to put sparc and ia64 to ~arch, go ahead, I have no >objections. >I will take a break also from amd64 and x86...let's see how things >will change. > Hi Agostino, this is very sad news but I'm not really surprised about your decision. It seems like every arch except amd64 and to some point arm(64) seems to be the target of massive vilification. On behalf of base-system team let me thank you for your awesome stabilization work. I hope you will return at some point when your frustration level has sufficiently decreased. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpatNBwwwG4t.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
On Fri, 04 Aug 2017 17:37:15 +0300 Mart Raudsepp wrote: >On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote: >> I am looking into this for openrc. I copied it over to my personal >> overlay. > >Ok, how about I mark myself as maintainer then and add you as co >-maintainer for OpenRC aspects, and you can e-mail me fixes for openrc >or otherwise? Last time I checked, plymouth-0.9.x had a hard requirement for systemd to work. From what I remember, making 0.9.x versions work with openrc might become a hard to solve task. >sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too >still, right? > >I'm not sure about >kde-plasma/breeze-plymouth >kde-plasma/plymouth-kcm >do you use KDE/Plasma to care for those too? > > Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpgPTkgVmXwH.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB
Am Sun, 17 Dec 2017 13:40:35 -0500 schrieb Mike Gilbert : > On Sun, Dec 17, 2017 at 1:39 PM, Mike Gilbert > wrote: > > On Sun, Dec 17, 2017 at 8:21 AM, Michał Górny > > wrote: > >> Hello, everyone. > >> > >> It's my pleasure to announce that with a majority vote the QA team > >> has accepted a new policy. The accepted wording is: > >> > >> Total size of 'files' subdirectory of a package should not be > >> larger than 32 KiB. If the package needs more auxiliary files, > >> they should be put into SRC_URI e.g. via tarballs. > >> > >> (the total size being computed as a sum of apparent file sizes) > >> > >> The relevant policy vote is finishing at bug #633758 [1]. The CI > >> reports [2] were updated to report packages whose 'files' > >> directories exceed 64 KiB, to avoid adding many new warnings at > >> once. The limit will be lowered down to 32 KiB as packages are > >> fixed to comply with the new policy. > >> > >> At the same time, I would like to explicitly remind developers that > >> the spirit of the policy is 'do not let "files" grow large', not > >> 'make sure you're one byte less than 32769.' Do not argue that > >> your package exceeds the limit only by few bytes -- even if it > >> gets close to the limit, then it means it's way too large. > > > > I just want to voice my opinion on this: as a developer, this policy > > is a royal pain in the ass. > > > > I would ask the council to please increase this limit to at least > > 100 KiB, preferably more. > > Please substitute "QA team" for "council" in the above message. > Thanks. > I second this request for the exact same reason. Lars
Re: [gentoo-dev] Projects up for grabs: cron, m68k
Am Wed, 20 Dec 2017 18:02:22 +0100 schrieb Michał Górny : > Hello, everyone. > > Due to prolonged inactivity of Mike Frysinger (vapier), the following > projects have had effectively no members for 6 months already: > > https://wiki.gentoo.org/wiki/Project:Cron > > sys-process/anacron [m] > sys-process/at sys-process/at is lacking the [m] > sys-process/bcron > sys-process/cronbase > sys-process/cronie [m] > sys-process/dcron > sys-process/fcron [m] > sys-process/vixie-cron > virtual/cron > > https://wiki.gentoo.org/wiki/Project:M68k > > sys-apps/zorroutils [m] > sys-fs/atari-fdisk > > The packages listed with '[m]' have other maintainers. The remaining > packages are solely maintained by the listed projects. > > If you are interested in helping out with some of those packages, > please consider joining the appropriate project and/or co-maintaining > the individual packages. > > If the projects see no activity within the next month, I will disband > them and move the appropriate packages to maintainer-needed. >
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote: >On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: >> * Posting to the list will only be possible to Gentoo developers and >> whitelisted additional participants. > >This is so contrary to what I and I thought Gentoo stands for: >openness, transparency, inclusiveness even when these require a rather >thick skin and result in high noise. It's a price worth paying. > >I guess I should a) pay more attention to council elections b) consider >the idea that the whole council thing as it stands now is just not >working. > Wow. I couldn't have said it better. Seems we're turning into an elitist club or something... I wonder how many users we're going to loose on this one. Well done council :-( -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpp26P9mjsBM.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list
Hi Gordon, On Wed, 10 Jan 2018 23:37:39 -0600 Gordon Pettey wrote: >On Wed, Jan 10, 2018 at 10:22 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as >> excerpted: >>> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier >>> JUMEL: >>>> Le 2018-01-10 10:53, Michał Górny a écrit : >>>> > Last I checked, Gentoo was a Linux distribution. However, some >>>> > people prefer to turn it into open discussion forum that has >>>> > nothing to do with making a distribution. >>>> >>>> No it has. Giving power to a subset of users, denying interaction >>>> with future contributors unless they enroll is the eaxct way to >>>> kill Gentoo as a community ! >>> >>> We wouldn't have needed to go this far if not for a few outside >>> trolls who >>> * keep pushing their personal agenda in endless threads, >>> * confuse their own inability to contribute with being a mistreated >>> underdog, >>> * and keep commenting opinionated on technical things they >>> plainly have no clue about (while whining when are told they sprout >>> bulls##t). >>> >>> We do not have a problem with "future contributors". I wager those >>> will rather increase in numbers once the list spam is gone. >> >> >> This has been my biggest concern about the whole thing: >> >> Are we going to be nipping future devs in the bud because there's >> now too many hoops to jump thru too early, and it's simply not worth >> the trouble when they can (and will) go elsewhere where it's easier, >> >> OR >> >> Are we going to be lowering the unwelcoming noise, confusion and >> name- calling threshold and making the community more welcoming for >> those who have a serious interest, clearing out some of the stuff >> that could otherwise discourage them. >> >> >> It's pretty clear that council believes it's the latter, at least to >> the degree that they're willing to try it for a time, effectively a >> wager of sorts, but I don't believe anyone can honestly say what the >> real effect one way or the other will be until it /is/ tried. >> >> >> Personally, my viewpoint is that while over the last year or so there >> were some 1-2 level frustrating posters on a 5-point scale, it's >> nothing compared to the level-4 (direct name calling, just short of >> physical threats that justify getting the law involved) stuff that >> I've seen on this list in the some-years-distant past. In my mind, >> unquestionably that level-4 stuff required action, and it was taken. >> >> The recent stuff seems so much milder in comparison that IMO it's >> hard to see what the hubbub is all about, but there's certainly an >> argument to be made that the previous experience simply desensitized >> our detection meters, and that were it not for that, the recent >> stuff would seem rather more shocking and horrible than it does, and >> that even if it's /less/ horrible, it's horrible /enough/ that it >> remains unacceptable in a civilized society, and if we /do/ accept >> it, we're effectively pushing others that won't, out. > >Given the quantity of relevant problem-mail that came from >@gentoo.org, maybe the glass house dwellers should be careful where >they aim their stones. I considered taking the dev quiz and everything >instead of just posting a few ebuilds on bugzilla years ago, but the >elitist, as Alex labelled it, voices from @gentoo.org are what made me >decide not to, and my decision keeps getting reinforced. That >impression has been there for years, and it's not getting better by >this. > very sad you got that impression. And unfortunately, I cannot even wholeheartedly deny that this is true. Given the fact that we are severely understaffed when it comes to active developers, I hope you will reconsider your decision at some point and start doing the quizzes. Kind regards -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpFHcQ4Bo_xI.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, 11 Jan 2018 10:03:54 +0300 Eray Aslan wrote: >On Wed, Jan 10, 2018 at 08:55:11AM +0100, Lars Wendler wrote: >> Seems we're turning into an elitist club or something... > >Elitist seems too kind a word. Knee-jerk reaction, petty vendetta, >impulsive emotional reaction comes to mind - instead of articulating >and implementing a vision for the distribution, principled action, >making all devs work together towards the goals that have been set. >Not day to day reactions and bad ones at that. Council is failing its >one main task - it prolly has been for some time, this one also fails >"first, do no harm" test. A german term comes to my mind which applies perfectly to this: "Blinder Aktionismus" which roughly translates to "blind actionism". >Mind you they are not harming willingly. I am pretty sure they are all >well intentioned. They, as a group, just do not have, I dont know, the >vision, the experience, the personality to lead a distro. > >We need a change as otherwise I am afraid the future is not bright. I >think with this last straw I lost faith in the current setup. Death by >a committee. Yey. > I'm totally baffled that few people seem to know how to filter trolls out of their inboxes. In the past such trolls were treated with a "plonk" and all was good. But nowadays everything has to be ruled somehow. Ah well, it's only a disservice to our users. Nothing the council needs to worry about as they seem to have forgotten that they once were users as well... -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpQsMGd7Cdiy.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Managing updates on many identical Gentoo systems
Hi Anthony, On Thu, 18 Jan 2018 06:46:53 -0500 Anthony G. Basile wrote: >Hi everyone, > >I'm trying to design an update system for many identical Gentoo >systems. > Using a binhost is obvious, but there are still problems with this >approach. > >Unless there's some magic I don't know about (and this is why I'm >sending this email) each machine still needs to have the portage tree >installed locally (1.5 GB) or somehow mounted by a network filesystem >(which is not practical if the machines are not on a local network). >Furthermore, each machine would have to run emerge locally to do the >calculation of what packages need updating. > >This procedure is redundant because each machine is housing the same >data and doing the same dependence-tree calculation. It should be >possible to do this calculation on a centralized binhost and simply >communicate the update information to the remote machines. They would >then only have to download the .tbz2's and install them, keeping a tidy >/var/db/pkg. Thus they avoid having to house the portage tree and >burning cpu cycles that just calculate redundant information. > >I'm inspired here by OpenBSD's pkg_add which doesn't require all of >ports to be installed, and mender which is a > >Any ideas? > well, I never did anything like that but regarding the dependency calculation... how about something like emerge -1OKanv $(qlist -CISq) (--oneshot --nodeps --usepkgonly --ask --noreplace --verbose) which simply omits dependency calculations, only takes into account available binary packages and doesn't replace same versions? Of course this requires all installed packages really being available as binpkgs. Since all the installations are the same, as long as you provide a sane set of binpkgs, dependency calculation should not matter anyway. The only issue I can think of is that a system might become broken if the update gets interrupted before all packages have been updated. Kind regards -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpBmwpubwc8w.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grabs
On Tue, 13 Mar 2018 12:58:10 +0100 Pacho Ramos wrote: >net-wireless/hostapd In case nobody else wants to take it I can do. But I'm a mere user of the package and don't know anything about its internals. So it would be very basic/low maintenance from me. Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpxACrFmV1id.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Mailing list moderation and community openness
On Tue, 20 Mar 2018 23:17:52 +1100 Michael Palimaka wrote: >I see that in bug #650964[1] Council is pushing forward again with >implementing user whitelisting on this mailing list (ie. anyone that is >not "approved" will have their mail rejected). > >Could someone please explain how this doesn't directly contradict the >core tenets of an open and inclusive community? > >1: https://bugs.gentoo.org/650964 > +1 This is ridiculous and council should be ashamed of this decision. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgp8dhy4aanHN.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] berkdb and gdbm in global USE defaults
On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote: >On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote: >> On 04/07/2018 02:44 PM, William Hubbs wrote: >> > >> > I'm with floppym on this one. Is there a specific reason we enable >> > them globally? >> >> It's a relic from before we had IUSE defaults. >> >> >> > Since there has been so little discussion on this thread, I will >> > start looking at what I need to do to remove these use flags from >> > the profiles. >> >> There's probably a few packages that will need IUSE defaults to avoid >> breakage, and everyone else should get fair warning before the flags >> are turned off by default. > >There is the case of packages that optionally use a db back end, >and I would argue that those may not need iuse defaults. > >It could also be argued that having one backend enabled globally is >good for consistency, but that would end up leading down a bikeshed >path that I'm not sure we should go down. I'm just not sure it makes >sense to enable more than one of these backends globally. > >Thoughts? > >William > Considering the questionable license situation with latest sys-libs/db releases (AGPL), I'd say we should prefer gdbm over berkdb in case we want to keep one db backend default enabled. IIRC Fedora is even trying to entirely getting rid of berkdb. Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpZtUTHcE5fW.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] Package up for grabs
Hi list, I'd like to give up maintenance of dev-libs/libratbag due to the software now depending on libsystemd[1] which I do not have the tiniest interest to infect my systems with. Unfortunately upstream refuses to make libsystemd optional because they don't wanna use dbus directly but rather prefer a useless additional layer for that (libsystemd). If nobody picks it up I either gonna put it on maintainer-needed in about 30 days or (if QA prefers that) lastrite it entirely. Kind regards Lars [1] https://github.com/libratbag/libratbag/issues/239 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpEIVSzHon2f.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] Current status with openssl-1.1
Hello dear Gentoo Devs, this is somewhat written out of frustration so please bear with me ;) CCing crypto@ in case they can provide some valuable input to the topic. If not, sorry guys for wasting your time. As you might have noticed, although being published back in August 2016, we still have openssl-1.1 in package.mask due to the numerous build issues we still have with various packages[1] that uses openssl. "Why is that so?" do I hear you asking. "Debian already switched over to openssl-1.1 for months already". Well... the did not entirely switch yet. There are still packages that are being compiled/linked against openssl-1.0 in Debian because their respective upstreams refuse to collaborate. The most prominent example is openssh[2] which also is the reason that this topic gives me so much frustration. They simply refuse to add compatibility code for openssl-1.1 because openssl upstream did such a silly move with making lots of interfaces opaque and make openssl-1.1 mostly incompatible with code written against older openssl versions. This and the fact that you can build openssl-1.1 with three different API versions (0.9.8, 1.0.0 and 1.1.0) makes it exceptionally hard for openssl consumers to migrate their code to openssl-1.1. openssh upstream even raised the idea to simply focus crypto support in their software on libressl which I personally think is a really bad move. But coming from the same people (openssh and libressl are both developed by OpenBSD people), it's no big surprise this idea came up at some point. So, basically openssl is the last big showstopper for openssl-1.1 to get out of p.mask. There are some inofficial patches floating around in the WWW but each one of them has some issues and they all are not really small in size. Last time I checked, the most complete (but still to some degree broken) patch had 2800+ LOC and was 80K in size. This is definitely nothing I want to maintain as downstream, left aside the fact that openssh should not be messed with lightly regarding security implications. My biggest concern right now is that openssh might still block openssl-1.1.1 once that got released. openssl-1.1.1 provides TLSv1.3 which is something we should provide to our users as soon as possible and is also targeted as next LTS release. [1] https://bugs.gentoo.org/592438 [2] https://bugs.gentoo.org/592578 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpfxryrsqsgo.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Sun, 14 Feb 2016 13:10:07 +0100 Patrick Lauer wrote:
>On 02/09/2016 01:17 PM, Rich Freeman wrote:
>> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric
>> wrote:
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this:
>> http://pastebin.com/sSDtpF4t
>More stable link:
>https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>>
>> With this:
>> http://pastebin.com/Lfn8r7qP
>More stable link:
>https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the lengthy
>> init.d script for apache misses).
>>
>Right, that's a bad comparison.
>
>The equivalent OpenRC init script is:
>
>```
>#!/sbin/runscript
>command="/usr/sbin/apache2"
>command_args="${APACHE2_OPTS}"
>description_reload="A graceful restart advises the children to exit
>after the current request and reloads the configuration."
>
>stop() {
>$command $APACHE2_OPTS -k graceful-stop
>}
>reload() {
>$command $APACHE2_OPTS -k graceful
>}
>```
>So that's almost exactly the same (modulo braces and newlines). There's
>no equivalent for PrivateTmp, and we ignore the extra data in
>/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
>another rant ;)
>
>Just that the current initscript does a lot more, and ... uhm ... why
>is the systemd unit sourcing /etc/conf.d/apache2 ?
Becasue I don't give a damn about systemd and nobody cared to send
patches yet.
>(Oh, and dependencies, but those just slow down startup )
>
>So if you compile the equivalent naive init script there's not much
>difference, and the initial argument falls on its face and disappears.
>
>I'm getting tired of having this argument :)
>
--
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39
Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html
pgpcf9zp1NjJS.pgp
Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grab
On Thu, 31 Mar 2016 12:21:08 +0100 Tony Vroon wrote: >On 31/03/16 12:17, Alexey Shvetsov wrote: >> net-libs/libmbim >> net-libs/libqmi >> sys-apps/gptfdisk Please don't remove me from gptfdisk when you add yourself. I am still interested in the package and have no plans to drop myself as maintainer :) >These are of interest. I'll take them. > >Regards, >Tony V. > > > -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See (self signed server cert for now) http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpEGuGQu8Ww1.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] CVS headers in ebuilds
On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote: >Does anyone still use the CVS $Id$ keywords that are in all ebuilds' >headers, or are they being expanded anywhere? Or is there any other >reason why they should be kept? > >In fact, the council had already voted to drop them in its 20141014 >meeting: > > Can we drop CVS headers post-migration? > Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, > radhermit, rich0, williamh > >Ulrich Yes, I still use these lines to check for ebuild changes between portage and my personal overlay. So please keep this line. Thanks. Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See (self signed server cert for now) http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpclkVFNS3fO.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Re: CVS headers in ebuilds
On Sat, 9 Apr 2016 12:12:44 +0200 Ole Reifschneider wrote: >On Tue, Apr 05, 2016 at 12:30:15AM -0400, Jonathan Callen wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 04/04/2016 02:58 AM, Lars Wendler wrote: >> > On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote: >> > >> >> Does anyone still use the CVS $Id$ keywords that are in all >> >> ebuilds' headers, or are they being expanded anywhere? Or is >> >> there any other reason why they should be kept? >> >> >> >> In fact, the council had already voted to drop them in its >> >> 20141014 meeting: >> >> >> >> Can we drop CVS headers post-migration? Aye: blueness, creffett >> >> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh >> >> >> >> >> >> Ulrich >> > >> > Yes, I still use these lines to check for ebuild changes between >> > portage and my personal overlay. So please keep this line. >> > >> > Thanks. >> > >> > Lars >> > >> >> I do the same (after enabling expansion in .git/info/attributes on >> just "*.ebuild", I can even get a quick diff of what changed in >> gentoo.git to update my overlay). >> > >Sounds cool. Can you please explain in more detail how you do this? > >Ole > Enable the ident feature for *.ebuild files in git: $ cat ~/gentoo/.git/info/attributes *.ebuild ident Now re-checkout every ebuild you wanna track. $ git checkout -- ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild Once you have done that those ebuilds will have some hash in the $Id$ field: $ grep '$Id' ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild # $Id: 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 $ The same hash is in each corresponding ebuild in my personal overlay as well. Occasionally I run a script to compare ebuilds from my overlay with the one from the git tree. When the hash is different something in the gentoo ebuild has changed and I can decide if I want to apply these changes to ebuilds in my overlay as well. I hope this brief explanation is sufficient. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See (self signed server cert for now) http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpjQtsVSDtLY.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Package up for grabs
On Sat, 28 May 2016 11:30:44 +0200 Pacho Ramos wrote: >Because of maintainer retiring the following packages are up for grabs: >app-admin/hwreport >app-admin/tmpwatch >app-misc/gramps >app-portage/g-ctan >net-misc/icaclient >virtual/pager > > I can take net-misc/icaclient as I need it for work. Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpL340DbFp9e.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grabs
On Sat, 06 Aug 2016 13:36:54 +0200 Pacho Ramos wrote: >This packages are now up for grabs: >app-admin/keepassx >media-sound/mumble >media-sound/murmur > > I gonna take all three packages. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpy1KQr1by5T.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Electron external dependencies
On Wed, 17 Aug 2016 19:27:40 +0300 Alexander Revin wrote: >Hello, > >Is there any plan to make electron more modular package? Right now it >builds its own protobuf, mesa and v8 (and maybe much more). These >packages do exist in a tree, maybe it's possible to reuse them? > >Regards, >Alex Hi Alex, I suggest you open a bug about this in our bugzilla [1]. Use something like "dev-util/electron uses bundled libs" as subject and describe the issue briefly. Thanks. [1] https://bugs.gentoo.org -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpi4js7gcwAH.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Developers, please work on underlinking issues!
On Thu, 18 Aug 2016 13:43:42 +0300 Andrew Savchenko wrote: >Hi, > >On Wed, 17 Aug 2016 22:37:42 +0200 Michał Górny wrote: >[...] >> That said, I'd really like for Gentoo to be able to finally switch to >> ld.gold by default. > >It still has problems with kernel or kernel modules here and there. > >Also from my experience gold demands more memory on linking large >binaries, thus it it unsuitable for low-memory setups. > >While gold indeed has its benefits, it is still too immature to >become system default. And as long as I keep reading such statements I won't use ld.gold anywhere on my (dev-)systems. A linker IMHO is a far too crucial toolchain component to blindly play around with. >Best regards, >Andrew Savchenko Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpQ0Dl2uKltV.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] base-system needs developers who care
On Tue, 23 Aug 2016 23:17:58 + Robin H. Johnson wrote: >Over the years, the base-system package herd has grown in size. Today >it comprises 320 packages, of which 61 of those have more than one >maintainer. The packages with more than one maintainer I'm only >concerned about if the other maintainer is also very busy or not >available. > >Some of these packages are very niche, and while they continue to work, >they could use a bit more attention than they get presently (you might >only hear about them when they break and never when they work). > >They are generally NOT broken and in need of tree-cleaning, but are >just lacking forward momentum (not a few bugs are reasonable upstream >bugs or feature improvements). Many were once shiny and had lots of >people that cared, but that dwindled as they become mundane and just >expected to work. > >General increase in the number of developers in base-system would not >be a bad outcome from this email either ;-). > >Some of this is from stuff I know needs eyeballs, and others are where >the package seems to have more than a few old bugs open. > >Packages in need of review & tweaks or just more eyeballs >-- >app-admin/sudo (upstream?) >app-admin/sysklogd- (upstream?) >app-shells/bash (upstream?) >dev-util/strace (upstream?) >net-dialup/ppp >net-firewall/iptables >net-fs/nfs-utils (upstream?) >net-misc/dhcpcd (upstream?) >net-misc/dhcp (upstream?) >net-misc/ntp (upstream?) >net-misc/openssh >net-nds/rpcbind >sys-apps/baselayout >sys-apps/coreutils (upstream?) >sys-apps/kbd (upstream?) >sys-block/aoetools >sys-block/iscsitarget >sys-block/open-iscsi >sys-block/thin-provisioning-tools >sys-block/vblade >sys-fs/lvm2 (mostly in regards to genkernel interaction) >sys-fs/multipath-tools >sys-fs/quota > I have some kind of interest for these packages: app-admin/sudo app-admin/sysklogd app-shells/bash net-dialup/ppp net-firewall/iptables net-misc/dhcpcd net-misc/dhcp net-misc/ntp net-misc/openssh sys-apps/coreutils sys-apps/kbd But I think I cannot maintain all of them alone. So yeah, fresh (active!) blood in base-system would be nice. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpukSXcsG7PA.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] Package up for grabs
This package is now up for grabs: net-irc/rbot -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpfOxyZA4prL.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] base-system needs developers who care
On Tue, 23 Aug 2016 20:08:30 -0400 Anthony G. Basile wrote: >On 8/23/16 8:03 PM, Lars Wendler wrote: >> I have some kind of interest for these packages: > >Lars, maybe once we get some names we should get a meeting of >base-system together and coordinate our efforts. In particular, I >mostly have interest in those packages that make up @system for the >stages I build. > Guys, I'd like to take the opportunity to "revive" the #gentoo-base IRC channel for coordination between base-system developers. Perhaps "revive" is not the appropriate word considering that the channel never stopped to exist but rather became extinct. Opinions? Furthermore what about the devs currently being listed in base-system team but stopped taking care of the team's packages for years? Oh, and to all new team members: Please keep in mind to *not* use EAPI-6 for base-system packages yet, so we can retain a somewhat stable upgrade path even for very old systems. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpt6JCNU2Zft.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] Last rites: sys-block/eject
Dead upstream since 2013. Superseded by eject from sys-apps/util-linux. Slated for removal in 30 days. -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpacC2d8Ws1q.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] bash-4.4 - call for testers
Hi, bash-4.4/readline-7.0 have been released and are available in Gentoo already although they are still being package.masked. This is a call for testers. If you feel brave enough, please give bash-4.4 a shot and report all problems you might have with it. Add the following to you package.unmask file/directory: =app-shells/bash-4.4* =sys-libs/readline-7.0* and emerge both packages. Once readline-7.0 has been installed you most likely need to run emerge -v @preserved-rebuild in order to get all readline reverse deps being built against new readline. Reporting those packages in our bug tracker [1] would be helpful. In case you encounter a real bug in bash or readline please report them to our bug tracker [1] as well. If you just seem to have successfully installed bash and found no problems after a while of testing, I'd like to know about it here on the list. This would help me determining when this bash version can be removed from package.mask. Perhaps we even consider stabilizing bash-4.4 a bit sooner now that there's a security bug [2] that requires bash-4.4 for the fix. Thanks in advance. [1] https://bugs.gentoo.org [2] https://bugs.gentoo.org/594496 -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpSdxnpG76aR.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grabs due to retirement
Hi Thomas, On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote: >Hi, > >I will retire, so here are my remaining packages. Sad day seeing another dev leaving :-( >net-misc/wicd I can take this one if nobody else is interested in it. >Cheers, >Thomas > > I wish you all the best and if you ever feel the urge, please come back :) Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpYMZWnXUb25.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grabs due to retirement
Hi, On Tue, 3 Jan 2017 16:00:52 +0700 (+07) gro...@gentoo.org wrote: >On Mon, 2 Jan 2017, Brian Evans wrote: >> IMO, this one should be given last-rites as upstream is dead and it >> heavily depends on wireless-tools and WEXT. this is plain wrong. Upstream is not dead, just not very active anymore. >I use it on 2 notebooks. It works fine, and is (from my point of view) >the most convenient tool to control ethernet and wifi connections on a >notebook. Why lastrite it when it works? > >Andrey > Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpETeGr0Dl2V.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages up for grabs
Am Sat, 19 Oct 2013 19:10:51 +0300 schrieb Panagiotis Christopoulos : > On 10:43 Sat 19 Oct , Daniel Campbell wrote: > > On 10/19/2013 10:32 AM, Pacho Ramos wrote: > >... > > > x11-wm/fluxbox > > > > I'm not a developer (but have a completed dev test that doesn't know > > where to go...). I'm interested in nabbing x11-wm/fluxbox (and any > > related projects that are still alive). I use Fluxbox daily and > > keep an eye on upstream. It'd be nice to be able to contribute > > something worthwhile to Gentoo, even if it's just one package (for > > now). > > I'll add myself to fluxbox and probably everything related to fluxbox > but as u know I'm not so active nowadays so anyone who is willing, > should add him/herself too. > > @Daniel, you can help by proxy-maintaining fluxbox or if you want to > become a gentoo developer I can mentor you if you don't find someone > else in your timezone. > > By the way, are you sure, guys, you want to remove the desktop-wm > herd at all? > I take x11-wm/icewm and x11-themes/icewm-themes Cheers -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
Am Wed, 30 Oct 2013 22:10:27 + schrieb "Robin H. Johnson" : > Hi all, > > Since it's been nearly a year since I last sent this email (and I got > poked with a stick about this), it's time for a reminder. I hope that > in future, if we get a non-maintainer update GLEP [1], this will > become unneeded, as it can be on api.gentoo.org. > > 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359 > > Over the years, I've come to be the maintainer a huge number of > packages (300+) Many of them are from inheriting packages when other > developers have retired - the upstream may also be dead, but there is > nothing that supersedes the functionality of the package, so if I use > it, it lives. > > If you're a developer waiting for an action on one of them, and > you've attached a fix to a bug, you should mostly feel free to go > ahead any just apply your patch. If you break it, I'll hunt you down. > > If you think you want to take over the package instead, or it should > go for last-rites/tree-cleaners etc; please claim it here or drop me > an email; or for the last category: just take it and leave a note. > > Notable changes from last year: > - I'm releasing mogilefs and perlbal. > - new category of stuff people are welcome to take. > > Exceptions: > dev-db/mariadb, dev-db/mysql - mysql herd > sys-libs/db - base-system > sys-fs/lvm2 - please be careful! > > Packages where I am the upstream, and feature requests probably won't > go far without large good patches: > app-admin/diradm > app-shells/localshell > sys-apps/readahead-list > dev-perl/WattsUp-Daemon > > Packages for tree-cleaner consideration: > dev-vcs/gitosis > dev-vcs/gitosis-gentoo > net-mail/vqadmin > > Here's a list of every package where I'm a maintainer and there is no > herd listed (but their might be other maintainers), and I slightly > care about the package: > app-admin/cancd > app-arch/duff > app-arch/unadf > app-backup/mirdir > app-crypt/af_alg > app-crypt/gpg-ringmgr > app-crypt/mhash > app-misc/ddccontrol > app-misc/egads > app-misc/g15composer > app-misc/g15daemon > app-misc/g15macro > app-misc/g15message > app-misc/g15stats > app-misc/gcalcli > app-text/sloccount > app-text/unrtf > dev-libs/libg15 > dev-libs/libg15render > dev-libs/libmcal > dev-libs/libmelf > dev-libs/libmemcache > dev-libs/libmemcached > dev-python/google-api-python-client > dev-vcs/cvs2svn > dev-vcs/git > net-analyzer/ipaudit > net-analyzer/ipv6-toolkit > net-analyzer/poink > net-analyzer/raddump > net-analyzer/sslsniff > net-analyzer/thrulay > net-dns/ndu > net-misc/adjtimex > net-misc/aggregate > net-misc/aggregate-flim > net-misc/ifenslave > net-misc/memcached > net-misc/netdate > net-misc/nstx > net-misc/pcapfix > net-nds/nsscache > net-wireless/bss > net-wireless/spectools > sys-apps/clrngd > sys-apps/input-utils > sys-apps/linux-misc-apps > sys-apps/usbmon > sys-auth/icmpdn > sys-auth/nss_ldap > sys-block/btrace > sys-block/fio > sys-block/scsiping > sys-block/scsirastools > sys-block/seekwatcher > sys-block/tw_cli > sys-power/iasl > sys-power/nut > sys-power/pmtools > sys-process/audit > > Items in this list, you're welcome to take them, just leave a note; > they will still work last I checked, and I do use them occasionally, > but I'm not fussy about them. > app-emulation/qenv > app-misc/dnetc > app-misc/interceptty > app-text/binfind > app-text/convmv > dev-cpp/threadpool > dev-db/libdbi > dev-db/libdbi-drivers > dev-lang/snobol > dev-libs/bglibs > dev-libs/OpenSRF > dev-libs/yaz > dev-lua/lgi > dev-util/checkbashisms > dev-util/fuzz > dev-util/idutils > dev-util/its4 > dev-util/mpatch > dev-util/pscan > dev-util/rats > dev-util/re2c > dev-util/sgb > dev-util/wiggle > media-gfx/monica > media-gfx/springgraph > net-firewall/ipset > net-libs/cvm > net-misc/dcetest > net-misc/openrdate > net-misc/rdate > net-misc/tiers > net-misc/valve > net-misc/vmnet > net-misc/vmpsd > net-misc/zsync > net-nds/led > net-proxy/piper > sys-apps/hwinfo > sys-libs/openhpi > > app-misc/g15composer app-misc/g15daemon app-misc/g15macro app-misc/g15message app-misc/g15stats dev-libs/libg15 dev-libs/libg15render I could help maintaining these as I am using a Logitech G15 and have a Logitech G19 in my locker. dev-vcs/git I'd be interested in this as well although like promethanfire I might be overwhelmed with the mere amount of code in the ebuilds. app-text/convmv I will take it. -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
Am Fri, 08 Nov 2013 20:17:27 -0500 schrieb Chris Reffett : > On 11/8/2013 7:14 PM, Markos Chandras wrote: > > Hi, > > > > I see nobody seems to take care of nagios packages anymore. > > There are numerous bugs (and many of them are pending version > > bumps). > > > > Is the sysadmin@ herd still interested in this package? If not, > > could you please consider moving it to maintainer-needed@? Maybe > > users are interested in working with proxy-maintainers to bring > > this package up to date. > > > > https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios > > > If sysadmin@ doesn't want it, I know a user/potential dev who would be > interested in maintaining it with me as a proxy. Just let me know. > > Chris reffett > Oh dear... I already have too many packages to take care of but my company is using nagion on Gentoo so I take care of it. Although I wouldn't mind if somebody else helps with the packages as well. Cheers -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Am Wed, 13 Nov 2013 14:12:24 -0500 schrieb Rich Freeman : > On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. > wrote: > > > > long story short > > having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 > > switch) greatly simplified the upgrade of an old server on a client. > > > > Why not keep a copy on the servers? I mean > > http://distfiles.gentoo.org/snapshots/ > > > > Going back in time with portage is the easy part - it is in CVS. > > The real problem is all the distfiles themselves, especially things > like out-of-tree patch tarballs hosted by devs. IMHO not even the worst problems as long as devs stop removing files they consider as "deprecated" or "old". I keep everything in my dev-space I ever put in an ebuild that landed in our official portage tree. Of course this only works as long as you reference that place in the affected ebuilds. Once you go the route to use mirror://gentoo in ebuilds as SRC_URI people are screwed as soon as the ebuild vanishes from portage. I'd love to see this (mis-)behavior being more vigorously discouraged in Gentoo-land... Cheers -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Am Thu, 28 Nov 2013 08:55:56 -0700 schrieb Christoph Junghans : > 2013/11/28 Rich Freeman : > > On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson > > wrote: > >> On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: > >>> Paul B. Henson wrote: > >>> > In openntpd ebuilds starting with version 20080406-r3, logging > >>> > was changed from using the default standard syslog to running > >>> > the daemon in debug mode, logging to stderr, and having > >>> > start_stop_daemon background the process itself and redirect > >>> > the output to a log file. > >>> > > >>> > I think this is broken. > >>> > >>> Yes, I think it is really f-ing broken too. > >> > >> Well, looks like it's just you and me in that camp :(, quite > >> disappointing no other devs stepped up with an opinion on this. > >> Guess I'll just fix this in my local overlay and the rest of the > >> users can fend for themselves. > > > > Did anybody actually talk to the maintainer about this and ask why > > this was done? That would probably be a good first step if you want > > it to change. Having 47 devs agree with you doesn't really > > accomplish much if none of them care to maintain the package in > > question. > Paul talked to me via the bug tracker, bug 491134, and due to > discussion we had there openntpd-20080406-r5 features a use flag to > bring back syslog support (for details see the bug). This allows to > run openntpd with two different ways of logging, via syslog (like Paul > wants) and with a separate log file to avoid boot delays (like djc > wants). We could easily make syslog logging the default, like > polynomial-c suggested in another thread, but syslog is enabled in > most profiles by default anyway. > > > > > Also, you can always publish your overlay. :) > > > > Rich > > > > > I think I messed something up here. Yesterday I tried to reply on the latest mail being in this discussion thread but added Christoph's email address with a typo so the reply was not sent at all. I then only sent the reply to him and not to the list. So for completeness, here's my reply from yesterday: [Begin of quote] CCing ottxor (he's our openntpd maintainer) so he won't miss further discussion about this. Actually I partially do agree with the complaints that appeared in this thread. If logging once was done via syslog this should not be changed. So rather than making this available via USE flag being disabled by default I'd rather prefer to have the USE flag being enabled by default. I do not agree with Paul's suggestion to remove the -d option from the init script again. Unfortunately openntpd does not create a PIDfile once it gets started. This would not be a problem if openrc would not require a PIDfile to _reliably_ determine if the daemon is still running or not. So I think ottxor did the only right thing here. On the other hand since the daemon's init script starts the daemon with -d I see occasional ntpd crashes on one of my systems. I'm still investigating this and right now won't blame anyone. Fixes for the boot delays have already been mentioned (don't use ntpd's -s option) and other problems I cannot really see. [End of quote] I think there's some confusion on what the -d option actually does, so let me cite the relevant parts from "man 8 ntpd": ntpd uses the adjtime(2) system call to correct the local system time without causing time jumps. Adjustments larger than 128ms are logged using syslog(3) with LOG_INFO priority. The threshold value is chosen to avoid having local clock drift thrash the log files. Should ntpd be started with the -d option, all calls to adjtime(2) will be logged. [snip] -d Do not daemonize. If this option is specified, ntpd will run in the foreground and log to stderr. [snip] -v This option allows ntpd to send DEBUG priority messages to syslog. Now let's discuss if this can be considered as "debug mode" or not. @Christoph: Sorry I messed up your nickname so badly :-/ -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
[gentoo-dev] =net-fs/samba-4* vs. dev-libs/openssl[kerberos]
Hi list, in [1] we got a bug where was pointed out that it is impossible to use =net-fs/samba-4* on a system which has dev-libs/openssl[kerberos] installed. Long story short, samba-4 hard requires app-crypt/heimdal while openssl[kerberos] hard requires app-crypt/mit-krb5. Of course both packages are mutually exclusive as both are their own kerberos implementation. The bug reporter suggests to use bundled heimdal from samba-4 which I would like to avoid if possible. If anyone knows some better solution please speak up. It is highly appreciated. [1] https://bugs.gentoo.org/490872 Kind regards -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Am Tue, 10 Dec 2013 21:55:05 +0100 schrieb Pacho Ramos : > https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 > > This has reminded me that maybe we should switch to cronie from > vixie-cron as default and recommended cron provider in Handbook. Last > time I checked, vixie-cron upstream was died while cronie forked it > fixing some bugs :/ > > What do you think? > > > > +1 from me (as the package maintainer of cronie I cannot vote differently here :P) -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Am Wed, 11 Dec 2013 23:42:03 + schrieb Pavlos Ratis : > On Tue, Dec 10, 2013 at 8:55 PM, Pacho Ramos wrote: > > > https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 > > > > This has reminded me that maybe we should switch to cronie from > > vixie-cron as default and recommended cron provider in Handbook. > > Last time I checked, vixie-cron upstream was died while cronie > > forked it fixing some bugs :/ > > > > What do you think? > > > > > > > > > > > I am all for it. I wouldn't say that vixie-cron is dead since it is > still functional, however I would rather say that it is outdated. > In my opinion, cronie, unlike the other cron variants is the most > reliable. Also, many other distributions like Arch[1] and openSUSE[2] > have already switched from vixie-cron to cronie. > > Note: We need a new entry for cronie to our Cron wiki page [3] > > [1] https://wiki.archlinux.org/index.php/cron > [2] http://en.opensuse.org/openSUSE:Cron_replace > [3] https://wiki.gentoo.org/wiki/Cron > > Pavlos I've added cronie to our Wiki cron page. -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog
Am Wed, 25 Dec 2013 14:16:07 +0100 schrieb Patrick Lauer : > > > > > You are interfering with my workflow and I already told you why I > > kept the useflag, so stop reverting my commits after I told you the > > reasons in a private mail. > > Eh, it's been two days, and the temporary issue is still there ... > > Fix your workflow not to rely on repoman warnings being nonfatal, > then I won't have any reason to annoy you. > > (And I thought that was a one-time oopsie, not an issue that'll appear > more often) > > > QA is more than just running repoman and doing random commits on > > other peoples ebuilds. > > Being a dev is more than just doing your thing and ignoring the rest. > I'm getting tired of cleaning up behind people (not only you, it's on > average 2 issues a day I have to figure out and either fix or file > bugs). Don't expect any lenience or tolerance as long as the average > is that bad, I just prune the list of repoman warnings and errors > down as far as possible. > > (Today alone I filed 4 bugs for gnome [incomplete gnome-3.6 removal], > had to clean up after a stabilization bug [cups-filters], fixed a ruby > package that had now unsatisfiable ruby_targets [fxruby] ... and maybe > I've even forgotten a thing or two there. See how you adding random > spurious warnings is not improving my mood? ;) ) > > Have a nice pagan ritual day, > > Patrick > Just for the record. I've reintroduces the polarssl USE flag to media-sound/umurmur ebuilds and package.use.mask-ed the flag until upstream bug [1] is fixed. Now please stop this useless "but he has taken my lollipop" kind of fight. [1] https://github.com/fatbob313/umurmur/issues/24 Once again, thanks hasufell for taking care of the polarssl issue in umurmur. Without you it would have completely escaped my attention. ;) Cheers -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Tightening EAPI rules
On Mon, 10 Feb 2014 21:46:56 +0800 Patrick Lauer wrote: >On 02/10/2014 09:23 PM, Anthony G. Basile wrote: >> The statement "Deprecating an EAPI can mean breakage" depends on >> what we mean by "deprecating." I'm assuming here we mean something >> like repoman won't allow commits at EAPI=1,2,3 but that ebuilds in >> the tree at those EAPI's will continue working. Eg. dosed which was >> deprecated in the EAPI 3 to 4 jump. > >Right now EAPI 1 and 2 are deprecated, which means repoman prints some >warnings that get ignored and nothing happens. Not in my case. I EAPI-bump each ebuild to either EAPI-4 (base-system packages) or EAPI-5 where repoman complains about when I put my fingers on them... I hope I am not the only one doing this. >Going from the current state I would distinguish between deprecated >(=unwanted, but tolerated) and banned (not tolerated) > >> >> I think we should look at the question of deprecating EAPI's on and >> ad hoc basis with discussion on the list and a vote in the council. > >I think it's safe to deprecate the antepenultimate EAPI, and then do >the banning on a more delayed and controlled basis. > >Patrick > > -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Hi,
On Wed, 12 Feb 2014 00:39:14 +0200 Alex Alexander wrote:
>Hello fellow developers,
>
>In the first meeting of the new QA team, we discussed the state of the
>gtk{,2,3} USE flags in the main tree. [0]
>
>In its current state, USE="gtk" means gtk2. The Gnome team is trying
>to change this into "the most recent gtk version" (it is a work in
>progress).
>
>Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in
>packages that may support either or both the toolkits. To handle this,
>a few developers have introduced the "gtk3" useflag, that prefers gtk3
>over gtk2 when both toolkit versions are supported. At this point, the
>Gnome team highly recommends prefering gtk3 if possible, skipping the
>useflag altogether. [1]
>
>Some developers choose to follow the Gnome team's highlights, while
>others choose to go their own way. The QA team would like to establish
>a guideline that solves this problem in the best way possible.
>
>During our discussion, it was pointed out that keeping a generic
>USE="gtk" is sub-optimal. The non-straightforward nature of new
>toolkit versions makes transitioning from one to the other a slow,
>tedius process and we think that a non-versioned USE flag makes things
>even worse.
>
>A few of our members recommended a move away from the unversioned
>USE="gtk" to versioned-only USE flags. Qt managed to do this quite
>successfully when they transitioned from the unversioned
>USE="qt" (that actually meant qt3) to USE="qt4". The benefits can be
>seen now that qt5 is around the corner. USE="qt5" is straightforward,
>does not mess with qt4 packages and was introduced to the tree without
>messing with current packages too much - other than adding a new use
>flag where appropriate. There is also no need for USE="qt" anymore.
>
>To achieve this, version 3 of gtk should always be enabled by
>USE="gtk3". At some point in the future, when gtk2 consumers reach
>zero, we will retire "gtk" for good. Then, if some day gtk4 comes
>around, we will be able to introduce support for it in the tree by
>simply adding USE="gtk4", without having to re-structure half the tree.
>
>We are reaching out to the developer community to hear your thoughts
>and ideas on the matter. We would like to reach a decision that could
>possibly affect and direct the state of whole tree. This decision
>could then be turned into a policy, improving Gentoo's consistency
>across the tree.
>
>Cheers
>
>[0]
>https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
>[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
This is a really good idea and I am all in favor of it.
gtk+:3 still isn't adopted widely and there are still not many good
looking skins available for it. (sorry but I don't want to have all gtk+
apps I am using looking totally ugly again)
I doubt gtk+:2 will be deprecated that soon as some of our devs try
to imply.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Wed, 19 Feb 2014 23:23:23 +0100 Ulrich Mueller wrote: >Following up to today's QA meeting: The gtk3 USE flag is used by >27 packages, so I suggest making it a global flag: > >gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 > >Ulrich +1 gtk+:3 still is a mess even in its tenth incarnation... -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: new global USE flag gtk3
On Thu, 20 Feb 2014 11:28:36 +0200 Samuli Suominen wrote: > >On 20/02/14 11:23, Steev Klimaszewski wrote: >> On Thu, 2014-02-20 at 03:59 -0500, Alexandre Rostovtsev wrote: >>> And this is an example of why everyone on the gnome team doesn't >>> like the "gtk3" flag. Because well-meaning developers will be >>> looking at their one corner of the portage tree, deciding that they >>> are going to handle the choice of gtk version without slotting, and >>> not consider the effect on the distro as a whole. >>> >>> You know what's going to happen now, after the QA team decision? >>> >>> First of all, lots of developers will start renaming "gtk" to >>> "gtk3" in their ebuilds' IUSE. >>> >>> Which means "gtk gtk3" will soon have to be added to USE in >>> targets/desktop/gnome/make.defaults (currently, the gnome profile >>> globally only has USE="gtk" because the "gtk3" flag is evil). >>> >>> And users of non-gnome profiles who use gnome applications will of >>> course manually add "gtk gtk3" to USE in their local make.conf. >>> >>> Unfortunately, at the same time, lots of other developers are going >>> to start adding support for building against gtk2 XOR gtk3. Because >>> of course "Gentoo is about choice", and the more choices, the >>> merrier, and the gtk3 flag has been declared as supported by the QA >>> team. And that means lots of REQUIRED_USE="^^ ( gtk gtk3 )". >>> >>> For the gnome team this results in a headache: maintaining a big >>> list of "-gtk" / "-gtk3" entries in >>> targets/desktop/gnome/package.use so that gnome users get a >>> sensible choice and don't need to edit /etc/portage/* just to >>> emerge widely used desktop tools. >>> >>> But for non-gnome users who manually added USE=gtk3 to make.conf, >>> this means regular emerge conflicts after sync, forcing them to >>> *guess* whether "-gtk" or "-gtk3" in pacakge.use is the better >>> choice. Maybe with portage auto-suggesting the wrong solution just >>> to add to the wonderful user experience :/ >>> >> See, now this is an example of a good email as to why supporting both >> can be a hassle for more than just one desktop. Instead of telling >> me that I'm dumb for thinking it's a good idea to follow upstream's >> supported ideas, and that we should force one or the other. >> >> The KDE team seems to be able to deal with it just fine, but somehow >> it's impossible and hard for the GNOME team. Why is that? What does >> KDE do differently that makes it feasible? >> >> > >No, they didn't manage it, at all, which why we don't see Qt3/KDE3 in >tree anymore. > Very bad excuse... They punted kde3 because they didn't have the manpower to stem both KDEs... -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
[gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only
Hi,
it seems like some GNU projects start to release their source tarballs
in lzip compressed versions only [1][2].
This is a problem since portage's unpack function doesn't know anything
about lzip.
For sys-fs/ddrescue (where I am the Gentoo package maintainer) I simply
added "app-arch/lzip" to DEPEND and added an appropriate src_unpack()
function to the ebuild. That immediately lead to [3] where I got the
request to get rid of that dependency by either convince upstream to
release their tarballs in a differently compressed format or provide a
recompressed source tarball myself. My conversation with ddrescue
upstream was not successful in the way that they were willing to
provide their sources in several differently compressed tarballs.
Now sys-apps/ed started the same with version 1.10 [2] and I really
don't want to repeat the whole stuff from ddrescue again without having
this discussed here.
So what can we do? Three solutions came to my mind which I list
here in the order first being my favorite, last being my least
favorite:
1.)
Make portage's unpack function lzip compatible
2.)
Fix this on ebuild level:
- add app-arch/lzip to DEPEND
- add something like
'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die'
to a custom src_unpack() function.
3.)
Provide all affected source tarballs ourselves in a portage compatible
compressed format.
4.)
Try very hard to convince upstream to provide sources in differently
compressed tarballs.
What do you think?
[1] ftp://ftp.gnu.org/gnu/ddrescue/
[2] ftp://ftp.gnu.org/gnu/ed/
[3] https://bugs.gentoo.org/485462
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only
On Thu, 20 Feb 2014 16:28:30 +0100 Ulrich Mueller wrote:
>Last time I checked, lzip compressed slightly worse and was slower
>than xz-utils, so there really is no reason why one would want to use
>it. Maybe more important, even if lzip was at par with xz-utils, the
>latter has won the competition and is vastly more popular.
>
>What was his argument for refusing a release in .tar.xz format?
You can find some of his arguments in https://bugs.gentoo.org/249059
>> So what can we do? Three solutions came to my mind which I list here
>> in the order first being my favorite, last being my least favorite:
>
>> 1.) Make portage's unpack function lzip compatible
>
>> 2.) Fix this on ebuild level: - add app-arch/lzip to DEPEND - add
>> something like 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' to a
>> custom src_unpack() function.
>
>> 3.) Provide all affected source tarballs ourselves in a portage
>> compatible compressed format.
>
>> 4.) Try very hard to convince upstream to provide sources in
>> differently compressed tarballs.
>
>It would rate them in order 4, 3, 2, 1, with 4 being my favourite.
>
>Ulrich
Well, 4 is the most uphill of all solutions with little chance of
success. And even if we can convince some upstreams, we'd still have to
deal with the ones refusing our request.
3 is similar annoying as we have to make sure to provide these tarballs
like forever.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
On Mon, 24 Feb 2014 14:16:36 -0500 Alex Xu wrote: >On 24/02/14 12:48 PM, Lars Wendler (Polynomial-C) wrote: >> This is another good reason why udev should have _never_ been >> integrated into systemd! >> >> In case someone still wants to retain his original systemd >> INSTALL_MASK, just use udev ebuilds from poly-c overlay. These >> ebuilds >> >> - still install udevd into /sbin where a daemon belongs to. >> - disable the crappy new network naming scheme by default >> - install the new naming scheme config files into /lib/udev/network/ >> (version >=209) >> - try to prevent most naming pollution of pure udev with systemd >> crap. >> >> I have no plans to stop fixing the annoyances the gentoo udev >> ebuilds have since udev was integrated into systemd in the ebuilds >> from my overlay. >> >> Ursprüngliche Nachricht Von: Mike >> Gilbert Datum:24.02.2014 16:55 >> (GMT+01:00) An: Gentoo Dev >> Betreff: Re: [gentoo-dev] News item draft for >> >=sys-fs/udev-209 upgrade On Mon, Feb 24, 2014 at >> >7:58 AM, Thomas D. wrote: >>> Hi, >>> >>> not everyone is using systemd. On my systems for example, I don't >>> have "/lib/systemd/" (INSTALL_MASK). >>> >>> The current news item draft raises question like "When the 'actual >>> configuration' is in /lib/systemd/network/99-default.link... what >>> will happen to people without systemd (and a INSTALL_MASK set)?" >>> >>> Would be nice if the news item and Wiki could handle upgrade path >>> for systemd *and* non-systemd users... >>> >> >> You need to remove /lib/systemd/ from INSTALL_MASK. If you don't want >> unit files, mask /lib/systemd/system/ instead. >> > >While you're whinging about integration, you're sending bad HTML email. > Yeah, didn't know my mobile phone's mail client is sending that ugly mails. Gotta look for a better one... -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
On Tue, 25 Feb 2014 06:31:20 +0200 Samuli Suominen wrote:
>
>> - disable the crappy new network naming scheme by default
>> - install the new naming scheme config files into /lib/udev/network/
>> (version >=209)
>
>stupid, since upstream assured me, systemd-udevd won't be the only
>package reading the file from it's intended location
Funny that the person who turned official Gentoo udev ebuilds into the
stupid pile of crap they are today tells that these changes are
stupid...
But well... I wouldn't have expected anything else...
>> - try to prevent most naming pollution of pure udev with systemd
>> crap.
>
>childish. me don't like pink ponies. pink too much. pony okay.
Riiight... as udev has anything else to do with systemd other than
being uselessly integrated into systemd whereas it can still work on
its own with no whatsoever relation to systemd. But yes, totally
childish...
>>
>> I have no plans to stop fixing the annoyances the gentoo udev ebuilds
>> have since udev was integrated into systemd in the ebuilds from my
>> overlay.
>
>as you wish, /me passes the `find . -exec sed -i -e 's:systemd::g' {}
>+` beer can opener :)
>
>>
>> Ursprüngliche Nachricht
>> Von: Mike Gilbert
>> Datum:24.02.2014 16:55 (GMT+01:00)
>> An: Gentoo Dev
>> Betreff: Re: [gentoo-dev] News item draft for >=sys-fs/udev-209
>> upgrade
>>
>> On Mon, Feb 24, 2014 at 7:58 AM, Thomas D. wrote:
>> > Hi,
>> >
>> > not everyone is using systemd. On my systems for example, I don't
>> > have "/lib/systemd/" (INSTALL_MASK).
>> >
>> > The current news item draft raises question like "When the 'actual
>> > configuration' is in /lib/systemd/network/99-default.link... what
>> > will happen to people without systemd (and a INSTALL_MASK set)?"
>> >
>> > Would be nice if the news item and Wiki could handle upgrade path
>> > for systemd *and* non-systemd users...
>> >
>>
>> You need to remove /lib/systemd/ from INSTALL_MASK. If you don't want
>> unit files, mask /lib/systemd/system/ instead.
>>
>
>
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
On Tue, 25 Feb 2014 19:46:23 +0100 Peter Stuge wrote: >Lars Wendler wrote: >> >> - try to prevent most naming pollution of pure udev with systemd >> >> crap. >> > >> >childish. me don't like pink ponies. pink too much. pony okay. >> >> Riiight... as udev has anything else to do with systemd other than >> being uselessly integrated into systemd whereas it can still work on >> its own with no whatsoever relation to systemd. But yes, totally >> childish... > >I wouldn't say childish but it doesn't seem too useful to me. It >seems clear (at least to me) that even if there isn't so tight >integration of udev with systemd today it's reasonable to expect >that there will be tight integration in the soonish future, as >upstream continues to move in the direction they like. > >There's nothing wrong per se with a future udev ebuild which >applies a mega-patch onto systemd sources in order to get udevd >standalone but I think that's probably not the most useful >contribution you can make to Gentoo, Lars. > >Of course in the end you should work on what you like, but in your >place I would probably focus on something else, probably eudev. > > >//Peter As long as it's feasible I will continue patching the systemd crap out of udev. The worst part always was and still is the man pages as one cannot re-use previous patches on them. Whatever systemd maniacs are doing there, it's the most time consuming part of the patching. The fun part is, it's still quite easy to get udev standalone without anything being related to systemd (with the exception of the systemd unit files which still can be used with my ebuilds). -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>It would be very helpful if INSTALL_MASK could be overriden from an
>ebuild, if user hasn't
>set otherwise.
>So it could be configured like USE_ORDER which is
>"env:pkg:conf:defaults:pkginternal:repo:env.d"
>So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>This would be very helpful in preventing people from shooting themself
>in the foot
>
>The only problem is that I propably don't have enough python skills to
>make that happen w/
>sys-apps/portage. But does the suggestion make sense? Should I open a
>feature request bug?
>
No need for if the ebuild(s) would use sane installation paths.
Please finally stop imposing your insane ideas upon us, thanks.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
On Fri, 28 Feb 2014 16:41:23 +0200 Samuli Suominen wrote:
>
>On 28/02/14 16:41, Lars Wendler wrote:
>> On Fri, 28 Feb 2014 15:28:30 +0200 Samuli Suominen wrote:
>>
>>> It would be very helpful if INSTALL_MASK could be overriden from an
>>> ebuild, if user hasn't
>>> set otherwise.
>>> So it could be configured like USE_ORDER which is
>>> "env:pkg:conf:defaults:pkginternal:repo:env.d"
>>> So INSTALL_MASK_ORDER like "ebuild:${user's own INSTALL_MASK}"
>>> This would be very helpful in preventing people from shooting
>>> themself in the foot
>>>
>>> The only problem is that I propably don't have enough python skills
>>> to make that happen w/
>>> sys-apps/portage. But does the suggestion make sense? Should I open
>>> a feature request bug?
>>>
>> No need for if the ebuild(s) would use sane installation paths.
>>
>> Please finally stop imposing your insane ideas upon us, thanks.
>>
>
>You should stop attacking people. Period.
Once you stop trying to make things worse in Gentoo I will consider
stopping my attacks... so it's up to you.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] glibc-2.19 moving to ~arch
On Sat, 22 Mar 2014 02:10:46 -0400 Mike Frysinger wrote: >i've seen like no bugs due to glibc-2.19, so i'll be moving it into >~arch in the next week or so >-mike +1 Works fine on two of my systems. -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs / looking for new primary maintainers
On Sun, 20 Apr 2014 17:09:00 +0800 Ben de Groot wrote: >media-libs/fontconfig >x11-libs/cairo I'd be interested in these but I might not give them the attention they deserve. -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
[gentoo-dev] Need help with sys-fs/e2fsprogs-1.42.11 build failure
Hi guys,
I just add e2fsprogs{,-libs}-1.42.11 p.masked to our tree as I get a
strange build failure in e2fsprogs-1.42.11:
x86_64-pc-linux-gnu-gcc -I. -I../../lib -I../../lib -D_GNU_SOURCE
-march=barcelona -mtune=barcelona -O2 -pipe -DHAVE_CONFIG_H
-I../../debugfs -c tst_libext2fs.c -o tst_libext2fs.o make[2]: *** No
rule to make target '../../lib/libss.a', needed by 'tst_libext2fs'.
Stop. make[2]: Leaving directory
'/var/tmp/portage/sys-fs/e2fsprogs-1.42.11/work/e2fsprogs-1.42.11/lib/ext2fs'
Makefile:395: recipe for target 'all-libs-recursive' failed
The above run was with MAKEOPTS set to -j1 to make sure it's not a
parallel make issue.
I already looked into the sources but I can't figure out where the
problem comes from. Any help is highly appreciated.
Kind regards
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] Need help with sys-fs/e2fsprogs-1.42.11 build failure
On Sun, 20 Jul 2014 16:56:55 +0200 Jeroen Roovers wrote:
>On Sun, 20 Jul 2014 12:47:49 +0200
>Lars Wendler wrote:
>
>> I just add e2fsprogs{,-libs}-1.42.11 p.masked to our tree as I get a
>> strange build failure in e2fsprogs-1.42.11:
>
>Why let that bug tracker go unused? :)
>
>
> jer
>
Sorry my fault. I didn't look if there's a bug open for it. Thanks for
pointing that out and add me to CC.
Cheers
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] Need help with sys-fs/e2fsprogs-1.42.11 build failure
On Sun, 20 Jul 2014 11:12:17 -0400 Mike Gilbert wrote:
>On Sun, Jul 20, 2014 at 11:09 AM, Mike Gilbert
>wrote:
>> On Sun, Jul 20, 2014 at 6:47 AM, Lars Wendler
>> wrote:
>>> Hi guys,
>>>
>>> I just add e2fsprogs{,-libs}-1.42.11
>>
>> Is there some reason that we continue to maintain these as two
>> separate packages? It seems like the e2fsprogs ebuild could
>> build/install both the binaries and the libraries, and that would
>> probably prevent weird failures like this one.
>>
>> I see this in README.subset:
>
>Oops, hit send too quickly.
>
>I see this in README.subset:
>
>---
>This distribution contains a subset of the e2fsprogs package; it
>contains the base libraries (ss, et, uuid, blkid) which may be used by
>other non-ext2-related applications.
>
>This may be useful for non-Linux operating systems that need these
>libraries for GNOME, but who do not need the ext2/ext3 filesystem
>utilities.
>---
>
>From what I can tell, e2fsprogs and e2fsprogs-libs have mostly the
>same KEYWORDS with a couple of exceptions:
>
>x86-fbsd
>x86-freebsd
>x86-solaris
>
>It hardly seems worth the effort to maintain 2 ebuilds for these small
>platforms.
>
I think vapier could shed some light on this.
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
Re: [gentoo-dev] systemd profiles
On Sat, 30 Aug 2014 08:03:10 -0400 Rich Freeman wrote: >On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny >wrote: >> Dnia 2014-08-30, o godz. 13:27:08 >> "J. Roeleveld" napisał(a): >>> >>> Not sure if this idea has been discussed before, but: >>> Wouldn't it be an idea to have a "virtual/init" which depends on 1 >>> of: >> >> You mean our virtual/service-manager? >> > >Michał is already well-aware of this one, but for general interest, >the main blocker to actually doing this is: >https://bugs.gentoo.org/show_bug.cgi?id=504116 Which is really a shame that there's such slow progress. I already added several patches to the blocking bugs but none was fixed meanwhile... >Rich > Lars -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] Adding dev-lang/perl version to emerge --info
On Sat, 4 Oct 2014 00:05:19 +0200 Andreas K. Huettel wrote: > >Hi all, > >since Perl is a fairly central package and it's hard to debug problems >without the exact version, the perl team would like to add >dev-lang/perl to profiles/info_pkgs. > >This has the effect that the installed version of dev-lang/perl is by >default included in every "emerge --info" output. > >Opinions, encouragement, opposition, flamewars? :) > >Cheers, >Andreas > Doit! This has always bugged me and it could be quite helpful. -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Are users forced to use PAM?
On Mon, 06 Oct 2014 03:53:11 +0300 Nikos Chantziaras wrote: >On 05/10/14 16:20, Diego Elio Pettenò wrote: >> Please get upstream to apply the patch and release a new sudo >> version. >> >> Simple as this: -pam is not by default tested and you keep the >> pieces if it breaks. If you can get upstream to just apply that >> patch, you solve your problem. Insulting developers as it's >> happening on that bug will bring you nowhere. > >I didn't insult anyone. > > > Yeah, we didn't mean you. Sorry if that impression might have arose. But as can be clearly seen in the bug, there is a person which thinks insults and rude behavior could speed up things. He could not be more wrong but that's a different topic and should not be discussed here. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC signature.asc Description: PGP signature
Re: [gentoo-dev] Re: About time to unify 'cdda' and 'cdaudio' USE flags and make the remaining one global?
Let's finally move on regarding this topic. As I'm also in favour of the "cdda" USE flag I'd like to know if there's any objection against the decision to unify/convert the "cdaudio" USE flag into "cdda". If there's no good reason against this conversion I will proceed with filing bugs against packages using the "cdaudio" USE flag next weekend. Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler Am Wednesday 08 July 2009 02:52:07 schrieb Duncan: signature.asc Description: This is a digitally signed message part.
[gentoo-dev] perl-5.10 inclusion
Hello list,
I already talked about this topic yesterday in #-dev.
perl-5.10 is out since end of 2007 [1] and we still don't have it in our main
portage-tree but rather have it kinda rotting in the perl-experimental
overlay.
I know that the perl team is badly understaffed with only one active dev who
is not even on the member list (is that right, tove?) but there has to be
done something. We cannot stick with perl-5.8 forever.
So my suggestion is to ask for help here. Anybody willing to help please grab
the perl-experimental overlay, install {lib,}perl-5.10 and start to use it on
a regular basis. If you don't mind, try to install as much perl-packages as
possible and report back any failures to our bugzilla.
I already started on that and "infected" two of my systems with perl-5.10. My
VM (which I originally only set up for testing of kde-4) is currently running
a 'USE="perl" emerge -e @world' and till now 320 out of 550 packages
installed without any problems on that machine.
Next step will be to go though perl-core and dev-perl categories and install
every package being in there.
My intention is to get a picture about how many packages are broken with
perl-5.10. The fixing of those packages is something I unfortunately cannot
do (I'm a complete perl-noob) but maybe this is a good start getting
perl-5.10 finally into portage.
By the way, as soon as I find the first packages being broken with perl-5.10 I
will open a tracker bug in bugzilla. So watch out for it if you stumble about
failing packages with perl-5.10 yourself.
Lars Wendler (Polynomial-C)
Gentoo Staffer and bug-wrangler
[1] according to the perl website version 5.10 is more than one year and seven
months old: http://www.cpan.org/src/README.html
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
> In summation, I say hard-enable these: > > acl > Please don't do this. It would force installation of sys-apps/acl to any user which I think is not desired by everybody. I'd rather like to see this being enabled by either the acl or the consolekit USE flag. Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman storage location (again)
> It's just impossible to choose perfect location that suits all needs and > it should stay user-configurable. So again, do not change this default > we no real need another time, please. /usr/local is a bad choice for an ebuild-generated default. Like I said in bug #253725 I don't want ebuilds to mess with stuff in /usr/local. So either remove this default completely and let the user decide when setting up layman or move it around. The best suggestions I've read here for now were either /var/layman or /usr/layman which I would have no problem with. -- Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman storage location (again)
Am Samstag 16 Januar 2010 19:26:04 schrieb Sebastian Pipping: > On 01/16/10 13:56, Ben de Groot wrote: > >> anybody objecting to /var/layman ? > > > > I like that. > > it seems that > > /var/layman > > is the only location nobody has objected to, yet. i plan to go with > that atm. /var/lib/layman is my second favorite. > > again, any objections? > > > > sebastian > +1 -- Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: > On 16-06-2010 14:40, Jim Ramsay wrote: > > Chí-Thanh Christopher Nguyễn wrote: > >> I propose that this license be added to the EULA group. The previous > >> AdobeFlash-10 license is similar in this regard, and could possibly > >> also be added to that group. > > > > Agreed, on both points, and done. Thanks for finding and airing this > > issue! > > > >> One notable section is 7.6 in which Adobe reserves the right to > >> download and install additional Content Protection software on the > >> user's PC. > > > > Not like anyone will actually *read* the license before adding it to > > their accept group, but if they did this would indeed be an important > > thing of which users should be aware. > > I defend it is our job to warn users about this kind of details. To me > it sounds that a einfo at post-build phase would do the job, what do you > guys think? Definitely yes! This is a very dangerous snippet in Adobe's license which should be pretty clearly pointed at to every user. -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Am Freitag 18 Juni 2010, 00:37:29 schrieb Chí-Thanh Christopher Nguyễn: > Dale schrieb: > >>>>> One notable section is 7.6 in which Adobe reserves the right to > >>>>> download and install additional Content Protection software on the > >>>>> user's PC. > >>>> > >>>> Not like anyone will actually *read* the license before adding it to > >>>> their accept group, but if they did this would indeed be an important > >>>> thing of which users should be aware. > >>> > >>> I defend it is our job to warn users about this kind of details. To me > >>> it sounds that a einfo at post-build phase would do the job, what do > >>> you > >>> guys think? > > Though I am not opposed to adding a warning, I think the license mask is > sufficient. If users demonstrate their indifference by setting > ACCEPT_LICENSE="*" or adding AdobeFlash-10.1 without reading the > license, then I somehow doubt that elog messages will have an effect. Maybe I'm quite alone with that but I have ACCEPT_LICENSE="*" because I hate to edit my make.conf each time I try to emerge a package with yet another license that is missing in the variable. But I still watch for elog messages carefully after each merge. > >> Definitely yes! This is a very dangerous snippet in Adobe's license > >> which > >> should be pretty clearly pointed at to every user. > > > > Could that also include a alternative to adobe? If there is one. > > There are three open-source flash browser plugins in portage: > - swfdec: development seems to have stalled > - gnash: I have received mixed reports about the stability of the > current version. The next release will include VA-API support and other > improvements. > - lightspark: a recent effort which is in its early stages and still > incomplete in many ways (eg. audio support is planned for 0.4.2) > > None of them I consider good enough to replace adobe-flash for the > average user. Unfortunately yes. Especially now that Adobe fails to provide x86_64 users a non-vulnerable plugin I'd very much prefer to use an open-source replacement that for sure would be fixed much faster in case it's affected by some security vulnerability as well. One can only hope that flash finally vanishes from WWW now that HTML5 could become a good alternative... > Regards, > Chí-Thanh Christopher Nguyễn -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring: > On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote: > > Lars Wendler wrote: > > > Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: > > >> On 16-06-2010 14:40, Jim Ramsay wrote: > > >>> Chí-Thanh Christopher Nguyễn wrote: > > >>>> One notable section is 7.6 in which Adobe reserves the right to > > >>>> download and install additional Content Protection software on the > > >>>> user's PC. > > >>> > > >>> Not like anyone will actually *read* the license before adding it to > > >>> their accept group, but if they did this would indeed be an important > > >>> thing of which users should be aware. > > >> > > >> I defend it is our job to warn users about this kind of details. To me > > >> it sounds that a einfo at post-build phase would do the job, what do > > >> you guys think? > > > > > > Definitely yes! This is a very dangerous snippet in Adobe's license > > > which should be pretty clearly pointed at to every user. > > > > Could that also include a alternative to adobe? If there is one. > > The place to advocate free alternatives (or upstreams that are > nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs or at > best in metadata.xml... einfo should be "this is the things to watch > for in using this/setting it up" not "these guys are evil, use one of > the free alternatives!". Maybe I expressed myself a bit misinterpretative. I don't want to request an elog message telling users about alternative packages. But in my opinion an elog message pointing at the bald-faced parts of Adobe's license should be added. These parts about allowing Adobe to install further content protection software is just too dangerous in my opinion. > Grok? > > ~harring -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] The future of sys-apps/openrc in Gentoo
Hi list, now that openrc has no active upstram anymore [1] what shall we do? To be honest I was really looking forward for openrc/baselayout-2 finally becoming stable in Gentoo but this seems to be quite implausible now that openrc has no upstream anymore. If there's anyone out there who would volunteer to maintain openrc, please step up now or else I fear we must abandon openrc which would be very sad. [1] https://bugs.gentoo.org/326865 -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
Am Sonntag 04 Juli 2010, 23:02:39 schrieb Mike Frysinger: > On Sunday, July 04, 2010 10:29:57 Lars Wendler wrote: > > now that openrc has no active upstram anymore [1] what shall we do? To be > > honest I was really looking forward for openrc/baselayout-2 finally > > becoming stable in Gentoo but this seems to be quite implausible now that > > openrc has no upstream anymore. > > If there's anyone out there who would volunteer to maintain openrc, > > please step up now or else I fear we must abandon openrc which would be > > very sad. > > like i already told William a few months ago, it really doesnt matter. > openrc was a Gentoo project to start with and since it is all based in > git, there's nothing for us to do -- we already have an openrc git repo on > the Gentoo git server. > > http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=summary > -mike Not very clear to anyone as metadata.xml still contains this snippet: r...@marples.name Roy Marples Upstream - please CC him on valid bugs -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
Am Montag 05 Juli 2010, 00:15:44 schrieb Mike Frysinger: > it > certainly doesnt warrant a paniced "the sky is falling" message. Which I was nowhere trying to imply. I just wanted to have this situation sorted out which now hopefully seems to be the case. -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Lastrite: www-client/seamonkey-bin
# Lars Wendler (12 Jul 2010) # Masked for removal in 30 days. # No active maintainer. www-client/seamonkey-bin No active maintainer and latest version in tree has security bugs. maintainer- needed, otherwise it's ready for removal in 30 days. -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Lastrite: app-office/mozilla-sunbird{,-bin}
# Lars Wendler (26 Jul 2010) # Masked for removal in 30 days. # Discontinued by upstream and superseded by Thunderbird with Lightning app-office/mozilla-sunbird app-office/mozilla-sunbird-bin -- Lars Wendler (Polynomial-C) Gentoo developer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Going inactive
Sad to read this... You were the one who gave me editbugs in bugzilla some years ago which can be seen as the starting point of me becoming a package maintainer. Thanks for all the work you did for Gentoo. I'm looking forward to your return :) -- Lars Wendler (Polynomial-C) Gentoo maintainer and bug-wrangler Am Montag 27 September 2010, 20:53:18 schrieb Daniel Drake: > Hi, > > I've been too busy with other things to work on Gentoo for quite some > time and this isn't going to change now that I've just picked up new > study and work commitments. > > So I'm gonna drop out of the IRC rooms and stop checking this email > account (which is spammed to death). > > I guess this means my access will be removed at some point, although I'd > welcome the idea of it staying put in case I can find time in future. > > Thanks to everyone who taught me something or helped with my projects. I > learned a huge amount through this distro and community. > > Cya around! > Daniel signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New PUEL license
Hi folks, a couple of weeks ago I was told that the PUEL license we have in our license pool is outdated. We currently have version 6 from July 28, 2008 but latest virtualbox releases come with version 8 from April 19, 2010. A quick glance at the diff between both licenses revealed nothing but replacement of SUN with Oracle and some small wording changes but as english is not my native language I find it quite hard to understand licenses written in english and distinguish between wording changes with big or rather small impact on the license. Last but not least IANAL of course. So I'd appreciate if someone could have a deeper look at the differences and tell me if it's okay to just drop the old license and add the new one of if we need to keep both, old and new one in our license pool. Regards -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
[gentoo-dev] app-emulation/virtualbox-ose got renamed to app-emulation/virtualbox
Hi folks, with Oracle releasing virtualbox-4.0.0 they changed their proprietary stuff which was formerly only available in the app-emulation/virtualbox-bin package into extensions which can also be used by the source-based 4.0.0 ebuild when you enable the "extensions" USE flag or install app-emulation/virtualbox- extpack-oracle. To reflect this new state we renamed app-emulation/virtualbox-ose packages to app-emulation/virtualbox. The package move should be completely automatically. Please pretty please read the elog messages when you update/install app- emulation/virtualbox for the first time after this package move. It contains important information! -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] app-emulation/virtualbox-ose got renamed to app-emulation/virtualbox
Sorry guys,
after thinking about it I definitely chose the wrong lists. Won't happen
again...
--
Lars Wendler (Polynomial-C)
Gentoo package maintainer and bug-wrangler
Am Freitag 07 Januar 2011, 22:05:27 schrieb Jeremy Olexa:
> On 01/07/2011 10:07 AM, Rich Freeman wrote:
> > Bottom line is that if the goal is to let users of a package know
> > about a change, -dev-announce is neither sufficient nor on-topic. At
> > least, that's my thinking...
>
> I agree, why do I as a reader of gentoo-dev{,-announce} care about vbox?
> I've never used it. I assume the intent was to get the original message
> to vbox USERS, not the general dev population.. :)
>
> -Jeremy
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage in main tree
Hi, I don'f feel very well with this idea especially because no matter how hard I try I don't get comfortable with EAPI-3. No offense to our prefix guys, you surely did a hell of a good job and EAPI-3 seems to really get you out of quite some trouble you had with earlier EAPIs, but... I for myself never tried a prefix installation and I don't have any intentions to do this in the foreseeable future so I still prefer EAPI-2 wherever I can simply because EAPI-3 imposes overhead on my side which I have no real benefit from and I have no real clue about how to write proper EAPI-3 ebuilds. -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler Am Dienstag 25 Januar 2011, 12:20:30 schrieb Tomáš Chvátal: > Hi, > I would like to upgrade tree-wide policy for EAPI usage in main tree. > Currently we say that developers can use any named version they wish or > find sufficient. > I would on other hand like to have all ebuilds to use Latest EAPI > version possible (given the eclasses support it [hint hint maintainers > of eclasses should always try to support latest :P]) with expection for > base-system or more specialy depgraph for portage that needs to be > EAPI0. [[ And here we need to find out some upgrade proccess that would > work for everyone so we could somehow migrate them too :)]] > > With this usually new developers should be aware only of latest EAPI and > wont need to memorize what which EAPI support. Heck even I sometimes > forget what i can do with some version and whatnot. > > Winner for being PITA in this race is python.eclass that HAS completely > different behavior based on EAPI version used... > > Cheers > > Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc portage news item
-- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler Am Donnerstag 21 April 2011, 03:12:21 schrieb Donnie Berkholz: > On 13:32 Thu 14 Apr , Kfir Lavi wrote: > > When i run world update, I usually don't really check all the written > > stuff. > > > > If I do this, I'm sure a lot more Gentoo users do the same. So do > > expect people rebooting the machine without checking what your have > > wrote. This can be a major headache if you have few systems that are > > doing auto updates. I would solve this issue by stopping the emerge > > and getting the attention of the user. If I don't get the attention of > > the user, no openrc will be installed. It should be something like > > emerge -C ... 1 .2 3 4 5... > > > > To conclude, you can't issue such a change without proper confirmation > > from the user. > > I know this is the case. You're going to get literally thousands of > people (or more) who break their Gentoo systems if that indeed is the > consequence of not reading the migration guide and doing some action. > > From a glance over the guide, it wasn't immediately obvious what in > there would result in a broken system. Perhaps it's the "run > dispatch-conf" that's buried in the middle of a paragraph without enough > emphasis? That's particularly confusing for people who use etc-update > instead, and it *needs* to move somewhere more obvious like a separate > code listing with big tags and bold text. The line of red > text just isn't enough, it needs to stand out even more. > > It seems like nobody's really clear on what exactly happens though, > since I've seen people talking about this *maybe* resulting in an > unbootable system. Has anyone tested it? I didn't test it intentionally. The last time I accidently rebooted a system freshly moved to bl-2/openrc without updating the config files the boot process threw a couple of strange errors. I cannot exactly remember what kind of errors that were but the result was a system hanging in the middle of the boot process with a message similar to "nothing left to do in this runlevel" and I wasn't able to log into the system. Another problem I've once encountered after updating a system to use openrc was no running udev daemon after boot. I first didn't notice this but X didn't start and funny part was that X won't tell you it cannot start because the devicenodes in /dev for the graphics card were missing. So took me nearly a day of frustrating research until I found that the udev init script wasn't added to the sysinit runlevel. Of course this is mentioned in the migration guide but it should be explicitly pointed out how fatal this can be to not have udev getting started. I can offer to "abuse" my two stable VMs (amd64 / x86) for this to test if there's interest in getting "exact results". :) > One potential cleaner approach to the same idea Kfir suggested is to > make it an interactive emerge with an ACCEPT_LICENSE-like feature that > pops up something you must read and agree to. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: > On 27-06-2011 14:08:52 +, Justin Lecher wrote: > > Please do not use / as seperater when using sed with CFLAGS. I came > > across a bug today where it failed for crossdev. Here the toolchain > > header paths in the cflags and consowuently the seds fail. > > Please also don't use ':' as separator, as some platforms have options > for their toolchain that includes colons. Rather than telling us what to _not_ use as separator how about suggesting a list of konwn to be good separators for such cases. How about the @ character? -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] More signing problems
Am Donnerstag 14 Juli 2011, 14:54:41 schrieb Kacper Kowalik: > W dniu 14.07.2011 12:31, Thomas Kahle pisze: > > Hi, > > > > When doing automatted committing during stabilization, I recently > > started seeing manifest signing fail like this: > > > > gpg: pkglue.c:41: mpi_from_sexp: Assertion `data' failed. > > !!! !!! gpg exited with '6' status > > !!! Disabled FEATURES='sign' > > > > The curious thing: It works most of the time, but fails sometimes. I > > don't know how to trigger the behaviour. > > > > Any ideas? > > > > Cheers > > Thomas > > Problem reported here: > http://www.gossamer-threads.com/lists/gnupg/gcrypt/55063 > and fixed upstream > +10pts for Arfrever :) > Cheers, > Kacper Yep. This bug was fixed in =app-crypt/gnupg-2.0.17-r3 so make sure to have libgcrypt-1.5.0 installed together with at least that version of gnupg. -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Am Freitag 06 Januar 2012, 17:07:20 schrieb Alex Alexander: > On Fri, Jan 06, 2012 at 08:35:32AM -0500, Rich Freeman wrote: > > On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander wrote: > > > If people are really interested in keeping a tight, self contained > > > root, we need to: > > > > > > - establish a [tight] list of software we consider critical for / > > > - fix/patch software in that list so it can run without /usr there > > > - create /bin => /usr/bin/ symlinks for above software (simplifies > > > things if packages start hardcoding /usr/bin here and there) > > > - move everything else in /usr/bin/ > > > > You're missing one thing: > > > > - establish a list of all the configurations that will actually work > > with this self-contained root > > > > I think this is why there is so much disagreement over whether this is > > a good move. If you have a really simple configuration, then the > > self-contained root concept works reasonably well (though apparently > > we'll have to heavily patch newer versions of udev or abandon it to > > sustain this). > > > > However, if you have a very complex configuration the current > > self-contained root is already broken and you need an initramfs > > anyway. For in-between cases things might work now but that is likely > > to change as upstream moves on. > > > > The binary distros don't have users tweaking their kernels and init > > scripts, so they basically have to design for worst-case. Gentoo can > > get away with designing for more of an average case since we just tell > > anybody with a complex case to go read a howto and configure what is > > necessary (and we like to do that stuff anyway). > > > > We can choose not to like it, but it sounds like maintaining a > > self-contained root for even the typical case will become untenable. > > Those who argue that having /usr on a separate partition simply > > shouldn't be supported are basically just saying that our > > "self-contained root" should include everything in /usr which seems to > > defeat the whole point of a "self-contained root" anyway. > > > > It seems to me that the most reasonable approach is to not force the > > issue, but not deviate greatly from upstream either. That means > > accepting that over time the rootfs will become less and less capable > > of working on its own, and immediately improving tools like dracut to > > overcome these limitations. Users who can get away with it can avoid > > using an initramfs, at least for a time. > > > > Sure, it is all open source, and Gentoo can swim upstream if we REALLY > > want to. However, this only works if developers are willing to spend > > the time constantly fixing upstream's tools. It sounds to me like the > > maintainers of packages like udev/systemd/etc want to actually move in > > the same direction as upstream so in practice I don't see that > > happening. > > > > Now, Gentoo is about choice, so one thing we should try to do as much > > as possible is understand the limitations of the various > > configurations and make it clear to users when they do and don't need > > an initramfs. To be honest, tight coupling worries me more than the > > /usr move, since that has a lot more potential to constrain the > > choices we can offer our users (which is a great deal of the value > > that Gentoo offers). I understand its advantages, but it seems > > somewhat contrary to "the unix way." > > That's why I wrote "tight list". I do not expect the self-contained root > to be able to handle everything /usr (or a complete initramfs) would. > What it could and couldn't do is something that needs to be decided, but > some work is already done there - it's just a bit messy and incomplete > and because most people don't care it keeps getting worse. > > The important thing here is to make a clear definition of where we draw > the line and make sure things work the way we want them to. > > I agree with you in that at some point patching may become too time > consuming, but I still believe that if we do this properly, with a > well-defined plan and list of packages we want to keep in / (with > symlinks to be compatible with whatever others are trying to do), we > won't be alone in this. Gentoo may be one of the most hardcore > power-user distros out there, but we're certainly not the only one. > > Now, if only we had people interested enough in doing this... :) I'm interested in everything which prevents such kind of insanity from Gentoo. So count me in as volunteer keeping /bin, /sbin and /lib in Gentoo and systemd away from it. As long as we keep trying and working hard I'm sure we can do the workload that might come across when blind upstreams start adopting those foolish systemd/GnomeOS ideas... -- Lars Wendler (Polynomial-C) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 1/3] acct-group/uptimed: Inital commit
Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Lars Wendler --- acct-group/uptimed/metadata.xml | 8 acct-group/uptimed/uptimed-0.ebuild | 8 2 files changed, 16 insertions(+) create mode 100644 acct-group/uptimed/metadata.xml create mode 100644 acct-group/uptimed/uptimed-0.ebuild diff --git a/acct-group/uptimed/metadata.xml b/acct-group/uptimed/metadata.xml new file mode 100644 index 000..95aa13f6c5e --- /dev/null +++ b/acct-group/uptimed/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + polynomia...@gentoo.org + Lars Wendler + + diff --git a/acct-group/uptimed/uptimed-0.ebuild b/acct-group/uptimed/uptimed-0.ebuild new file mode 100644 index 000..eb3672ba65e --- /dev/null +++ b/acct-group/uptimed/uptimed-0.ebuild @@ -0,0 +1,8 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +ACCT_GROUP_ID=210 -- 2.23.0.rc1
[gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit
Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Lars Wendler --- acct-user/uptimed/metadata.xml | 8 acct-user/uptimed/uptimed-0.ebuild | 12 2 files changed, 20 insertions(+) create mode 100644 acct-user/uptimed/metadata.xml create mode 100644 acct-user/uptimed/uptimed-0.ebuild diff --git a/acct-user/uptimed/metadata.xml b/acct-user/uptimed/metadata.xml new file mode 100644 index 000..c7be278b645 --- /dev/null +++ b/acct-user/uptimed/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + +polynomia...@gentoo.org + Lars Wendler + + diff --git a/acct-user/uptimed/uptimed-0.ebuild b/acct-user/uptimed/uptimed-0.ebuild new file mode 100644 index 000..d0b6431a114 --- /dev/null +++ b/acct-user/uptimed/uptimed-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="user for uptime daemon" +ACCT_USER_ID=103 +ACCT_USER_GROUPS=( uptimed ) + +acct-user_add_deps -- 2.23.0.rc1
[gentoo-dev] [PATCH 3/3] app-misc/uptimed: Revbump replacing user eclass
with uptimed group/user packages.
Also bump to EAPI-7
Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler
---
app-misc/uptimed/uptimed-0.4.1-r2.ebuild | 60
1 file changed, 60 insertions(+)
create mode 100644 app-misc/uptimed/uptimed-0.4.1-r2.ebuild
diff --git a/app-misc/uptimed/uptimed-0.4.1-r2.ebuild
b/app-misc/uptimed/uptimed-0.4.1-r2.ebuild
new file mode 100644
index 000..02322685333
--- /dev/null
+++ b/app-misc/uptimed/uptimed-0.4.1-r2.ebuild
@@ -0,0 +1,60 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools systemd
+
+DESCRIPTION="System uptime record daemon that keeps track of your highest
uptimes"
+HOMEPAGE="https://github.com/rpodgorny/uptimed/";
+SRC_URI="https://github.com/rpodgorny/uptimed/archive/v${PV}.tar.gz ->
${P}.tar.gz"
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~hppa ~mips ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd"
+IUSE="static-libs"
+
+RDEPEND="
+ acct-group/uptimed
+ acct-user/uptimed
+"
+DEPEND="${RDEPEND}"
+
+src_prepare() {
+ default
+ # fix configure.ac for >=automake-1.13 (bug #467582)
+ sed 's@AM_CONFIG_HEADER@AC_CONFIG_HEADERS@' -i configure.ac || die
+ eautoreconf
+}
+
+src_configure() {
+ econf $(use_enable static-libs static)
+}
+
+src_install() {
+ local DOCS=( ChangeLog README.md TODO AUTHORS CREDITS INSTALL.cgi
sample-cgi/* )
+ default
+ find "${ED}" -type f -name '*.la' -delete || die
+
+ local spooldir="/var/spool/${PN}"
+ keepdir ${spooldir}
+ fowners uptimed:uptimed ${spooldir}
+
+ newinitd "${FILESDIR}"/${PN}.init-r1 uptimed
+ systemd_dounit "${FILESDIR}/${PN}.service"
+}
+
+pkg_postinst() {
+ local spooldir="/var/spool/${PN}"
+ if [[ -d "${spooldir}" ]] ; then
+ einfo "Fixing permissions in ${spooldir}"
+ find ${spooldir} -type f -links 1 \
+ \( -name records -o -name records.old \) \
+ | xargs --no-run-if-empty chown uptimed:uptimed || die
+ fi
+ echo
+ elog "Start uptimed with '/etc/init.d/uptimed start' (for openRC)"
+ elog "or systemctl start uptimed (for systemd)"
+ elog "To view your uptime records, use the command 'uprecords'."
+ echo
+}
--
2.23.0.rc1
Re: [gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit
On Tue, 06 Aug 2019 16:22:18 +0200 Michał Górny wrote: >On Tue, 2019-08-06 at 16:19 +0200, Lars Wendler wrote: >> Package-Manager: Portage-2.3.71, Repoman-2.3.17 >> Signed-off-by: Lars Wendler >> --- >> acct-user/uptimed/metadata.xml | 8 >> acct-user/uptimed/uptimed-0.ebuild | 12 >> 2 files changed, 20 insertions(+) >> create mode 100644 acct-user/uptimed/metadata.xml >> create mode 100644 acct-user/uptimed/uptimed-0.ebuild >> >> diff --git a/acct-user/uptimed/metadata.xml >> b/acct-user/uptimed/metadata.xml new file mode 100644 >> index 000..c7be278b645 >> --- /dev/null >> +++ b/acct-user/uptimed/metadata.xml >> @@ -0,0 +1,8 @@ >> + >> +> "http://www.gentoo.org/dtd/metadata.dtd";> + >> + >> +polynomia...@gentoo.org >> +Lars Wendler >> + >> + >> diff --git a/acct-user/uptimed/uptimed-0.ebuild >> b/acct-user/uptimed/uptimed-0.ebuild new file mode 100644 >> index 000..d0b6431a114 >> --- /dev/null >> +++ b/acct-user/uptimed/uptimed-0.ebuild >> @@ -0,0 +1,12 @@ >> +# Copyright 2019 Gentoo Authors >> +# Distributed under the terms of the GNU General Public License v2 >> + >> +EAPI=7 >> + >> +inherit acct-user >> + >> +DESCRIPTION="user for uptime daemon" >> +ACCT_USER_ID=103 > >Any reason to use disjoint UID/GID? Thanks for reviewing :) No explicit reason. They were never being joined on any of my systems so I thought that's no big deal. Is that mandatory? >> +ACCT_USER_GROUPS=( uptimed ) >> + >> +acct-user_add_deps > Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgphG3Sy99XvD.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit
On Tue, 06 Aug 2019 16:22:18 +0200 Michał Górny wrote: >On Tue, 2019-08-06 at 16:19 +0200, Lars Wendler wrote: >> Package-Manager: Portage-2.3.71, Repoman-2.3.17 >> Signed-off-by: Lars Wendler >> --- >> acct-user/uptimed/metadata.xml | 8 >> acct-user/uptimed/uptimed-0.ebuild | 12 >> 2 files changed, 20 insertions(+) >> create mode 100644 acct-user/uptimed/metadata.xml >> create mode 100644 acct-user/uptimed/uptimed-0.ebuild >> >> diff --git a/acct-user/uptimed/metadata.xml >> b/acct-user/uptimed/metadata.xml new file mode 100644 >> index 000..c7be278b645 >> --- /dev/null >> +++ b/acct-user/uptimed/metadata.xml >> @@ -0,0 +1,8 @@ >> + >> +> "http://www.gentoo.org/dtd/metadata.dtd";> + >> + >> +polynomia...@gentoo.org >> +Lars Wendler >> + >> + >> diff --git a/acct-user/uptimed/uptimed-0.ebuild >> b/acct-user/uptimed/uptimed-0.ebuild new file mode 100644 >> index 000..d0b6431a114 >> --- /dev/null >> +++ b/acct-user/uptimed/uptimed-0.ebuild >> @@ -0,0 +1,12 @@ >> +# Copyright 2019 Gentoo Authors >> +# Distributed under the terms of the GNU General Public License v2 >> + >> +EAPI=7 >> + >> +inherit acct-user >> + >> +DESCRIPTION="user for uptime daemon" >> +ACCT_USER_ID=103 > >Any reason to use disjoint UID/GID? No explicit reason. They were never being joined on any of my systems so I thought that's no big deal. Is that mandatory? >> +ACCT_USER_GROUPS=( uptimed ) >> + >> +acct-user_add_deps > -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpq1eo0j6DY9.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] [PATCH] acct-group/uptimed: Synced GID with uptimed user's UID
Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Lars Wendler --- acct-group/uptimed/uptimed-0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/acct-group/uptimed/uptimed-0.ebuild b/acct-group/uptimed/uptimed-0.ebuild index eb3672ba65e..952c350399c 100644 --- a/acct-group/uptimed/uptimed-0.ebuild +++ b/acct-group/uptimed/uptimed-0.ebuild @@ -5,4 +5,4 @@ EAPI=7 inherit acct-group -ACCT_GROUP_ID=210 +ACCT_GROUP_ID=103 -- 2.23.0.rc1
