Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Patrick Lauer]

On 05/05/2016 01:12 AM, William Hubbs wrote:
> On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote:
>> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
>>> On 05/04/2016 10:52 AM, Sam Jorna wrote:
 On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
>> On Wed, 4 May 2016, Austin English wrote:
>>> Your list of affected packages obtained with "git grep" in the
>>> Portage tree will not be complete, since the command won't catch
>>> any init scripts installed from elsewhere. You should look for the
>>> set of installed files instead.
>> How is that relevant here at all? I'm cleaning up portage installed
>> init scripts, [...]
> You are cleaning up only those init scripts that are installed from
> FILESDIR, but you will miss the ones that are installed from a file
> in SRC_URI.
 Perhaps an alternate way to do it would be to have a QA check look at
 any files installed to ${D}etc/init.d/ and throw a warning if their
 shebang is "#!/sbin/runscript"

>>> A repoman check is a much saner approach, I'm not convinced there is
>>> sufficient need for this change to begin with, in particular to start
>>> touching a wide range of packages. Breaking backwards compatibility in
>>> any way should have a darn good reason, and I haven't seen one yet
>> I'm not arguing for or against it in general, just in terms of technical
>> implementation.
>>
>> That being said, a repoman check would only catch those distributed in
>> ${FILESDIR} as well. My thinking with the above was to also identify
>> those installed from distfiles to be handled accordingly.
> Actually, you won't need to worry about any qa checks in portage,
> because I am going to put a deprecation warning in OpenRC upstream which
> will be displayed when a service script invokes runscript instructing
> you to convert to openrc-run.
>
> OpenRC will keep runscript, with this warning, for a while.
>
>
So again, because I feel like either I'm too stupid to understand this,
or too smart to let such an obviously bad idea continue:

What problem is being solved here?

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[William Hubbs]

On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote:
> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
> > On 05/04/2016 10:52 AM, Sam Jorna wrote:
> > > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
> > >>> On Wed, 4 May 2016, Austin English wrote:
> > >>
> >  Your list of affected packages obtained with "git grep" in the
> >  Portage tree will not be complete, since the command won't catch
> >  any init scripts installed from elsewhere. You should look for the
> >  set of installed files instead.
> > >>
> > >>> How is that relevant here at all? I'm cleaning up portage installed
> > >>> init scripts, [...]
> > >>
> > >> You are cleaning up only those init scripts that are installed from
> > >> FILESDIR, but you will miss the ones that are installed from a file
> > >> in SRC_URI.
> > > 
> > > Perhaps an alternate way to do it would be to have a QA check look at
> > > any files installed to ${D}etc/init.d/ and throw a warning if their
> > > shebang is "#!/sbin/runscript"
> > > 
> > 
> > A repoman check is a much saner approach, I'm not convinced there is
> > sufficient need for this change to begin with, in particular to start
> > touching a wide range of packages. Breaking backwards compatibility in
> > any way should have a darn good reason, and I haven't seen one yet
> 
> I'm not arguing for or against it in general, just in terms of technical
> implementation.
> 
> That being said, a repoman check would only catch those distributed in
> ${FILESDIR} as well. My thinking with the above was to also identify
> those installed from distfiles to be handled accordingly.

Actually, you won't need to worry about any qa checks in portage,
because I am going to put a deprecation warning in OpenRC upstream which
will be displayed when a service script invokes runscript instructing
you to convert to openrc-run.

OpenRC will keep runscript, with this warning, for a while.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Re : Cannot see my eclass modifications

[Farid BENAMROUCHE]

ok, thank you.I will try the chroot stuff as soon as I have some time.

As for what I'm trying to do: making portage able to add user/groups when using 
--root option.
This is a known limitation since a long time. I'm currently also discussing 
this point with the "shadow" upstream team (I have some patches for useradd and 
groupadd)

So for now I'm trying to make portage to just echo some traces when calling 
enewgroup for example, when I emerge sys-power/nut as a test package (that 
package is creating a nut user and group)
I tried to put some einfo at the begining of the  enewgroup function, but I do 
not see them. I also tryed echo "test" > /tmp/test.txt, and I do no see the 
file too...

And I see the traces from the nut ebuild (package_setup if I remember 
properly). And if I remove the nut group from my /etc/group, I do see the 
enewgroup original traces, but not mine.
It's as if portage is using a different enewgroup function, or a cached one...

I tried the irc last time, but nobody was there (most likely because of the 
time. I will try tomorrow late afternoon)


En date de : Mer 4.5.16, Ian Stakenvicius  a écrit :

 Objet: Re: [gentoo-dev] Re : Cannot see my eclass modifications
 À: gentoo-dev@lists.gentoo.org
 Date: Mercredi 4 mai 2016, 20h28
 
 On 04/05/16 02:30 PM,
 Farid BENAMROUCHE wrote:
 > hum... yes I've
 setup all the relevant settings in my /etc/portage...
 > I've also read the man, and still not
 understanding why.
 > 
 > But At least you are confirming me that
 directly modifying the user.eclass in /usr/portage/eclass
 should work!
 > 
 > The
 exact command line I've used was ROOT=/sysroot emerge
 -av sys-power/nut, where sysroot is a working x86 rootfs
 (ie, I can chroot in it) with no portage inside...
 > 
 >
 PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf
 seems to not work too...
 
 
 ..ok so if you've got a
 full chroot, you might want to use 'emerge
 --config-root=/path/to/chroot [stuff]' and
 make sure that the
 /etc/portage/repos.conf
 changes you made are in the chroot too.
 
 Barring that, though, the issue may very well
 be the type of changes
 you're trying to
 make to user.eclass just not working (or being
 called) as expected.
 
 A bunch of us hang out on irc.freenode.org in
 #gentoo-dev-help , and
 stuff like this may
 be easier to help with in a more interactive
 environment like that.
 

Re: [gentoo-dev] Reminder: ALLARCHES

[waltdnes]

On Wed, May 04, 2016 at 04:05:50PM -0400, Ian Stakenvicius wrote
> On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote:
> > 
> > emerge --keyword-write
> > 
> > ... similar to "emerge --autounmask-write", but have it write to
> > package.accept_keywords, rather than package.unmask?
> > 
> >   That would achieve the effect that people are looking for, with less
> > work.
> > 
> 
> 
> --autounmask-write modifies package.mask, package.accept_keywords and
> package.use already, FYI -- has done so since its inception so far as
> I'm aware..

  The emerge man page does mention unmasking packages and setting
package.use with --autounmask, but not keywords

--autounmask [ y | n ]
   Automatically unmask packages and generate package.use  settings
   as  necessary to satisfy dependencies.

***BUT***

--autounmask-unrestricted-atoms [ y | n ]
  If --autounmask is enabled, keyword and mask changes using  the
  ´=´  operator  will be written

  This is confusing, to say the least.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Reminder: ALLARCHES

[Ian Stakenvicius]

On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote:
> 
> emerge --keyword-write
> 
> ... similar to "emerge --autounmask-write", but have it write to
> package.accept_keywords, rather than package.unmask?
> 
>   That would achieve the effect that people are looking for, with less
> work.
> 


--autounmask-write modifies package.mask, package.accept_keywords and
package.use already, FYI -- has done so since its inception so far as
I'm aware..







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[waltdnes]

On Tue, May 03, 2016 at 09:46:10PM -0700, Matt Turner wrote
> On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert  wrote:
> > On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers  wrote:
> >> The solution is to have people with an actual interest in a specific
> >> architecture determine whether stabilising a package is viable, and
> >> taking sensible action, like dropping stable keywords where applicable.
> >
> > If these people do not actually exist or are not doing their job by
> > culling the depgraph appropriately, we should really drop a number of
> > archs from "stable" status.
> 
> I mostly agree, modulo the comment about people "doing their jobs".
> Arch testing completely sucks.
> 
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.
> 
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually
> significantly better than the alternative of dropping them to
> unstable.

  Matt points out a problem with the current situation.  There are
basically 2 levels of unstable...

1) Ancient or really new stuff that doesn't compile, let alone run, in
the presence of current libraries.

2) Stuff that actually works, but the devs have not stabilized it yet.

  People who accept unstable ~arch generally want the second group, but
going all out ~arch brings in builds from the first group, which breaks
systems.  The way to get "the best of both worlds" is to start with
stable, and only keyword stuff that you need, which is hopefully in the
second group.  That can get painfull with multiple dependancies,
requiring re-iterative multiple runs and keywording.  Can I make a
suggestion here?  Is it possible for the devs to come up with with...

emerge --keyword-write

... similar to "emerge --autounmask-write", but have it write to
package.accept_keywords, rather than package.unmask?

  That would achieve the effect that people are looking for, with less
work.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re : Cannot see my eclass modifications

[Ian Stakenvicius]

On 04/05/16 02:30 PM, Farid BENAMROUCHE wrote:
> hum... yes I've setup all the relevant settings in my /etc/portage...
> I've also read the man, and still not understanding why.
> 
> But At least you are confirming me that directly modifying the user.eclass in 
> /usr/portage/eclass should work!
> 
> The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, 
> where sysroot is a working x86 rootfs (ie, I can chroot in it) with no 
> portage inside...
> 
> PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too...


..ok so if you've got a full chroot, you might want to use 'emerge
--config-root=/path/to/chroot [stuff]' and make sure that the
/etc/portage/repos.conf changes you made are in the chroot too.

Barring that, though, the issue may very well be the type of changes
you're trying to make to user.eclass just not working (or being
called) as expected.

A bunch of us hang out on irc.freenode.org in #gentoo-dev-help , and
stuff like this may be easier to help with in a more interactive
environment like that.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Cannot see my eclass modifications

[Farid BENAMROUCHE]

hum... yes I've setup all the relevant settings in my /etc/portage...
I've also read the man, and still not understanding why.

But At least you are confirming me that directly modifying the user.eclass in 
/usr/portage/eclass should work!

The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, 
where sysroot is a working x86 rootfs (ie, I can chroot in it) with no portage 
inside...

PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too...


En date de : Mar 3.5.16, Mike Gilbert  a écrit :

 Objet: Re: [gentoo-dev] Re : Cannot see my eclass modifications
 À: "Gentoo Dev" , fariou...@yahoo.fr
 Date: Mardi 3 mai 2016, 23h39
 
 On Tue, May 3, 2016 at
 5:42 PM, Farid BENAMROUCHE 
 wrote:
 > Hi,
 >
 > I'm still searching for the reason why
 I'm not seeing my eclass modifications... no luck so
 far.
 >
 > What can I do
 to debug portage's behavior?
 >
 > Thank you
 >
 >
 
 > En date de : Sam 30.4.16, Farid
 BENAMROUCHE 
 a écrit :
 >
 > 
 Objet: Re : Cannot see my eclass modifications
 >  À: gentoo-dev@lists.gentoo.org
 >  Date: Samedi 30 avril 2016, 20h03
 >
 >  Hi all,
 >
 >   I'm
 currently developping a patch for user.eclass, but
 I'm
 >   banging my head
 against a wall...
 >
 >   So for testing first,
 I've setup an overlay, and I now
 > 
 that
 >   it is taken in
 account by portage (If I rename portage's
 >   user.eclass, emerge is still
 working. If I remove my
 >   overlay, emerge complains
 about missing user eclass. So my
 >   overlay is actually
 working)
 >   I've modified
 enewgroup and egetent for example and put
 >  some
 >   einfo and also modified some
 other stuffs to be sure that
 >   I'm entering the
 function
 >
 >   Then emerge sys-power/nut, I
 can see the pkg-setup traces,
 >   just after the call to
 enewgroup... but still cannot see
 > 
 my
 >   eclass
 modifications!
 >   I tried to
 modify directly the
 >   /usr/portage/eclass/user.eclass
 file, but still the same
 >   issue...
 >   I'm totally puzzled about
 this point! I'm most likely
 >   missing a stupid point
 somewhere...
 >
 >   Anyone knows what could be
 the problem? Please let me know
 >   what traces/info you need and
 I will post them.
 >
 >   Thank you!
 >
 >
 
 Portage will only use eclasses from your
 overlay for ebuilds in your
 overlay, at
 least by default. You can force it to use your overlay by
 setting eclass-overrides in repos.conf.
 
 I have no idea why you would
 experience this problem if you are
 modifying
 /usr/portage/eclass directly.

Re: [gentoo-dev] Reminder: ALLARCHES

[Matt Turner]

On Wed, May 4, 2016 at 8:44 AM, Mike Gilbert  wrote:
> On Wed, May 4, 2016 at 10:41 AM, Peter Stuge  wrote:
>> Mike Gilbert wrote:
>>> "doing your job"
>>
>> Remember that everyone is a volunteer.
>
> I am referring to arch testing as a job, because it only really works
> if people treat it that way. If stabilization does not take place in a
> timely manner, the system falls apart, and you end up with frustrated
> maintainers.
>
> If there aren't people who are putting in that time commitment, the
> arch should not be called "stable".

I think it should be plainly obvious at this point why the bug tracker
is full of unresolved stable requests.

Re: [gentoo-dev] Reminder: ALLARCHES

[Damien LEVAC]

On 05/04/2016 11:41 AM, Ian Stakenvicius wrote:

On 04/05/16 02:01 AM, Kent Fredric wrote:

On 4 May 2016 at 16:46, Matt Turner  wrote:

Having built many stages for an "unstable" arch (mips) has taught me
one thing: it's awful being unstable-only. There's no end to the
compilation failures and other such headaches, none of which have
anything at all to do with the specific architecture.

Short of adding a middle level ("stable, wink wink nudge nudge") where
things at least compile, I think the current situation is actually
significantly better than the alternative of dropping them to
unstable.

I feel like there needs to be something inbetween, a mechanism where
things can be deemed "tentatively stable", where in they can still be
later destabilized if evidence compels it.

As it is, stabilization seems one-directional. If critical defects are
found in "stable" releases, they tend not to escalate in the other
direction.

And I understand why that is, but it doesn't stop me wishing otherwise.

But instead of adding a rung between stable and unstable ... maybe the
right approach is to add a layer /beneath/ stable : "Long term
stable".

Where long-term stable is "Known to be good at a deep and thorough
level by people who use the software regularly".

Long-term stable at this point is not something I'd suggest people set
as their keywords in general, but it would be a thing that would only
be granted to specific packages on a case-by-case basis, and it would
only be encouraged to be used in the sense of
/etc/portage/package.keywords , where mixing long-term stable and
stable would be "supported" ... somehow.

IDK, there's still a lot wrong with my ideas, but hopefully there's
some ball here to run with.




Rather than adding a third layer of stability and splitting the
userbase even further, how about we just be less shy about dropping
stable keywords on packages back to ~arch when we have bugs that can't
be resolved quickly?  I know this isn't ideal given everyone --sync's
at different times and varying intervals, but if a particular ebuild
gets stabilized on an arch and is found to really not be ready at
least there's a recourse to undo the stabilization and stop -some-
users from getting the new version via their -uDN @world updates.

What might we need in terms of better PM support, for stable -> ~arch
keywording?



+1

Nice to know that when there is a bug on stable that a world upgrade 
will fix the issue within a reasonable time frame. Even if it means some 
downgrades.

Re: [gentoo-dev] Reminder: ALLARCHES

[Mike Gilbert]

On Wed, May 4, 2016 at 10:41 AM, Peter Stuge  wrote:
> Mike Gilbert wrote:
>> "doing your job"
>
> Remember that everyone is a volunteer.

I am referring to arch testing as a job, because it only really works
if people treat it that way. If stabilization does not take place in a
timely manner, the system falls apart, and you end up with frustrated
maintainers.

If there aren't people who are putting in that time commitment, the
arch should not be called "stable".

Re: [gentoo-dev] Reminder: ALLARCHES

[Ian Stakenvicius]

On 04/05/16 02:01 AM, Kent Fredric wrote:
> On 4 May 2016 at 16:46, Matt Turner  wrote:
>> Having built many stages for an "unstable" arch (mips) has taught me
>> one thing: it's awful being unstable-only. There's no end to the
>> compilation failures and other such headaches, none of which have
>> anything at all to do with the specific architecture.
>>
>> Short of adding a middle level ("stable, wink wink nudge nudge") where
>> things at least compile, I think the current situation is actually
>> significantly better than the alternative of dropping them to
>> unstable.
> 
> I feel like there needs to be something inbetween, a mechanism where
> things can be deemed "tentatively stable", where in they can still be
> later destabilized if evidence compels it.
> 
> As it is, stabilization seems one-directional. If critical defects are
> found in "stable" releases, they tend not to escalate in the other
> direction.
> 
> And I understand why that is, but it doesn't stop me wishing otherwise.
> 
> But instead of adding a rung between stable and unstable ... maybe the
> right approach is to add a layer /beneath/ stable : "Long term
> stable".
> 
> Where long-term stable is "Known to be good at a deep and thorough
> level by people who use the software regularly".
> 
> Long-term stable at this point is not something I'd suggest people set
> as their keywords in general, but it would be a thing that would only
> be granted to specific packages on a case-by-case basis, and it would
> only be encouraged to be used in the sense of
> /etc/portage/package.keywords , where mixing long-term stable and
> stable would be "supported" ... somehow.
> 
> IDK, there's still a lot wrong with my ideas, but hopefully there's
> some ball here to run with.
> 
> 


Rather than adding a third layer of stability and splitting the
userbase even further, how about we just be less shy about dropping
stable keywords on packages back to ~arch when we have bugs that can't
be resolved quickly?  I know this isn't ideal given everyone --sync's
at different times and varying intervals, but if a particular ebuild
gets stabilized on an arch and is found to really not be ready at
least there's a recourse to undo the stabilization and stop -some-
users from getting the new version via their -uDN @world updates.

What might we need in terms of better PM support, for stable -> ~arch
keywording?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dev retirement - Farewell message

[Ian Bloss]

prends soin de toi

On Tue, May 3, 2016 at 11:43 AM Sven Vermeulen  wrote:

> On Sun, May 01, 2016 at 04:57:09PM +0200, José Fournier wrote:
> > I have been a bit far from Gentoo for a rather long time now. I joined
> > Gentoo in 2013 and I used to be a translator for the French language. At
> > this time, I had to become a developer in order to be able to submit my
> > work in the previous documentation system – but in reality I am not a
> > developer at all.  Nowadays, with the new wiki – which I can see grow
> > and improve day after day – it is no longer necessary for people like me
> > become a developer.
> >
> > At the beginning I could get a friendly and patient help from Sven
> > Vermeulen who introduced me and was my mentor for a while. I am very
> > grateful to him because it is not something obvious for someone who is
> > not a computer scientist to enter a world like the Gentoo Community and
> > Sven contributed a lot to make me feel at home.
> >
> > Recently, I decided to join the Fedora community to help as a translator
> > again. It a very different distribution and community but my previous
> > experience at Gentoo is very valuable. Arriving in this new home, I told
> > them all the good I think of the Gentoo distribution and of its people.
> > If there is one distribution which made me progress substantially in my
> > understanding of the Linux system, it is Gentoo, with no doubt.
> >
> > Before leaving your community, I want to wish you all the best and thank
> > you very much for your constant effort to make free and open source
> > software available to everyone.
> >
>
> Hi José,
>
> Although it's sad to see you leave, I feel it's more like a mutation than a
> farewell. I'm glad you continue to contribute to the open source/free
> software community, and wish you all the best within the Fedora community.
>
> With kind regards,
>
> Sven Vermeulen
> aka SwifT
>
>

Re: [gentoo-dev] Reminder: ALLARCHES

[Peter Stuge]

Mike Gilbert wrote:
> "doing your job"

Remember that everyone is a volunteer.


> dropping stable keywords on everything but the bare necessities

Gentoo magically does a number of things which upstream never
intended and do not intentionally support. It is amazing, and
thank you so much to everyone who makes it possible!

At the same time all the upstream crap is pretty tragic.

I am absolutely in favor of exposing users to it, rather than the
happy Gentoo garden full of magic patches :) and fast-path:ing bugs
upstream when things do not work. In an ideal world, upstream would
care. Of course many don't, and patches may still end up in Gentoo,
but then at least users would know, and might get involved upstream,
where they can actually help improve the package. Gentoo is the wrong
place for that, so it doesn't make sense for them to get involved in
Gentoo.

I think unstable on (most) everything would be a great thing.


Again: Thanks to everyone who contributes to Gentoo! :)


//Peter

Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Manuel Rüger]

On 04.05.2016 11:19, Duncan wrote:
> Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:
> 
>>> On Wed, 4 May 2016, Austin English wrote:
>>
 Your list of affected packages obtained with "git grep" in the Portage
 tree will not be complete, since the command won't catch any init
 scripts installed from elsewhere. You should look for the set of
 installed files instead.
>>
>>> How is that relevant here at all? I'm cleaning up portage installed
>>> init scripts, [...]
>>
>> You are cleaning up only those init scripts that are installed from
>> FILESDIR, but you will miss the ones that are installed from a file in
>> SRC_URI.
> 
> While you are correct, the current problem isn't lack of low hanging 
> fruit to fix in the files dir, as he said there's 700 packages on the 
> list already, too many to file individual bugs for.
> 
> So while it is indeed worthwhile to keep in mind the init-scripts 
> installed from SRC_URI...
> 
> There's seven hundred "miles of open road" to cross before we have to 
> worry about that SRC_URI bridge, so maybe worry about that when we're 
> within 50 or 100, or even a couple hundred, "miles", not 700. =:^]
> 

Hi Austin,

to be honest, I'm not too happy with the fixes you applied.
Although it's just a tiny change, I'd rather have expected a revision
bump to the ebuilds and a revision bump to the init files themselves
than just a in-file rewrite.
Your fix changes the content of files that are installed to ones system.
Such a change usually requires a revbump.


Cheers,

Manuel




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[Mike Gilbert]

On Wed, May 4, 2016 at 12:46 AM, Matt Turner  wrote:
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.
>
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually
> significantly better than the alternative of dropping them to
> unstable.

In that case, "doing your job" would mean dropping stable keywords on
everything but the bare necessities, and refusing to stabilize
packages outside of that group without good cause.

[gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Duncan]

Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:

>> On Wed, 4 May 2016, Austin English wrote:
> 
>>> Your list of affected packages obtained with "git grep" in the Portage
>>> tree will not be complete, since the command won't catch any init
>>> scripts installed from elsewhere. You should look for the set of
>>> installed files instead.
> 
>> How is that relevant here at all? I'm cleaning up portage installed
>> init scripts, [...]
> 
> You are cleaning up only those init scripts that are installed from
> FILESDIR, but you will miss the ones that are installed from a file in
> SRC_URI.

While you are correct, the current problem isn't lack of low hanging 
fruit to fix in the files dir, as he said there's 700 packages on the 
list already, too many to file individual bugs for.

So while it is indeed worthwhile to keep in mind the init-scripts 
installed from SRC_URI...

There's seven hundred "miles of open road" to cross before we have to 
worry about that SRC_URI bridge, so maybe worry about that when we're 
within 50 or 100, or even a couple hundred, "miles", not 700. =:^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Kristian Fiskerstrand]

On 05/04/2016 10:52 AM, Sam Jorna wrote:
> On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
>>> On Wed, 4 May 2016, Austin English wrote:
>>
 Your list of affected packages obtained with "git grep" in the
 Portage tree will not be complete, since the command won't catch
 any init scripts installed from elsewhere. You should look for the
 set of installed files instead.
>>
>>> How is that relevant here at all? I'm cleaning up portage installed
>>> init scripts, [...]
>>
>> You are cleaning up only those init scripts that are installed from
>> FILESDIR, but you will miss the ones that are installed from a file
>> in SRC_URI.
> 
> Perhaps an alternate way to do it would be to have a QA check look at
> any files installed to ${D}etc/init.d/ and throw a warning if their
> shebang is "#!/sbin/runscript"
> 

A repoman check is a much saner approach, I'm not convinced there is
sufficient need for this change to begin with, in particular to start
touching a wide range of packages. Breaking backwards compatibility in
any way should have a darn good reason, and I haven't seen one yet


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[Kristian Fiskerstrand]

On 05/04/2016 06:46 AM, Matt Turner wrote:
> On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert  wrote:
>> On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers  wrote:
>>> The solution is to have people with an actual interest in a specific
>>> architecture determine whether stabilising a package is viable, and
>>> taking sensible action, like dropping stable keywords where applicable.
>>
>> If these people do not actually exist or are not doing their job by
>> culling the depgraph appropriately, we should really drop a number of
>> archs from "stable" status.
> 
> I mostly agree, modulo the comment about people "doing their jobs".
> Arch testing completely sucks.
> 
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.

Thats bad

> 
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually

If it doesn't compile on at least one architecture (the one where the
dev is doing the work) it shouldn't be committed to the tree at all, no
need for a middle layer.

> significantly better than the alternative of dropping them to
> unstable.

In a perfect world compile testing wouldn't be sufficient for stable
either, it actually should be properly tested before releasing it on
users and testsuites are sadly lacking in many situations. Even worse
for GUI applications that can't easily be tested without actual user
interaction, but as long as we keep servers in good shape I'm not
necessarily too worried about those, and it is possibly easier to spot
than a miscalculation in a statistics library

Maybe a workshop to write more testsuites is a fruitful event at some
point in time..

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Ulrich Mueller]

> On Wed, 4 May 2016, Austin English wrote:

>> Your list of affected packages obtained with "git grep" in the
>> Portage tree will not be complete, since the command won't catch
>> any init scripts installed from elsewhere. You should look for the
>> set of installed files instead.

> How is that relevant here at all? I'm cleaning up portage installed
> init scripts, [...]

You are cleaning up only those init scripts that are installed from
FILESDIR, but you will miss the ones that are installed from a file
in SRC_URI.

Ulrich


pgpQUUlZaiquo.pgp
Description: PGP signature

[gentoo-portage-dev] [PATCH] repoman: include HOME in the variable.readonly check

[Göktürk Yüksek]

According to the PMS section 11.1, HOME is a read-only
variable. Include it in the list of read-only variables for the
variable.readonly check in repoman.

Signed-off-by: Göktürk Yüksek 
---
 pym/repoman/modules/scan/ebuild/checks.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pym/repoman/modules/scan/ebuild/checks.py 
b/pym/repoman/modules/scan/ebuild/checks.py
index 8cdc230..5833d42 100644
--- a/pym/repoman/modules/scan/ebuild/checks.py
+++ b/pym/repoman/modules/scan/ebuild/checks.py
@@ -236,7 +236,7 @@ class EbuildAssignment(LineCheck):
"""Ensure ebuilds don't assign to readonly variables."""
 
repoman_check_name = 'variable.readonly'
-   read_only_vars = 
'A|CATEGORY|P|P[VNRF]|PVR|D|WORKDIR|FILESDIR|FEATURES|USE'
+   read_only_vars = 
'A|CATEGORY|P|P[VNRF]|PVR|D|WORKDIR|FILESDIR|FEATURES|USE|HOME'
readonly_assignment = re.compile(r'^\s*(export\s+)?(%s)=' % 
read_only_vars)
 
def check(self, num, line):
-- 
2.7.3

[gentoo-portage-dev] Fw: [PATCH] xml-text/missing-doctype: test for missing DOCTYPE in metadata.xml

[Brian Dolbec]

Begin forwarded message:

Date: Wed, 4 May 2016 00:14:55 -0700
From: Brian Dolbec 
To: Göktürk Yüksek 
Subject: Re: [PATCH] xml-text/missing-doctype: test for missing DOCTYPE
in metadata.xml


On Wed,  4 May 2016 01:57:19 -0400
Göktürk Yüksek  wrote:

> Signed-off-by: Göktürk Yüksek 
> ---
>  xml-test/missing-doctype/metadata.xml   |  5 +
>  xml-test/missing-doctype/missing-doctype-0.1.ebuild | 10 ++
>  2 files changed, 15 insertions(+)
>  create mode 100644 xml-test/missing-doctype/metadata.xml
>  create mode 100644
> xml-test/missing-doctype/missing-doctype-0.1.ebuild
> 
> diff --git a/xml-test/missing-doctype/metadata.xml
> b/xml-test/missing-doctype/metadata.xml new file mode 100644
> index 000..f70816e
> --- /dev/null
> +++ b/xml-test/missing-doctype/metadata.xml
> @@ -0,0 +1,5 @@
> +
> + +  
> +Test for missing DOCTYPE
> +
> diff --git a/xml-test/missing-doctype/missing-doctype-0.1.ebuild
> b/xml-test/missing-doctype/missing-doctype-0.1.ebuild new file mode
> 100644 index 000..eea16bc
> --- /dev/null
> +++ b/xml-test/missing-doctype/missing-doctype-0.1.ebuild
> @@ -0,0 +1,10 @@
> +# Copyright 1999-2016 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=6
> +
> +DESCRIPTION="Metadata with missing DOCTYPE"
> +LICENSE="HPND"
> +SLOT="0"
> +KEYWORDS="~amd64"  

applied, Thank you :)

-- 
Brian Dolbec 



-- 
Brian Dolbec 

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Ulrich Mueller]

> On Tue, 3 May 2016, Austin English wrote:

> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1], by starting on the maintainer-needed
> packages. That's done (aside from some stabilizations needed, but
> I'll deal with that latter). The trouble is that there are roughly
> 700 packages that need to be updated, and that's an insane number of
> bugs to file.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846

Your list of affected packages obtained with "git grep" in the Portage
tree will not be complete, since the command won't catch any init
scripts installed from elsewhere. You should look for the set of
installed files instead.

Also, what problem are you trying to solve? My guess would be that
/sbin/runscript must be kept around indefinitely in any case, in order
not to risk breakage on users' systems.

Ulrich


pgpC1YIuUyeGN.pgp
Description: PGP signature

[gentoo-portage-dev] [PATCH] xml-test/valid: valid metadata.xml test based on the example in GLEP 68

[Göktürk Yüksek]

Signed-off-by: Göktürk Yüksek 
---
 xml-test/valid/metadata.xml | 64 +
 xml-test/valid/valid-0.1.ebuild | 12 
 2 files changed, 76 insertions(+)
 create mode 100644 xml-test/valid/metadata.xml
 create mode 100644 xml-test/valid/valid-0.1.ebuild

diff --git a/xml-test/valid/metadata.xml b/xml-test/valid/metadata.xml
new file mode 100644
index 000..c33f7ac
--- /dev/null
+++ b/xml-test/valid/metadata.xml
@@ -0,0 +1,64 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+
+  
+develo...@example.com
+Example Developer
+  
+  
+proj...@example.com
+Example Project
+  
+  
+upstr...@example.com
+Upstream Developer
+Upstream developer, wishing to be CC-ed on bugs
+  
+  
+First paragraph of extensive description.
+
+Second paragraph.
+  
+  
+Erster Absatz mit detaillierter Beschreibung.
+
+Zweiter Absatz.
+  
+  
+Compatibility slot providing libvalid.so.11 only.
+
+  Match SONAME of libvalid.so.
+
+  
+  
+Kompatibilitäts-Slot, installiert ausschließlich 
libvalid.so.11.
+
+  Subslot ist stets identisch mit dem SONAME von libvalid.so.
+
+  
+  
+Enables foo feature
+Enables bar feature 
(requires xml-test/missing)
+Enables bar 
feature
+  
+  
+Konfiguriert das Paket mit Unterstütztung für foo
+Konfiguriert das Paket 
mit Unterstütztung für bar (benötigt xml-test/missing)
+Konfiguriert das Paket 
mit Unterstütztung für bar
+  
+  
+
+  upstr...@example.com
+  Upstream Developer
+
+
+  John Smith
+
+http://www.example.com/releases.html
+http://www.example.com/doc.html
+http://www.example.com/doc.de.html
+http://www.example.com/issues.html
+gentoo/gen-b0rk
+  
+
diff --git a/xml-test/valid/valid-0.1.ebuild b/xml-test/valid/valid-0.1.ebuild
new file mode 100644
index 000..3b2c1c8
--- /dev/null
+++ b/xml-test/valid/valid-0.1.ebuild
@@ -0,0 +1,12 @@
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+EAPI=6
+
+DESCRIPTION="GLEP68 compliant metadata example"
+HOMEPAGE="https://wiki.gentoo.org/wiki/GLEP:68#Example_metadata.xml_file;
+LICENSE="HPND"
+SLOT="11"
+KEYWORDS="~amd64"
+IUSE="foo bar"
-- 
2.7.3

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Austin English]

On 05/04/2016 01:02 AM, Patrick Lauer wrote:
> On 05/04/2016 06:27 AM, Austin English wrote:
>> Hi there,
>>
>> I've been working on the transition from #!/sbin/runscript to
>> #!/sbin/openrc-run [1],
> ... and once more I have to ask:
>
> Is there any reason that Stuff Needs To Change because of a packaging
> conflict in *debian* where it really doesn't matter at all for us?
>
> I mean, ok, it's your time, do what you want, but I'm still confused
> about the benefits of this change ...

OpenRC isn't exclusive to Gentoo. Why should we use the generic #!bin/sh
when we usually intend #!/bin/bash? Because being explicit is nice
instead of relying on implementation details.

Additionally, you know, it helps the wider open source community. Most
would call that a beneficial thing. You're welcome to your own opinion.

Regardless, if you have a a technical objection rather than an objection
to following upstream's recommendations, I'm listening.
>>  by starting on the maintainer-needed packages.
>> That's done (aside from some stabilizations needed, but I'll deal with that
>> latter). The trouble is that there are roughly 700 packages that need to
>> be updated, and that's an insane number of bugs to file.
>>
>> So, instead, I'm going to give developers to two weeks to update their
>> initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
>> initscripts/copyrights, but will leave revbumping to maintainer's discretion.
>>
>> Thanks,
>> Austin
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846
>>
>>
>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Patrick Lauer]

On 05/04/2016 06:27 AM, Austin English wrote:
> Hi there,
>
> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1],
... and once more I have to ask:

Is there any reason that Stuff Needs To Change because of a packaging
conflict in *debian* where it really doesn't matter at all for us?

I mean, ok, it's your time, do what you want, but I'm still confused
about the benefits of this change ...

>  by starting on the maintainer-needed packages.
> That's done (aside from some stabilizations needed, but I'll deal with that
> latter). The trouble is that there are roughly 700 packages that need to
> be updated, and that's an insane number of bugs to file.
>
> So, instead, I'm going to give developers to two weeks to update their
> initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
> initscripts/copyrights, but will leave revbumping to maintainer's discretion.
>
> Thanks,
> Austin
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846
>
>

Re: [gentoo-dev] Reminder: ALLARCHES

[Kent Fredric]

On 4 May 2016 at 16:46, Matt Turner  wrote:
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.
>
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually
> significantly better than the alternative of dropping them to
> unstable.

I feel like there needs to be something inbetween, a mechanism where
things can be deemed "tentatively stable", where in they can still be
later destabilized if evidence compels it.

As it is, stabilization seems one-directional. If critical defects are
found in "stable" releases, they tend not to escalate in the other
direction.

And I understand why that is, but it doesn't stop me wishing otherwise.

But instead of adding a rung between stable and unstable ... maybe the
right approach is to add a layer /beneath/ stable : "Long term
stable".

Where long-term stable is "Known to be good at a deep and thorough
level by people who use the software regularly".

Long-term stable at this point is not something I'd suggest people set
as their keywords in general, but it would be a thing that would only
be granted to specific packages on a case-by-case basis, and it would
only be encouraged to be used in the sense of
/etc/portage/package.keywords , where mixing long-term stable and
stable would be "supported" ... somehow.

IDK, there's still a lot wrong with my ideas, but hopefully there's
some ball here to run with.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL