Re: [gentoo-dev] [gentoo-proxy-maint] Package up for grabs

[Manuel Rüger]

On 11.09.2016 20:57, Nick Vinson wrote:
> Hi,
> 
> I am the former maintainer of net-print/hplip-plugin, and because I have
> removed myself as the package maintainer, there are no other maintainers
> listed in metadata.xml.
> 
> Thus, the net-print/hplip-plugin package is now up for grabs.
> 
> - Nicholas Vinson
> 

Thanks for creating and maintaining the package, Nicolas! I've added the
printing project as the maintaining team.

Cheers,

Manuel

[gentoo-dev] Re: Package up for grabs: skencil

[Duncan]

Kristian Fiskerstrand posted on Fri, 16 Sep 2016 14:58:22 +0200 as
excerpted:

> On 09/16/2016 02:31 PM, Hanno Böck wrote:
>> media-gfx/skencil is a python-written vector graphics tool. It was once
>> popular before inkscape became the de-facto-standard. It hasn't seen
>> any upstream activity for a decade(!), but surprisingly it still seems
>> to work.
>> 
>> I haven't used it for many years myself.
>> 
>> There are 4 open bugs in bugzilla.
>> 
>> Anyone interested in taking it? (else the usual: will be reassigned to
>> maintainer-needed)
> 
> Also sounds like a candidate for treecleaning / moving to an overlay and
> not keeping non-upstream maintained things in tree if nobody want to
> take the maintainer burden of it.


Why treeclean it, if it still works and can still be built against in-
tree python?

Sometimes mature packages don't get further maintenance because they 
"just work" as they are, and don't _need_ to eventually be bloated to 
include email and browsing functionality or whatever.

Of course if it requires old python and eventually the last supported in-
tree python is being removed, and nobody steps up to update it then, 
/then/ it should be removed from the tree as it'll be broken /then/, but 
that's not the case now, as Hanno explicitly said it still seems to work.

-- 
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] Proposed future EAPI feature: FILES whitelist

[Kent Fredric]

On Fri, 16 Sep 2016 20:34:49 +0200
Ulrich Mueller  wrote:

> That is, similar syntax as for SRC_URI? That would make parsing of the
> FILES variable by ebuilds practically impossible. So presumably, one
> would need another variable similar to A then, containing the files
> from FILES but without the USE-disabled ones.

Yeah, that's the sort of misgivings I had when I thought of a similar
idea myself.

I'd much rather a way to label groups of files by purpose, have portage
validate them, and then apply certain labels manually against certain
USE flags

For instance,

   FILES["foo"] = "foo.patch bar.patch"
   FILES["quux"] = "quux.patch"

...

   if use foo; then
 eapply $FILES["foo"]
   else
eapply $FILES["quux"]
   fi

But that gets into things that are too hard to do in bash, like named
arrays ( doable but unfamilar for most ) and arrays-in-named-arrays
( ummm )

Probably not a good idea to push the limitations of bash in this way.


pgpgCzd_2tn71.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Ulrich Mueller]

> On Fri, 16 Sep 2016, Zac Medico wrote:

> If FILES supports USE conditionals,

That is, similar syntax as for SRC_URI? That would make parsing of the
FILES variable by ebuilds practically impossible. So presumably, one
would need another variable similar to A then, containing the files
from FILES but without the USE-disabled ones.

> then it's possible to use inotify to implement a QA check that
> detects unused files in FILES.

Ulrich


pgpuaunFS5UHR.pgp
Description: PGP signature

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Ian Stakenvicius]

On 16/09/16 11:20 AM, Ulrich Mueller wrote:
> 
> AFAICS that proposal goes into a direction which is somewhat opposite
> to what we have pursued in EAPI 6. There, we have allowed directories
> as arguments to eapply, in order to simplify application of patchsets.
> Now maintainers would have to list all single files contained in the
> directory again.

I had thought that particular functionality was more to support
patchset tarballs that get extracted to ${WORKDIR} rather than
supporting such (ab)use in ${FILESDIR} ?





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Zac Medico]

On 09/16/2016 08:20 AM, Ulrich Mueller wrote:
>> On Sat, 17 Sep 2016, Kent Fredric wrote:
>> 4. Due to referential integrity, it should be trivial to identify which
>> files are needed by a given ebuild, and which files are now redundant,
>> assisting with keeping the tree pruned.
> 
> How does a file in FILESDIR get stale? The typical scenario is that a
> patch will no longer be needed after a version bump and pruning of old
> ebuild versions. I fear that with FILES the problem would simply be
> shifted: instead of forgetting to delete the stale file, people would
> forget removing the patch from the FILES list.

If FILES supports USE conditionals, then it's possible to use inotify to
implement a QA check that detects unused files in FILES.
-- 
Thanks,
Zac

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Kent Fredric]

On Fri, 16 Sep 2016 17:20:28 +0200
Ulrich Mueller  wrote:

> > 3. Each entry in FILES dictates that the given file is "Used by" the
> > ebuild.  
> 
> Do you mean "file" in its Unix meaning here, i.e. including
> directories? Or only regular files?

I'd say regular files for now. Mostly because I think it should be explicit
if you want to include directory children.

/expressions/ could be expanded during MD5 generation against ${REPO}.../files/ 
path, which would probably work in the case of "${PV}/*" for instance.

But I'm undecided if I like that, only suggesting to get people thinking about 
it as a possibility.

> 
> > 4. the FILES variable is expanded and interpreted during package
> > sourcing  
> 
> > 5. "repoman full" and "repoman ci" must ensure any entry listed in FILES
> > exists  
> 
> > 6. "repoman full" and "repoman ci" must ensure any use of ${FILESDIR}
> > without a declared FILES variable is a failure.  
> 
> > 7. Under this future EAPI, the location of where ${FILESDIR} expands to
> > changes to a location within
> > ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files  
> 
> > 8. The contents of ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files
> > is generated from the source-time $FILES entry by mapping entries from
> > ${repostory_location}, either by symlink or by copy (though copy is
> > preferred to avoid potential side effects), mapping their heirachy
> > exactly ( that is, preserving directory structure )  
> 
> > 9. Files not listed in/indicated by $FILES are thus unavailable to the
> > ebuild at runtime and will not be seen in ${FILESDIR}, even if they are
> > in ${repository_location}  
> 
> AFAICS that proposal goes into a direction which is somewhat opposite
> to what we have pursued in EAPI 6. There, we have allowed directories
> as arguments to eapply, in order to simplify application of patchsets.
> Now maintainers would have to list all single files contained in the
> directory again.

This wouldn't change the ability for eapply to do that when used with 
patch-tarballs in SRC_URI, and it wouldn't change the ability to call:

   eapply ${FILESDIR}

It would only change where ${FILESDIR} was and what it contained.

But the use of that against directories in $FILEDIR is slightly more
cause for concern at present, though mostly due to abuse where files/*
are all considered. Such abuses /could/ possibly be made more obvious
with this mechanism.

> Also I am not sure if I like the additional burden imposed on ebuild
> maintainers by requiring double bookkeeping. FILESDIR is already a
> well defined location for the support files needed by a package.

Agreed to an extent. Though I was of the opinion that to a greater extent
at least, such concern cases would simply be relocating the book-keeping
logic for defining the file-sets to be at the FILES location, which would
give you a canonical variable to consume elsewhere.

In theory under the expression system, you could have "FILES=*" which
would basically regress the feature to what it currently is, but then having
the feature at all wouldn't be very useful.

It could be an "opt-in" feature instead of a mandatory one mind, where it would
basically degrade to a default mechanic of "Like a PATCHES array, but repoman
can check it"

> 
> > :: Benefits ::  
> 
> > [...]  
> 
> > 4. Due to referential integrity, it should be trivial to identify which
> > files are needed by a given ebuild, and which files are now redundant,
> > assisting with keeping the tree pruned.  
> 
> How does a file in FILESDIR get stale? The typical scenario is that a
> patch will no longer be needed after a version bump and pruning of old
> ebuild versions. I fear that with FILES the problem would simply be
> shifted: instead of forgetting to delete the stale file, people would
> forget removing the patch from the FILES list.
> 
> Ulrich

I Know those seem like similar problems, but the subtle difference does stick 
out
for me.

With the existing scenario the basic assumption is that *every* ebuild
needs a given file, and you have to check every ebuild and make sure
you don't break one.

And this is true *even* if you're a maintainer who tries to keep things tight.

A good maintainer can prune the contents of an ebuilds FILES= list *at
the time they perform the bump*, where as by contrast, you *cant* prune
the files themselves at the time of the bump, because they are still
needed.

So in a sense, the use of a FILES= list allows you to keep things
contextualised, you can mark which you still need, and remove that
which you don't.

Which means when a second maintainer comes along and removes an ebuild,
they don't need to have the knowledge the first maintainer internalised
when they made the bump.

Removing the ebuild will immediately alert them of the presense of
unused files, because they will cease to be indicated by any ebuilds.

So you're keeping the knowledge of "I changed the ebuild" attached to
"I changed which files are needed", 

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Mart Raudsepp]

Ühel kenal päeval, R, 16.09.2016 kell 17:20, kirjutas Ulrich Mueller:
> How does a file in FILESDIR get stale? The typical scenario is that a
> patch will no longer be needed after a version bump and pruning of
> old
> ebuild versions. I fear that with FILES the problem would simply be
> shifted: instead of forgetting to delete the stale file, people would
> forget removing the patch from the FILES list.
> 
> Ulrich

While I'm not sure I would like this feature as a whole, compared to
the status quo, the only way this would really work in a reasonable way
(and maybe not at all in some cases without the duplication) is if you
don't eapply them in a way that lists them again, but it would replace
PATCHES functionality or you'd do some bash magic to eapply everything
in $FILES that ends in .patch or something.


Mart

[gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Ulrich Mueller]

> On Sat, 17 Sep 2016, Kent Fredric wrote:

> Just an idea that seemed obvious enough and obviously missing.

> 1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as
> a stand-in for now ).

> 2. FILES contains an array (or perhaps whitespace delimited string) of
> entries (or perhaps expressions) relative to
> ${repository_location}/${CATEGORY}/${PN}/files/

> 3. Each entry in FILES dictates that the given file is "Used by" the
> ebuild.

Do you mean "file" in its Unix meaning here, i.e. including
directories? Or only regular files?

> 4. the FILES variable is expanded and interpreted during package
> sourcing

> 5. "repoman full" and "repoman ci" must ensure any entry listed in FILES
> exists

> 6. "repoman full" and "repoman ci" must ensure any use of ${FILESDIR}
> without a declared FILES variable is a failure.

> 7. Under this future EAPI, the location of where ${FILESDIR} expands to
> changes to a location within
> ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files

> 8. The contents of ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files
> is generated from the source-time $FILES entry by mapping entries from
> ${repostory_location}, either by symlink or by copy (though copy is
> preferred to avoid potential side effects), mapping their heirachy
> exactly ( that is, preserving directory structure )

> 9. Files not listed in/indicated by $FILES are thus unavailable to the
> ebuild at runtime and will not be seen in ${FILESDIR}, even if they are
> in ${repository_location}

AFAICS that proposal goes into a direction which is somewhat opposite
to what we have pursued in EAPI 6. There, we have allowed directories
as arguments to eapply, in order to simplify application of patchsets.
Now maintainers would have to list all single files contained in the
directory again.

Also I am not sure if I like the additional burden imposed on ebuild
maintainers by requiring double bookkeeping. FILESDIR is already a
well defined location for the support files needed by a package.

> :: Benefits ::

> [...]

> 4. Due to referential integrity, it should be trivial to identify which
> files are needed by a given ebuild, and which files are now redundant,
> assisting with keeping the tree pruned.

How does a file in FILESDIR get stale? The typical scenario is that a
patch will no longer be needed after a version bump and pruning of old
ebuild versions. I fear that with FILES the problem would simply be
shifted: instead of forgetting to delete the stale file, people would
forget removing the patch from the FILES list.

Ulrich


pgpy7uZbzdsnL.pgp
Description: PGP signature

Re: [gentoo-dev] Arch testers need themselves an IRC channel so I can love them more

[Rich Freeman]

On Fri, Sep 16, 2016 at 9:00 AM, Kent Fredric  wrote:
>
> As such, I believe Arch Testers should have themselves an IRC channel,
> where Arch testers are OP, and membership of arch testers is voluntary
> ( but encouraged ).
>

The history here is that ATs typically hung out in the arch channels
themselves, like #gentoo-amd64.

Back in the day when the arches were new, there was a lot of general
activity in these channels around adapting packages/etc.  For the more
minor arches it may still be that way.  The ATs were viewed as just
another part of that.  Non-dev ATs were typically given at least voice
in these channels.  Back in those days the arch leads were also fairly
active positions.  Different arches sometimes had different policies
on the role of ATs, and for non-dev ATs there was close coordination
since a dev would need to make the commits.

These days upstream is a lot more attentive to the more popular archs
(IMO), so there isn't as much widespread patching/porting/etc going
on.  I think this is part of what has led to the drop in arch team
activity, and AT activity as well (nobody is
recruiting/encouraging/etc them).

I'm not trying to dismiss your suggestion.  I just wanted to point out
that ATs do actually have a place of sorts right now other than -dev.
They just don't have one place across all arches.  Maybe that should
change, maybe not.  I'd be interested in the thoughts of the ATs
themselves.

-- 
Rich

[gentoo-dev] Arch testers need themselves an IRC channel so I can love them more

[Kent Fredric]

If you're an arch tester reading this, I love you.

Your job is mostly thankless and how important it is seems relatively
un-reflected in our regular conversations, and this needs to be
rectified.

Often, I see a stable request get done, and I know what got stabilized
was a monumental amount of work, and I just want to thank you for your
effort, but there isn't a good place for this.

Other times, I may want to ask questions in an informal setting, and
get an authoritative answer on what exactly you want of us as an arch
tester.

Presently, if I want to ask questions about arch testing, the only
place to do this is #gentoo-dev, or seek the mailing list like I am now.

The latter of these is a bit time consuming, and that probably
discourages participation.

And the former is not entirely useful as that's likely to get
side-tracked by all the people who don't do arch testing opining on
what to do, mostly directed by their experience with working with arch
testers. 

This is not "bad" as such, but its not really an authority on arch
testing.

I believe that as arch testers, you have a right to run a channel as
you see fit, and have an authority on how it is you do what you do.

As such, I believe Arch Testers should have themselves an IRC channel,
where Arch testers are OP, and membership of arch testers is voluntary
( but encouraged ).

I myself would start such a channel, but I feel it is not my place to
found such a channel, as I'm not an arch tester, it would be wrong of
me to hold OP of such a channel: That's a right only an Arch tester
should have.

And a channel opped by and filled with Non-Arch testers on the subject
of arch-testing sounds too much like certain political problems we have
lately.

I also believe somewhat in the idea that /people who are most concerned
about an issue/ should also be the same people who /do the work to
resolve that issue/, and in that light, it is somewhat disingenuous
to constantly fret over the state of arch testing while doing little to
actually fix the problem myself.

I do have it on my TODO list to attempt rectifying this, and in a
semi-long-term view of things I might find myself doing arch testing,
but I don't think we should wait until then to have an arch-testing
channel ;)

It would also probably be useful to have such a channel for arch
testers and interested potential-arch-testers to congregate and discuss
things, so that the potentials can get a feel for the work in an
informal capacity before stepping up to take the load, and the channel
would thus also facilitate the transfer of knowledge to widen the
tester base.

( I understand people may be discussing the potential formation of an
AT mailing list/alias/project or something along those lines, but
I find such a strategy far too formal to be valuable, and much prefer
the flexibility of self-organising groups and the relaxed informality of
IRC, which typically don't need any approval to to create or infra
assistance to start )

In closing, this is a petition to somebody who is a recognised arch
tester to form a channel for this purpose, and encourage other testers
to join, and people like myself can then hop on and maybe be more
productive as a result.

<3




pgpbYel139gO2.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: skencil

[Kristian Fiskerstrand]

On 09/16/2016 02:31 PM, Hanno Böck wrote:
> media-gfx/skencil
> is a python-written vector graphics tool. It was once popular before
> inkscape became the de-facto-standard. It hasn't seen any upstream
> activity for a decade(!), but surprisingly it still seems to work.
> 
> I haven't used it for many years myself.
> 
> There are 4 open bugs in bugzilla.
> 
> Anyone interested in taking it? (else the usual: will be reassigned to
> maintainer-needed)

Also sounds like a candidate for treecleaning / moving to an overlay and
not keeping non-upstream maintained things in tree if nobody want to
take the maintainer burden of it.


-- 
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

[gentoo-dev] Package up for grabs: skencil

[Hanno Böck]

media-gfx/skencil
is a python-written vector graphics tool. It was once popular before
inkscape became the de-facto-standard. It hasn't seen any upstream
activity for a decade(!), but surprisingly it still seems to work.

I haven't used it for many years myself.

There are 4 open bugs in bugzilla.

Anyone interested in taking it? (else the usual: will be reassigned to
maintainer-needed)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Kent Fredric]

Just an idea that seemed obvious enough and obviously missing.

1. Have, in a future EAPI, a variable (I'm going to call it "FILES" as
a stand-in for now ).

2. FILES contains an array (or perhaps whitespace delimited string) of
entries (or perhaps expressions) relative to
${repository_location}/${CATEGORY}/${PN}/files/

3. Each entry in FILES dictates that the given file is "Used by" the
ebuild.

4. the FILES variable is expanded and interpreted during package
sourcing

5. "repoman full" and "repoman ci" must ensure any entry listed in FILES
exists

6. "repoman full" and "repoman ci" must ensure any use of ${FILESDIR}
without a declared FILES variable is a failure.

7. Under this future EAPI, the location of where ${FILESDIR} expands to
changes to a location within
${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files

8. The contents of ${PORTAGE_TEMPDIR}/portage/${CATEGORY}/${PF}/files
is generated from the source-time $FILES entry by mapping entries from
${repostory_location}, either by symlink or by copy (though copy is
preferred to avoid potential side effects), mapping their heirachy
exactly ( that is, preserving directory structure )

9. Files not listed in/indicated by $FILES are thus unavailable to the
ebuild at runtime and will not be seen in ${FILESDIR}, even if they are
in ${repository_location}



:: Benefits ::

1. Referential integrity of this field means basic tooling like repoman
can verify in advance the presence of things that are deemed necessary
for the ebuild to function, and can check for their absense.

2. Said referential integrity can propagate failures to mirror
properly and mistakes by ebuild authors (specifically, naughty ones who
side-step repoman) to escallate to being errors long before the files
are needed by executable code.

3. Due to point 2, the risk of silent failures due to lack of explicit
handling for the files being missing is reduced.

4. Due to referential integrity, it should be trivial to identify which
files are needed by a given ebuild, and which files are now redundant,
assisting with keeping the tree pruned.

5. When maintaining a given ebuild, the use of a variable means that
one can consult the list of files a given ebuild uses canonically, and
thus know which files may need oversight when performing changes, as
the canonical form of the variable can theoretically be computed during
metadata/ generation. ( but probably not wise to just flop that in
there, unless we can guarantee that this subtle change to the md5
format won't cause problems elsewhere ), but tooling can still be
written to spit out a list of FILES= entries. ( Currently, you must
grep the ebuild or approximate grep with your eyes, and that is prone
to errors, especially in cases of anything that uses horror shows like
eblits )

6. Due to this introducing a concept of connectedness between .ebuild/
and files/, this opens a door to a potential emerge feature of
--reinstall-if-files-changed , which would allow people to trigger a
rebuild for any ebuild which may have been subtly changed due to
patches to any of its dependency files. ( Though I'd expect to see
little use of this feature if added, except for weird anal people like
me who disable dynamic deps ;) ) 

:: Mixed Change/Benefit Cases ::

1. Some eclasses presently support a PATCHES= variable, which contain
an ordered list of patches that may be applied, stating the order of
application.

Here, in many cases, PATCHES could be dropped from need and a more
universal syntax of `eapply $( echo ${FILESDIR}/*.patch | sort )` as
generic logic in the default src_patch

Due to the ${FILESDIR} being a synthetic location constructed from the
contents of the FILES= variable, you can get away with doing a lot of
tricks that would otherwise be undesirable in the current situation.

For instance: 

 use foo-feature && eapply ${FILESDIR}/foo-feature/*.patch

Because the nature of what "FILESDIR" contained is already strictly
regulated elsewhere in the ebuild and validated long before the patch
phase.


:: Possible Future Abuses ::

FILES=$( cat ${FIlEDIR}/$PV/series )

Though this would stil be validated by repoman to make sure all entries
in "series" exists, and assuming the data was staticised to the md5
metadata cache, would not be so bad. But  probably should have
people shot for doing this. 


As always, this feature probably exists in some package manager other
than portage for ebuilds in EAPIs other than the one portage support,
but I have not checked those for feature comparison. 





pgpdU_r0bXafX.pgp
Description: OpenPGP digital signature