Re: [gentoo-dev] Printer drivers and net-print

[Ulrich Mueller]

> On Tue, 21 Feb 2017, Gordon Pettey wrote:

> There is no requirement for category names to be x-y.

https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1 "Category Names"


pgpj2063_n6TN.pgp
Description: PGP signature

Re: [gentoo-dev] Printer drivers and net-print

[M. J. Everitt]

On 22/02/17 02:48, Gordon Pettey wrote:
> On Tue, Feb 21, 2017 at 7:05 PM, M. J. Everitt  > wrote:
>
> On 21/02/17 08:53, Lars Wendler wrote:
> > On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
> >
> >> Hey all,
> >>
> >> 1) Putting printer drivers into "net-print" is silly.
> >>
> >> Something that converts format a to device-specific format b has
> >> absolutely nothing to do with network.
> >> So, a new category "sys-print", emphasizing that it's hardware
> >> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make
> sense.
> > Like I said in IRC, I'm all in favor of this. "media-print" seems
> > reasonable as I don't consider printing related packages being
> > system-relevant (and thus no sys-print).
> >
> >
> Maybe we can shoot for "app-print" .. its not really a system package
> any more than a networking one, nor a (multi-)media package per-se
> (cue
> bikeshed on what 'media' means) .. so perhaps just 'app-print' or
> 'app-printing' .. I dunno ..
>
>
> There is no requirement for category names to be x-y. Instead of
> forcing a prefix-suffix pattern that doesn't really fit, just call it
> "printing".
Whilst I don't think there is anything specified in PMS/devmanual ..
find me another category without X-Y pattern? I'm not sure about portage
internals, but there could be some exploiting of the fact this is
'normally' the case ..

I could, ofc, be mistaken ...


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[Gordon Pettey]

On Tue, Feb 21, 2017 at 7:05 PM, M. J. Everitt  wrote:

> On 21/02/17 08:53, Lars Wendler wrote:
> > On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
> >
> >> Hey all,
> >>
> >> 1) Putting printer drivers into "net-print" is silly.
> >>
> >> Something that converts format a to device-specific format b has
> >> absolutely nothing to do with network.
> >> So, a new category "sys-print", emphasizing that it's hardware
> >> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.
> > Like I said in IRC, I'm all in favor of this. "media-print" seems
> > reasonable as I don't consider printing related packages being
> > system-relevant (and thus no sys-print).
> >
> >
> Maybe we can shoot for "app-print" .. its not really a system package
> any more than a networking one, nor a (multi-)media package per-se (cue
> bikeshed on what 'media' means) .. so perhaps just 'app-print' or
> 'app-printing' .. I dunno ..
>

There is no requirement for category names to be x-y. Instead of forcing a
prefix-suffix pattern that doesn't really fit, just call it "printing".

Re: [gentoo-dev] Printer drivers and net-print

[M. J. Everitt]

On 21/02/17 08:53, Lars Wendler wrote:
> Hi,
>
> On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:
>
>> Hey all, 
>>
>> 1) Putting printer drivers into "net-print" is silly.
>>
>> Something that converts format a to device-specific format b has
>> absolutely nothing to do with network.
>> So, a new category "sys-print", emphasizing that it's hardware
>> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.
> Like I said in IRC, I'm all in favor of this. "media-print" seems
> reasonable as I don't consider printing related packages being
> system-relevant (and thus no sys-print).
>
>
Maybe we can shoot for "app-print" .. its not really a system package
any more than a networking one, nor a (multi-)media package per-se (cue
bikeshed on what 'media' means) .. so perhaps just 'app-print' or
'app-printing' .. I dunno ..

Just my 2c50 as usual ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: Live ebuilds in the main tree (was: Re: [gentoo-dev] ...)

[Alexis Ballier]

On Tue, 21 Feb 2017 22:58:03 +0100
"Andreas K. Huettel"  wrote:

> Am Dienstag, 21. Februar 2017, 14:39:55 CET schrieb Francesco Riosa:
> 
> > BTW that help a lot we, users, that want to test that package in
> > the limbo time upstream has done some changes and the ebuild as not
> > caught up. Othrewise just avoid the - in tree, a lot of
> > developer have said they are evil in the past (right?)  
> 
> Actually I'm not so convinced that - live ebuilds in the tree are
> "evil" anymore (assuming they have no keywords). 
> 
> Why?
> 
> Compare the git history of, say, app-office/libreoffice (with the
> live ebuilds in the main tree), with kde-apps/kmail (with the live
> ebuilds separately in the kde overlay).


Yeah there is that, and it is also much simpler to maintain a live
ebuild than to rewrite and check 10 new configure options at each major
version.
This assumes the maintainer is using the live ebuild quite seriously
though :)

[gentoo-dev] Last rites: python.eclass

[Michał Górny]

Hi,

Similarly to the old distutils.eclass, python.eclass is now on its way
towards removal. Besides the packages using distutils.eclass
(and therefore python.eclass indirectly), the remaining 5 packages are
either awaiting stabilization or last rited for removal. Those are
tracked via bug #609750 [1].

If everything goes to plan, python.eclass will be removed on 2017-03-21. 
If you have any custom packages using that eclass, you need to either
migrate them, copy the eclass to your local repository or remove them.

I've already filed reports for all Gentoo repositories on the official
list.

[1]:https://bugs.gentoo.org/609750

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Live ebuilds in the main tree (was: Re: [gentoo-dev] ...)

[Andreas K. Huettel]

Am Dienstag, 21. Februar 2017, 14:39:55 CET schrieb Francesco Riosa:

> BTW that help a lot we, users, that want to test that package in the limbo
> time upstream has done some changes and the ebuild as not caught up.
> Othrewise just avoid the - in tree, a lot of developer have said they
> are evil in the past (right?)

Actually I'm not so convinced that - live ebuilds in the tree are "evil" 
anymore (assuming they have no keywords). 

Why?

Compare the git history of, say, app-office/libreoffice (with the live ebuilds 
in 
the main tree), with kde-apps/kmail (with the live ebuilds separately in the 
kde overlay).

For LibreOffice one can easily follow not just the version bumps but also the 
changes to the live ebuilds, which often document why something was changed 
(bug number, upstream modification).

For KMail the main tree mainly has "Added version" and "Removed version" 
commits, but if and why the ebuilds changed between versions is essentially 
documented in the kde overlay.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 2/3] ruby-ng.eclass: Use eapply for RUBY_PATCHES in EAPI 6

[Hans de Graaff]

On Sun, 2017-02-19 at 09:26 +0100, Michał Górny wrote:
> W dniu 19.02.2017, nie o godzinie 09∶03 +0100, użytkownik Hans de
> Graaff
> napisał:
> > 
> > This also removes the need for inheriting eutils in EAPI 6.
> > 
> Wouldn't EAPI 6 be a good opportunity to kill this dualism and just
> require people to say FILESDIR explicitly?

Which made me think: why have RUBY_PATCHES at all. I think we added
that at the time to allow bash arrays as input. So I've changed this
patch to use the default phase in EAPI 6 instead, removing the need for
explicit eapply_user and PATCHES support.

Hans

1b2b8abde99a59e72fbcc0bc8f9e835dcaee2176
Author: Hans de Graaff 
AuthorDate: Sun Feb 19 08:42:31 2017 +0100
Commit: Hans de Graaff 
CommitDate: Tue Feb 21 20:18:17 2017 +0100

Parent: 1d36503 ruby-ng.eclass: add support for EAPI=6
Merged: eapi6 master
Containing: eapi6

ruby-ng.eclass: use the default src_prepare in EAPI 6

This removes the need for inheriting eutils in EAPI 6.  It also use
the standard PATCHES support instead of RUBY_PATCHES, which was
introduced to handle arrays on patches at the time.

The default phase also handles eapply_user to handle user patches.

1 file changed, 30 insertions(+), 13 deletions(-)
eclass/ruby-ng.eclass | 43 ++-

modified   eclass/ruby-ng.eclass
@@ -73,7 +73,14 @@
 # (e.g. selenium's firefox driver extension). When set this argument
is
 # passed to "grep -E" to remove reporting of these shared objects.
 
-inherit eutils java-utils-2 multilib toolchain-funcs ruby-utils
+local inherits=""
+case ${EAPI} in
+   2|3|4|5)
+   inherits="eutils"
+   ;;
+esac
+
+inherit ${inherits} java-utils-2 multilib toolchain-funcs ruby-utils
 
 EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile
src_test src_install pkg_setup
 
@@ -399,15 +406,24 @@ ruby-ng_src_unpack() {
 }
 
 _ruby_apply_patches() {
-   for patch in "${RUBY_PATCHES[@]}"; do
-   if [ -f "${patch}" ]; then
-   epatch "${patch}"
-   elif [ -f "${FILESDIR}/${patch}" ]; then
-   epatch "${FILESDIR}/${patch}"
-   else
-   die "Cannot find patch ${patch}"
-   fi
-   done
+   case ${EAPI} in
+   2|3|4|5)
+   for patch in "${RUBY_PATCHES[@]}"; do
+   if [ -f "${patch}" ]; then
+   epatch "${patch}"
+   elif [ -f "${FILESDIR}/${patch}" ];
then
+   epatch "${FILESDIR}/${patch}"
+   else
+   die "Cannot find patch
${patch}"
+   fi
+   done
+   ;;
+   6)
+   if [[ -n ${RUBY_PATCHES[@]} ]]; then
+      eqawarn "RUBY_PATCHES is no longer
supported, use PATCHES instead"
+   fi
+   ;;
+   esac
 
    # This is a special case: instead of executing just in the
special
    # "all" environment, this will actually copy the effects on
_all_
@@ -432,14 +448,15 @@ ruby-ng_src_prepare() {
    # almost every other ebuild.
    find . -name '._*' -delete
 
-   _ruby_invoke_environment all _ruby_apply_patches
-
+   # Handle PATCHES and user supplied patches via the default
phase
    case ${EAPI} in
    6)
-   eapply_user
+   _ruby_invoke_environment all default
    ;;
    esac
 
+   _ruby_invoke_environment all _ruby_apply_patches
+
    _PHASE="source copy" \
    _ruby_each_implementation _ruby_source_copy
 

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH 3/3] ruby-ng.eclass: Remove support for jruby in EAPI 6

[Hans de Graaff]

On Sun, 2017-02-19 at 09:29 +0100, Michał Górny wrote:
> W dniu 19.02.2017, nie o godzinie 09∶03 +0100, użytkownik Hans de
> Graaff
> napisał:
> > 
> > jruby has not been supported for some time. Removing support for it
> > in
> > EAPI 6 allows us to drop the java-utils-2 eclass which in turn also
> > inherits eutils.
> > 
> Hmm, don't you have to change something more to make jruby disappear
> from the targets? Like, ban it in ruby_get_use_targets() or something
> like that?

Maybe. I guess it makes more sense to drop all jruby support at the
same time (including packages, profiles, and eclasses), so I'll skip
this patch for now.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/

[Francesco Riosa]

2017-02-21 12:56 GMT+01:00 Alexis Ballier :

> On Tue, 21 Feb 2017 13:16:59 +1300
> Kent Fredric  wrote:
>
> > Also, given its a - package, standards and assumptions of quality
> > are typically much lower.
>
> not at all; a lot of people do maintain - pretty well in order to
> follow upstream and use it as a template when bumping the next version,
> so standards and assumptions of quality are actually higher there :)
>
> yes, or to look from a different angle, speaking for - packages _in_
tree:
It can be expected that it does not build because the ebuild has not caught
up with upstream, hopefully for the shortest time possible.
_but_ it should have the same level of (bash/EAPI/deps) code cleanliness of
any other ebuild.

BTW that help a lot we, users, that want to test that package in the limbo
time upstream has done some changes and the ebuild as not caught up.
Othrewise just avoid the - in tree, a lot of developer have said they
are evil in the past (right?)

cheers,
Francesco

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/

[Alexis Ballier]

On Tue, 21 Feb 2017 13:16:59 +1300
Kent Fredric  wrote:

> Also, given its a - package, standards and assumptions of quality
> are typically much lower.

not at all; a lot of people do maintain - pretty well in order to
follow upstream and use it as a template when bumping the next version,
so standards and assumptions of quality are actually higher there :)

Re: [gentoo-dev] Printer drivers and net-print

[Ulrich Mueller]

> On Tue, 21 Feb 2017, Lars Wendler wrote:

>> 1) Putting printer drivers into "net-print" is silly.
>> 
>> Something that converts format a to device-specific format b has
>> absolutely nothing to do with network.
>> So, a new category "sys-print", emphasizing that it's hardware
>> drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.

> Like I said in IRC, I'm all in favor of this. "media-print" seems
> reasonable as I don't consider printing related packages being
> system-relevant (and thus no sys-print).

+1

If the category is badly named, move the packages to something more
reasonable. Users don't expect printer drivers in net-*. (Also I
don't buy the argument that package moves won't be worth the effort.
Not doing the move means that any future packages will also have an
inappropriate name.)

No large preference for either media-print or sys-print here.

>> 2) After introducing that, however, "net-print" becomes nearly empty.
>> 
>> On a quick glance, the only *network*-specific packages in there are
>> cups and lprng. Maybe one or two more which I dont recognize.

Do a complete move please. Leaving a category with two packages
doesn't make any sense.

Ulrich


pgpnSxLGkZQsN.pgp
Description: PGP signature

Re: [gentoo-dev] Printer drivers and net-print

[Lars Wendler]

Hi,

On Mon, 20 Feb 2017 22:47:17 +0100 Andreas K. Huettel wrote:

>Hey all, 
>
>1) Putting printer drivers into "net-print" is silly.
>
>Something that converts format a to device-specific format b has
>absolutely nothing to do with network.
>So, a new category "sys-print", emphasizing that it's hardware
>drivers, (or "cups-drv"?) (or maybe "media-print"?) might make sense.

Like I said in IRC, I'm all in favor of this. "media-print" seems
reasonable as I don't consider printing related packages being
system-relevant (and thus no sys-print).

>2) After introducing that, however, "net-print" becomes nearly empty.
>
>On a quick glance, the only *network*-specific packages in there are
>cups and lprng. Maybe one or two more which I dont recognize.
>
>So move cups and lprng to "net-misc" and drop "net-print"? 
>Or move them to new "sys-print" as well?
>
>What do you think?
>
>Cheers, 
>Andreas
>

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpCDWMR5hBp6.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/

[Kristian Fiskerstrand]

On 02/20/2017 08:50 PM, Mart Raudsepp wrote:
> Have respect towards others and their wishes and their maintenance and
> don't run over other people and maintainers. Do not run over
> maintainers after a 3 hour period of bug filing 

This seems like an overall good recommendation to remember after reading
this thread

-- 
Kristian Fiskerstrand
OpenPGP keyblock 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] Printer drivers and net-print

[Kristian Fiskerstrand]

On 02/20/2017 11:11 PM, Matthew Thode wrote:
> On 02/20/2017 03:47 PM, Andreas K. Huettel wrote:

>>
>> What do you think?

> The question to me is 'is there a great enough need to
> go through the pain of this?'.

I would agree with this sentiment. The lesson is to put more care into
naming categories to begin with so they are sufficiently broad to
contain a useful set of packages, but moving it around after the fact
causes more complexity than I would normally consider useful.

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



signature.asc
Description: OpenPGP digital signature