Re: [gentoo-dev] Re: New categories: mate-base and mate-extra

[Andreas K. Huettel]

Am Samstag, 22. Februar 2014, 19:02:54 schrieb Tom Wijsman:
> On Sat, 22 Feb 2014 17:33:57 + (UTC)
> 
> 
> (Or do we want a consistent 'mate-base' / 'mate-extra' approach?)

If there is a clear distinction between a core set of packages and extra stuff 
(as in e.g. kde4), the combination mate-base / mate-extra would probably be 
best.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Alexandre Rostovtsev]

On Sat, 2014-02-22 at 15:59 -0600, Ryan Hill wrote:
> On Sat, 22 Feb 2014 15:50:17 -0600
> Ryan Hill  wrote:
> 
> > On Sat, 22 Feb 2014 16:09:53 -0500
> > Alexandre Rostovtsev  wrote:
> > 
> > > On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > > > wxGTK not only splits up libraries by version and toolkit, but also by
> > > > charset and debug/release.  If we had to use different SLOTs rather than
> > > > USE flags we would need eight of them for 2.8 alone.  And I don't know 
> > > > how
> > > > we would name the ebuilds (-r100,-r200,... ugh).
> > > 
> > > Remember, a single process cannot load both gtk2 and gtk3 - you *will*
> > > get random crashes. If you think that dealing with interesting bug
> > > reports - e.g. caused by application foo which was built against your
> > > wxGTK[gtk3] and then crashed after enumerating its plugin directory
> > > because of the presence of binary plugin bar which links to libbaz which
> > > sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
> > > fun than doing a bit of work at the start and slotting wxGTK, then
> > > please go ahead ;)
> > 
> > Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
> > today.  That's already the case.  But what does that have to do with 
> > slotting?
> 
> Oh.  The libs are named explicitly:
> 
>   /usr/lib64/libwx_gtk2u_core-3.0.so
>   /usr/lib64/libwx_gtk3u_core-3.0.so
> 
> You can't load the wrong one.

Ah, I see. I was afraid you were proposing to use the same library name
for wxGTK+gtk2 and wxGTK+gtk3.


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

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Sat, 22 Feb 2014 15:50:17 -0600
Ryan Hill  wrote:

> On Sat, 22 Feb 2014 16:09:53 -0500
> Alexandre Rostovtsev  wrote:
> 
> > On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > > wxGTK not only splits up libraries by version and toolkit, but also by
> > > charset and debug/release.  If we had to use different SLOTs rather than
> > > USE flags we would need eight of them for 2.8 alone.  And I don't know how
> > > we would name the ebuilds (-r100,-r200,... ugh).
> > 
> > Remember, a single process cannot load both gtk2 and gtk3 - you *will*
> > get random crashes. If you think that dealing with interesting bug
> > reports - e.g. caused by application foo which was built against your
> > wxGTK[gtk3] and then crashed after enumerating its plugin directory
> > because of the presence of binary plugin bar which links to libbaz which
> > sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
> > fun than doing a bit of work at the start and slotting wxGTK, then
> > please go ahead ;)
> 
> Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
> today.  That's already the case.  But what does that have to do with slotting?

Oh.  The libs are named explicitly:

  /usr/lib64/libwx_gtk2u_core-3.0.so
  /usr/lib64/libwx_gtk3u_core-3.0.so

You can't load the wrong one.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Sat, 22 Feb 2014 16:09:53 -0500
Alexandre Rostovtsev  wrote:

> On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> > wxGTK not only splits up libraries by version and toolkit, but also by
> > charset and debug/release.  If we had to use different SLOTs rather than
> > USE flags we would need eight of them for 2.8 alone.  And I don't know how
> > we would name the ebuilds (-r100,-r200,... ugh).
> 
> Remember, a single process cannot load both gtk2 and gtk3 - you *will*
> get random crashes. If you think that dealing with interesting bug
> reports - e.g. caused by application foo which was built against your
> wxGTK[gtk3] and then crashed after enumerating its plugin directory
> because of the presence of binary plugin bar which links to libbaz which
> sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
> fun than doing a bit of work at the start and slotting wxGTK, then
> please go ahead ;)

Yeah and package built against wxGTK (gtk2) could dlopen gtk3 at runtime
today.  That's already the case.  But what does that have to do with slotting?


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

[Alexandre Rostovtsev]

On Sat, 2014-02-22 at 14:57 -0600, Ryan Hill wrote:
> wxGTK not only splits up libraries by version and toolkit, but also by charset
> and debug/release.  If we had to use different SLOTs rather than USE flags we
> would need eight of them for 2.8 alone.  And I don't know how we would name 
> the
> ebuilds (-r100,-r200,... ugh).

Remember, a single process cannot load both gtk2 and gtk3 - you *will*
get random crashes. If you think that dealing with interesting bug
reports - e.g. caused by application foo which was built against your
wxGTK[gtk3] and then crashed after enumerating its plugin directory
because of the presence of binary plugin bar which links to libbaz which
sometimes dlopens gtk2 at runtime when USE=wombat is enabled  - is more
fun than doing a bit of work at the start and slotting wxGTK, then
please go ahead ;)


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

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Thu, 20 Feb 2014 05:16:55 -0500
Alexandre Rostovtsev  wrote:

> The other unfortunate aspect of the gtk3 flag is that it encourages
> using flags instead of slotting for libraries that can support both gtk
> and gtk3, resulting in needless rebuilds of when one of the flags is
> switched on/off. But again, that could be addressed with a bit of
> documentation.

Slotting a library by toolkit rather than by version just doesn't work in a lot
of cases.  Having multiple versions of a library installed is common enough
practice and upstreams will often take that into account and version their
library names, include paths, pkgconfig files, etc.  Most don't do that for
different toolkits.  So if you're slotting by toolkit you have to start
installing one in a non-standard location to prevent file collisions (and it's
always the newer toolkit since you don't want to break existing packages), and
every new ebuild using that toolkit needs to be changed to look in the right
place, and you have to start futzing around with symlinks, and wrapper scripts,
and eselect, and eclasses, and every time some dev uses the wrong depend atom
you get a bug about it, and it goes on and on and on.

Or you can add USE=gtk3, deal with collisions internally, install one set of
headers, and go do something productive with your life.

wxGTK not only splits up libraries by version and toolkit, but also by charset
and debug/release.  If we had to use different SLOTs rather than USE flags we
would need eight of them for 2.8 alone.  And I don't know how we would name the
ebuilds (-r100,-r200,... ugh).


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] first steps in gentoo devolment

[Paweł Hajdan, Jr.]

On 2/19/14, 8:05 AM, Roelof Wobben wrote:
> Am I right I have to make a local repo to test if it's build.

Yeah, I suggest just using /usr/local/portage and adding it to
PORTDIR_OVERLAY in make.conf.

> And does ebuild x.ebuild  manifest also builds the package or do I have
> to use emerge x for that.

Please see "man 1 ebuild" for explanation what the commands do.

It's probably good to indeed use emerge for full end-to-end testing.

> And for testing Is repoman scan enough after looking if the package can
> installed of course.

Feel free to use repoman. IMHO building, installing and using the
package is a much more important test, but repoman can point out issues
even though the package seems to work.

> I have looked into the manuals but I cannot find a clear answer.

Which docs have you checked? Make sure to see 

Good luck, and glad to hear you're working on contributing to Gentoo.

Paweł




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: RFD: new global USE flag gtk3

[Ryan Hill]

On Thu, 20 Feb 2014 11:26:18 +0200
Samuli Suominen  wrote:

> Bye bye distribution level consistency :-(

The last time we had distribution level consistency was the moment between the
first and second packages getting committed to the tree.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: New categories: mate-base and mate-extra

[Michael Palimaka]

On 02/23/2014 05:02 AM, Tom Wijsman wrote:
> On Sat, 22 Feb 2014 17:33:57 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> Tom Wijsman posted on Sat, 22 Feb 2014 18:08:24 +0100 as excerpted:
>>
 That seems a little on the small side? Can we just do a single
 category for all of it, instead? People can go bikeshed on the
 name.
>>>
>>> TL;DR: Yes, we could try that; but what would be a consistent name?
>>
>> mate-desktop ?
> 
> While still inconsistent with what already exists, that indeed sounds
> sane towards the user, +1; does someone object 'mate-desktop'?
> 
>> (The mate-base and mate-extra split seems more consistent with the
>> rest of the tree to me, and around a dozen packages each seems fine,
>> but if it's to be a single category, mate-desktop seems reasonable.
>> Or desktop- mate, or mate-dt...)
> 
> (Or do we want a consistent 'mate-base' / 'mate-extra' approach?)
> 
I personally prefer the base/extra approach for consistency and
segregation reasons.

Re: [gentoo-dev] Re: New categories: mate-base and mate-extra

[Dirkjan Ochtman]

On Sat, Feb 22, 2014 at 7:02 PM, Tom Wijsman  wrote:
> While still inconsistent with what already exists, that indeed sounds
> sane towards the user, +1; does someone object 'mate-desktop'?

I was thinking mate-de, but -desktop seems okay, too.

Anyway, you should probably give people some time to voice their
objections before you go into action mode.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: New categories: mate-base and mate-extra

[Tom Wijsman]

On Sat, 22 Feb 2014 17:33:57 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> Tom Wijsman posted on Sat, 22 Feb 2014 18:08:24 +0100 as excerpted:
> 
> >> That seems a little on the small side? Can we just do a single
> >> category for all of it, instead? People can go bikeshed on the
> >> name.
> > 
> > TL;DR: Yes, we could try that; but what would be a consistent name?
> 
> mate-desktop ?

While still inconsistent with what already exists, that indeed sounds
sane towards the user, +1; does someone object 'mate-desktop'?

> (The mate-base and mate-extra split seems more consistent with the
> rest of the tree to me, and around a dozen packages each seems fine,
> but if it's to be a single category, mate-desktop seems reasonable.
> Or desktop- mate, or mate-dt...)

(Or do we want a consistent 'mate-base' / 'mate-extra' approach?)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[gentoo-dev] Re: New categories: mate-base and mate-extra

[Duncan]

Tom Wijsman posted on Sat, 22 Feb 2014 18:08:24 +0100 as excerpted:

>> That seems a little on the small side? Can we just do a single category
>> for all of it, instead? People can go bikeshed on the name.
> 
> TL;DR: Yes, we could try that; but what would be a consistent name?

mate-desktop ?

(The mate-base and mate-extra split seems more consistent with the rest 
of the tree to me, and around a dozen packages each seems fine, but if 
it's to be a single category, mate-desktop seems reasonable.  Or desktop-
mate, or mate-dt...)

Regardless, thanks for bringing mate to gentoo. =:^)

-- 
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] New categories: mate-base and mate-extra

[Tom Wijsman]

On Sat, 22 Feb 2014 17:16:11 +0100
Dirkjan Ochtman  wrote:

> On Sat, Feb 22, 2014 at 12:06 AM, Tom Wijsman 
> wrote:
> > Currently, the MATE overlay has 14 meta-base packages and 16
> > mate-extra packages; this might slightly change when reconsidering
> > if their location is alright, however it is near the average (~15)
> > per category so that should be fit.

TL;DR: My avg was wrong, it is larger (110); but low (51) on *-base.

The average there was based on what I historically saw mentioned in
another new category thread, our categories seem to have grown since; I
didn't actually check it, but running the following command to check
out the actual average it seems that it is higher at ~110 packages.

`for d in $(find /usr/portage/ -maxdepth 1 -type d | grep -) ; do ls -1
${d} | wc -l ; done | awk '{sum+=$1}END{print sum/NR}'`

If we however do this on the -base packages (grep -- -base), we get ~51
packages as being the average; gnome-base for example has 41 packages.

> That seems a little on the small side? Can we just do a single
> category for all of it, instead? People can go bikeshed on the name.

TL;DR: Yes, we could try that; but what would be a consistent name?

Given these more correct statistics, that indeed seems rather small;
combining them, we indeed would get closer to a reasonable size for a
category. But its naming becomes way more tricky then.

The first thing that comes to mind is dropping the suffix; but then we
end up with just 'mate' which is inconsistent with how we name the rest.

Since introducing a suffix after 'mate' when grouping all packages
doesn't really make much sense, it might make more sense to make '-mate'
the suffix. But enumerating existing prefixes, I see none that makes
sense; see for yourself: app-mate, dev-mate, games-mate, gnome-mate,
gnustep-mate, gpe-mate, java-mate, kde-mate, lxde-mate, mail-mate,
media-mate, net-mate, perl-mate, razorqt-mate, rox-mate, sci-mate,
sec-mate, sys-mate, www-mate, x11-mate, xfce-mate

So, this makes me question why to go for an inconsistent naming; and if
we keep 'mate-base' then it feels wrong to move 'mate-extra' stuff in
there, so, I really wonder if the amount of packages matters that much.
Especially since I count at least 27 categories that are <= 20 pkgs:

`for d in $(find /usr/portage/ -maxdepth 1 -type d | grep -) ; do if
[[ $(ls -1 ${d} | wc -l) -le 20 ]] ; then echo ${d} ; fi ; done | wc -l`

Doing this again we see 43 categories that are <= 30 pkgs, that's like
a quarter of the Portage tree; it's representative to show that this is
uncommon, but not necessarily an actual exception.

It's indeed a recipe for bikeshedding; but I want to avoid this from
falling under a situation where there's no actual decision no which way
we proceed.

As I see it going forward:

 - If we agree on a consistent name for a single category, we pick that.

 - If we don't agree on a name for a single category, we see whether
   we want to agree on just having two categories to be consistent.

 - If we neither agree on the naming or two categories, I see myself
   forced to insert MATE packages across other existing categories; but
   I don't think people would be happy with that either.

Thank you in advance for further input on this.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] New categories: mate-base and mate-extra

[Dirkjan Ochtman]

On Sat, Feb 22, 2014 at 12:06 AM, Tom Wijsman  wrote:
> Currently, the MATE overlay has 14 meta-base packages and 16 mate-extra
> packages; this might slightly change when reconsidering if their
> location is alright, however it is near the average (~15) per category
> so that should be fit.

That seems a little on the small side? Can we just do a single
category for all of it, instead? People can go bikeshed on the name.

Cheers,

Dirkjan

Re: [gentoo-dev] Packages up for grab

[Marc Schiffbauer]

* Christian Ruppert schrieb am 22.02.14 um 14:57 Uhr:

Hi,

I don't use the listed packages anymore so feel free to take those:

net-analyzer/mk-livestatus
net-misc/igmpproxy
x11-misc/tint2
x11-misc/tintwizard
net-misc/cfengine - I'll just keep maintaining Cfengine 2.x for now since
we/Infra still use it.


I will take cfengine, since we use it a lot.

-Marc

--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

[gentoo-dev] Packages up for grab

[Christian Ruppert]

Hi,

I don't use the listed packages anymore so feel free to take those:

net-analyzer/mk-livestatus
net-misc/igmpproxy
x11-misc/tint2
x11-misc/tintwizard
net-misc/cfengine - I'll just keep maintaining Cfengine 2.x for now since
we/Infra still use it.

-- 
Regards,
Christian Ruppert
Gentoo Linux developer, Bugzilla administrator and Infrastructure member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8


pgpKpUhdx4yLG.pgp
Description: PGP signature

Re: [gentoo-dev] Re: mbox -- looks sort of interesting

[Александр Берсенев]

Hello,

I've updated the autodep and testing it now.

I've fixed a problem with the integration of autodep in the newest version
of Portage, but I think I did it in a hackish way. I want to ask if it is
possble to solve it better.

First, some words about the architecture of autodep. Autodep consists of
two parts:
1) A library, injected with LD_PRELOAD, which intercepting glibc functions
like open, read, write, etc. The library connects using unix socket with a
server part and asks this server about each file operation. The server can
say to permit or to block an operation.
2) The server part, which logs requests from clients and answers them.

The integration with the portage is made, using two hooks on
build(EbuildBuild.py):
 build = EbuildExecuter(background=self.background, pkg=pkg,
  scheduler=scheduler, settings=settings)

 build.addStartListener(self._build_start)
 build.addExitListener(self._build_stop)

 self._start_task(build, self._build_exit)

The _build_start creates the server thread, and passes a unix-socket path
using LOG_SOCKET environment variable.

 self.logserver.start()

 # Copy socket path to LOG_SOCKET environment variable
 env=self.settings.configdict["pkg"]
 env['LOG_SOCKET'] = self.logserver.socket_name

The  _build_stop stops the server and removes LOG_SOCKET environment
variable.
 env=self.settings.configdict["pkg"]
 if 'LOG_SOCKET' in env:
  del env['LOG_SOCKET']

 events=self.logserver.stop()
 self.logserver=None

If LOG_SOCKET env var is set then the new processes(like ebuild.sh )
are started with my library injected using LD_PRELOAD trick.

The problem: on newer portage versions packages are merged in a subprocess
to allow the Scheduler run in main thread while files are moved or copied
asynchronously(file _MergeProcess.py). This subprocess is created before
the _build_stop is called, so it still has a copy of settings with
LOG_SOCKET set. When _build_stop is called the server stops and merging
fails because the unix-socket is closed.

To solve this I added this code before forking in _MergeProcess.py:
 # Delete LOG_SOCKET from environment
 env=self.settings.configdict["pkg"]
 if 'LOG_SOCKET' in env:
  del env['LOG_SOCKET']

But I think this can be done better. Do you know a better way?

P.S. The old variant of integration patch is available here:
http://git.overlays.gentoo.org/gitweb/?p=proj/autodep.git;a=blob;f=integration_with_portage.patch;h=ff8f487306e85cbc6ba9e69be6fe613e99b39b53;hb=HEAD

Best,
Alexander Bersenev

2014-02-14 14:08 GMT+06:00 Александр Берсенев :

> Aleksandr
>
>
> 2014-02-14 13:50 GMT+06:00 Greg Turner :
>
> Holy crap, that looks awesome!  How does one pronounce your name,
>> Александр?
>>
>> On Thu, Feb 13, 2014 at 11:28 PM, Александр Берсенев 
>> wrote:
>> > Ok, I'll work on it.
>> >
>> >
>> > 2014-02-13 23:00 GMT+06:00 Rich Freeman :
>> >
>> >> On Thu, Feb 13, 2014 at 11:07 AM, Brian Dolbec 
>> wrote:
>> >> > Yes, if you can please work on updating it.  Please contact us on the
>> >> > gentoo-portage-dev mail list or irc #gentoo-portage for changes to
>> >> > portage that will help keep it working in the future.  I started
>> >> > development of a public_api branch long ago just for having a stable
>> >> > API for apps to use.  Perhaps some of what you need can be integrated
>> >> > there.
>> >>
>> >> Seems like a valuable tool.  It would be best if it could either use
>> >> portage APIs where available, or if effort could be directed at
>> >> incorporating the necessary features into portage or its APIs so that
>> >> you're not stuck maintaining a fork.  I'm sure the portage team will
>> >> help where they can.
>> >>
>> >> Rich
>> >>
>> >
>>
>>
>