Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Mon, 2012-02-27 at 20:29 +0100, Pacho Ramos wrote:
> El lun, 27-02-2012 a las 16:06 +0100, "Paweł Hajdan, Jr." escribió:
> > On 2/24/12 6:56 PM, "Paweł Hajdan, Jr." wrote:
> > > I'd like to modify eutils.eclass to only generate one command:
> > >
> > > # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \
> > > rm '/usr/lib/libv8.so.3.9.4'
> >
> > Given supporting comments to this thread (and totally off-topic
> > zfs/btrfs discussion), I'd like to commit the patch below in 24 hours.
> >
> > > --- eutils.eclass.orig2012-02-26 10:02:24.0 +0100
> > > +++ eutils.eclass 2012-02-26 10:03:17.0 +0100
> > > @@ -1276,16 +1276,8 @@
> > > fi
> > > # temp hack for #348634 #357225
> > > [[ ${PN} == "mpfr" ]] && lib=${lib##*/}
> > > - ewarn " # revdep-rebuild --library '${lib}'"
> > > + ewarn " # revdep-rebuild --library '${lib}' && rm '${lib}'"
> > > done
> > > - if [[ ${notice} -eq 1 ]] ; then
> > > - ewarn
> > > - ewarn "Once you've finished running revdep-rebuild, it should
> > > be safe to"
> > > - ewarn "delete the old libraries. Here is a copy & paste for
> > > the lazy:"
> > > - for lib in "$@" ; do
> > > - ewarn " # rm '${lib}'"
> > > - done
> > > - fi
> > > }
> > >
> > > # @FUNCTION: built_with_use
> >
>
> I think somebody pointed some "revdep-rebuild" versions where exiting
> with successful code even when failed, was fixed version stabilized?
No, it is only in - so far. It has not been released in a -0.3*
ebuild yet.
The last patch to revdep-rebuild fixing return codes is:
http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=3e51df74595c535656ef9f38bf7a577a4f64d0f5
from 11 days ago.
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due ken69267 retirement
On Sun, 2012-03-04 at 13:21 +0100, Pacho Ramos wrote: > Due his retirement the following packages need a new maintainer: > app-portage/gpytage I'll take this one, since I've been intermittently involved in it's develoment. And aside from bots, the only one consistently hanging around in #gpytage. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
[gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
As times have changed and IRC is used more an more. I propose adding an optional data field to layman's repositories.xml file format. This information would be listed along with the other information when running: # layman -i some-overlay This added information would then be available and listed in >=layman-2.0* for any overlays that choose to add that information to their listing. Yes, that functionality is present in layman-2.0.0_rc3 which is currently in the tree. For layman 1.* versions this additional information would simply be ignored and not printed since there is no code to detect and print it. So there would be no backwards compatible problems caused by running the older layman versions. I also do not intend to add that functionality to the 1.* versions as the 2.0.0_rc3 release is quite stable and I am near to releasing a 2.0.0 final. The irc field would be a simple string that can contain irc:// urls or plain text channel listings. Same as the homepage field. eg: Channel #gentoo-guis on the freenode network or #gentoo-guis on the freenode IRC network, irc://irc.gentoo.org/gentoo-guis For those that might not like the repositories.xml file grow slightly larger with the additional data (if added). The layman-2.0 api has made changes to reduce the bandwidth usage on the gentoo servers. I will create a more detailed blog post about those results later. But for those wanting to see the data that Alec Warner graciously compiled from the infrastructure logs. See bug 398465 [1]. The layman-2.0 api will reduce overall bandwidth far more than the additional irc data will add to it. [1] https://bugs.gentoo.org/show_bug.cgi?id=398465 -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On Mon, 2012-03-12 at 08:49 +, Robin H. Johnson wrote: > On Mon, Mar 12, 2012 at 08:52:20PM +1300, Kent Fredric wrote: > > On 11 March 2012 22:09, Brian Dolbec wrote: > > > > > > eg: > > > > > > Channel #gentoo-guis on the freenode network > > > or > > > #gentoo-guis on the freenode IRC network, > > > irc://irc.gentoo.org/gentoo-guis > > > > > > > Though a freeform text field is probably better for humans, I'd > > suggest having more explicit data available as an option, ie: > > > > Channel > > #gentoo-guis on the freenode network > +1 on this. > ... and just when I was beginning to think no one actually cared :) ... The proper form of an irc url is in my example "irc://irc.gentoo.org/gentoo-guis" and I took it from gentoo's irc channel page at http://www.gentoo.org/main/en/irc.xml . That would mean limiting a single field to just valid url's just like the field. irc://irc.gentoo.org/gentoo-guis The other thing I find with your example is that layman no longer uses that old style of xml. It still supports it, if you have that format for some overlay definitions. But does not fit the current repositories.xml format. Personally I would find it quite simple to use a reg expression to extract a valid irc url from a mixture of written text and url. #gentoo-guis on the freenode IRC network, irc://irc.gentoo.org/gentoo-guis So far there is not a gui for working with layman, so is all command line, including the output of layman -i some-overlay. Don't get me wrong, I have nothing aginst a layman gui. I actually ended up taking over layman's development because of it's lack of a good api for other apps to use. Namely porthole. Plus I fully intend to create a standalone gui for layman. Would it be better that I create 2 irc sub data types then? #gentoo-guis on the freenode IRC network irc://irc.gentoo.org/gentoo-guis So far it seems many/most systems do not come setup to recognize and take proper action for irc:// mime types like they do for http:// -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: location of portage tree
On Wed, 2012-03-28 at 08:25 +1300, Kent Fredric wrote:
> On 28 March 2012 08:05, William Hubbs wrote:
> > All,
> >
> > I know this has come up before, but I don't really recall what the
> > specific objections were.
> >
> > IMO the portage directory doesn't belong under /usr at all.
> > I was chatting with another developer who uses
> > /var/cache/portage/{tree,distfiles}, and I'm thinking about switching my
> > default setup to do this.
> >
> > I realize that historically the portage tree has been installed under
> > /usr, but Can we consider changing this default for new installations
> > and providing instructions for users for how to get the portage tree out
> > of /usr?
> > William
> >
>
> I think I'd rather something closer to paludis's notion, don't assume
> its "portage", assume its a repository instead.
>
>
> /var/cache/repositories/gentoo/*
> /var/cache/repositories/perl-experimental/*
> /var/cache/distfiles/*
> /var/cache/packages/*
>
> Or something along those lines. ( And definitely with the default
> locations for distfiles and pkg's outside the repository tree instead
> of inside it )
>
I am very much in favor of moving all overlays and the main tree into a
common repos, or repositories directory in /var somewhere, maybe even
just /var/repos/gentoo, /var/repos/sunrise,... I see no need to put them
under cache/, etc.. Although under /var/db/ would be the one I'd prefer
from the choices.
Layman currently uses /var/lib/layman/overlay-name. It would be best I
feel to place them in one common location. I also feel the main tree
should be stored as the same name as it's repo_name value.
If it is done in some fashion like that. The package managers could
also be modified to automatically scan the base directory for valid
repositories without the need to have them specifically configured in
make.conf. Not to say that they cannot be set in make.conf, but would be
required for anything outside of that base dir.
While we're discussing repos location and naming in general, I recently
came upon a layman overlay (via bug 408897) that is listed as haskell in
layman, but it's repo_name value is gentoo-haskell. This was for the
glep 42 news reporting feature I just added to layman-2.0. I had to
patch layman to get around this issue of the mismatched names by getting
the correct name from portage which is needed for the portage
news-reporting function that layman will do after an add/sync
operation.
Is this something we should specify for them to match?
My thinking is that they should, at the very least, for consistency.
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote: > But that's ok, because extensive studies have shown that the only possible > reasons for putting /usr/portage on its own partition are historical, > since everyone has an SSD now. > Yeah, right. Since I must be the only one out there that doesn't yet have an SSD, you'll give me (and anyone else that still doesn't) one? -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Wed, 2012-03-28 at 11:37 -0400, Rich Freeman wrote: > On Wed, Mar 28, 2012 at 10:59 AM, Richard Yao wrote: > > On 03/28/12 03:16, Brian Dolbec wrote: > >> On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote: > >>> But that's ok, because extensive studies have shown that the only possible > >>> reasons for putting /usr/portage on its own partition are historical, > >>> since everyone has an SSD now. > >> > >> Yeah, right. Since I must be the only one out there that doesn't yet > >> have an SSD, you'll give me (and anyone else that still doesn't) one? > > > > In response to the people who don't like what Brian had to say, I would > > like to say that we can't start making assumptions about what hardware > > people have and ignore anyone who does not fit those assumptions. > > Nobody doesn't like what Brian had to say. Most everybody around here > including Ciaran likely agrees with him. > > The issue is that Ciaran said the complete opposite of what he was > trying to communicate (sarcasm), and that likely due to > language/culture/etc that might not have been clear to somebody who > isn't a native English speaker in a western culture. > > The allusion was clearly to the larger udev/systemd/usr issues and the > point he was making is that many of these boil down to disagreements > about what use cases you consider important. > > So, just take everything Ciaran said in that particular post, assume > he meant the exact opposite, and now you'll see where he is coming > from. > > Yes, I do agree that sarcasm tends to cause problems on international > email lists, but his post did at least make me smile. :) > > Rich > I didn't miss that his statements were sarcasm. I just failed at sarcastic reply without it being clear that it was. Sorry, Not my best work :/ -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: location of portage tree
On Wed, 2012-03-28 at 14:43 -0400, Aaron W. Swenson wrote:
> So, we're all getting way off topic and discussing reorganizing the
> whole enchilada.
>
> How about we all agree or disagree on the primary point: The Portage
> tree doesn't belong in /usr.
>
> I believe that it does belong under /var/cache/.
>
> We can go a bit further and make it /var/cache/gentoo-repos/portage/.
a little too convoluted. It should be simpler... see example below
>
> That way Layman and friends can all make the move there quite simply
> without major infrastructure changes.
Layman, portage, pkgcore have all been able to have them elsewhere. It
won't break anything. It is only a config value change. Coding not
required. So it is easy to do that now. We are arguing about the
default location
>
> The Portage PMS on it's next release would just do a 'mkdir
> /var/cache/gentoo-repos/portage/ && sync && rm -rf /usr/portage &&
> echo "Portage has moved"' on its next 'emerge --sync' while still
> looking in both locations for packages.
>
It would be quite easy for simple use cases (the majority of users), to
create a migration script that users could use which would read the
current config values, then migrate them and update the config values.
But that would be entirely optional. If a user wants to keep it at the
current location it would not break anything. The only thing that would
be required is to set the correct variables in make.conf to override the
new defaults to maintain the current locations.
> (After looking at overlays, if /usr/portage exists, check there first,
> if not found look in /var/cache/gentoo-repos/).
>
> Other PMSs can then continue to use /usr/portage until they catch up.
> It also allows 'emerge --sync' on older versions of the Portage PMS or
> whatever the other PMSs use to continue working without breaking
> everything.
>
> We can continue forward with restructuring the tree in later stages,
> but we can't move the tree and break compatibility in one go. There
> must be stages to the restructuring. The first step is moving it to
> the proper top/sub level directory.
>
I fail to see the complexity that you seem to think is involved to
accomplish this.
> So, I'm proposing we use /var/cache/gentoo-repos/portage/ as the
> location of the official tree.
>
> - Aaron
to keep everything under one directory like some would prefer...
I propose we name that dir, "gentoo" simple, to the point.
then to sum up several other posts.
/var/{db,cache,}/gentoo/repositories/gentoo
/var/{db,cache,}/gentoo/repositories/local
/var/{db,cache,}/gentoo/repositories/{overlay of choice}
/var/{db,cache,}/gentoo/distfiles
/var/{db,cache,}/gentoo/packages
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal to move use.local.desc somewhere in /var
On Tue, 2012-04-24 at 16:45 +0200, Michał Górny wrote: > On Tue, 24 Apr 2012 10:37:31 -0400 > Mike Frysinger wrote: > > > On Tuesday 24 April 2012 10:11:44 Theo Chatzimichos wrote: > > > Since .cvsignore is needed either way, I'm going to do it in three > > > days if there are no objections. But I'd like some feedback for the > > > move of the file in /var. Opinions? > > > > considering the server generates it and the end user never does, i > > don't see the point. they get it via the normal `emerge --sync` > > process. -mike > > Maybe we should consider moving it to metadata/? > > On the other hand, moving it will require fixing all tools using it. > And as it is already deprecated, I don't see much good in still working > on it. > I agree, a sudden move (3 days) will cause nuisance breakage. If anything, lets firm up the schedule for it's removal, so that all tools can be updated to use cat/pkg/metadata.xml only for local flags. Otherwise there will be a lot of user noise generated over broken tools such as several gentoolkit utilities, porthole, kuroo, kportagetray,... -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Sat, 2012-05-05 at 21:20 -0500, Dale wrote:
> Ben wrote:
> > On 6 May 2012 08:29, Dale wrote:
> >> I mentioned this once a long time ago. We expect things to stay the
> >> same unless we do something to change them. If things change without us
> >> doing the change, we tend to freak out a bit. We don't need any
> >> freaking out.
> >
> > Sounds to me like it would be a good idea to make a new, more minimal
> > profile.
> > What do you guys think?
> >
> > Cheers,
> > Ben | yngwin
> >
> >
>
>
>
> Me, I don't mind the change but please let us know if the current one is
> changed. Why not put this in for the 2012 or 11 profile? Whatever
> number comes next. That way the users will know to look and have to
> change to the new profile.
>
> I usually do a emerge -uvaDN world before I change profiles, then
> change the profile and repeat with -a. That is when I expect to see USE
> flag changes and lots of other goodies that you devs do. :-)
>
> Someone mentioned a news item. That would work but maybe a new and
> fancy profile would work too. Someone may want to make others changes
> to while they are at it.
>
> Just a thought.
>
> Dale
>
> :-) :-)
>
1) Yes, create a new profile for this change.
2) Create a news item stating the change in default behavior for this
new profile.
3) mention the tools available to help with migrating this change. (see
below)
I created enalyze in gentoolkit for helping migrate changes like this
without breaking systems. It is also very useful for lost/broken
package.{use,keywords} files. Both the analyze and rebuild sub-modules
of enalyze can show you how use flags are used for installed packages on
your system. The analyze module shows which flags are default/not and
the pkgs using them. It can help you decide what you want set in
make.conf. The rebuild module can generate a new package.{use,
keywords} file for you after considering the defaults and make.conf. In
this case for making profile or make.conf use flag changes so that
everything already installed will remain the same on your system for
upgrades/re-installs.
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Portage Output / End User Experience
On Mon, 2012-07-09 at 10:56 -0400, Rich Freeman wrote: > On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge wrote: > > Rich Freeman wrote: > I don't have a copy of the message but when I got the update to > qt-webkit the message was fairly cryptic when it added the !icu? > dependency on libxml2. If anything I think it was less clear. > > Rich > There have already been users on the forums with that very confusion of what to do with the cryptic "[!icu?]". And there are currently many forum threads involving the icu use flag, qt-webkit,... -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > > How do you plan to handle the following: > > - foo installs an udev rule > > - install foo with old udev > > - upgrade udev > > > > are rules installed by foo used by new udev ? > > No, they wouldn't be; that is a good reason to question the value of the > eclass itself. Maybe the correct way to do this is to forget the eclass > and just file bugs against packages that break having them move their > rules to the new location and set a dependency on the newer udev. > > This would have to be a rev bump for the broken packages. > > William > > > > > A. > > So, does that mean the rule itself changes or just the location change is needed? If it is just a location change, a fairly simple udev-updater script would do it. If the pkg needs to be re-compiled to work with/depend on the new udev, then a more complex script would be needed. One more along the line of python-updater/perl-cleaner. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 2012-07-12 at 12:30 -0400, Alexis Ballier wrote: > On Wed, 11 Jul 2012 20:41:04 -0700 > Brian Dolbec wrote: > > > On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: > > > On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: > > > > How do you plan to handle the following: > > > > - foo installs an udev rule > > > > - install foo with old udev > > > > - upgrade udev > > > > > > > > are rules installed by foo used by new udev ? > > > > > > No, they wouldn't be; that is a good reason to question the value > > > of the eclass itself. Maybe the correct way to do this is to forget > > > the eclass and just file bugs against packages that break having > > > them move their rules to the new location and set a dependency on > > > the newer udev. > > > > > > This would have to be a rev bump for the broken packages. > > > > > > William > > > > > > > > > > > A. > > > > > > > > So, does that mean the rule itself changes or just the location change > > is needed? > > > > If it is just a location change, a fairly simple udev-updater script > > would do it. > [...] > > how do you handle the package manager database containing the location > of the file ? > > A. > Personally, since I'm not a bash programmer, I'd use python. And since this is the package managers db, I'd use the pkg manager to do it. Specifically I'd create an emaint module to do it in the fully modular/plug-in-able emaint rewrite I did (waiting for Zac's review, merge). It can make it's modules fully available for direct or managed import by other portage code, or other scripts. In fact in that branch I moved some clean-logs code from emerge into an emaint module, extended it a bit so you can change the time setting, run pretend runs (-c, --check)... and had the emerge FEATURE run it instead. So you could run it independently of emerge if you choose. There is an outdated vdbkeys emaint module that did changes and updates to several files in a pkg's vdb directory. Creating one to do this should be quite simple. That said, I don't profess to know what other possible ramifications there would be to changing a few entries in a pkg's CONTENTS file. I'll leave that up to Zac and the others. But I haven't heard any screaming of breakage that would occur for doing so. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Mon, 2012-07-23 at 20:28 -0400, Rick "Zero_Chaos" Farina wrote: > A lot of things, app-portage/ufed for example, don't support this yet... > ufed is on the endanged species list, along with a few other app-portage utilities. It hasn't been developed or maintained for some time now. If it is to survive, It'll need someone to step up and update it. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Mon, 2012-07-23 at 22:22 -0400, Jesus Rivero (Neurogeek) wrote: > > On Jul 23, 2012 9:43 PM, "Brian Dolbec" wrote: > > > > On Mon, 2012-07-23 at 20:28 -0400, Rick "Zero_Chaos" Farina wrote: > > > > > A lot of things, app-portage/ufed for example, don't support this > yet... > > > > > > > ufed is on the endanged species list, along with a few other > app-portage > > utilities. It hasn't been developed or maintained for some time > now. If > > it is to survive, It'll need someone to step up and update it. > > I don't see a bug for this change for ufed. > > I can take care of this change in ufed. > > > -- > > Brian Dolbec > > Thank you. Also I believe it does not support /etc/portage/package.use as well. Contact Fuzzyray about any change in ufed's status. He recently started a thread in the gentoo-portage-dev list to review the status of packages we maintain. Ufed being one without a maintainer/developer. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] stripping escape sequences from build logs
On Sat, 2012-09-01 at 17:39 -0500, William Hubbs wrote: > All, > > I find the included escape sequences to be annoying when I am reading a > build log. > > Is there a way to strip these? > > Thanks, > > William > Porthole's terminal strips most of them, processes some. It also does message filtering and highlighting for warnings, errors, and an emerge process summary. The filtered messages are also double click-able to bring you to the exact spot in the log. Making it easy to find the errors. The filtered messages can also be easily configured (well, if you can do python reg expressions ;). It can load build logs for viewing, "Actions" ==> "Open Emerge Log" menu items in portholes main window. It also has dynamic automatic line wrapping, so resizing the window reformats the viewed text. P.S. It did message filtering long before portage got the capability. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring.
On Thu, 2012-09-13 at 03:39 -0700, Brian Harring wrote:
> Hola.
>
> CC'ing pms since obviously they should comment, although the
> discussion should be on -dev (aka, public, not an alias).
>
> Sorry, this is a long email; condensing it down into a glep is viable,
> just my time is limited (it's telling I started the gentoo stuff at
> 2am, wrapping up likely at 4am).
>
> The length of this email basically relates to the subtlety of this
> proposal; at first glance it may appear as if I'm proposing a syntax
> shuffle just for aesthetic reasons, but as elaborated in the tail end,
> that subtle syntax change opens up a lot of possibilities.
>
>
> Either way, what I propose, is pretty simple. Currently USE_EXPAND'd
> groups are pushed into USE in the form ${use_group}_${setting}.
>
> Thus VIDEO_CARDS="intel nvidia" becomes video_cards_intel
> video_cards_nvidia. This should be reasonably well known and
> understood from the dev standpoint; from the PM side of things, this
> actually seriously sucks ass; if we see video_cards_intel in an IUSE
> somewhere, we don't know if it's a USE flag, or a use_expanded group;
> to figure that out, we basically have to do a longest prefix matching
> (or suffix tree).
>
> There in is one of the subtle design flaws of it; two USE_EXPAND'd
> targets, VIDEO_CARDS and VIDEO, can intersect in their namespace.
> While we (devs) intentionally avoid this potential via careful name
> choice, the fact the possibility exists is a bit of a sign that
> USE_EXPAND was a bit of a hack.
>
> What I propose is simple enough, and is for >=EAPI5:
>
> 1) We disallow '@' in USE flags (yes, a use flag can actually have
> '@' in it's name according to PMS; someone was hitting the crack
> pipe pretty damn hard when they allowed that one). This doesn't
> impact anything in gentoo-x86, nor any tree I've ever seen.
>
> 2) If (${use_group}_${setting}).
>
> 3) If >=EAPI5, we export ${use_group}_${setting}, *and*
> ${use_group}@${setting}. While there may be complaints about having
> it exported in two fashions, the reason for this is simple- it makaes
> transition way the fuck easier, meaning we don't make devs wrie pain
> in the ass "if eapi x, else blah" code. Basically, for eclass code,
> the dev would do thus:
> 3.a) If the eclass supports ${use_group}_${setting}.
> 3.b) If however that eclass is >=EAPI5, they should check for the new
> form; ${use_group}@{setting}.
>
> 4) At some point in the future, when either code involved has migrated
> all to EAPI5, or we do something in a later EAPI that renders
> supporting ${use_group}_${setting} untenuable, we stop exporting
> ${use_group}_${setting} for those EAPIs. Preferably with one EAPI
> cycle w/ deprecation warnings.
>
...
> ~harring
>
+1
This would make things easier for PM consumer apps to process use flags
without specialized code to figure out if the flag was use_expanded or
just had an "_" in it's name...
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sun, 2012-09-16 at 06:52 -0700, Brian Harring wrote: > Folks- > > Keeping it short and quick, a basic glep has been written for what I'm > proposing for DEPENDENCIES enhancement. > > The live version of the doc is available at > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html > > > Wording fixes will occur, but the core concept shouldn't change (and > if it does, per PEP standards, the changes will be noted/tracked). > > Please have a read through; it should be clear/concise as to why PM > authors are pushing for a unified dependencies to be done, what we can > get from it now, what it enables moving forward, and the direct cost > to devs should this idea be implemented. > > Just to be absolutely clear, what I'm proposing is basically zero cost > for devs- they can (and should when it's in their benefit) switch to > the new syntax when it makes their job easier; it can be used in > parallel to existing DEPEND/RDEPEND/PDEPEND both to ease > transition/compatibility. > > In addition, a prototype portage patch has been cut for dependencies > support (needs work/full validation), and a matching pkgcore one has > been cut. > > I realize it's a complex subject; if you have questions, please feel > to ask. > > Thanks, and pardon the ancillary/daft noise that has gone with this > subject. > > ~harring > I like the idea of a unified DEPENDENCIES. Potential flame wars aside, I also like the extended USE flag syntax approach. While it would be nice to loose the repetitive "dep:" portion, I can understand the importance of maintaining a namespace ID to prevent it from being injected where it does not belong. It adds to the consistency of the USE flag syntax while condensing the results. Reducing the size will help speed things along as well as reduce resource overhead (rsyncing the tree). I think it will be a good step forward in the evolution of gentoo. I would also put forth effort to help with tools to help devs migrate and check correctness before committing. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote: > Hello, > > The current dependency syntax: > > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION] > > suffers a few problems: > > > 1. It is not really human-friendly. > > People don't say things like: > > I need newer than monkey-1.2. > > They say instead: > > I need monkey, newer than version 1.2. > [snip :/ ] > 4. It follows the syntax used by bash (for conditionals), pkg-config > -- it is more natural in the environment. > The BIG problem with that is bash has nothing to do with evaluating dependencies. All bash does is source the *DEPEND and pass the value to the package manager which does all the processing. And all 3 current package managers are set up to parse those dep strings with a set syntax and whitespace. None of the PM's dependency resolvers are written in bash, two are python based, one C++. This proposal would throw a big monkey wrench into parsing those strings. Introducing lots of bugs, both in the PM and the ebuilds. And this after all the fuss about the unified DEPENDENCIES proposal, which is a small syntax change for the current processing code, easily incorporated into the PM's. AND has definite, measurable advantages. so, -1 -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
oops, didn't reply to the list. re-sending On Sat, 2012-09-22 at 19:19 +0200, Michał Górny wrote: > On Sat, 22 Sep 2012 10:05:41 -0700 > So, I think you just don't like it and are inventing disadvantages > without even caring enough to consider them before writing. > Oh, I considered it for the past 4 hours before responding. Got nothing in favour of it. The current atom format and syntax in CONSISTENT throughout the configs, and PM code. This proposal would split that in two, configs, ebuilds one format, everything else the old. quote " Mine is easily incorporated into the PM; it is just a change in a single place splitting and parsing the tokens. " That is unless you also change all the code to the new format and a new data type. I have written *DEPEND processing code (porthole's grahical Dependencies view) and worked on code in portage, pkgcore, gentoolkit, gpytage,... all working with the current atom syntax. This proposed change would require all those tools and more to be refactored too! So, to throw your words back at you: This proposal was submitted ... "without even caring enough to consider them before writing." enough said. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] reworking python-wrapper and wrapper scripts.
if the invoking script is not needed to be 2to3 translated (super minimal python code) but the remaining python libs need to be? > While it's minor in space savings, it's possible to eliminate that > redundancy via a shebang target that looks at the pathway it was > invoked via. Fairly easy actually, and basically zero overhead if > done. > > Either way, thoughts? > > What I'm proposing isn't perfect, but I'm of the view it's a step up > from what's in place now- and via centralizing this crap, makes it > easier to change/maintain this going forward as necessary. > ~harring > +1 from me. Eclean has been checking the name it was invoked with long before I did the major re-write. From that it cleans either distfiles or packages if invoked by either the eclean-dist or eclean-pkg symlinks. If invoked by eclean itself then it looks for the target in the arguments. So Brian's proposal is not something totally new, never been done before... While this proposes something a little different. It is still very much along the same line and in my opinion a much better solution. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
[gentoo-dev] app-portage/mirrorselect-9999 call for testers
I've just done a major update of mirrorselect. While the actual functioning code did not change significantly it has been chunked up, moved short list of changes: -- fix the make.conf move. now dual location capable -- now py3 compatible. (3.1 restricted, due to differences, failures) 2.6, 2.7, 3.2, 3.3 have been tested, are known to work. testing with pypy, jython and others welcomed -- now works with a POSIX locale as well as unicode locales -- all code has been moved from a mostly monolithic script into site-packages. A minimal script now just imports and calls the site-packages code -- split up the code into several files -- create a usable api -- create a MirrorSelect class which holds all primary functions and logic -- move the logic out of main() into individual step functions. main() now calls the steps in sequence. It is primarily for use by the cli script. While it is not an often used tool past an initial install. It is a very useful tool used by many new users. I would like to get some broader testing by more people to ensure the code is ready for a release. It has not been tested in prefix yet, I'm still getting mine up to date. Thank you -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS
On Sat, 2012-11-24 at 15:30 +0100, Theo Chatzimichos wrote:
> Hello,
>
> We currently have values like the following:
> RUBY_TARGETS="ruby19"
> PHP_TARGETS="php5-3"
> PYTHON_TARGETS="python2_7"
>
> I find it confusing, and I would like to propose to keep the same style for
> all
> the above values. I personally prefer the ruby one.
> Keep in mind that if the relevant teams decide to migrate to some other
> style,
> it needs an announcement and migration plan.
>
> Theo
+1 for the idea,
but:
I think format should be python2_7, a simple replace('_', '.') produces
the correct version string. If need be it can be extended to minor
versions
2_7_3 to get 2.7.3
For ruby19, split in the middle to get 1.9, but what about 110, is it
11.0 or 1.10.
For php5-3, what happens if a future package has a digit as part of it's
name which is allowed and are in the tree. It looks too much like php5
dash version 3
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS
On Sat, 2012-11-24 at 08:07 -0800, Diego Elio Pettenò wrote: > On 24/11/2012 07:46, Brian Dolbec wrote: > > For ruby19, split in the middle to get 1.9, but what about 110, is it > > 11.0 or 1.10. > > Okay stop. > > There's no 1.10. > > There's 2.0 that's being developed for a long time. > > And we're not going to change our scheme just because of some > theoretical corner case that has been proven not happening in our world. > > Especially since we were the first (and not even with ruby-ng, the > syntax has been the same for years, starting with ruby16). > Sorry, I didn't mean/intend to pick on ruby. I personally don't use it, nor do I have RUBY_TARGETS, or PHP_TARGETS set. I was just trying to point out a possible flaw in using that scheme as a common method of specifying versions in all those variables, or any future *_TARGETS type variable. ok, then please substitute "foo" for any ruby, python, php references in my previuos post... If we are going to come up with a common way of doing it, we will need to consider such a "corner case" so that we have as few exceptions to the rule as possible. Unlike the English language that I think too often has more exceptions to the rule than ones that actually follow the rule :/ It was not my intention to start yet ANOTHER -dev mail list flame war! My apologies to the list. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
[gentoo-dev] Gentoolkit-dev is now merged into >=gentoolkit-0.4.0 (Deprecation warning)
We are pleased to announce that the remaining useful gentoolkit-dev tools have now been merged into the main gentoolkit package. The tools moved are: ebump ekeyword imlate The remaining tools are no longer used for the gentoo repository and considered deprecated. With the release of gentoolkit-0.4.0 you will now be required to unmerge gentoolit-dev to install >=app-portage/gentoolkit-0.4.0. This will only affect ~arch or version users at this time that have both packages installed. Stable versions of both packages remain in the tree and can co-exist with each other. Once gentoolkit-0.4.0 has been stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning. Thank you -- Brian Dolbec
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
this arch at all. (In my opinion not necessary, since we > can always set all profiles of an arch to exp.) > > > 4] Meaning for other tools > All arches set to "stable" are considered "stable arches", meaning > * they get listed first in eshowkw > * they require stabilization requests in bugzilla > * ... > > > 5] Initial value in the Gentoo repository > On introduction, the setting will be "stable" for all stable arches, > "testing" for all arches where "inofficial" stable keywords exist > (sh, s390, ...), and "unstable" everywhere else. > > > 6] Rationale > At the moment we have several cases where repoman finds its limits: > > a) An arch loses its stable status (imagine s390), but the arch team > doesnt want to drop all the stable keywords since they are useful for > stage building. Since stable keywords on s390 are an > arch-team-internal thing, everyone can drop the latest stable version > of a package, and it's the arch team's responsibility to keep their > "unofficial stable tree" straight. Right now this means that we have > to set all *profiles* of this arch to "exp", otherwise repoman throws > errors about a broken stable deptree. If we do that, repoman does > however also not check ~s390 consistency, meaning that the ~s390 > deptree will soon be broken as well. With arches.conf, one could set > (arch: testing, profile: stable), which results in stable keywords > being ignored, but the ~s390 deptree still being enforced. > > b) An arch prepares for becoming a stable arch (think arm64). > So, first the ~arm64 deptree should be fine, and then stable keywords > can be added. However, to avoid repoman errors as long as the stable > deptree isnt complete yet the profiles need to be set to dev/exp, and > again this brings the danger of the ~arm64 deptree getting > inadvertently broken. Again the combination (arch: testing, profile: > stable) helps. > > Finally, at the moment the "semi-official" algorithm to figure out if > an *arch* is stable (i.e., requires stabilization requests etc bla > bla) is to check if the arch has any stable profile. This makes > non-stable arches which want to keep a consistent deptree (think > mips) impossible. Reading the arch status from arches.desc instead > solves this problem. > > > 7] Compatibility > > a) No arches.desc and new system, or arch not listed in arches.desc > Arches are treated as "stable" by repoman (current behaviour), with > profile status according to profiles.desc. So, business as usual. > Gentoolkit and other tools trying to determine a list of stable > arches should fall back to current method of scanning profiles.desc > for stable profiles. > > b) arches.desc and old system > Tools ignore the unknown file (?). > Repoman and other tools may emit surplus dependency errors when > profiles are checked on arches that are "testing" (they check the > consistency of the stable tree alone, which is not OK, since "arch" > is supposed to be treated like "~arch"). This affects only > development work and can be fixed by updating repoman. > > c) PMS may need to be amended to allow the additional file. > > > 8] Several repositories > > If arches.desc is present in several repositories, then the strictest > setting for an arch wins. [I don't really see many usecases for this > though.] > > > Congratulations for getting this far. What's your opinion? > -- Brian Dolbec pgp9tJJDrGBMM.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On Sun, 9 Apr 2017 23:36:18 +0200 Francesco Riosa wrote: > On 09/04/2017 18:15, William L. Thomson Jr. wrote: > > Not sure if this is practical, it may be less work if the use of > > Python and Ruby versions ( maybe others ) is reversed. Rather than > > adding all the versions that the ebuild supports. What if it only > > included versions it did not support? > > > > Rational > > When new versions are added. Ebuilds must be updated to support the > > new version. This can require editing a decent amount of ebuilds. > > Many may work fine with the new version. Making this extra needless > > work. From a user point of view, You cannot move to the newer > > version without keeping older around till all are updated to the > > newer version. > > > > Now one could say its the same work to mark versions not supported. > > But I think there is less of that. Also if something supports and > > older version and not newer, it may stand out more failing. > > Requiring someone to reduce to the older version, and maybe filing > > bugs to get it updated to the newer version. > > > > Python 2.7 stuff aside. I am not sure how many Python and Ruby > > packages break with a newer release. In pythons case I think once > > they support Python 3.x, there is little chance if it breaking with > > further 3.x releases. Not sure about Ruby. > > > > I could be very wrong and the present way of doing things being the > > only way. However if this is feasible it may lead to less work. It > > would allow all packages to move to a newer version. Also allowing > > punting of older sooner. This leaves the versions solely up to the > > eclasses. Then ebuilds simply mark the unsupported versions. Just > > like we do now with adding versions it does support. > > > > Which if something was say only Python 2.7. It would have a >= to > > excluded any newer version of Python. That said, we could do the > > same with the current way. Saying this supports Python/Ruby >=SLOT. > > > > Either way I do not think the current way is the best way. You have > > to add every version/slot to ebuilds that work fine with any > > version. When new ones are added, the ebuild has to be touched > > again. When it may work fine with a new version without requiring > > the ebuild to be modified. > > > > This came up with some stuff requiring ruby23 as I moved to 24. > > Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So > > I will stick to 3.4 till everything is at 3.6. Otherwise no point > > and still have other versions. > > > > The approach mentioned above, if the packages do not have issue. I > > could go ahead and switch to ruby24 and pyton 3.6 across the board. > > Which I cannot do now till a bunch of ebulids have their targets > > increased. > > > +1 to the python part, cannot speak about ruby. > or totally automate the addition of python versions to ebuilds at the > exact time of bumping dev-lang/python. > > This could be partially automated using buildbot. The easiest would be for pkgs containing working test suites. Those that pass could be auto-enabled with that python with ~arch keywords. I think if a stable pkg is to be added the new python, it should be via a revision bump and ~arch'ing the keywords. But we could enforce the bot to rev-bump all ebuilds just as easily. Pkgs without tests, those would be harder and we could do some basic tests on those, like syntax, test imports, but would require additional means of testing in order to qualify for an auto-python addition. It should also be possible for the bot to scrape setup.py for comppatible python versions. Many of the pkgs I have been working with recently have them listed. Also there is travis.yml files in many upstream pkg repos which can also be scraped for tested pythons. It could certainly reduce the manpower needed to keep things up to date. -- Brian Dolbec
Re: [gentoo-dev] [RFC] Should the compressed archive of an executable file be executable too?
On Sun, 18 Jun 2017 13:41:17 +0200 Jonas Stein wrote: > Dear all, > > if we compress an executable script > hello.sh > with bzip2 or gzip the result is a file > hello.sh.bz2 or hello.sh.gz > with executable permissions. However it is not executable, of course. > > ./hello.sh.bz2 > "cannot execute binary file: Exec format error" > > One can not blame bzip2 for it, because it is exactly what its man > page writes: > "Each compressed file has the same modification date, permissions, > and, when possible, ownership as the corresponding original, so that > these properties can be correctly restored at decompression time." > > On gentoo systems we can find many archives with with executable bit > by running > > $ find /usr/share/doc/ -executable -type f > > > * Is it proper to install compressed archives (.zip, .gz, .bz2) > with executable permissions? > > * Should we compress executable files at all? > (Example scripts are usually very small.) > > * Should we remove the executable permission of example scripts > anyway, because the user should not execute it directly, but > rather see it as example? The user reads it, copies and modifies > it and then sets the +x. > > > I am interested in your comments and wish you a nice Sunday. > yeah, makes sense to drop +x, it is better to look at the examples before running them blindly. -- Brian Dolbec
Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values
On Mon, 10 Jul 2017 15:41:04 +0200 Kristian Fiskerstrand wrote: > On 07/10/2017 03:35 PM, Kent Fredric wrote: > > On Mon, 10 Jul 2017 13:43:43 +0200 > > Pacho Ramos wrote: > > > >> Yes, but it's similar as the cases when we need to fix our packages > >> to work with a newer library they depend on. In this case it would > >> be even easier as we can have multiple python versions and switch > >> to the newer one for testing while going back to the stable one (if > >> preferred) later. > >> > > > > I'm starting to think we need a collection of QA scripts in a repo > > somewhere, optimized for symlinking into /etc/portage/hooks/install/ > > > > I might've read things too quickly, we're not talking a repoman check > here? > Yes, the warning would be a repoman check for version bumps, etc... What he is talking about, is OT, and I want to automate with a buildbot instance that can do automated testing for all python pkgs (to start with) that have tests enabled in the ebuild. I am also planning to help with automatic version bumps for those pkgs as well. If not committed straight to the tree, then emailed as a patch to the maintainers, perhaps in a pending repo/branch, bugzilla... TBD. Oh, and I want to connect as many arch specific workers to it as well. That should ease ebuild bumps, PYTHON_COMPAT and keywording maintainence. Once in place and operational, it should give the groundwork to add other pkg types, not just python based pkgs. -- Brian Dolbec pgpN7g2ENsI6V.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Reviving the Sandbox project
On Fri, 22 Sep 2017 15:06:49 + James McMechan wrote: > On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman > wrote: > >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich > > wrote: > >> > >> Some other distros try harder to isolate build environment either > >> through chroot and/or private mount/user/network namespace that > >> contains only explicitly specified files in build environment. > >> > >> That would require more cooperation from package manager to fetch > >> list of all visible depends. > >> > > > >I definitely think this is something that would be VERY useful to > >have, because it makes build-time dependency issues almost > >impossible. > > > >However, you don't need that complete solution just to have a > >sandbox. You could simply create a container with the entire > >contents of the main filesystem, but read-only, with the exception > >of the build area. That would replicate the functionality of the > >current sandbox and would be easier than building out just the files > >specified in the dependencies. > > > >The main issue I see with making it dependency aware is performance. > >You would need to walk all the dependencies and their run-time > >dependencies, and the system set, and then individually bind-mount > >the files that belong to them read-only into the container. That > >isn't necessarily difficult, but I imagine that it would be slow. > >Walking the dependencies obviously already happens during resolution > >so that could probably be cached. You could also cache the list of > >files for the system set, and you could even maintain a snapshot of > >these that is used as the base of the container (somebody would need > >to work out the savings of doing this vs the cost of updating it > >every time a system set package changes). > > > >However, the main thing I wanted to point out is that you don't need > >a dependency-aware solution to just replace the existing sandbox. > > > >> I like clear sandbox error reporting. > > > >As far as error reporting goes, you would get kernel-level errors > >like attempting to write to a read-only bind mount, or trying to > >read a file that doesn't exist. To a portage dev it should be > >pretty obvious what is going on. You could add canned text to the > >portage error output at the end. I'm not sure how visible the > >problems would be to portage except to the degree that the build > >system makes them visible > >- it would just see make terminate with a non-zero return. > > > >I would think that containers would be almost completely bug-free > >though. The only thing I could see as an issue is some build system > >that relies on IPC with the host, network access, etc. Namespaces > >themselves are very robust, and the kernel already looks at every > >process as belonging to a set of namespaces even in the default case > >where you only have one set of namespaces on the system, so they > >don't involve different code paths/etc. > > > >-- > >Rich > > Another possibility, could be to have the sandbox be an overlayfs > not of the build directory but of the entire system starting at "/" > and stick that into the container, only CLONE_NEWNS looks to be > needed. > > A container with all writes going to the upper layer of the overlay > could be safe against even #RM -RF / and other disasters, while still > tracking what is happening during the build. > > Should performance be too much of a problem having a bind mount of > the build directory on top of the overlay should give normal > performance to everything that is obeying good practice. > > After the build completes the directory that was mounted as upper > could be scanned to find any wayward writes that had occurred... > > This would not require LD_PRELOAD or ptrace eliminating most of the > "high magic" currently used. > > Just yesterday I had a lot of ptrace failures while trying something > odd with ROOT= and custom USE > > Jim McMechan I kinda like this idea, It looks to me to have pretty much all the benefits of a sandbox and nearly none of the drawbacks. Sounds like it should get more research into this idea, figure out it's limitations and if there are any caveats. -- Brian Dolbec
Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer
On Sat, 11 Nov 2017 12:31:15 -0500 Michael Orlitzky wrote: > Essentially,we have two commands to create a directory, "dodir" and > "do-empty-dir" (which we call "keepdir"). The latter is only necessary > due to an implementation detail, so it doesn't belong in the user > interface -- the PM should figure out what to do. > > As far as the actual implementation goes, I'm not sure that > automatically-generated ".keep" files are better than having the > package manager maintain its own database. The latter would be more > complex, but would avoid littering everyone's filesystems with > ".keep" files. > Well, for: 1) using .keepdir files makes this package manager non-specific, ie: using a different PM would mean it too sees that it is suppose to be kept. 2) Most ebuilds don't need/or use .keepdir, so I doubt there are that many littering up your filesystem. 3) There already is a database of the files installed by a package. But, how does it know which other packages might need to install to that directory. So, what does it do on unmerge of the package. Typically, the package manager will refuse to remove a non-empty directory after the files it is removing are removed. 4) Creating a single database for these will make the system more vulnerable to corruption and data loss. It would save on disk usage and number of inodes used. But there is a tradeoff between space and robustness. If one .keepdir is lost, it may only affect a few packages. If the database becomes corrupted. It could potentially mean the loss of much more of your installed pkg data. Spanning a great deal of the installed pkgs. In this case simplicity of .keepdir is in my opinion, much better than a single db. -- Brian Dolbec
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
On Wed, 13 Dec 2017 15:55:59 -0500 Lucas Ramage wrote: > I see, well I can setup buildbot to do that. Is there some place in > particular that I should send my test results? > > On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson > wrote: > > > On 2017-12-13 13:20, Lucas Ramage wrote: > > > > In my discussions with other developers, I've found that this > > > > is the > > > > > > > biggest concern. Most devs are runnning ~amd64, so they don't > > > feel that > > > > they can mark things stable. > > > > > > W > > > hat about running a stable chroot? Are there any tools that can > > > be used to automate this process? > > > > Yes, a stable chroot is okay, and there is app-portage/tatt that > > can run through the various USE flag combinations for you. > > > > It’s output isn’t terribly helpful, so it takes a little while to > > understand what it’s trying to tell you. > > > > > Lucas, ping me on irc/email me directly. I have been maintaining buildbot in gentoo for awhile and my day job is working on/developing buildbot scripts. I am planning out some pkg bumping scripts to help with regular pkg maintenance. I hope to have some initial code running during the holiday break. There should be a bunch of shared factory code possible as there will be some overlap in their needs. -- Brian Dolbec
Re: [gentoo-dev] Questions on overlays, repositories and PMS
On Fri, 23 Feb 2018 18:36:07 +0100 Michael Lienhardt wrote: > I started refactoring my solver to make it more modular, to fix some > details w.r.t. the PMS and to manage different repositories. I thus > have several questions on how multiple repositories work in portage. > > 1. My understanding was that /etc/portage/repos.conf replaced the > PORTDIR_OVERLAY variable, however this variable is still documented > (e.g. in > https://devmanual.gentoo.org/general-concepts/overlay/index.html). > Was my intuition right? Or in other word, it is enough to only look > at /etc/portage/repos.conf? In general, an overlay is a repository, > i.e., a valid tree layout for the PMS, right (as stated in > https://devmanual.gentoo.org/general-concepts/overlay/index.html)? > Yes, you should not have to look at the old make.conf variables, yes, they do work, but mostly for backward compatibility with some old third party tools. Those really need to be updated. I forget now how many there are, but if I remember correctly only 2 or 3 are left. And yes, we have been slow to get them updated or replaced. > 2. the PMS states that any valid repository has a profiles folder > which can contain profiles and a package.mask file. > - can the profiles in a repository different from DEFAULT be > selected? > - is the package.mask file apply only on the packages of that > repository, or on every packages of every repositories listed > in /etc/portage/repos.conf? > > 3. many repositories do not have an eclass folder, and miss many > (optional) configuration files in the profiles folder (like > arch.list, categories): > - is such information implicitly inherited from the DEFAULT > repository (even though > https://wiki.gentoo.org/wiki//etc/portage/repos.conf states that it > is not)? the brother overlay > (https://github.com/stefan-langenmaier/brother-overlay) does not > specify any masters > - when the eclass folder, profiles/arch.list and such are present, > is the data from the DEFAULT repository still implicitly inherited? > - when the eclass folder, profiles/arch.list and such are present, > are they visible globally (i.e., a package from another repository > can use a keyword of the arch.list and inherit from one of the > eclass)? > > 4. is the "masters" attribute in /etc/portage/repos.conf make the > repository inherit other data than the eclasses? > > 5. since every repos can have a profiles/categories file, is the > file /etc/portage/categories obsolete (or should it be)? > > > Best Regards, > Michael Lienhardt > > -- Brian Dolbec
Re: [gentoo-dev] Monthly x11@ project status for May 2018
On Mon, 7 May 2018 13:38:47 -0700 Matt Turner wrote: > > If there's a way to have repoman alert developers to deprecated > dependencies in the same way we handle deprecated eclasses, I'd like > to know about it. > > Currently there is not. Thinking out loud... It would mean parsing package.mask to generate the list filtering out those with "masked for removal", from other general mask reasons, but even that is not consistent. from another email in today's batch... (not to pick on this one, was just a lucky coincidence) eg: Subject: [gentoo-dev] Last rites: old, ruby23-only, slots of various ruby packages # Hans de Graaff (7 May 2018) # Old slots that are ruby23-only and no longer maintained # upstream, and that do not have packages depend on them. # Migrate to newer slot of the same package. Perhaps we would need to add a separate last-rites.mask list that the package manager merges internally as part of the .mask stack. That would make just one file to load without a need for filtering. A separate list might also be beneficial for the undertakers and any tooling for its automation. (I am not familiar with any of that tooling) I would then suggest the dependency depth check to default to one (or two) so as to not slow things down drastically. Perhaps a Q/A check report to scan the whole tree on a weekly basis. But that would also require PMS to be updated for the new file, which means a council vote... -- Brian Dolbec pgpDUQqsEMJ4M.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Openstack Summit MeetUp: dinner planning for Wednesday?
On Mon, 14 May 2018 22:49:26 + "Robin H. Johnson" wrote: > On Sun, May 13, 2018 at 01:11:30PM -0700, Jack Morgan wrote: > > Gentoo, > > > > I will be attending the Openstack Summit in Vancouver, BC. The > > conference is May 21-24th. I would like to organize a Gentoo meetup > > for those attending or living in the area. I personally will be > > there from May 20th - 26th. > > > > Please reply if you are interested in meeting and which > > day(s)/time(s) you are available. I'm looking forward to it! > I'm Vancouver-local, and will ALSO be attending the summit. > > Available for events during the daytime during the conference, and > also evenings of Monday & Wednesday. I am NOT available on the > evenings. > > As a note, Monday is a (provincial) public holiday in Vancouver, and > you may find a lot of restaurants closed (more than the ones that are > usually closed Mondays). > > Unless there are specific objections, let's try to plan the meetup for > Wednesday evening based on the above? > > I can help to arrange a dinner outing Wednesday evening. If you're > interested, privately email me. Please include a mention of specific > dietary requirements if any. > I am also local to Vancouver, but won't be at the event. Wednesday works better for me too. My daughter has ball games Tuesday and Thursday. -- Brian Dolbec pgphPm7lUDY8d.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation
On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner wrote: > Hello, > > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has > meant classic r100, r200, r300, and r600 drivers and gallium r600 and > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965 > drivers as well as gallium i915. > > I added more-specific VIDEO_CARDS for those separate drivers a few > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and > only get the one radeonsi driver they actually wanted while still > enabling support for x11-libs/libdrm's radeon support code which is > used by most of those radeon drivers. Of course some users want this > control and others don't care at all. > > The confusion comes in with "classic" DRI drivers vs Gallium drivers. > The Gallium abstraction layer allows a hardware driver to handle > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For > instance, users try to build the classic i965 driver (there is no > Gallium driver for this hardware) with USE=opencl or USE=vaapi and > don't understand why they didn't get what they wanted (or REQUIRED_USE > prevents them from doing so). > > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax, > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a > USE_EXPAND for Gallium-only options to attempt to avoid confusion? > Another point of confusion: not all Gallium drivers support all of > these features. For instance only the r600 and radeonsi drivers > support OpenCL. How to best handle this? > > It seems like at one extreme you build an extensive set of > REQUIRED_USE conditions that force users to micromanage their USE > flags, or you let them enable all sorts of impossible combinations and > deal with the confused bug reports. > > I would like to somehow get rid of the 'classic' and 'gallium' USE > flags entirely, but I'm not totally sure how. Maybe I can enable them > dependent on VIDEO_CARDS... > > Suggestions welcome. > What about creating a tiny pkg that has all the combinations in a dictionary and can set the USE and VIDEO_CARDS flags according to the video card(s) you have. This would be along the same lines as the app-portage/cpuid2cpuflags pkg. Then the pkg is updated as new drivers and combinations are changed. Perhaps have it run in pkg_postisnt to print any irregularities it finds and ewarn they need fixing. -- Brian Dolbec
Re: [gentoo-dev] Trustless Infrastructure
On Mon, 2 Jul 2018 11:01:58 -0500 R0b0t1 wrote: > On Mon, Jul 2, 2018 at 10:36 AM, Jason A. Donenfeld > wrote: > > Hey guys, > > > > While our infrastructure team has some nice technical competence, > > the recent disaster and ongoing embarrassing aftermath has made > > ever more urgent the need to have end-to-end signatures between > > developers and users. While the infrastructure team seems fairly > > impressive at deploying services and keeping the house running > > smoothly, I'd rather we don't place additional burden on them to do > > everything they're doing securely. Specifically, I'd like to ensure > > that 100% of Gentoo's infrastructure can be hacked, yet not > > backdoor a single witting user of the portage tree. Right now, as > > it stands, rsync distributes signatures to users that are derived > > from some infrastructure-controlled keys, not from the developers > > themselves. > > > > Proposal: > > - Sign every file in the portage tree so that it has a corresponding > > .asc. Repoman will need support for this. > > Signed hashes should be faster, no? Each directory with files could > have a manifest. > > > - Ensure the naming scheme of portage files is sufficiently strict, > > so that renaming or re-parenting signed files doesn't result in > > RCE. [*] > > - Distribute said .asc files with rsync per usual. > > Rsync would work with this setup, but there is also webrsync-gpg in > Portage right now. This covers the vast majority of usecases right > now. There is often no need to sync more than once per day. > > Speaking of, the keys for that have lapsed. Will they be updated? > > Cheers, > R0b0t1 > app-crypt/gentoo-keys has been updated yesterday. with renewed interest in gpg signatures, I will endeavor to keep it updated until is fully automated. -- Brian Dolbec
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, 3 Jul 2018 10:22:35 -0500 William Hubbs wrote: > All, > > Mostly because of the recent "trustless infrastructure" thread, I am > wondering why we are still distributing the portage tree primarily > via rsync instead of git? > > Can someone educate me on that, and is it worth considering moving > away from rsync distribution? > > Thanks, > > William > because: 1) it is still the most bandwidth economical means of distributing the tree 2) we have a large infrastructure of rsync mirrors, which we do not for git. 3) see #1 -- Brian Dolbec pgpjViOjx5GaR.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 24 Jan 2016 18:44:08 -0500 Göktürk Yüksek wrote: > Andrew Savchenko: > > On Sun, 24 Jan 2016 16:00:31 +0100 Patrice Clement wrote: > >> Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote : > >>> Remove the paragraph about adding binary files to CVS. Replace > >>> the instances of CVS with git. > >>> > >>> X-Gentoo-Bug-URL: > >>> https://bugs.gentoo.org/show_bug.cgi?id=558642 Signed-off-by: > >>> Gokturk Yuksek --- > >>> ebuild-maintenance/text.xml | 19 +++ 1 file > >>> changed, 3 insertions(+), 16 deletions(-) > >>> > >>> diff --git a/ebuild-maintenance/text.xml > >>> b/ebuild-maintenance/text.xml index ac68dcd..10709ea 100644 > >>> --- a/ebuild-maintenance/text.xml +++ > >>> b/ebuild-maintenance/text.xml @@ -42,22 +42,9 @@ above 20KB) > >>> which should be distributed as tarballs via the >>> link="::general-concepts/mirrors/#suitable-download-hosts">Gentoo > >>> > >>> > mirror system so that people do not waste excessive > >>> amounts of bandwidth and hard drive space. Also, you should > >>> not add binary (non-ASCII) files to the -Portage CVS tree. If > >>> you need to do this in another CVS tree, for -example, if you > >>> need to add a small PNG graphic for whatever reason, -be sure > >>> to add it to CVS by using the -kb option, like so: - > >>> - - -# cvs add > >>> -kb myphoto.png - - - -The -kb option tells > >>> CVS that myphoto.png is a binary -file and should > >>> be treated specially. For example, merging the -differences > >>> between two different versions of this file should not be > >>> -allowed to happen, for obvious reasons. Also, speaking of > >>> merging +git tree. Also, speaking of merging changes, any > >>> patches you add to Portage should generally not be > >>> -compressed. This will allow CVS to merge changes and > >>> correctly inform +compressed. This will allow git to merge > >>> changes and correctly inform developers of conflicts. > >>> > >>> @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff. > >>> Also note that the gentoo extension informs people > >>> that this patch was created by us, the Gentoo Linux > >>> developers, rather than having been grabbed from a mailing list > >>> or somewhere else. Again, you should not compress these > >>> -patches because CVS does not play well with binary files. > >>> +patches because git does not play well with binary files. > >>> > >>> > >>> -- 2.4.10 > >>> > >>> > >> > >> "Again you should not compress these patches because git does > >> not play well binary files". > >> > >> I'm not sure this statement still holds true with git. Does it? > > > > What about repoman checks? Will it still yell at >20 kB patches? > > > Yessir: > https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/checks/ebuilds/fetches.py?h=v2.2.27#n104 > > Even though it's not an issue with the git tree, rsync users will > still suffer for >20kB patches. > > > Best regards, Andrew Savchenko > > > > - -- > gokturk > > just for future reference, here it is again in the repoman rewtire code waiting to be merged and likely be in the next release: https://gitweb.gentoo.org/proj/portage.git/tree/pym/repoman/modules/scan/fetch/fetches.py?h=repoman#n109 - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWpXF6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YV6IP/34NmzdtaMg4W471cXYn8pR0 8JdcHkC2YehpNNzSjDbWmI9pEArBS/3yWC8lfXMeu21GU66OUb6eKR5KMURg5OP9 FT4DJCHO9RWK31QEOD03PLZXhoaw6JgYQpvjbnWP1CN8mdWg7CeA0r0y4BPe63Kp FGpFZXjduszpT1ALIt86tN85pB9jmYdwDgj9vLWG6SyThFuA6aDeEHSaAB05blDU p6NVksGfSG6bbS+Kok1uRdF5vVqBQU+aSxNbZW9mpRtYDtdr5DoInbq/uXz/Dy1S Kp7iDg8+SW3nwA60vqss5SZmZDW3cnEH1XWIdEgDjH4NBvlaVnA9yxIa12MJ6qSy FZ+5F5HVAdRs8eLK0OsK/RbFm4gCEFxmhm6YJ2qXpIXuD/MM4GJXJa+O7qrURzqI td5rJNTHGbIBmwDjJwotwyuT+FgWajicbrnQpxgiLoNYcvvB7mihwT+DFKx4WxWm rw2O21fFaUD/OQp255y0OLyVfVC6SRk3UXXlDd9Pl+UYLLIyC6ibVI4dxDxp4hd2 DGUTQ2FFm3m4h5RTxeCJNJgTMlKSbCyDut6vM8mMyIzMxcD5nfWFv53KNIbOPfGH vmUbc5scrhKLiawzos2w+ChzGkzGParzCF7rZ1S2nOlJFt87qgVVs7JNVUJ0D1QX XlmqJV+fmRhaDLRXNVQA =gmwE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf
On Sun, 24 Jan 2016 16:46:41 +0800 konsolebox wrote: > On Sat, Jan 23, 2016 at 4:27 AM, Brian Dolbec > wrote: > > On Sat, 23 Jan 2016 03:45:14 +0800 > > konsolebox wrote: > > > >> On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec > >> wrote: > >> > On Sat, 23 Jan 2016 01:05:12 +0800 > >> > konsolebox wrote: > >> > > >> >> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> > >> >> wrote: > >> >> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as > >> >> > excerpted: > >> >> >> Hi, I can't find a way to make `emerge --sync` add an option > >> >> >> like `-f` to `git pull` when it runs it. How about adding > >> >> >> sync-git-extra-opts or sync-git-pull-extra-opts to > >> >> >> repos.conf? We already have sync-rsync-extra-opts for rsync > >> >> >> so I think it's fair to add one for git. > >> >> > > >> >> > If you have layman installed, you can set repo sync-type to > >> >> > laymansync, and layman, in turn, has configuration options > >> >> > that allow you to set additional options for git as well as > >> >> > the other repo-type fetch commands (bzr, svn, etc). > >> >> > > >> >> > >> >> Unfortunately I need it for the `gentoo` repo itself. I do have > >> >> layman repos but I update them separately with `layman -S`, and > >> >> I don't want them to always get updated together with `gentoo` > >> >> everytime I run `emerge --sync`. > >> >> > >> > > >> > No, the portage sync system controls which repo(s) get synced via > >> > the auto-sync setting. So layman can git sync the gentoo repo > >> > like Duncan described without also syncing your manually synced > >> > layman repos. > >> > >> Ok I think I follow a bit, but wouldn't it be better to have that > >> feature without relying on layman? > >> > > > > Yes, it would be better. But there are only do many hours we each > > can spend on Gentoo. I have the repoman rewrite as my primary > > portage work in progress at the moment. And this feature is not > > something I am in need of... > > > > For those who may wish to add this and/or other features to the > > sync, The repos.conf repo definitions are now capable of extra > > options per sync type (They don't have to be common to all sync > > modules). So it is possible to add this to the git sync module and > > have specific repo settings. We are around and eager to help > > anyone wishing to contribute patches :) > > I made a pull request for it in github. Please check. Thanks. > > https://github.com/gentoo/portage/pull/23 > Thank you, the patch looks good. I'll post the patch to our development list for review before merge. It'll likely be included in the next release soon. -- Brian Dolbec
Re: [gentoo-dev] New schema language for metadata validation?
On Wed, 27 Jan 2016 14:39:02 +0100 Dirkjan Ochtman wrote: > On Wed, Jan 27, 2016 at 1:09 PM, Michał Górny > wrote: > > Could you post a generated .rng and XML Schema files for comparison? > > They don't have to be perfect conversions, just to see how different > > they are. > > Here's the RNG, generated with dev-python/rnc2rng: > > https://raw.githubusercontent.com/djc/gentoo-data-dtd/metadata-rnc/metadata.rng > > The best way to convert from RELAX NG to XML Schema seems to be with > trang; I downloaded an older binary and a JDK on my laptop, but > couldn't easily get it to run. I don't really have a Gentoo machine on > which I want to install the whole Java shebang, so maybe someone else > can run a quick conversion? > > Cheers, > > Dirkjan > that looks very easy to read and modify. -- Brian Dolbec
Re: [gentoo-dev] [PATCH v3 05/21] ebuild-writing/misc-files: replace the code for cvs commit with git #558642
On Wed, 3 Feb 2016 19:57:33 -0500 gokt...@binghamton.edu wrote: > From: Gokturk Yuksek > > Replace "cvs commit" with the equivalent "git add && git commit" > version. > > Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=558642 > Signed-off-by: Gokturk Yuksek > --- > ebuild-writing/misc-files/metadata/text.xml | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/ebuild-writing/misc-files/metadata/text.xml > b/ebuild-writing/misc-files/metadata/text.xml index e506b1c..2de3cf5 > 100644 --- a/ebuild-writing/misc-files/metadata/text.xml > +++ b/ebuild-writing/misc-files/metadata/text.xml > @@ -532,7 +532,21 @@ is currently: > > xmllint --noout --valid metadata.xml > glep31check metadata.xml > -cvs commit -m "Adding category metadata.xml for my-category" > metadata.xml +git add metadata.xml > +git commit --gpg-sign > This should be repoman commit still, not git commit + > + > + > +The commit message should be formatted properly. > +A sample commit is shown below: > + > + > + > +commit db359439bcd52f5a7f20d2332ab62feb16657504 > +Author: Alexis Ballier <aball...@gentoo.org> > +Date: Tue Sep 22 10:47:49 2015 +0200 > + > + dev-ros: Add metadata.xml for the category. > > > -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer wrote: > Ohey, > > I've opened a bug at: > https://bugs.gentoo.org/show_bug.cgi?id=573922 > > The idea here is to change the order of the providers of virtual/udev. > For existing installs this has zero impact. > For stage3 this would mean that eudev is pulled in instead of udev. > > The rationale behind this is: > > * eudev is an in-house fork, and there's more than a dozen distros > already using it by default that are not us. Which is a little bit > weird ... > > * Both udev and eudev have pretty much feature parity, so there won't > be any user-visible changes > > * udev upstream strongly discourages standalone udev (without systemd) > since at least 2012 > > (see for example: > https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html > https://lkml.org/lkml/2012/10/3/618 > ) > > So it'd be (1) following upstreams recommendations and (2) dogfooding > our own tools. I don't see any downsides to this :) > +1 I switched to eudev a few years ago and glad I did. The non-systemd profiles should have eudev as default. -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 8 Feb 2016 12:01:33 -0500 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/02/16 11:18 AM, Rich Freeman wrote: > > However, I think we're actually missing the bigger issue here. > > Why is this virtual even in @system to begin with? When I set up > > a chroot or some kinds of containers I don't need udev, or > > sysvinit (or openssh - but let's set that one aside for now). > > > > We don't stick grub or genkernel or even gentoo-sources in our > > stage3s. Why stick (e)udev in there? > > > > It seems like this should just be another step in the handbook - > > pick your desired device manager. > > > > Obviously if we produce a boot CD it will need a device manager > > (and kernel and bootloader and network manager), and I don't care > > which one it is. > > > > This just seems more like the Gentoo way, and it completely > > sidesteps all the controversy over defaults. We're already > > working on fixing the few remaining functions.sh references so > > that openrc can be removed from the system set as well. > > > > I thought the point of this discussion had to do mostly with what > udev variant gets installed when a user doesn't specify one. And > AFAIK, since there are still plenty of packages that *DEPEND on > virtual/udev , the discussion's still worth having isn't it? > > Besides, if we just move the goal of this discussion from "order of > atoms in virtual/udev" to "order of items in this new Handbook > page", we still need to decide what the default is don't we? Yes, we do. Also, it is releng's intention to change to a stage4 for normal new install stages. It will contain the most needed pkgs for new installs, and allow the @system set to be trimmed down more. It is entirely possible, to at that point, then create smaller chroot/container images without undue hardships and complexities for new installs. But please let's not sidetrack this thread more with this tangent. That's a different bikeshed to paint. - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWuNEMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YTVQQAJhStpgaDT2pqMsVuTO3HZx6 XfaZoNtcN01nqOttBwQ4C+17n8Rv2/d52Zu6lc3YSrdPgHRGOVT0LU8CyzZlz8Rw rnFeo5oZAZheqlA/4UzRMOkhXbOvT4FRDL1bF/q5t00h+pADoPDSC3ZIyS8enkvr Evm3DYpDDT40pM5f7cwlAqRarJL604XDgFmU5Qhtmtnxw+TRIicGTwHoWe4fk77u PNm3ZrU+ea7b2XAwKH+oDVM0UDMfFLi37APGd4R2VC0jJmp0msPnNfKRvpURcNo5 3iZMMDuM7vqJergB2yCfiqaGdHmaEPX1PLpQEuhgLWS0b6lCN4JKenYpRdNVLjZG FqOEtSVUs9iNt++XmsZ6goLQAczePOxqR/aAJOMrXuhePiuXMRmm1MBQK2yRRo6q 6MU/lj+1YAzEWMyOZH9GNzQhCl1cBj+futm6mRTWYsNCaKOGi/ocnIHiQpXyKf/U dp/hlvx2rhqMz6eqO60OaJHaKzbCV6EbGb3kv0AsC4VGGFS+DpoUen21aetBh82O aE6c/hKNvsgARQl0mpwFDttSnB24oRr8E9pR5Rvf7iQJwL7h/5gHvs2YQRL9PxFR vSN1R67Sge9JrAzQ/OmEBbl5exO2a1/0HShfdfvU6oA/lDShFHyttJXYxGi0tDym A2Bo/b9FonL7aEmwilCH =PiEj -END PGP SIGNATURE-
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 9 Feb 2016 08:44:03 -0500 Rich Freeman wrote: > I'll admit this has been a bit of an emotional thread for me. I think > my frustration comes from the fact that it seems like the whole reason > that eudev exists is because people really strongly believe that > systemd isn't the right way to go, and yet those same people don't > seem to realize that others might feel just as strongly that eudev > isn't the right way to go. > I started the replies with a simple +1, and that I had switched to eudev... No, "Down with the evil systemd.borg" comments As one of the few huge threads that I have been reading. It is you that has been taking this thread more in the direction of something akin to a preacher shouting we're all going to burn in hell for even considering switching the default. While you were obviously more emotional, Anthony was very calmly, and clearly refuting many of your statements. > Surely anybody suggesting switching to eudev as the default > virtual/udev provider had to have realized that this would create a > huge controversy. > BUT WHY DOES it have to be! Why can't we as a group simply respond to something like this with a simple +1, -1 and a few pros/cons Why must it become yet another shouting match. And I'm sorry to have to tell you this, but you have been leading the charge in that direction. > Even if standalone udev is a dead-end (something that is speculation > at this point), it isn't like the code that exists today will suddenly > stop working. Worst case we just have to change the default at a > later point in time. > > Even just kicking the can down the road has a lot of advantages: > 1. Everything works fine today. yes > 2. We don't know for sure that it will ever stop working. no, we don't > 3. Deferring a decision means we don't have to wage a huge battle > over which way the decision ought to go. As I pointed out above, you seem to be leading the battle charge. Why couldn't you have simply replied "-1 I use systemd like most other distros" and "It works for me as is" and leave it at that. > 4. If we do have to make a decision in the future, we'll have more > information to act on. > put off till tomorrow what you can avoid doing today... tsk, tsk, tsk IT IS A SIMPLE POLL of the possibility of switching the default VIRTUAL we were suppose to be talking about/voting on Sorry everyone for a little shouting of my own. -- Brian Dolbec
Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!
On Tue, 9 Feb 2016 14:53:52 -0500 Ian Stakenvicius wrote: > On 09/02/16 02:51 PM, Michał Górny wrote: > > Hello, everyone. > > > > After all those boring, meaningless and violent mailing list > > threads, here's something nice and simple. I'd like to find a new > > nice name for the C wrapper part of python-exec2, and I would like > > to ask you for ideas. > > > > For some explanation, python-exec2 consists of two wrappers. One of > > them is the 'core' C wrapper that does most of the work. The other > > is a Python script with special shebang that is used to keep > > 'python /usr/bin/foo' working while deferring direct executions to > > the C wrapper. > > > > The Python wrapper is installed as /usr/lib/python-exec/python-exec2 > > and this can't change since everything is symlinked to it. The C > > wrapper is named python-exec2-c (which is an ugly name), and since > > it's used only internally, I can safely change its name to > > something nicer. > > > > Any ideas? If possible, I'd like to avoid ambiguity between the two > > wrappers, so the C counterpart would have to be highlighted somehow. > > > > python-exec-cwrapper ? > NO, No, you mistyped it... python-exec-crapper :O -- Brian Dolbec P.S. just finning with you :)
Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!
On Tue, 9 Feb 2016 12:32:38 -0800 Brian Dolbec wrote: > On Tue, 9 Feb 2016 14:53:52 -0500 > Ian Stakenvicius wrote: > > > On 09/02/16 02:51 PM, Michał Górny wrote: > > > Hello, everyone. > > > > > > After all those boring, meaningless and violent mailing list > > > threads, here's something nice and simple. I'd like to find a new > > > nice name for the C wrapper part of python-exec2, and I would like > > > to ask you for ideas. > > > > > > For some explanation, python-exec2 consists of two wrappers. One > > > of them is the 'core' C wrapper that does most of the work. The > > > other is a Python script with special shebang that is used to keep > > > 'python /usr/bin/foo' working while deferring direct executions to > > > the C wrapper. > > > > > > The Python wrapper is installed > > > as /usr/lib/python-exec/python-exec2 and this can't change since > > > everything is symlinked to it. The C wrapper is named > > > python-exec2-c (which is an ugly name), and since it's used only > > > internally, I can safely change its name to something nicer. > > > > > > Any ideas? If possible, I'd like to avoid ambiguity between the > > > two wrappers, so the C counterpart would have to be highlighted > > > somehow. > > > > python-exec-cwrapper ? > > > > NO, No, you mistyped it... > > python-exec-crapper > > :O > > Sorry Michał, but Ian inadvertently set that one up to nicely to avoid a little humour injection. But for a real answer perhaps: python-cexec it's much simpler, less likely to get bastardized like I did above. -- Brian Dolbec
Re: [gentoo-dev] Re: Changing order of default virtual/udev provider
On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs wrote: > > Often the decision to procrastinate is a decision that is rewarded. > > That should be considered carefully. > > + 1. > > I also saw another issue that made me shudder. If we change the > default to eudev, people who are running separate /usr are going to > think they can kill their initramfs's, because people in gentoo > conflated the separate /usr and initramfs issue with udev [1]. > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4 That isn't a worthwhile reason to procrastinate. IMO we're going to get those _ANYWAY_ no matter how long we wait, within reason of course. There will always be users that can't read/type/whatever and fail and file bugs. So if we have to wait for one (or more) users to forget about the initramfs crud & confusion, we'll be waiting 20 years. By then even systemd will have been replaced by something else... -- Brian Dolbec pgpBW0P78uAcI.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote: > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer > wrote: > > If, for any reason, eudev should be abandoned - we can just change > > the virtual back. One-line change. > > Which is precisely the corresponding argument for not switching the > default to eudev in the first place. > OH, my, this is looking more like you are being paid by systemd peeps... THIS IS OPEN SOURCE, there is not a single project out there that might not become abandoned at some point in the future. Even Microsoft may eventually abandon their crappy windows, Apple abandon it's current platform, (wait they did that once or twice already)... You are just refusing to acknowledge these simple facts. systemd.: irrelevant to this decision standalone systemd-udev.: Vehemently unsupported, support for its capability to exist is planned to be punted in the future. eudev...: fully functional, actively developed, and fully supported, mature project, been around for years. Oh and here is one final piece that should blow your reason away https://github.com/gentoo/eudev <== NOTICE that it's upstream is within our gentoo domain. That means if Anthony (god forbid) were to be hit by that proverbial bus. The project can be easily assigned new developers. Not to mention the fact that with 14 downstream distributions using it as their udev implementation. That I am sure some downstream developers would step up and continue its development too. Need I go on to list examples of other current projects that have continued when their main developer had gone for one reason or another. HINT: they are current Gentoo defaults too. So PLEASE show us you are capable of seeing and acknoledging the above simple facts and give up these BS arguments. This whole BS over a simple decision is giving me flashbacks of jury duty I did. But at least then, it was over something serious. It was a murder trial. This is about a simple virtual and the default order of its providers!!! -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 19:53:48 +0100 Chí-Thanh Christopher Nguyễn wrote: > William Hubbs schrieb: > > Maybe FUD is the incorrect way to put it, but I think us doing > > something about it at this point is definitely premature since > > KDBUS is no where near ready to go -- they were forced to retract > > it a while back because they had to re-think the design. > > kdbus got sent for inclusion in the kernel, and they were sure ready > to pull off their plan back then if kdbus had been accepted. > > Whether switching to eudev now is premature is actually the central > issue of this whole discussion. Given that dropping support for udev > on non-systemd systems was narrowly avoided once, and upstream leaves > no doubt that they are ready to do so once their redesigned kernel > message bus goes upstream, I say describing such a move as > "definitely premature" is not warranted. > > > Best regards, > Chí-Thanh Christopher Nguyễn Thank you for bringing this information to the forefront of this debate. So, is it not better for us Gentoo-er's that wish to not install systemd, to set the default non-systemd udev to eudev. In that way, maybe eudev will get more contributed support and Anthony more eyes on things. It seems that unless kdbus is perpetually rejected by the kernel team... it is only a matter of time. So, I say, we've all had enough bickering about the subject. Time for a final vote! If we had all spent our time working on real problems as we've spent reading this never ending debate mail... but alas, this will be yet another item that must be decided by the council. -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 15:26:46 -0500 "Anthony G. Basile" wrote: > On 2/16/16 3:05 PM, Rich Freeman wrote: > > On Tue, Feb 16, 2016 at 2:57 PM, Patrick Lauer > > wrote: > >> The whole discussion, which seems to turn everyone into a raging > >> squirrel, is about changing the default provider of a virtual. All > >> other providers will continue being listed and available. The > >> change affects none of the current userbase (who seem to have a > >> preference for eudev if forums polls have any meaning). > > > > Why is it that anytime there is a great debate over something > > somebody says something like the following: > > https://www.youtube.com/watch?v=6rI8mDpnv7c > > > > > This decision is completely trivial and won't really change > > anything. That is why it is so critical that we make this decision > > right now! > > > > Either it matters or it doesn't... > > > > And I had resisted several times now of pasting in youtube links... :) time for some humor injection... OK, in this first link, the eudev people think the systemd people are the one migrating and the systemd people think the reverse... https://www.youtube.com/watch?v=AOOs8MaR1YM And from some people's comments in this thread... https://www.youtube.com/watch?v=dndAXxqJbc0 -- Brian Dolbec
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Tue, 16 Feb 2016 23:16:41 +0100 Michał Górny wrote: > On Tue, 16 Feb 2016 20:57:31 +0100 > Patrick Lauer wrote: > > > On 02/16/2016 08:33 PM, Michał Górny wrote: > > > This all is going into some bickering nonsense and noise made by > > > systemd haters just to feed their troll, FUD and whatever else > > > they made around here. > > You call it hate, I call it having a choice. > > You have a choice. This is trying to force your choice on everyone > else just because you hate the other option and don't want anybody to > be using it. > NOT EVERYONE, just make it the non-systemd default, htere is still choice to change to to whatever... > > > Because certainly > > > project that is created plainly for political reasons is better. > > > Because it will certainly be technically better if people have to > > > focus on copying regular udev maintainers and reworking their > > > changes to keep them working on forked codebase. > > > > > > And after all, as someone said, this will give eudev proper > > > testing. > > (1) It's already used by lots of people > > (2) 'proper' testing? As opposed to be the default in more than a > > dozen distros that have usecases you and I rarely think of? > > Are you really serious with those fringe distros? How many of them > have a dozen users that do not happen to be developers of the distro? > How many of them are actually used in production? How many of them > have diverse enough userbase to prove that eudev works in different > environments? Now you are starting to spout incomplete truths from being riled up, not thinking things through. Since you consider them to be just a dozen or so... In the 8 months where I am working now, they use eudev for all their installs. This includes more than 50 different server profiles and resulting images. Those are multiplied out into multiple instances in each rack and server clusters distributed in many places around the world. So a real world example puts it over a 1000 units (guesstimate) in daily production. Plus several hundred more on the development and testing clusters. Plus several hundred (minimum) workstation and developer vms. In that 8 months in the release engineering team, I've not seen one email or bug report that has been due to a problem with eudev. If there were I did not see it pass thru the group communications channels. So, there are lots more eudev users out there than the few dozen you seem to intimate to. Can we please put an end to this thread! ONE WAY OR THE OTHER!!! -- Brian Dolbec pgpFDfuOoylwW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?
On Wed, 24 Feb 2016 21:16:13 +0100 Luis Ressel wrote: > On Wed, 24 Feb 2016 11:18:55 -0800 > Raymond Jennings wrote: > > > As far as changelog generation, what about causing the changelogs to > > be autogenerated by the end user's computer? Divide and conquer. > > That would require a local git clone. And that's exactly what those > who still want Changelogs are trying to avoid. > Not only that, but their generation along with thick manifests are already quite resource intensive and time consuming for a relatively high powered server (a big reason behind this thread). Now make some older users system or low powered arm system do that with much lower resources and you are talking about a long time for completion. -- Brian Dolbec pgpF8oAtbYAJh.pgp Description: OpenPGP digital signature
[gentoo-dev] Gentoo tree package moves updates.
As discussed a few years ago. We agreed to trim the package moves updates to maintain 4 years history active in the tree. It currently still goes back to include 2010. There was a recent edit to a 2010 file that triggered a full re-processing of those files. Last night for me it was triggered again. I don't know the cause, but I really don't care enough to investigate. But it prompted bug 576752. That said, being 2016, I am going to trim 2010 and 2011 files from the active tree in 48 hours unless anyone shows a valid and justifiable reason to keep them. Unlike last time which I made the trimmed update files available for download. With the tree now being git based. They will be easily available in the git history. Thank you -- Brian Dolbec
Re: [gentoo-dev] Gentoo tree package moves updates.
On Tue, 8 Mar 2016 22:40:34 +0100 Ulrich Mueller wrote: > >>>>> On Tue, 8 Mar 2016, Brian Dolbec wrote: > > > As discussed a few years ago. We agreed to trim the package moves > > updates to maintain 4 years history active in the tree. It currently > > still goes back to include 2010. There was a recent edit to a 2010 > > file that triggered a full re-processing of those files. > > That's not correct. I had noticed reprocessing of all files already > around March 1st, definitely before the edit of the 1Q-2010 file. There has been at least one time recently that a change in the rsync tree generation scripts caused an massive download of files and re-processing of the updates. I believe that was the incident you were referring to. I saw chat (#gentoo-dev) a few days ago from dwfreed. He was testing out more changes to those scripts. So, it is possible that a script update once again caused the re-processing. I'm inquiring if that was indeed the reason. > > > Last night for me it was triggered again. I don't know the cause, > > but I really don't care enough to investigate. But it prompted bug > > 576752. > > > That said, being 2016, I am going to trim 2010 and 2011 files from > > the active tree in 48 hours unless anyone shows a valid and > > justifiable reason to keep them. > > That would (maybe) cure the symptoms, but don't you think that the > real bug should be found? I suggest that you wait with removal of the > files until then. > > Ulrich No, it won't cure the symptoms, just, shorten the number processed. Also it will eliminate a possible need to edit those old files like had been done recently. -- Brian Dolbec pgp3AUbJaRqtO.pgp Description: OpenPGP digital signature
[gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree
With the repoman rewrite stage2 code about to be merged into master. And a release including it to be made soon. I am going to start on stage3 of the rewrite. So... It is time to start painting a bikeshed about moving all possible check data to the tree. In that way small changes to things like the deprecated eclasses to scan for can be added to/or removed and the updates will propagate to everyone as they git pull the gentoo repo. So, here is my initial thoughts so far. We (portage team) discussed the possibility of making the data available for download via api.gentoo.org. But we decided it would be much better if that data was included in the repository. In that way it makes off-line work easier without having to deal with having a live connection to fetch the latest version of the data. It also then matches your current tree checkout. It could also make it easier for alternate repositories to establish their own QA data files. I'm thinking that we should establish a directory for the files containing the data for the checks being run. With the module systems now in place with the stage2 rewrite code. I was thinking that we should break up the data into logical files to go with the different scan modules present in repoman. If a new module is created, then a new data file may be created for it's dynamically changeable QA data. This also has the advantage that if a new app comes along that performs these same types of checks. It should be able to make use of this same data. So, where do we place this directory and what rules do we establish about it's modifications? location? : in the metadata dir alongside the install-qa-check.d directory? name of the directory? : repoman, qa-rules, qa-data, repo-qa-data, ... ideas? data format? : json (my favorite) compatible with many lanquages/interfaces is flexible to match various data types ie: dictionaries, lists, strings... is human readable/editable can be validated xml (PLEASE NO!) native python file (too language dependant) ini style (python configparser compatible) meh :/ other ideas? editing rules? : Similar to eclass modifications... email to the gentoo-dev list for review, possible objections. The current releases of portage/repoman would continue to use internal data. But this new data would need to precede a repoman release that uses it. Initially this stage3 code will continue to be developed in the repoman branch of the portage repo. It is also possible to test this git checkout code by establishing a symlink to the checkouts repoman command somewhere in your users PATH. Personally I named mine repom, and lives in my ~/bin directory. In that way I can easily switch between an installed repoman and the developing code to compare results to aid in debugging. -- Brian Dolbec
Re: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree
On Thu, 10 Mar 2016 18:40:31 -0800 Patrick McLean wrote: > On Thu, 10 Mar 2016 18:30:07 -0800 > Brian Dolbec wrote: > > > So, where do we place this directory and what rules do we > > establish about it's modifications? > > > >location? : in the metadata dir alongside the install-qa-check.d > >directory? > > That sounds reasonable to me, it is certainly metadata. > > > > >name of the directory? : repoman, qa-rules, qa-data, > > repo-qa-data, ... ideas? > > Something not project name specific, so nothing about repoman. Perhaps > something like "repo-checks", my personal vote would be make it a > directory with the contents being merged (so repo-checks.d maybe?) > > > > >data format? : json (my favorite) > > compatible with many lanquages/interfaces > > is flexible to match various data types > > ie: dictionaries, lists, strings... > > is human readable/editable > > can be validated > > > >xml (PLEASE NO!) > > > >native python file (too language dependant) > > > >ini style (python configparser compatible) meh :/ > > > >other ideas? > > YAML - like JSON but made to be edited/read by humans (comment support > is a big feature). Also valid JSON is valid YAML. Also can be > validated just like JSON can. OK, I just had a closer look at yaml. It does look easier for humans to edit and read. And seems to have the same data type flexibility. Maybe not quite as many languages have libs for it. But I don't think that is an issue for this data. I also want to separate the repoman release from the main portage release. This will have several advantages. 1) smaller portage install for installs that don't need repoman capabilities. 2) Repoman can add extra dependencies as needed for things like pyyaml and xmlschema. These deps would not be required for the base portage/emerge code. Keeping a base install stage3 lighter and not complicate bootstrapping a stage1, stage2. 3) They can be released indendant of each other as the need for a new release is desired/required. While repoman will still be tied to the portage codebase. Most of it's code use is via fairly stable API's. So only when those API's change will there need to be a simultaneos release. -- Brian Dolbec
Re: [gentoo-dev] Re: BROKEN: repository became broken!
On Wed, 30 Mar 2016 16:52:13 +0200 Patrick Lauer wrote: > On 03/30/2016 04:32 PM, mgo...@bonedaddy.net wrote: > > Looks like someone just broke Gentoo! > > > > New issues: > > https://qa-reports.gentoo.org/output/gentoo-ci/33f062a/output.html#dev-db/aerospike-server-community > > > > > > Introduced by commits: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=54033c5 > > > > > > Changes since last check: > > https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=range&q=0d2b3ad..54033c5 > > > > -- > > Gentoo repository CI > ... can you please either use repoman like everyone else, or fix > repoman to match the behaviour you like? > > 'cause it's annoying to have repoman say all is well and then get > such a nice response. Hard to comply with rules if there's no good > way to check the rules. > > Yeah, it would be nice to have a final resolution to the metadataDTD ==> xmlshema change so the repoman metadata module can get a proper re-write. In the meantime, repoman can not detect the recent change to the maintainer field. -- Brian Dolbec
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek wrote: > --- > metadata.dtd | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/metadata.dtd b/metadata.dtd > index 7626a57..b608852 100644 > --- a/metadata.dtd > +++ b/metadata.dtd > @@ -3,7 +3,7 @@ > > > > - ( (maintainer|natural-name|longdescription|slots|use|upstream)* )> > + ( (maintainer|longdescription|slots|use|upstream)* )> pkgmetadata pkgname CDATA ""> @@ -13,9 +13,6 @@ > explicit type) for Gentoo maintainers is prohibited. --> > > > - > - > - > > > Isn't this almost obsolete? it's now xmlschema... And I hope to have the new repoman with it out this weekend :) -- Brian Dolbec
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 1 May 2016 18:42:54 -0400 Göktürk Yüksek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Michał Górny: > > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >> > >> Michał Górny: > >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek > >>> wrote: > >>> > >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >>>> > >>>> Brian Dolbec: > >>>>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek > >>>>> wrote: > >>>>> > >>>>>> --- metadata.dtd | 5 + 1 file changed, 1 > >>>>>> insertion(+), 4 deletions(-) > >>>>>> > >>>>>> diff --git a/metadata.dtd b/metadata.dtd index > >>>>>> 7626a57..b608852 100644 --- a/metadata.dtd +++ > >>>>>> b/metadata.dtd @@ -3,7 +3,7 @@ >>>>>> pkgname CDATA ""> > >>>>>> > >>>>>> - >>>>>> > >>>>>> (maintainer|natural-name|longdescription|slots|use|upstream)* > >>>>>> )> + >>>>>> (maintainer|longdescription|slots|use|upstream)* )> > >>>>>> @@ > >>>>>> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is > >>>>>> prohibited. --> >>>>>> (person|project|unknown) "unknown"> > >>>>>> > >>>>>> - - >>>>>> natural-name (#PCDATA) > >>>>>>> - > >>>>>>> > >>>>>> > >>>>> > >>>>> Isn't this almost obsolete? it's now xmlschema... And I > >>>>> hope to have the new repoman with it out this weekend :) > >>>> > >>>> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see > >>>> that the example metadata.xml on the GLEP is missing DOCTYPE, > >>>> are we getting rid of those too? > >>> > >>> No, and I don't know. > >>> > >>> metadata.dtd is still required by many tools, and as such it > >>> makes sense to keep it. However, we may want to put some > >>> warning that it's not very strict, and allows major structural > >>> violations due to technical limitations. > >>> > >> After a discussion with ulm on IRC, we agreed that the following > >> makes sense: "the format of the metadata is defined in GLEP 68. > >> the syntax is defined in metadata.dtd. The xml-schema can be used > >> for stricter validation checks." If you have no objections, I > >> will update devmanual based on this description. > > > > What is the precise difference between 'format' and 'syntax' here? > > I'm no native English speaker, and I don't see any obvious split > > of responsibility between the two here, and I'm pretty sure this > > will be quite confusing for other people as well. > > > I admit that it is hard to make a clear distinction. When I look at > the GLEPs replaced by GLEP68, I see that they propose a change for > metadata.xml and explain how that affects metadata.dtd. GLEP34 has > "The DTD file would need to be updated to include the > element.", GLEP46 explicitly says "metadata.dtd should allow the use > of a upstream tag in metadata.xml.", GLEP56 points to #199788 which > required DTD to be patched. GLEP68 is rather vague as to how > metadata.dtd is affected. It doesn't say whether it should be updated > or if it has any role at all. > > GLEP68 provides a single human readable specification for the metadata > format. In that respect, however, the DTD along with the comments in > it is just as expressive, if not better: a developer can read through > the DTD and learn all the information contained in the GLEP, plus the > remote-id values which are not part of the specification for reasons > you stated earlier. And that was the reason why I used the term > "syntax": the DTD lists all the allowed elements, attributes, and > values for the metadata that should be used in conformance with the > GLEP . > > In the end, the DTD isn't much better than the GLEP as a human > readable document and does a worse job than the xsd as a machine
[gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing
In order to further improve the chances of Q/A tools catching errors. I have created a new repo (overlay) which will contain minimal test case ebuilds. The idea is to have test case ebuilds to run repoman code against. The outcome of these runs should be comparable to pre-recorded output. In that way as more code changes are applied as part of the stage3 re-write as well as new test cases and checks to be added to it's capabilities. It should minimize the bugs introduced in releases. Repoman does have some unit tests, but it is far from 100% coverage. Also with the major structural changes that the code has been undergoing, it is not always possible for the unit tests to be compatible with the new code. This new repository is open to all Gentoo developers to contribute to. All we ask is that you follow some simple common sense rules for adding additional test ebuilds. The repo is located at: https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ Here is the README included in the base directory. This repository is for the primary purpose of testing Q/A tools like repoman. The ebuilds it contains are for testing specific areas of tests that are performed as part of the normal operation of that Q/A tool. This repository is open to all Gentoo developers under the following rules: 1) The master branch is to remain the stable Q/A testing branch. 2) All ebuilds are to be minimal test cases. 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect. This makes it easier to spot errors during code development. Simply running repoman in a category should be enough to test everything the module tests. This excludes some commit only checks which can be run in a local only branch. 4) All category names are to represent the Q/A category being tested. ie: ebuild-test - tests various aspects of the ebuild repoman module eclass-test - various eclass module tests ... 5) like the category naming, the package naming will follow the test being performed. ie: eclass-test/live-keywords - test the eclass module LiveEclassChecks keywords check ebuild-test/invalid - test for invalid package name detection 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo That should ensure it maintains co-ordination with the main gentoo repo. All new or modified eclasses that affect pkg metadata should be validated in a branch. 7) New module development and test ebuilds will be done in a branch or personal repo and submitted to the gentoo-portage-dev email list for review and approval to merge into master. NOTE: This rule is lifted for the initial creation and population of test ebuilds to use to test out the repoman code. An anouncemnt to the gentoo-project email list will be made when this initial population period is being ended. 8) Signed commits only, also signed-pushes are mandatory 9) The metadata category will get files of validated output that can be used to verify code changes in the various categories and repo wide runs. Diffing the output, should help to verify code changes did not break anything. 10) See rules 1-9 :-) -- Brian Dolbec pgpU8UI_wWO7k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] On banning merge commits
On Sun, 08 May 2016 11:06:09 +0100 Amadeusz Żołnowski wrote: > I am working at the moment on debundling ejabberd. It will come with > ~30 packages and I will do "git merge --no-ff ejabberd-debundled" > because it will actually look less messy. > > Thanks, > -- Amadeusz Żołnowski Yes, this is exactly the type of merge commits that should be allowed. Not the one or two user PR commits that might be based on a weeks old tree, that a developer merges without rebasing. It is these merge commits which have caused all the grief we've experienced over merge commits. Merge commits should be used wisely and for larger branch merges like the kde, gnome team's development overlay merges to the main tree or similar larger one off project's like the one above. It is these larger commit branches that are much more difficult to "git pull --rebase && git push --signed" successfully without some other pushes in between causing a rejected non-fast forward push. -- Brian Dolbec pgpSUtzSFxJgr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
On Tue, 10 May 2016 21:42:19 -0400
Mike Gilbert wrote:
> On Tue, May 10, 2016 at 5:25 PM, Michael Orlitzky
> wrote:
> > On 05/10/2016 02:28 PM, Mike Gilbert wrote:
> >> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky
> >> wrote:
> >>> We have maybe 150 ebuilds in the tree using $ROOT in src_*
> >>> functions. Some are bugs, but many look OK to me. Do we really
> >>> want to say "never" do that?
> >>
> >> According to PMS, it is only legal in pkg functions.
> >>
> >> Can you point to an example where using ROOT in a src function is
> >> appropriate?
> >
> > Modulo the question "when should you use $ROOT over $EPREFIX"...
> >
> > * the chrome-binary-plugins ebuilds use it in src_install.
>
> This is quite obviously wrong. I happen to maintain that ebuild, so I
> just fixed.
>
> > * dmraid does
> >
> > einfo "Appending pkg.m4 from system to aclocal.m4"
> > cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 ||
> > \ die "Could not append pkg.m4
>
> This should be one of two things:
>
> cat /usr/share/aclocal/pkg.m4
>
> Or, if prefix support is desired:
>
> cat "${EPREFIX}"/usr/share/aclocal/pkg.m4
>
> > Both of those look like EPREFIX candidates to me, but they're not
> > obviously wrong, either. Maybe it made sense in EAPI <= 3.
> >
> > Anywhere that you need addpredict() it also seems reasonable. The
> > v4l-dvb-saa716x ebuilds use "${ROOT}/usr/src/linux/" where EPREFIX
> > would not be a good replacement.
>
> Nah, usually addpredict is dealing with stuff in the system that is
> performing the build. Sandboxed phases should never be looking at
> ROOT.
>
> Those ebuilds should probably do addpredict /usr/src/linux instead.
>
> >
> > Something needs to be fixed, though: you're right that the PMS
> > limits ROOT to pkg_*. Who knew? If we want to be serious about
> > banning ROOT in src_*, we should add a repoman error.
>
> Based on my own understanding of the ROOT variable, its use in src
> functions is always nonsensical, especially when you consider binpkgs.
> A binpkg can be installed with a ROOT value that is completely
> different from its value when the package is being compiled.
>
> To put it another way, in src functions, ROOT could/should always be
> "/". The real value of ROOT isn't determined until merge time.
>
> I agree, repoman should be catching this stuff.
>
Then Please contribute some test ebuilds for the gen-b0rk repo to test
repoman or any other Q/A apps with. If they fail to detect the test
ebuilds, it will give us something to use to help trace the code errors.
It'll also make for a much better testing system overall for any app
performing any type of Q/A on ebuilds.
--
Brian Dolbec
Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
On Tue, 10 May 2016 22:40:39 -0400 Mike Gilbert wrote: > On Tue, May 10, 2016 at 9:54 PM, Brian Dolbec > wrote: > >> I agree, repoman should be catching this stuff. > >> > > > > Then Please contribute some test ebuilds for the gen-b0rk repo to > > test repoman or any other Q/A apps with. If they fail to detect > > the test ebuilds, it will give us something to use to help trace > > the code errors. It'll also make for a much better testing system > > overall for any app performing any type of Q/A on ebuilds. > > I don't think there is a repoman check for ROOT in src functions > (yet). I was just saying that I think it would make sense to add that. > As you know, with the modular system now in place, It should be quite easy to add that check now. There is no need to figure out where in over 3000 lines of spaghetti code to insert it without messing up something else. Make the test ebuilds, at least one good one, plus however many to test the broken parts. It should only take an hour to add that check. -- Brian Dolbec
Re: [gentoo-dev] USE flag proposal: memcached
On Sat, 14 May 2016 11:32:02 -0400 "Anthony G. Basile" wrote: > On 5/14/16 11:19 AM, Dirkjan Ochtman wrote: > > All, > > > > I want to add a "memcached" USE flag to mail-filters/rmilter. Before > > doing so, I looked if there was a global USE flag. There is not, > > but I though see usage across 14 packages: > > > > dev-db/pgpool2[memcached]: Use memcached for query caching > > dev-php/pecl-mysqlnd_qc[memcached]: Use > > dev-libs/libmemcached as a storage handler > > mail-filter/opendkim[memcached]: Add support for using > > dev-libs/libmemcached > > mail-mta/postfix[memcached]: Add support for using > > net-misc/memcached for lookup tables > > net-analyzer/graphite-web[memcached]: Enable memcached support > > net-analyzer/munin[memcached]: Install the packages required for > > memcached monitoring. > > net-mail/automx[memcached]: Enable memcached support > > sys-auth/keystone[memcached]: Installs dependencies needed for using > > memcached as a backend > > sys-cluster/cinder[memcached]: Installs the memcached server > > sys-cluster/gearmand[memcache]: Support memcache daemon (via > > dev-libs/libmemcached) for the queue storage. > > sys-cluster/nova[memcached]: Installs the memcached server > > sys-cluster/swift[memcached]: adds memcached support > > www-servers/lighttpd[memcache]: Enable memcache support for mod_cml > > and mod_trigger_b4_dl > > > > Most of these seem to depend on dev-libs/libmemcached or > > net-misc/memcached, with a few packages depending on > > language-specific stuff (e.g. dev-perl/Cache-Memcached or > > dev-python/python-memcached). > > > > I suppose the description can just be "Enable memcached support". > > > > Any objections? > > > > Cheers, > > > > Dirkjan > > > > its a good idea given its popularity and the unequivocal meaning of > "memcached". so i say do it. > +1 -- Brian Dolbec
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 15 May 2016 11:05:21 +0200 Jeroen Roovers wrote: > On Sat, 7 May 2016 23:25:58 +0200 > Michał Górny wrote: > > > Do you seriously expect this code to work? How about testing? Or > > reading diffs before committing? > > > Somebody could have a go at implementing this: > > https://bugs.gentoo.org/show_bug.cgi?id=390651 > > It's been brewing for half a decade. Maybe it's time. :) > > > Regards, > jer > With the new repoman code structure, yes, it would be a lot easier to implement. Also with the gen-b0rk test repo, that will be a good testing ground for eclass changes too. It just needs more devs to make test ebuilds to get it fully populated ;) -- Brian Dolbec
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 15 May 2016 04:18:39 -0700 Daniel Campbell wrote: > On 05/15/2016 02:15 AM, Brian Dolbec wrote: > > On Sun, 15 May 2016 11:05:21 +0200 > > Jeroen Roovers wrote: > > > >> On Sat, 7 May 2016 23:25:58 +0200 > >> Michał Górny wrote: > >> > >>> Do you seriously expect this code to work? How about testing? Or > >>> reading diffs before committing? > >> > >> > >> Somebody could have a go at implementing this: > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=390651 > >> > >> It's been brewing for half a decade. Maybe it's time. :) > >> > >> > >> Regards, > >> jer > >> > > > > With the new repoman code structure, yes, it would be a lot easier > > to implement. > > > > Also with the gen-b0rk test repo, that will be a good testing ground > > for eclass changes too. It just needs more devs to make test > > ebuilds to get it fully populated ;) > > > What sort of test ebuilds are you looking for? There are a few > packages I'd like to see get into Gentoo but I don't want to break > anything. :P > Have a look at the gen-b0rk repo, See how the ebuilds are done, follow those examples. There are lots more errors that repoman looks for that are not yet covered by test ebuilds. There are a few more in other areas of code, but here is the biggest list of errors/warnings that repoman can test for. https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman -- Brian Dolbec pgpRMqKiMf0hB.pgp Description: OpenPGP digital signature
[gentoo-dev] NEW: split portage/repoman releases now in the tree
portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree. portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a few small patches applied. It mostly just installs less code, namely the repoman code. So, now servers and other systems that do not require repo Q/A ability will no longer get repoman installed anyway. repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now modular, and using the portage plugin system. The system is not yet fully plug and play. Those changes will take place in the stage3 re-writes. The two packages will remain in the same portage git repo, although the repoman code has been moved into it's own pkg directory. It is too tied into portage api's to be on it's own just yet. An that is not likely to happen until we get a stable portage API. This new system does allow for semi-independant releases for both repoman and portage. When important API's change, it will require both to be release at the same time. So you can look forward to seeing the minor version number to get more frequent bumps than it has this last decade. Currently, the portage ebuild does not RDEPEND on the repoman ebuild. You will have to explicitly emerge it for it to be installed. It has been suggested to add a use flag enabled RDEPEND (default on) for the dev profile. I will also be adding that to the portage- release for all profiles in the coming days. NOTES: Repoman now depends on lxml for it's xml parsing and error checking along with now using metadata.xsd. It now will report a lot more errors than the previous buggy code everyone has been using. I want to thank the following people for their help and contributions to make these releases: Zac Medico Alexander Bernsten Dirkjan Ochtman for the base xml re-write code Michal Gorny for the metadata.xsd changes Göktürk Yüksek for the metadata.xml test ebuilds patches. Mike Gilbert for all the testing on the rewite code, and a number of gen-b0rk repo test ebuilds. Coacher for the recent testing, bug reports and patches. And anyone else I missed ;) So, please report any issues with either the ebuilds or installs, bugs, etc... you know the drill ;) Don't forget, please contribute more test case ebuilds to the gen-b0rk repo. The better the test ebuild coverage we have, the better our Q/A tools (like repoman) will be and the less often things will be released broken. Thank you -- Brian Dolbec
Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree
On Tue, 17 May 2016 08:50:25 +0200 Marcin Mirosław wrote: > W dniu 16.05.2016 o 10:45, Dirkjan Ochtman pisze: > > On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec > > wrote: > >> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now > >> modular, and using the portage plugin system. The system is not yet > >> fully plug and play. Those changes will take place in the stage3 > >> re-writes. > > > > Thanks for working on this, it sounds great! > > But it doesn't sounds so great for every every user;) > https://bugs.gentoo.org/show_bug.cgi?id=583252 > > > There was a reason it was released as _rc1, And it was fixed real quick with _rc1-r1, it was a small easy fix. Incidentally , the error was in the portage code, not the new repoman code which your reply above seems to indicate. For those of you that might have installed _rc1, the easy fix is install repoman, then upgrade to _rc1-r1, then unmerge repoman if you don't want it. For those that may not know, _rc stands for release candidate, when major changes are done. Code is often released as a release candidate to shake out any missed change that might be needed but missed due to configuration and other conditions on the developers systems. Thank you to those that tested it quite thoroughly after I released it. Including finding the fix right away :D -- Brian Dolbec
Re: [gentoo-dev] Proposal for changes for the next EAPI version
On Tue, 17 May 2016 15:53:34 +0200 "M.B." wrote: > Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > > For normal users we wouldn't. But currently, arch-testers need to > > make a judgement call on what to test when a stable-req bug is > > filed. Tests run in src_test are provided by upstream, and does not > > guarantee that a package that has been merged will actually run on > > the system. If the maintainer could add a couple small scripts to > > check basic functionality > > of the merged package, it would make testing for arch testers much > > easier and reliable. > > Let me give an example. Let's say > > app-misc/screenfetch-2.7.7 is the current stable package for > > screenfetch in the portage tree. > > However, on running, it produces an error on the top, along with > > the proper output. > > If screenfetch-3.0.0 happens to fix that error, maintainer can add > > a simple script > > > >if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then > > eerror "Still producing error" > >fi > > > > To make sure the build is properly updating the screenfetch > > version, and that > > the bug has in fact been fixed. This is the only way I can see to > > reliabily and automatically test packages that have been merged > > successfully. > > > > --- > > Regards, > > Pallav > > > > On Mon, May 16, 2016 at 10:08 PM, Luis Ressel > > wrote: > >> On Mon, 16 May 2016 18:13:33 +0530 > >> Pallav Agarwal wrote: > >> > >>> What I'm suggesting is to add a new function post_install_test. > >>> The function will run only if the build is being run for > >>> stabilization (either as a part of automated stabilization, or > >>> manual) which can be controlled by a USE flag. The function would > >>> also require independent dependencies in case it uses external > >>> applications to test the one being built. > >> > >> Could you please elaborate on this? We already have src_test() for > >> automated tests. Why would we want to run additional tests after > >> the package has been merged? > >> > >> -- > >> Regards, > >> Luis Ressel > >> > >> Luis Ressel > >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > >> > > > > Good afternoon, > > facilities for running post-install (pre-merge) QA-checks are in > place. Please have a look at portage's misc-functions.sh, > install_qa_check() will reveal the locations where you can find the > installed checks, along with a place for local overrides. Perhaps you > can design something around this? > > With kind regards, > tomboy64 > These tests would be run post-merge, in the normal file system. Mainly for stabilization checks that can be automated, so not a QA-checks qualifier which looks for common problems that can potentially lead to bugs before it is merged to the normal file system. -- Brian Dolbec pgpX_padjvLLx.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
a GUI is optional.
>
> * USE=gtk3 may be used only for controlling extra libraries to be
> shipped for gtk3 support (the extra library file will link to gtk3),
> _in addition_ to gtk2 version. This is a temporarily measure until
> gtk2 support can be dropped and it will only ship gtk3 version of the
> library. This gives a flag to be able to USE depend on by gtk3 apps.
> This leaves the question about the opposite open, however. This is why
> USE=gtk2 would be bad for apps, maybe we need to use it for this
> library case, when gtk3 version is primary and we just have 1 app
> remaining that needs the gtk2 version or something.
> The concept of library is broad here, covering also gtk theme engines
> (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and
> modules (e.g caribou, libcanberra)
>
> * Applications may only use a gtk2 based stack or gtk3 based stack in
> a given version/revision. gtk3 is strongly preferred when it is
> deemed to not have any regressions compared to gtk2 build, but the
> choice is ultimately with the maintainer. Once the application
> converts to using gtk3 in our distribution, it should try hard to
> stay that way in upcoming versions as well.
>
> * Some exceptions to the above may exist under heavy consideration,
> especially in cases where the toolkit usage is complex and may have
> some issues for some, but in general gtk3 support is deemed good by
> upstream. Most notable here would be browsers like firefox and
> chromium, which are using gtk dependency more for emulating the theme
> it uses, rather than using it as its real toolkit. If such exceptions
> are allowed, the USE flag naming here must be consistent amongst the
> exceptions. My proposal would be USE=force-gtk2 then, as I have no
> better ideas without stomping on the USE=gtk{2,3} historical meaning.
>
>
> When arguing in favor of supporting gtk2 builds more for apps, please
> do keep in mind that gtk2 really is pretty much dead. And no, MATE,
> XFCE and others are NOT continuing its support; they are just slow in
> fully converting to gtk3, but they are doing so and I expect both of
> those to be fully done this year, around autumn.
> If the issue is political or just a general gnome3 or gtk3 hate, then
> I would ask you to keep your political opinions or hate outside this
> thread and go contemplate on more important life issues.
> If the issue is lack of themes, then I would like you to help package
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
> themes shouldn't be breaking anymore beyond this point, theoretically.
> And gtk3 theme packages should pretty much just be CSS files and some
> metadata. Though we have yet to get over that bumpy thing yet (a main
> reason gtk3.20 isn't in main tree yet).
>
> Thoughts? Agreements? Suggestions?
> I'm particularly interested in QA opinion here. I believe WilliamH
> wanted to spearhead this from their side.
>
>
> Regards,
> Mart Raudsepp
> Gentoo developer, GNOME team
>
I'll be really sad when gtk2 is totally abolished in Gentoo. :(
I suppose I'll have to break down and switch to KDE maybe.
In my opinion the upstream gtk developers have gone somewhat bonkers
with their cartoonish changes to the look, feel and generally
un-intuitive user interface. The new file selector is irritating to use
despite getting all the old behaviour settings I know of set, the lack
of the ability to paste a path into it, forcing you to navigate
directory by directory, and other BS behaviour... Some apps even have
less functionality and usefullnes. I have a local copy of
dev-vcs/gitg-0.27 ebuild which I use daily which despite some
instability is far more useful than it's "modern" counterpart. I use
xfce4 for both work and my own workstation, and like it, but it's apps
are getting increasingly more corrupted by gtk3isms :(
So, I accept I'll not be liked by the gtk team for wanting to keep gtk2
around still.
--
Brian Dolbec
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
On Fri, 27 May 2016 11:35:01 -0500 Canek Peláez Valdés wrote: > On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec > wrote: [snip] > > I'll be really sad when gtk2 is totally abolished in Gentoo. :( > > I suppose I'll have to break down and switch to KDE maybe. > > > > In my opinion the upstream gtk developers have gone somewhat bonkers > > with their cartoonish changes to the look, feel and generally > > un-intuitive user interface. The new file selector is irritating > > to use despite getting all the old behaviour settings I know of > > set, the lack of the ability to paste a path into it, forcing you > > to navigate directory by directory, and other BS behaviour... > > What's wrong with Ctrl-L to open the "Enter location or URL" text > field and pasting the path there? > > Regards. The unintuitive knowledge that that even existed for one. I have been informed in IRC about this and tried it. I also found out that you can just paste it without opening that box (haven't tried that yet) . Also typing / will bring it up. Without a / will start a search... All unintuitive changes since gtk2. I admit I don't know all the in's and out's of gtk2 either, but in gtk2 there was a small icon to open the text/paste box if it wasn't already a default. Also what is intuitive about special keystrokes in a gui? After all gui stands for Graphical User Interface. Keyboard shortcuts are one thing, totally hiding them from the interface quite another. There is a reason I tend to prefer __GOOD__ gui apps over command line ones in most cases. I hate trying/needing to memorize 100+ special keystrokes and/or commands and/or options for apps. It's more I know what I want to do, so do the few clicks/done, not spend half my time trying to read man pages/learn/memorize _some_app_ special keystrokes and/or command option in order to do it. -- Brian Dolbec
Re: [gentoo-dev] [RFC] Global USE=gui
On Tue, 7 Jun 2016 14:29:58 -0400 Michael Orlitzky wrote: > On 06/07/2016 12:20 PM, Michał Górny wrote: > > > > So many weird ideas... while the simplest one is a proper > > REQUIRED_USE with gui being the control flag, and IUSE defaults to > > select the preferred toolkit. > > > > This is what came to my mind. > > The underlying problem that we are hitting (a la Patrick) is that USE > flags are supposed to be a user-interface for building software from > source, but implementation details are an important part of > configuring the software to be built. > > It would be nice if USE=gui meant "build a GUI" and that was all the > input that we needed from the user. But if the upstream package > supports both QT and GTK and we need to pass either --with-qt or > --with-gtk to the build system, then there is an unavoidable choice > to be made. We can prefer one, but both options need to be available. > > If we want the best of both worlds -- a nice user-interface and full > configurability -- then we can use "the user wants a GUI" as a trigger > for the implementation choice. If there's a default implementation and > the user doesn't care, no further interference should be necessary. > Otherwise the presence of the generic USE=gui will let us know, so we > can let the user know, that he needs to pick one. > > This is where my thought from a few days ago kicks in... I had started to discuss it with Kristian. I propose to help alleviate the __MESS__ from all this force-foo and other complicated USE flag REQUIRED_USE madness... We instead implement something along the lines of: an ordered list of the gui toolkits in their preferred order of desirability. This should be an all inclusive list. Note: these are subject to package.use setting overrides. PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3" In the above it means that if gtk2 is an option, then choose it, mask (de-select) the others. In there it also means DO NOT SELECT gtk3 So if you want a pkg and it NEEDS gtk3, then the PM will puke it back at you saying you can't have one without the other... So, then you have to fix it manually via package.use settings. Accept gtk3 for this pkg only (not that it doesn't likely have other gtk3 deps that will also need this...) In the general case it will pick the first toolkit in order of preference (left to right) and only that toolkit that the pkg is capable of using. For pkgs capable of multiple simultaneous toolkits installed, then again, manual intervention would be needed to set package.use. This would also have to be a package manager feature and run similar to the auto-unmask feature. FEATURES="preferred-guis" Let's try and keep things as simple as possible. From what I've gleaned form the emails I have read, is that what the general user wants to happen, select the toolkit in the order of their preference. -- Brian Dolbec
Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED
On Fri, 17 Jun 2016 18:46:16 +0200 Kristian Fiskerstrand wrote: > On 06/17/2016 06:41 PM, Rich Freeman wrote: > > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand > > wrote: > >> On 06/17/2016 03:58 PM, Rich Freeman wrote: > >>> > >>> That could actually be generalized. I could see many types of > >>> bugs where the issue is with upstream, and we might want to track > >>> the progress as upstream implements a fix, releases it, and then > >>> it is stabilized on Gentoo. So, maybe we need another state to > >>> track in upstream's VCS vs the Gentoo repo. > >> > >> For a great deal of this we have UPSTREAM keyword, and also > >> combination with PATCH keyword if we've submitted an own patch. > > > > Usually we mean UPSTEAM to mean that the issue is an upstream issue, > > and should be pursued there. Usually we don't use it to mean that > > the issue IS resolved upstream but we're waiting for a > > release/etc. I'm > > Well, the issue is still upstream in that case, so I don't see that > necessarily being different, we're still waiting for a release > upstream to make a new downstream ebuild and stabilize it, so it fits > with UPSTREAM > > > not sure how important the distinction is in practice. The portage > > team could of course use it differently. > > Yeah, I'm talking ebuilds here, not portage and similar bugs, I think > your point of having own keyword for portage and the likes makes sense > to distinguish it. > > Then everyone PLEASE stop referring to the Gentoo ebuild tree as portage. Reserve portage for the upstream PACKAGE MANAGER. Further, I have always treated bugs about portage code like any other upstream. Only difference being that the portage upstream bug system is the same bugzilla used for the Gentoo ebuild tree. So, there will be some differences in how bugs are treated. When we as upstream commit patches for bugs we tag them as InVCS and close them when they are in a release. We have not kept them open until that release has been stabilized unless we've missed closing it or been distracted and forgotten to clean them up. If you want to track that at the ebuild level, you could do that, but would need to identify it's tracker in a clear way to distinguish it from code bugs. -- Brian Dolbec pgp69AoKFcWN9.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Looking for a new mentor...
On Wed, 20 Jul 2016 15:13:56 -0400 alexmcwhir...@triadic.us wrote: > I've been working towards becomming a gentoo developer for while now > in order to bring the sparc port up to speed with the rest of the > gentoo project. In short there appear to be no active gentoo > developers working on sparc. > > I had a mentor earlier this year, but i can no longer get in touch > with him. > > I have both quizzes nearly complete, i just need someone to look over > them and answer a question or two. Any help would be greatly > appreciated. > Alex, it would be helpful to list your timezone and normal availability times. That will help potential mentors know if they match up availability times. Aside from sparc related updates, is there any other areas of the ebuild tree your more interested in like desktop environments, gnome, kde, *box, networking, tools... -- Brian Dolbec
Re: [gentoo-dev] Farewell Gentoo.
On Mon, 8 Aug 2016 08:24:16 -0400 "Jesus Rivero (Neurogeek)" wrote: > After so many years of being a proud Gentoo dev, it comes that time > when I have to say bye (at least for now). > > There are no words to describe what Gentoo and being a Gentoo dev > meant for me. > I've made really good friends, learned a ton of skills in many facets > of computing from incredibly amazing and knowledgable people, and was > a big part of me getting great job opportunities. > > I didn't want to part without first saying thanks to all the devs > that have and continue to make Gentoo such an amazing project. Keep > making Gentoo better! > > Keep in touch. > Farewell, and thanks! > Sad to see you go, but, also glad you were a dev for so many years :) I hope to see you around in the future too, even if it is only for visit :) Take care, have fun,... don't be a stranger ;) -- Brian Dolbec
Re: [gentoo-dev] Packages up for grabs
On Sun, 07 Aug 2016 10:24:08 +0200 Pacho Ramos wrote: > This packages are now up for grabs: > app-portage/g-sorcery > app-portage/gs-elpa > app-portage/gs-pypi I'll sign layman project up for these -- Brian Dolbec
Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled
On Mon, 8 Aug 2016 09:12:32 -0500 William Hubbs wrote: > typo: anyonewho missed a space -- Brian Dolbec pgphFxTuJI75_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On Mon, 15 Aug 2016 12:05:43 +0800 Jason Zaman wrote: > On Mon, Aug 15, 2016 at 03:53:26PM +1200, Kent Fredric wrote: > > On Mon, 15 Aug 2016 11:45:22 +0800 > > Jason Zaman wrote: > > > > > IN_PROGRESS == we've put the fix in the git repo > > > RESO/TESTREQ == new release and in ~arch > > > > TESTREQ was incidentally my first thought. Only needs me to study > > how much that's already used and whether or not existing bugs with > > that flag meet that description or not. > > > > > > However, a distinction between IN_PROGRESS and RESO/TESTREQ is not > > possible here, because "in git" means "You'll get it if you sync > > >1h from now" > > Oh, I meant this is for our policy stuff. which is in > hardened-refpolicy.git and then every few weeks we make a release and > bump all the packages in sec-policy/selinux-*. For things that do not > need an actual release we just skip INPROG and go straight to TESTREQ > when we fix the ebuild in the tree. > > The important part to me is that RESO/FIXED should only mean fixed > when the problem is fixed in the stable tree too. There has to be > another state before FIXED that is for ~arch. If the package is not > stable on any arch then of course it is FIXED as soon as ~arch is > fixed. > > > IN_PROGRESS can thus only mean something about it being worked on > > but not yet pushed to the main git repo. (ie: overlays, private > > repos) > > > > But I would rather it part of the primary resolution path, not a > > mere property of the resolution type. > > > > Because its easier to say: > > > > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> INVCS -> STABLE > > > > Than > > > > UNCONFIRMED -> CONFIRMED -> INPROGRESS -> (RESOLVED/TESTREQ) -> > > (RESOLVED/FIXED) > > They are roughly equivalent, yeah. But I prefer TESTREQ because its > easier to see in the bug list page. You can of course choose which > items are shown in the list in bugzilla but resolution is already > there so no need to add an extra column. > > -- Jason > > I have some trouble with not being able to close bugs as resolved when the fixes have been released. But I do see that the majority of what is being discussed relates to pkg ebuilds more than it does to coding projects. In that sense it sounds reasonable. But for me, most of my work is project coding, so it overlaps with making releases which involves the ebuild. As a project coder, I want to be able to close a bug when a release has been made that contains the fix. In some cases that release might not get stabilized, but another one later does. For me IN_PROGRESS means the problem is being worked on, not that a fix has been posted/committed anywhere. INVCS is once the fix has been committed to the source repo and not anything to do with an ebuild from the coders perspective. The problem is the overlap of bugzilla for both ebuild repositories and source repositories. So if there is any changes to be made to the different states possible... Just remember the the different perspectives and try to make it clear what they are for. Also, if a pkg is never stabilized... does that mean it's bugs can never be closed? So far in the discussion, that point has not been brought up, but is very relevant to the discussion. /me mumbles about the extra bookeeping that work-flow will make...and subsequently put off and/or forget to do ;) -- Brian Dolbec
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On Mon, 15 Aug 2016 09:40:39 -0400 Rich Freeman wrote: > On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec > wrote: > > > > I have some trouble with not being able to close bugs as resolved > > when the fixes have been released. But I do see that the majority > > of what is being discussed relates to pkg ebuilds more than it does > > to coding projects. In that sense it sounds reasonable. But for > > me, most of my work is project coding, so it overlaps with making > > releases which involves the ebuild. As a project coder, I want to > > be able to close a bug when a release has been made that contains > > the fix. In some cases that release might not get stabilized, but > > another one later does. > > I'd suggest that we agree early-on that the scope of this is around > ebuild work. Not "upstream" work where the upstream is Gentoo. > > Of course, there could be overlap. portage-1.23.ebuild might have a > bug, and that gets fixed in the portage dev git, and later gets > released to portage-1.24, and then ends up in stable sometime later. > Those could be two separate bugs (the gentoo repo ebuild bug vs the > portage "upstream" bug), but I'm not sure that makes life easier. If > they were two separate bugs (as they would be if Gentoo weren't the > upstream) then the scope of this effort is focused on the Gentoo > ebuild repo bug. > I suppose we could use the tracker bug a little differently than we have to handle the release/ebuild stabilization process. We have often recycled a tracker to the next version, but instead we can generate a new one each time and allow it to be used this way. If a release is being skipped for stabilization, then it could be added to the next tracker's depend. The only thing is that we will still end up with duplicate bugs being filed since the trackers do not have any search data of the original bugs which have been fixed and released in an unstable version. Of which the original bug had been marked resolved. In this case, could the search system be modified to keep that search data until all references to that bug (ie: blocks the tracker bug) have been stabilized/closed. hmm, looking a bugzilla... Gentoo Linux: The Gentoo Linux Distribution – Ebuilds and System related issues Always attach the output of emerge --info to your bug report! Before reporting a bug, please make sure the issue you are about to file is not the result of a misconfiguration on your part. Our other support venues (for instance the Forums or IRC channels) can help you find out whether the issue warrants a bug report. Examples for bugs in this product: New package and version bump requests Compile errors (please follow the instructions contained in the error message!) Application crashes (be sure to have a backtrace available) General issues regarding your Gentoo system Examples for bugs that should NOT be filed here: Security updates (use Gentoo Security below) Documentation updates (use Documentation below) Issues regarding our website and infrastructure (use Gentoo Infrastructure or Website www.gentoo.org below) Issues about OpenRC, genkernel, or catalyst (use Hosted projects below) -- This is still a very broad range... This can still cover bugs for many small projects that are not in the hosted projects category. It also can contain bugs that will never involve stabilization of an ebuild. Perhaps we need to add a new category SPECIFICALLY for dealing with the stabilization process and/or Gentoo tree state. The current "Gentoo Linux" would continue to act as the catch-all, but as a bug is fixed and involves a release/in tree new version,..., it get's re-categorized to a "Gentoo Stabilization" (or some other aptly named) category. In that way, once a fix has been made the re-categorization could reduce the search results for projects working on bugs that need fixing. While at the same time, not completely close a bug. For tracker bugs, it would be the tracker that gets re-categorized to the specific "Gentoo Stabilization" category where it too could get better search results and/or some semi-automated tools could send reminders for ebuilds not stabilized after the 30 day time when that version has no bugs in the catch-all category. Also if bugs are filed against it, a tool could auto-tag it's DEPEND with the "Gentoo Linux" bug number. I think something like this could help improve the process. -- Brian Dolbec
[gentoo-dev] New single dev-python/twisted package releases in the tree
Since the mid 15.x.x releases of twisted, upstream changed from the
split releases twisted-{core,names,web,...} to a single twisted package
release. Our gentoo tree has been behind with upstream releases since
then partially due to this change and the work involved in the
conversion.
I am pleased to inform you that I have now completed the new twisted
package ebuilds and updated/additional/new dependencies. There are now
dev-python/twisted-16.2.0 and 16.3.2 releases in the gentoo tree and I
am working on 16.4.1 to get the tests working before adding it to the
tree. I have been doing testing of the 16.2 and 16.3 releases in my
buildbot-0.9.0 (day job) work without any issues.
Currently I have added dev-util/buildbot, dev-util/buildbot-worker,
www-servers/tornado, dev-python/autobahn, dev-python/txrequests
ebuilds which have ||() dependencies on either the old split twisted
or new twisted single pkg dependencies.
Since there are no longer any split twisted-* pkg releases, any new
pkgs/ebuilds should be made with either the new dev-python/twisted only
or ||() twisted pkgs dependencies as the maintainer sees fit. You
should also list the new dev-python/twisted pkg first in any ||() deps
you add. I have come across a portage bug where the resolver was not
able to solve a conflict between the old split pkgs and the new single
pkg where it should have been able to. This was partially due to having
the old split twisted pkgs listed as the first (left) entry in the ||().
You should not introduce new pkgs and hopefully new ebuild versions of
existing pkgs that list only the old split twisted pkgs as dependencies.
I am sure that eventually the old split releases will be tree-cleaned
at some future point.
Thank you
--
Brian Dolbec
pgpxfrk_UJPrK.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] New single dev-python/twisted package releases in the tree
On Wed, 12 Oct 2016 16:35:25 -0700
Brian Dolbec wrote:
> Since the mid 15.x.x releases of twisted, upstream changed from the
> split releases twisted-{core,names,web,...} to a single twisted
> package release. Our gentoo tree has been behind with upstream
> releases since then partially due to this change and the work
> involved in the conversion.
>
> I am pleased to inform you that I have now completed the new twisted
> package ebuilds and updated/additional/new dependencies. There are
> now dev-python/twisted-16.2.0 and 16.3.2 releases in the gentoo tree
> and I am working on 16.4.1 to get the tests working before adding it
> to the tree. I have been doing testing of the 16.2 and 16.3 releases
> in my buildbot-0.9.0 (day job) work without any issues.
>
> Currently I have added dev-util/buildbot, dev-util/buildbot-worker,
> www-servers/tornado, dev-python/autobahn, dev-python/txrequests
> ebuilds which have ||() dependencies on either the old split twisted
> or new twisted single pkg dependencies.
>
> Since there are no longer any split twisted-* pkg releases, any new
> pkgs/ebuilds should be made with either the new dev-python/twisted
> only or ||() twisted pkgs dependencies as the maintainer sees fit. You
> should also list the new dev-python/twisted pkg first in any ||() deps
> you add. I have come across a portage bug where the resolver was not
> able to solve a conflict between the old split pkgs and the new single
> pkg where it should have been able to. This was partially due to
> having the old split twisted pkgs listed as the first (left) entry in
> the ||().
>
> You should not introduce new pkgs and hopefully new ebuild versions of
> existing pkgs that list only the old split twisted pkgs as
> dependencies. I am sure that eventually the old split releases will
> be tree-cleaned at some future point.
>
> Thank you
I forgot...
The new twisted package is also mostly python3 compatible. There is
code in twisted's setup.py that will not install modules to a py3 that
are not yet ported to python3. So, there should be no issue turn up
during the twisted install.
I have not checked as to which modules have not been ported yet, but
those modules will still install to python2.7. If you have any issues
with your pkg using twisted under python3, then you may have to
restrict py3 from your pkg's PYTHON_COMPAT. As I get caught up, I'll
check in more detail which modules are not yet ported. If you come
across any, feel free to send me a note or even add an ewarn to the
affected twisted ebuild about that sub-modules py3 availability.
--
Brian Dolbec
pgp48SDhsw0vP.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Future EAPI version operator changes
On Mon, 7 Nov 2016 22:47:24 +0200 Alon Bar-Lev wrote: > On 6 November 2016 at 12:52, Michał Górny wrote: > > Hi, everyone. > > > > > So, what are your comments? > > Hi, > > Just my 2 cents... > I kinda love the prefix nature of the expressions which is consistent > and easier to parse. > Using infix only for versions and leaving all the rest prefix will > create abnormality. > > Regards, > Alon > But the main problem with it is that most upstream requirements.txt, etc.,... all use the infix method. And I hate to say it, but more and more so-called "package management" systems (mostly language specific ones) all use that method. So transitioning to that, should make package maintenance easier. Possibly even have some automation tools to check them during version bumps, etc... -- Brian Dolbec
Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
On Tue, 29 Nov 2016 23:59:57 +0100 Ulrich Mueller wrote: > >>>>> On Tue, 29 Nov 2016, Robin H Johnson wrote: > > > TL;DR: Let's replace profiles/**/ChangeLog with profiles/ChangeLog, > >because it's a mess. > > > I'm writing the new changelog generation code [1][2], and I'm > > wondering if we can clean up the mess that we have in profiles/. > > > The existing Portage egencache --update-changelogs command does NOT > > generate any ChangeLogs for profiles/ (or eclasses, licenses, > > scripts, metadata, toplevel skel.*). > > I'd say keep it simple: > - one ChangeLog for each package dir, > - one ChangeLog for each first-level subdir other than categories > (i.e. eclass, licenses, profiles, etc.), > - no ChangeLog for category dirs (they contain only a single > metadata.xml), > - top-level ChangeLog for anything not covered by the other > ChangeLogs. > > Ulrich +1, keep it simple -- Brian Dolbec pgpY7ZcxtzCHE.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH] distutils-r1.eclass, drop unused egg-base settings
While working on the last 2 version bumps to the twisted package, I
kept getting an error in which the *egg-info/SOURCES.txt file absolute
paths for all the files found in that very same directory. They are
required to be relative paths only. This problem currently only affects
some pkgs depending on the setuptools pkg for install. The source of
the change is that setuptools patches the cpython findall() with one
that returns relative paths for anything in/below the passed in base
directory. Everything else it returns the absolute path.
Why we should apply this:
Python upstream has merged the setuptools findall() code and will be
included in the next releases of python, 2.7.13, 3.4.6, 3.5.4 (I
think). So, there is potential for many more python pkgs to be
affected by this that are not requiring setuptools for install.
Without the ebb-base setting, the egg-info/* files are not included
in SOURCES.txt. The install proceeds without error.
NOTE: This first affects the python_compile_all phase, long before
it even tries to run the tests (if enabled).
Some history:
The egg-base settings were originally added for parallel
testing/install purposes. They are not used due to problems in
parallelizing testing, etc.. (something along those lines, I
don't want to search thru the logs, and mails to see what Michal's
original words were about it.)
I am working on twisted-16.5.0 and 16.6.0 releases (tests are still
failing), but 16.6.0 has many improvements to the testing code, so has a
lot fewer errors to fix. Once these are fixed and the eclass changes
are merged, I will be able to add it to the tree.
See attached patch. NOTE: actual commit message will be
different/updated correctly. This was just an interim patch for
testing and initial review.
--
Brian Dolbec
From 95ae3bf2c330ca3c527a6350829e3b6fc7fb9dc8 Mon Sep 17 00:00:00 2001
From: Brian Dolbec
Date: Fri, 25 Nov 2016 11:48:09 -0800
Subject: [PATCH] nuke setting egg info path
---
eclass/distutils-r1.eclass | 5 -
1 file changed, 5 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 2db3be8..68151af 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -288,8 +288,6 @@ distutils_install_for_testing() {
PYTHONPATH=${libdir}:${PYTHONPATH}
local add_args=(
- egg_info
- --egg-base="${libdir}"
install
--home="${TEST_DIR}"
--install-lib="${libdir}"
@@ -394,9 +392,6 @@ _distutils-r1_create_setup_cfg() {
# make the ebuild writer lives easier
build-scripts = %(build-base)s/scripts
- [egg_info]
- egg-base = ${BUILD_DIR}
-
# this is needed by distutils_install_for_testing since
# setuptools like to create .egg files for install --home.
[bdist_egg]
--
2.9.3
Re: [gentoo-dev] [PATCH] distutils-r1.eclass, drop unused egg-base settings
On Tue, 29 Nov 2016 19:13:19 -0500 Mike Gilbert wrote: > On Tue, Nov 29, 2016 at 6:57 PM, Brian Dolbec > wrote: > > > > While working on the last 2 version bumps to the twisted package, I > > kept getting an error in which the *egg-info/SOURCES.txt file > > absolute paths for all the files found in that very same > > directory. They are required to be relative paths only. This > > problem currently only affects some pkgs depending on the > > setuptools pkg for install. The source of the change is that > > setuptools patches the cpython findall() with one that returns > > relative paths for anything in/below the passed in base directory. > > Everything else it returns the absolute path. > > > > Why we should apply this: > > > >Python upstream has merged the setuptools findall() code and > > will be included in the next releases of python, 2.7.13, 3.4.6, > > 3.5.4 (I think). So, there is potential for many more python pkgs > > to be affected by this that are not requiring setuptools for > > install. Without the ebb-base setting, the egg-info/* files are not > > included in SOURCES.txt. The install proceeds without error. > > > >NOTE: This first affects the python_compile_all phase, long > > before it even tries to run the tests (if enabled). > > > > > > Some history: > > > >The egg-base settings were originally added for parallel > >testing/install purposes. They are not used due to problems in > >parallelizing testing, etc.. (something along those lines, I > >don't want to search thru the logs, and mails to see what > > Michal's original words were about it.) > > > > I am working on twisted-16.5.0 and 16.6.0 releases (tests are still > > failing), but 16.6.0 has many improvements to the testing code, so > > has a lot fewer errors to fix. Once these are fixed and the eclass > > changes are merged, I will be able to add it to the tree. > > > > See attached patch. NOTE: actual commit message will be > > different/updated correctly. This was just an interim patch for > > testing and initial review. > > > > Seems ok to me. Hopefully it doesn't break something in a subtle, hard > to detect way. ;-) > I agree, but with 1600+ dev-python/*.* ebuilds, it would take one hell of a tinderbox run to check for definite breakage. Subtle runtime breakage is quite another. -- Brian Dolbec
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:02:48 -0500 Mike Gilbert wrote: > The devmanual states: > > The name section should contain only lowercase non-accented letters, > the digits 0-9, hyphens, underscores and plus characters. Uppercase > characters are strongly discouraged, but technically valid. > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > > > Why are uppercase characters strongly discouraged? > > Wouldn't it make sense to follow upstream's naming convention? > I think so. In at least one of the pkgs I created, I used mixed case to prevent conflicts with other existing projects that google, pypi, etc. searching returned results for. But still have the name represent what it did. -- Brian Dolbec
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:38:19 -0600 William Hubbs wrote: > On Fri, Dec 02, 2016 at 07:47:01PM +0100, Michał Górny wrote: > > On Fri, 2 Dec 2016 13:02:48 -0500 > > Mike Gilbert wrote: > > > > > The devmanual states: > > > > > > The name section should contain only lowercase non-accented > > > letters, the digits 0-9, hyphens, underscores and plus > > > characters. Uppercase characters are strongly discouraged, but > > > technically valid. > > > > > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > > > > > > > > > Why are uppercase characters strongly discouraged? > > > > > > Wouldn't it make sense to follow upstream's naming convention? > > > > I'd say keeping things lowercase makes sense for end user packages. > > For pure dependencies with consistent conventions (e.g. perl), it > > makes sense to keep upstream's naming. > > I'm not advocating renaming this, but I found an example of this when > looking to package something: > > dev-python/configargparse is called ConfigArgParse upstream. > If we had named it dev-python/ConfigArgParse, we wouldn't need to set > MY_PN, MY_P or S in our ebuild, and I wouldn't have had to check the > package to see if it was the same as the package I need to depend on. > > William > It gets worse than that. I recently added several pkg to the tree that had slightly different names for the github repo than they publishedin pypi. I in turn ended up naming it slightly different to fit our category/pkg system. So, the end result is not one common name, but three. For some, I tried to stick with the github repo name, despite getting the tarball from pypi due to the inconsistent github sha's. -- Brian Dolbec pgpCuU6XZuV45.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
On Sat, 03 Dec 2016 12:08:44 -0500 "William L. Thomson Jr." wrote: > On Saturday, December 3, 2016 5:58:29 PM EST Tobias Klausmann wrote: > > Hi! > > > > On Sat, 03 Dec 2016, William L. Thomson Jr. wrote: > > > Google has hired a few core developers as has Gaikai. Both seem > > > to be good, though not sure Google is giving back as much given > > > their financial benefit. Gaikai isn't selling an OS, but Google > > > is based on Gentoo... > > > > That last bit is not true. While yes, Chrome OS and Core OS had a > > Gentoo base, a lot was done of top of that. > > I realize I left out ChromeOS in the previous comment, last bit. I > was not meaning to imply Google ran on Gentoo, just ChromeOS was > based on it. > > Thanks for some insight into Google though! > I think you will find that ChromeOS is not really based on Gentoo, but built using Gentoo as the base os it IS built from. It is still Linux based, but ChromeOS doe not use ebuilds and such for normal operations. But the binary pkgs that build it are custom built using Gentoo's ebuild system and modified package management systems. The final resulting OS has it's own methods of updating itself and installing the binaries. (At least that is the way it was some years ago, last I had looked) -- Brian Dolbec pgpxLUP0qbKGd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass
On Sat, 03 Dec 2016 16:49:19 -0500 "William L. Thomson Jr." wrote: > On Saturday, December 3, 2016 11:27:20 AM EST Brian Dolbec wrote: > > > > I think you will find that ChromeOS is not really based on Gentoo, > > but built using Gentoo as the base os it IS built from. It is > > still Linux based, but ChromeOS doe not use ebuilds and such for > > normal operations. But the binary pkgs that build it are custom > > built using Gentoo's ebuild system and modified package management > > systems. > > All that sounds like it is based on Gentoo. Its packages before they > turn them into binaries are ebuilds. > > > The > > final resulting OS has it's own methods of updating itself and > > installing the binaries. (At least that is the way it was some > > years ago, last I had looked) > > Yes, but if you want to modify any binaries etc, you are back to > ebuilds. If you want to add a new package not available its the same > thing. They use overlay concepts etc. > > I do get ChromeOS is very different, kinda like Android, you must > flash images you build. No installing it in the normal sense. > > No matter what terms you use, Google uses Gentoo to build products it > makes money off. In that sense I think it could give back allot. If > not in donations, resources (tinderbox), etc. > Well, It does give back some. I know there are times patches are pushed to gentoo from them. Plus we get financial support from them via the Google Summer Of Code. It has been pointed out recently that the majority of our available funds have come from the GSOC. Not only that, but it also helps us get new developers to work with and further Gentoo projects. -- Brian Dolbec pgppzGjJj1BIz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
earched
> and contacted before Gentoo's.
>
> By replacing references to 'bugs.gentoo.org' passed to ./configure
> with ``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
> reduction in wasted effort handling inappropriately filed bugs when
> the issues are caused by changes by the forks and derivatives.
>
>
> Roadmap
> - ---
>
> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change. As
> forks, derivatives, and other organisations change the environment
> variables in their profiles or ``make.conf`` files, all updated
> ebuilds will immediately reflect the changes.
>
> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.
>
>
> Suggested Wording
> - -
>
> Attached is a patch for pms.git with suggested wording for the two
> variables mentioned above.
>
> - --
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> http://adelielinux.org
oooh, I like it :)
- --
Brian Dolbec
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQJ8BAEBCgBmBQJYRM8DXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YBygP/2nQpokQuH00x8AfYO10lT11
XfVQuDEcDwsq2dtai1w7Q19nSdlQU1Re6HR8CV76aZcohis0dJOBV0gbF/vdU+oH
tbw7MBjXJDRELKs1+imxbpLvFmMjeTlRE/rm0qtjafmSq1ZfHZlqzA+pDjInTGvX
fcH57ee39PPK+j3zOU2ZRfnv/OhiFg30YRDPQ88YS9uaVng7TJGxLgAjLVI2TICq
1dyiSCDzRNDmYBxZxgbw/FOE5gk3nqKHOQ6mBhbfeXHYuZPNEAO3/lBErWqB51R9
S20HP9J1gXzD7JeQcumrmoF5rxoJ4XyjtQti75HnEY338V08DlSzPqTbFZB+yL1l
irG6BU/CAJKlN6Kj8uoTKc8vv+wLIGFW2ecaoBJO59t8FdW6fk86M76bGlC72Ghv
+b7hZUA9z3V40cwUBJ2CeZwo3xxk7eQqmhAsuq+SiYs4kpeOShGSjf9be4IX787J
8NDhuzxJAiSbZdfIkqVwG1gsXjcGMxemp2/8cghN86S+ESHGNEGG5Q/VMaRBcNnt
l+ciFVPFHZ8pVbJ+zjKfS+x4j38NXfCY1NDnG3VNu+/uSyznWFCkZExfwSWflB1R
+j6I5ulxnbHCr+HWjIgW0gl3eCDXO5ESOlfTs3gXvYEbteb0pAtVJQGPNi3JB856
Cy7Y++qf+4xrlAWAZ5cA
=C/+p
-END PGP SIGNATURE-
Re: [gentoo-dev] Signature found, but from unknown key (see push-cert)
On Sun, 1 Jan 2017 16:31:27 +0300
Andrew Savchenko wrote:
> Hi,
>
> On Sun, 1 Jan 2017 18:12:23 +0700 (+07) gro...@gentoo.org wrote:
> > Happy new year to *,
> >
> > Yesterday I've changed expiration dates of my gpg key and its
> > subkeys. And today I cannot push to Gentoo repo:
> >
> > remote: Signature found, but from unknown key (see push-cert)
> > remote: Your push was not signed with a known key.
> > remote: You MUST use git push --signed with a known key.
> > remote: If you just updated your key, please wait 15 minutes for
> > sync. remote: git-receive-pack variables:
> > remote: GIT_PUSH_CERT='ef16430106a13fa3758d2211100be5b9f2bd88d8'
> > remote: GIT_PUSH_CERT_KEY=''
> > remote: GIT_PUSH_CERT_NONCE='1483268914-e0cd9c07e06304c00a64'
> > remote: GIT_PUSH_CERT_NONCE_SLOP=''
> > remote: GIT_PUSH_CERT_NONCE_STATUS='OK'
> > remote: GIT_PUSH_CERT_SIGNER=''
> > remote: GIT_PUSH_CERT_STATUS='N'
> > remote: A push-cert was found, and follows:
> > remote: =
> > remote: certificate version 0.1
> > remote: pusher 0x3AFFCE974D34BD8C 1483268914 +0700
>
> Looks like git hook is still using your old key. You should wait
> for a day or so in order for your change to propagate through
> servers. It this doesn't help, you should probably contact infra to
> update your key.
>
> Best regards,
> Andrew Savchenko
No, infra has it refreshing keys several times an hour.
I just dig another gkeys run and refreshed the keys from the servers.
You did not reset the expiry on your signing subkey. See the following
reports which show the details. After you reset it and gpg --send-key
it to the keyservers again. It can take a few hours for it to
propagate and to be able to push to the gentoo repo again.
===
dolsen@vulture /var/lib/gkeys $
python3.4 /var/lib/gkeys/gentoo-keys/gkeys/bin/gkeys
-c /var/lib/gkeys/gkeys.conf list-key -C gentoo-devs -n grozin
Nick.: grozin
Name.: Andrey Grozin
Keydir...: grozin
Gpg info.: /var/lib/gkeys/keyrings/gentoo-devs/grozin/pubring.gpg
--
pub rsa4096/53D4ABFA88DD61C4 2013-02-26 [SC] [expires:
2017-12-24] Key fingerprint = 6FCC 83E2 6D94 FB05 4B76 1016 53D4 ABFA
88DD 61C4 uid [ unknown] Andrey Grozin (science)
sub rsa4096/34966948B00C83E6 2013-02-26 [E]
[expires: 2017-12-24]
Gkey task results:
Done.
dolsen@vulture /var/lib/gkeys $
python3.4 /var/lib/gkeys/gentoo-keys/gkeys/bin/gkeys
-c /var/lib/gkeys/gkeys.conf spec-check -C gentoo-devs -n grozin
Checking keys...
grozin, Andrey Grozin: 0x53D4ABFA88DD61C4
==
--
Fingerprint..: 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Key type : PUBCapabilities.: scESC
Algorithm: Pass Bit Length...: Pass
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: -, Unknown
Days till expiry.: 356
Capability...: Pass
Qualified ID.: Pass
This primary key.: Pass
--
Fingerprint..: 902F154026C4AD5055486D0234966948B00C83E6
Key type : SUBCapabilities.: e encrypt
Algorithm: Bit Length...:
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: -, Unknown
Days till expiry.: 356
Capability...: Pass
Qualified ID.: Pass
This subkey..: Pass
--
Fingerprint..: 08C4EDF669C5A630FE7DEB943AFFCE974D34BD8C
Key type : SUBCapabilities.: s
Algorithm: Pass Bit Length...: Pass
Create Date..: Pass Expire Date..: Pass
Key Version..: Pass Validity.: e, Expired
Days till expiry.: 0
Capability...: Pass
Qualified ID.: Pass
This subkey..: Fail
Key summary
primary..: Pass signing subkey: Fail
encryption subkey: Yes authentication subkey: No
SPEC requirements: Fail
No signing capable subkey:
Andrey Grozin : 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Failed to pass SPEC requirements:
Andrey Grozin : 6FCC83E26D94FB054B76101653D4ABFA88DD61C4
Gkey task results:
Found Failures:
---
Revoked: 0
Invalid: 0
No Signing subkey..: 1
No Encryption subkey...: 0
Algorithm..: 0
Bit length.....: 0
Qualified IDs..: 0
Expiry.: 0
Expiry Warnings: 0
SPEC requirements..: 1
=
SPEC Approved..: 0
dolsen@vulture /var/lib/gkeys $
--
Brian Dolbec
pgpiNpf50PLG8.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] New Project: Gentoostats
On Thu, 5 Jan 2017 22:06:23 -0800 Daniel Campbell wrote: > Still, interesting project and I might run it on a machine if it can > help us out. > What do you mean "if"... You __WILL__ run it!! ;) -- Brian Dolbec pgpVwdxfQbgPH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating repoman
On Thu, 10 Mar 2022 12:07:40 -0600 William Hubbs wrote: > On Thu, Mar 10, 2022 at 09:29:59AM -0800, Matt Turner wrote: > > On Wed, Mar 9, 2022 at 11:09 PM Joonas Niilola > > wrote: > > > > > > On 9.3.2022 23.00, Matt Turner wrote: > > > > I'd like to deprecate and ultimately remove repoman. I believe > > > > that dev-util/pkgcheck and pkgcommit (from > > > > app-portage/mgorny-dev-scripts) are far superior replacements, > > > > and it makes sense to have people using the same tool and > > > > seeing the same warnings as in the CI. > > > > > > > > Are there any useful checks or behaviors of repoman that are > > > > missing from pkgcheck and pkgcommit? > > > > > > > > Thanks, > > > > Matt > > > > > > > > > > I still fail to see the "why" in here. Repoman is better than > > > pure 'git commit' that I know some people still like to use, and > > > as long as it's kept maintained. > > > > repoman is inferior to other tooling mentioned. The other tooling is > > actually run in CI. Developers should get the same warnings locally > > as in CI. Restated another way: I'm tired of telling people to stop > > using repoman or "pkgcheck would have caught that". > > I am going to nit-pick here, but pkgcheck pulls in pkgcore still. As > far asI know, pkgcore was meant to be a portage-like package manager, > but it isn't maintained. So, can we break that dependency before we > make pkgcheck the official tool for qa checks? I would rather not have > pkgcore landing on everyone's systems unless it is usable. If I am > wrong about pkgcore, please correct me and I'll be quiet, but if not > let's make pkgcheck independent from it before we deprecate repoman. > > Thanks, > > William William. pkgcheck uses pkgcore base code as it's library for accessing and evaluating repositories and ebuilds just like repoman uses portage api's to do the same. This is why pkgcheck is primarily faster than repoman. pkgcore was a re-design from the ground up of how to handle repositories and ebuilds within them, with efficiency and speed in mind. Unfortunately, pkgcore never gained enough developer support to to keep up with EAPI changes and the miriad of portage options that kept expanding. So pkgcore never ended up replacing portage as our main package manager. This is one reason why Brian eventually gave up on it and subsequently left gentoo. While I put a lot of effort into the re-write of repoman so that the code is maintainable, more easily extendable. It will never be as fast as pkgcheck due to the legacy portage code it is based on. Yes, repoman could be updated to do more checks and catch everything that pkgcheck does. It can be made to do many of the checks in parrallel, but it will never be as efficient as pkgcheck due to the underlying portage code it uses. I largely stopped working on repoman/gentoo due to the near constant bitching about nearly everything I did from another (ahem) gentoo developer which shall remain un-named. My only concern about the possible deprecation of repoman, is the fact that is is based on the current official and primary package manager code used in gentoo. While pkgcheck is not. For that reason, changes made to the core code is mostly automatically carried over to repoman without need to change repoman as well. Ideally, development should be moved to pkgcore and portage be put into maintenance mode only. With pkgcore taking over as the primary package manager for gentoo. But Zac is just too damn efficient at updating/fixing portage bugs! As well as adding features and options... (too damn many to remember half of them now)
Re: [gentoo-dev] Deprecating repoman
On Fri, 11 Mar 2022 10:25:19 -0800 Alec Warner wrote: > On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge wrote: > > > > Matt Turner wrote: > > > repoman is inferior to other tooling mentioned. The other tooling > > > is actually run in CI. > > > > The problem seems to be that CI is running something other than > > developers run, not the other way around. > > > > > > > Developers should get the same warnings locally as in CI. > > > > I agree. And developers and their tools should not have to bend to > > whatever CI does, I think the other way around makes more sense. > > > > > > CI doesn't use repoman because of performance issues. > > I think the problem is that making committers use the CI tool is > technically a fairly straightforward change; while everything you > discuss further in the thread is not; because it implies people will > work on improving tools that have shown little or no progress on > improving in the 15 years I've been in Gentoo. > Somewhat incorrect here. I did the majority of the re-write to make the code maintainable, extensible not that long ago. It even has the ability to be repository configurable and include the ability for custom repository plugin checks to be added and run. The CI system was being developed at the same time using pkgcheck. See my other reply to WilliamH for more detail about that and fundamental speed differences. > > > > What if pkgcore evolves to provide a portage-compatible API? > > No API is planned and no one is working on it. > I and a few others did some work to ensure pkgcore had some usable api's from early in it's development. But pkgcore is so different from portage code, it was difficult for early to mediocre python devs to wrap their head around. There was even work to make porthole be able to use pkgcore as it's backend package manager, but it was never fully utilized due to more work needed on pkgcore for some functionality. > > > > Then CI could use repoman without performance problems, and > > developers would also enjoy improved performance, without spending > > time on replacing tooling which already works for them. > No, pkgcore and it's QA tool pkgcheck are designed to work together. Repoman is designed to work with portage base code. Checks can be designed to work on either, but not both. The missing checks that the CI does can be added to repoman, but the primary dev(s) creating them on the CI don't recreate them for repoman. They want to work on pkgcheck. Repoman code will NEVER be as fast as pkgcheck due to the legacy portage code structure it relies on. Pkgcore was a re-design from the ground up to to improve upon the shortcomings of the original portage structure. This resulted in vast speed improvements and reduction in lines of code to do the same functionality. Portage (due to Zac) has made vast improvements in structure, but still requires a ton more changes to get to where it should be. > The benefit of getting people to change their behavior is that the > benefits (less breakage, better tooling) are achieved now; as opposed > to in some hypothetical future where repoman is improved. > Note that we have been waiting for 'improved repoman' for about 8 > years; so..I'm not willing to bet on it when we have better tooling > that works today and the primary complaint is that...what exactly? > > The new workflow with pkgcheck was announced at the end of 2019: > https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck > > It's been 2 years, I think we can bring everyone into the fold here. > > > > > Looking into the future then maybe portage could even come to use > > pkgcore for the low-level things that pkgcore does, then even users > > could enjoy improved performance. > > Many things could happen but again, if you talk to people who work on > pkgcore; there is no concrete plan for this. So I don't see why we are > betting on it happening. > > If you read radhermit's blog: > https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one > take on the project and why it struggled. > > -A > > > > > > > Right? > > > > //Peter > > >
[gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
Starting from a question by Markos in #gentoo-portage about whether to remove entries in profiles/updates for tree-cleaned packages... I propose that we say, once a year, schedule a tree-cleaning of old updates files. These updates files could be added to a tarball made available for download. That way if they are needed to update a system older than what the main tree has been tree-cleaned to. They can then be manually downloaded, extracted to the normal location and then run the "fixpackages" command. The main question here is what is a reasonable length of time to keep the updates actively in-tree? -- From my experience in the forums, I think any updates older than 4 years should be subject to tree-cleaning. -- Most old systems that have been updated tend to be less than that, probably about 2 years. This should allow a reasonable amount of time for a user to update an old system. Thoughts? -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Sun, 2012-12-09 at 15:10 -0800, "Paweł Hajdan, Jr." wrote: > On 12/9/12 1:17 PM, Brian Dolbec wrote: > > Starting from a question by Markos in #gentoo-portage about whether to > > remove entries in profiles/updates for tree-cleaned packages... > > What's the advantage of doing that? None, it actually could make it more difficult for a user to know why his old installed pkg isn't available. It was just what started the discussion about cleaning the old updates. Zac suggested this thread for opinions... ... [12:46] dol-sen: you should take a poll on the gentoo-dev ml to see how long people think we should keep them ... [12:47] yeah, seems like it's good to end-of-life them at some point > > > I propose that we say, once a year, schedule a tree-cleaning of old > > updates files. These updates files could be added to a tarball made > > available for download. That way if they are needed to update a system > > older than what the main tree has been tree-cleaned to. They can then be > > manually downloaded, extracted to the normal location and then run the > > "fixpackages" command. > > I think that complicates the process. :-/ But maybe the advantages > outweigh that. > It does make updating an ancient system slightly more difficult. But that would be the least of the user's troubles compared to some of the pkg updates, tinderbox downloads and manual unpacks that have been needed to be done. But on the other hand how long should we keep that stale info in the tree? See below :) > > The main question here is what is a reasonable length of time to keep > > the updates actively in-tree? > > > > -- From my experience in the forums, I think any updates older than > > 4 years should be subject to tree-cleaning. > > Yeah, 4 years is ancient and would probably be non-trivial to update anyway. yup, they are > > > -- Most old systems that have been updated tend to be less than that, > > probably about 2 years. > > 2 years seem reasonable. > That works too. FYI... Currently there are updates files in profiles/updates/ dating back to 2004 -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Mon, 2012-12-10 at 01:52 +0100, Peter Stuge wrote: > Brian Dolbec wrote: > > > > remove entries in profiles/updates for tree-cleaned packages... > > > > > > What's the advantage of doing that? > > > > None > .. > > FYI... Currently there are updates files in profiles/updates/ > > dating back to 2004 > > Do they take up significant storage space or transfer time, compared > to the rest of the tree? > > If not, I can't think of a reason to remove them. > > > //Peter No, once they are downloaded, they don't change ever after the quarterly rollover which starts a new updates file. Nor do they take up significant storage space. They probably take up a higher percentage of your fs's inodes than % diskspace. But they do take time to process and verify every time emerge initiates a fixpackages call after every sync. That will save time more than it will space. Also, (taking it a bit to extremes ;) ) why would a new user with a 2 month old system and up-to-date tree want 8 year old update cruft lingering about their filesystem...taking time to check they've been processed? Do you? Let's just do an annual tree-cleaning and be done with them. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On Sun, 2012-12-16 at 19:10 -0500, Michael Orlitzky wrote: > On 12/16/12 14:04, Markos Chandras wrote: ... > This guy posted a graph the other day: > > http://hwoarang.silverarrow.org/wp-content/uploads/recruitment_stats.png > HA, HA, that's a good one... quote the the above link to the guy that created and posted it in the first place :D > People aren't bothering. It's not because of any fundamental problem -- > it's because the process is obscure and potentially a waste of time. > > > > > >> > >> 3. Get off CVS for Christ's sake. Nobody wants to work with that. I > >> don't know how this fits into my bullet list, but it's important. > >> > > I believe this is Irrelevant > > > > It's the least important of the three probably. The (lack of) > recruitment process is the biggest problem. > > The git migration is making progress. It is nearly there. From what I know, there are a few things holding it up right now... 1) one of the main dev's working on it has had a computer failure and busy work schedule. 2) waiting for me to code the new gentoo-keys project which will manage the gpg keyrings needed and some code for the git commit validation hooks which which check every commit pushed to the main tree. I'm working on it :) but I also have to work to feed my family, etc.. 3) with the above done and ready. a final schedule to perform the migration with a minimum of disruption. So, not only is the tree moving to git, it's getting some needed upgrades in the process. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving our/portage stuff to var
On Mon, 2012-12-17 at 11:23 +0100, Diego Elio Pettenò wrote: > On 17/12/2012 11:19, Tomáš Chvátal wrote: > > > > I've always myself override these defaults in make.conf to point for > > /var/portage/ (not /var/lib because I never bothered enough how to > > make world and config files to be put elsewhere :P). > > I would say let's work on that so that portage can keep them there. > Although I'm more for /var/cache/portage myself, as both distfiles and > tree can be re-generated. > I've been pushing for the portage tree to move somewhere in /var for awhile. Also I think the tree and layman overlays should be under the same master directory, then portage, pkgcore,... could just quickly scan the master directory & sub directories to auto-add the valid overlays there. No need to add them to PORTDIR_OVERLAY something like /var/cache/repositories/ /var/cache/repositories/gentoo /var/cache/repositories/x11<== overlay /var/cache/repositories/local<== overlay /var/cache/repositories/distfiles<== move it out of the tree dir. /var/cache/repositories/packages<== move it out of the tree dir. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
