Re: [gentoo-dev] [RFC] News item: GCC 4.8.3 defaults to -fstack-protector

2014-06-10 Thread Petteri Räty
On 10.6.2014 5.31, Jeroen Roovers wrote:
 On Mon, 9 Jun 2014 18:16:02 -0600
 Ryan Hill rh...@gentoo.org wrote:
 
 Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
 enabled by default.[..]
 
 .. on supported architectures.
 
 
 Right?
 

I would rather make news items architecture specific if the
functionality differs so we can give the best possible information for
users.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: cleaning away old news items

2013-11-24 Thread Petteri Räty
Hi everyone,
when doing a fresh installation I noticed that during I get to see many
old news items. There used to be a problem with Portage so no news items
could  be removed. I think that has now been fixed for years so we
should be able to do this without problems. How about we start by
cleaning away everything from for example before 2011? Alternatively to
total removal if we want keep them for historical purposes, we could add
conditions that make them impossible to show to anyone.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Temporary DevRel actions for CoC violations

2013-06-20 Thread Petteri Räty
On 20.6.2013 14.01, Matthew Thode wrote:
 On 06/20/2013 03:39 AM, Fabio Erculiani wrote:
 The final outcome I would love to see is that everybody eventually
 graduates from kindergarten :-)
 And perhaps introduce a culture-fit score in the recruiting,
 mentoring process.

 As an employee that works for a company that requires a culture fit
 (very important to us).  This helps a ton.
 

Sounds good in theory but how do you calculate that score? In companies
there's much more interactions that allow to accumulate information for
such things.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Temporary DevRel actions for CoC violations

2013-06-20 Thread Petteri Räty
On 20.6.2013 16.07, Matthew Thode wrote:
 On 06/20/2013 07:49 AM, Petteri Räty wrote:
 On 20.6.2013 14.01, Matthew Thode wrote:
 On 06/20/2013 03:39 AM, Fabio Erculiani wrote:
 The final outcome I would love to see is that everybody eventually
 graduates from kindergarten :-)
 And perhaps introduce a culture-fit score in the recruiting,
 mentoring process.

 As an employee that works for a company that requires a culture fit
 (very important to us).  This helps a ton.


 Sounds good in theory but how do you calculate that score? In companies
 there's much more interactions that allow to accumulate information for
 such things.

 Regards,
 Petteri

 We do it during the interview process.  I kinda think the best analog we
 can do is to watch both before and during the probation period to see
 how well they fit.
 

That's already part of the process. What we can improve is that I don't
remember mentors reporting back on problems during the probation period.
Maybe automate that in some way so the mentors get emails and should
respond.

Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] January stabilization candidates

2013-01-22 Thread Petteri Räty
On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote:
 Please review attached automatically generated stabilization candidates
 for January.
 
 I don't want to annoy people with automatically filed bugs, and at the
 same time I also received lots of positive feedback about the effort to
 keep the stable tree more up-to-date.
 
 I think the best way to proceed is to listen to that feedback and
 continue the effort, while also keeping an updated list of exclusions
 for packagers/herds that are actively stabilized by maintainers.
 

I have an RSS feed for this purpose at:

http://gentoo.petteriraty.eu/stable.rss

Sources are available here:

https://github.com/betelgeuse/scripts/blob/master/rss-changelog

Maybe this is something that should be pushed to official Gentoo
infrastructure so more people know about it and use it?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele

2012-11-30 Thread Petteri Räty
On 24.11.2012 23.12, Pacho Ramos wrote:

 
 # Pacho Ramos pa...@gentoo.org (24 Nov 2012)
 # Doesn't build against recent kernels (#247898), all its supported
 # devices are not supported by latest kernels. Removal in a month.
 net-wireless/linux-wlan-ng-modules
 net-wireless/linux-wlan-ng-utils
 net-wireless/linux-wlan-ng-firmware
 net-wireless/linux-wlan-ng
 

Thanks for the work. You could link here for to provide users
information on the replacement modules:

http://wiki.debian.org/linux-wlan-ng

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

2012-11-19 Thread Petteri Räty
On 19.11.2012 18.33, Rich Freeman wrote:
 On Mon, Nov 19, 2012 at 11:10 AM, Peter Stuge pe...@stuge.se wrote:
 Anthony G. Basile wrote:
 The answer appears to be that a file is the unit

 I personally consider it to be smaller; a number of lines within
 a file, or even a single line, all depending on things.
 
 Yup - any creative expression is copyrightable.  Your two line email
 is completely copyrightable, and so is the one line you quoted.  That
 said, Anthony couldn't have used copyright to prevent you and I from
 quoting him, as it would almost certainly be considered fair use.
 That doesn't mean that his email wasn't copyrightable - only that
 copyright is not an impervious protection.
 

Under Finnish law there's the concept threshold of originality and I
doubt you would get a court to accept a single line of email for that.
There's also a body creating precedent for it but I haven't investigated
their decisions. I tried googling but couldn't find a source for it but
I think FSF has also operated so that they haven't required copyright
assignment for single patches worth a couple lines. This is my memory
from talking to a GNU maintainer some years back.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-19 Thread Petteri Räty
On 18.11.2012 6.28, Greg KH wrote:

 
 Also, you can not assign copyright to a third party, unless you have a
 copyright assignment form.  Do the developers doing this work have such
 a form assigned?  And in what country and state is that form valid for?
 Different countries, and states, have different laws here, and
 one-form-fits-all is not true anywhere.
 

Finnish law doesn't require transferring author's rights to be done with
a written form. Of course it's prudent to have some kind of a permanent
record about it (you need to be explicit about rights to modify and
transfer to third parties). I agree that this is a complex issue and
best left to lawyers if you want to do a thing like this globally.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

2012-11-19 Thread Petteri Räty
On 19.11.2012 19.02, Greg KH wrote:
 On Mon, Nov 19, 2012 at 07:41:54AM -0500, Anthony G. Basile wrote:
 Thank you for these responses because they did help me understand
 copyright/left better.  I appreciate your expertise in the matter
 and would hope I can draw on it again in the future, because despite
 what you said a few emails ago, copyright/left is not something that
 every software developer understands.
 
 I'm curious as to why this is?  Didn't you learn about this in school
 (if you went to school for software development), or from any company
 you have worked for?  At numerous companies I have worked for, it was
 part of the introduction to company FOO, here's your legal training on
 what to do and not to do with regards to open source.  _ANY_ company
 dealing with Linux should have this type of thing in place, otherwise,
 as I have found out first hand, it can get you in big trouble.
 

In Finland you can graduate with a computer science degree without
taking any law related course. There's an optional course on IT law that
is very good but not everyone takes it. For working in a company the law
assigns copyright of source code automatically to the company. For
proprietary shops the training could mostly be about not touching open
source code without prior approval. So in summary my guess is that there
are many open source contributors around who also work in IT who don't
have the exposure to law you think. For people dealing directly with
Linux it's probably as you say.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Merging the devrel handbook into the devmanual

2012-11-01 Thread Petteri Räty
On 31.10.2012 14.39, Michael Palimaka wrote:
 Hi all,
 
 In bug #304435[1], hwoarang suggested merging the devrel handbook[2]
 into the devmanual[3].
 
 As the project has grown, so has the amount - and dispersion - of
 development information. I believe consolidation of this information
 into a single point will make everyone's (especially new developers)
 lives easier.
 
 What do you think?
 

I think you will only find people who support the idea. Some years back
I tried to list people to migrate information on the basis of for
example one page per developer but the actual contributions didn't
amount to much. Let's hope there's renewed energy on this front.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS

2012-10-29 Thread Petteri Räty
On 29.10.2012 18:15, Mike Gilbert wrote:


 
 Good idea to inform users.
 
 Is there a way to have this news item go away, say after a year or so?
 Every time I do a fresh install, I get hit with a couple of
 perpetual news items, and it is a little annoying.
 

News items were designed to be deleted when they are not deleted.
Unfortunately Portage used to crash when that was first tried. I think
it's been quite a long time since that was fixed so it could be safe to
try again.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Petteri Räty
On 22.5.2012 8.53, Michał Górny wrote:


 Excuse me but the way this change was handled is a bit depressing.
 First, the ebuilds should have been fixed to inherit eutils and then
 remove eutils from autotools. Now, a bunch of ebuilds are broken out
 of nowhere. I don't believe this issue was that urgent in order to
 justify the significant breakage of portage tree.
 
 First of all, to quote devmanual:
 
 | Before updating eutils or a similar widely used eclass, it is best to
 | email the gentoo-dev list. It may be that your proposed change is
 | broken in a way you had not anticipated [...]. If you don't email
 | gentoo-dev first, and end up breaking something, expect to be in a
 | lot of trouble.
 
 Not that this disrespect for this rule is something new...
 

Even more important is the next chapter:

When removing a function or changing the API of an eclass, make sure
that it doesn't break any ebuilds in the tree, and post a notice to
gentoo-dev at least 30 days in advance, preferably with a patch included.

This qualifies as changing the API of an eclass. This chapter comes from
a council decision:

http://www.gentoo.org/proj/en/council/meeting-logs/2008-summary.txt

Regards,
Petteri



Re: [gentoo-dev] About validate_desktop_entries in eutils.eclass

2012-04-29 Thread Petteri Räty
On 15.04.2012 17:12, Pacho Ramos wrote:
 El dom, 15-04-2012 a las 16:02 +0200, Michał Górny escribió:
 On Sun, 15 Apr 2012 11:59:50 +0200
 Pacho Ramos pa...@gentoo.org wrote:

 I am unsure about validate_desktop_entries() utility. It's currently
 provided by eutils.eclass and only called by net-firewall/fwbuilder.
 Shouldn't this be moved to a qa check? Current way is pretty useless
 as it's not used by most of packages, and calling it from a lot of
 eclasses/ebuilds doesn't sound me like a good idea.

 What do you think?

 Agreed. It should be in repoman.

 
 The check needs to be run over desktop file going to be installed, not
 sure how repoman can handle it, it looked to me more like a emerge job
 (like is done with other qa checks run before installation)

There's actually already code in repoman that runs
desktop-file-validate. It of course only works for installed packages.
Someone could make it run runtime too.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: newsitem: unmasking udev-181

2012-03-13 Thread Petteri Räty
On 12.3.2012 1.15, William Hubbs wrote:

 How do you plan to handle notifying stable users if you go with ?
 
 I was thinking of another news item once we are ready to go stable.
 
 What do you think?
 
 William
 

We could reuse the same news item if we now release it as = and then
release a new revision when it's ready for stable by changing the atom
to . This way stable users would not get the same item twice.

Regards,
Petteri



Re: [gentoo-dev] Re: newsitem: unmasking udev-181

2012-03-11 Thread Petteri Räty
On 11.03.2012 04:53, Rich Freeman wrote:
 On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs willi...@gentoo.org wrote:
 here is the udev 181 unmasking news item.

 If all goes well, this will be committed to the tree  on 3/14 UTC.
 
 I guess this might be OK for unstable, but before this goes stable we
 really need to improve the docs around this.  As far as I can tell
 neither the genkernel nor dracut docs have specific instructions about
 how to handle mounting /usr.  Since having a separate /usr is often
 the result of having a more complex configuration (nfs, lvm, mdraid,
 etc), instructions explaining how things work and how to handle
 variations is pretty important.  Perhaps genkernel automagically does
 the right thing in some cases, but I know that dracut does not unless
 you properly configure it.  I doubt either tool will handle more
 complex situations without some scripting.
 

The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what point does Portage show it when
the atom is = so we might want to evaluate the options. In the long
term we really should have a new revision that enables something like
Display-If-Installed  Display-If-Unmasked.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: newsitem: unmasking udev-181

2012-03-11 Thread Petteri Räty
On 11.3.2012 17.33, Zac Medico wrote:
 On 03/11/2012 04:03 AM, Petteri Räty wrote:
 The Display-If-Installed atom shows the news item to stable users once
 it's committed. I am not sure at what point does Portage show it when
 the atom is = so we might want to evaluate the options. 
 
 It's displayed after the package is installed, before emerge exits, just
 after the message about config file updates.

Based on this I think = is better than  so people will get when they
actually update.

Regards,
Petteri



Re: [gentoo-dev] Re: newsitem: unmasking udev-181

2012-03-11 Thread Petteri Räty
On 11.3.2012 23.43, William Hubbs wrote:
 On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
 On 11.3.2012 17.33, Zac Medico wrote:
 On 03/11/2012 04:03 AM, Petteri Räty wrote:
 The Display-If-Installed atom shows the news item to stable users once
 it's committed. I am not sure at what point does Portage show it when
 the atom is = so we might want to evaluate the options. 

 It's displayed after the package is installed, before emerge exits, just
 after the message about config file updates.

 Based on this I think = is better than  so people will get when they
 actually update.
 
 That means that people won't be notified that they have the news item to
 read until after they install = sys-fs/udev-181.
 
 Is that how we would want this to work?
 
 William

How do you plan to handle notifying stable users if you go with ?

Petteri



Re: [gentoo-dev] Last rites: media-sound/minitunes

2012-01-21 Thread Petteri Räty
On 21.01.2012 20:08, Markos Chandras wrote:
 On 01/21/2012 05:04 PM, Paweł Hajdan, Jr. wrote:
 On 1/21/12 5:45 PM, Matt Turner wrote:
 On Sat, Jan 21, 2012 at 5:28 AM, Markos Chandras
 hwoar...@gentoo.org wrote:
 # Markos Chandras hwoar...@gentoo.org (21 Jan 2012) # Package
 renamed to media-sound/musique #
 http://flavio.tordini.org/minitunes-renamed-to-musique #
 Removal in 30 days media-sound/minitunes

 Is it normal to wipe out the ChangeLog when renaming the
 package?
 
 I think it's worth to keep it, but I'm not aware of any
 policies...
 
 By the way, I don't think it's necessary to send last rites on
 renames.
 
 The ChangeLog was pretty minimal. Haven't checked but I think it only
 had one entry. I didn't know at that time that last rites was not
 required. I did it properly afterwards
 
 

Neither is updating package.mask if you use profiles/updates. Anyone
unsure how that works feel free to contact me off list for help.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Documentating advanced portage feaetures in Gentoo Handbook

2012-01-03 Thread Petteri Räty
On 3.1.2012 19.51, Sven Vermeulen wrote:

 [2] http://dev.gentoo.org/~swift/docs/previews/hb-portage-advanced.xml
 
 The discussion however is if it is okay to document these things there or
 not. Some of the features are considered to be too fragile to be broadly
 documented (at least in a beginners resource like the Gentoo Handbook) and
 might cause eventual bugs to be closed as RESO:WONTFIX because the user used
 such a feature.
 

A quick read didn't seem like there would be something overly dangerous
or support nightmare producing there.

Regards,
Petteri



Re: [gentoo-dev] Six month major project on Gentoo

2011-12-18 Thread Petteri Räty
On 14.12.2011 13:06, Gaurav Saxena wrote:
 Hello all, 
 I am interested in doing my final year computer scence project on
 gentoo. I would be having a duration of six months to work on the
 project. Could you please suggest me some good project ideas that would
 be helpful to me as well as gentoo. I am interested in parallel
 computing, data structures , operating system. I am well versed in
 C/C++. I think  there might be projects which need to be done, I would
 like to work on them.
 

There are parallel computing aspects in libbash for metadata generation,
data structures in AST building for bash and it's quite low level. Feel
free to contact me off list if you are interested. It would be nice to
get that project back on track again after the last GSoC.

http://www.gentoo.org/proj/en/libbash/index.xml

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] libbash licensing

2011-12-18 Thread Petteri Räty
On 18.12.2011 19:13, Paweł Hajdan, Jr. wrote:
 On 12/18/11 6:02 PM, Petteri Räty wrote:
 There are parallel computing aspects in libbash for metadata generation,
 data structures in AST building for bash and it's quite low level.
 
 By the way, I've always wondered why libbash is separate from the
 upstream bash.
 
 Have you considered contributing to the upstream bash to convert the
 shell itself to a more library-oriented design (somewhat similar to
 LLVM), so that you have a guarantee that the lib and the shell stay in sync?
 

The main reason is that Portage is GPL-2 and bash upstream is GPL-3.
Unless someone is willing to do the work to get Portage to GPL-3 or FSF
to get bash GPL-2 then those two will not mix.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] We need *you* for a USE=selinux dependency

2011-12-04 Thread Petteri Räty
On 04.12.2011 22:35, Sven Vermeulen wrote:
 Hi guys 'n gals
 
 obligatory tl;dr:
   Please check your package below this list and see if it (the package) has
   a proper DEPEND and RDEPEND on the listed sec-policy/selinux-module 
 package(s)
 

The list would be easier to read if it was sorted. Also it should be
quite easy to check automatically that the atoms in place.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] enew{user,group}: killing off [extra] argument

2011-11-06 Thread Petteri Räty
On 03.11.2011 17:30, Mike Frysinger wrote:
 http://sources.gentoo.org/eclass/user.eclass?r1=1.8r2=1.9
 -mike

Less than a day is quite a short time for people to comment. Also it
would be better to include the diff in the original email.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Shutdown of berlios

2011-10-30 Thread Petteri Räty
On 29.10.2011 12.39, Tomáš Chvátal wrote:

 
 If the upstream is dead I have no clear idea what to do, but maybe
 infra could set-up something download.gentoo.org where we could keep
 all the files with their sums and gpg sign from us gentoo devs to
 ensure their validity.
 

The files should stay on our mirrors as long as ebuilds refer to them.
When no ebuilds refer to them do we have any need for the files?

Regards,
Petteri



Re: [gentoo-dev] portability.eclass: dead egethome, egetshell, is-login-disabled funcs ?

2011-10-30 Thread Petteri Räty
On 27.10.2011 2.40, Mike Frysinger wrote:
 i can't see any ebuild/eclass using egethome, egetshell,
 is-login-disabled from portability.eclass.  anyone have a reason for
 keeping these before i punt them ?
 -mike
 

Breaking overlays. Isn't the standing policy still to not break
backwards compatibility as long as an eclass exists?

Regards,
Petteri



Re: [gentoo-dev] Re: gentoo-x86/dev-libs/libffi: ChangeLog libffi-3.0.10_rc8.ebuild libffi-3.0.9.ebuild

2011-09-08 Thread Petteri Räty
On 8.9.2011 16.16, Markos Chandras wrote:
 
 (Consider my refusal to reply any more messages in this thread as
 an polite attempt of avoiding escalation and flame.)
 
 Consider my email as a friendly and polite request to please change
 your ChangeLog behaviour from now on.
 
 
 The changelog entry message is irrelevant in this case since the
 changelog already lists which files were removed ( -foo-1 -foo-2 ) so
 please don't make us restart the old discussion about changelogs which
 will lead us again to nasty and undesired results. Moreover I haven't
 seen you complaining about my Changelogs either ( I use a bare ^
 when removing ebuilds ) so instead of recycling old threads, please
 lets move forward and deal with the auto-generated changelogs once and
 for all.
 

I usually read the Changelog entry before I look at what files have been
changed so the message is not irrelevant for me.

Regards,
Petteri




Re: [gentoo-dev] RFC: devqawarn()?

2011-09-01 Thread Petteri Räty
On 1.9.2011 12.03, Michał Górny wrote:
 Hello,
 
 A quick idea. Right now eclasses sometimes do API changes and start
 yelling at users merging ebuilds using outdates APIs. This often means
 users start filling bugs about outdated ebuilds requiring maintainers
 either to ignore that or start updating old ebuilds retroactively.
 
 Maybe we should add some kind of devqawarn() function to eutils.eclass,
 which would trigger special QA warnings only when ebuild is merged by
 a developer? This could be triggered e.g. by some kind of voluntary
 make.conf setting.
 

What's wrong with eqawarn that's already provided by eutils?

Regards,
Petteri



Re: [gentoo-dev] RFC: devqawarn()?

2011-09-01 Thread Petteri Räty
On 1.9.2011 13.51, Michał Górny wrote:
 On Thu, 01 Sep 2011 13:44:47 +0300
 Petteri Räty betelge...@gentoo.org wrote:
 
 On 1.9.2011 12.03, Michał Górny wrote:
 Hello,

 A quick idea. Right now eclasses sometimes do API changes and start
 yelling at users merging ebuilds using outdates APIs. This often
 means users start filling bugs about outdated ebuilds requiring
 maintainers either to ignore that or start updating old ebuilds
 retroactively.

 Maybe we should add some kind of devqawarn() function to
 eutils.eclass, which would trigger special QA warnings only when
 ebuild is merged by a developer? This could be triggered e.g. by
 some kind of voluntary make.conf setting.


 What's wrong with eqawarn that's already provided by eutils?
 
 The first paragraph?
 

Have Portage defaults so that users only see if them if they read the
merge logs and then developer profiles can set the settings to log them?

Regards,
Petteri



Re: [gentoo-dev] RFC: devqawarn()?

2011-09-01 Thread Petteri Räty
On 1.9.2011 14.31, Michał Górny wrote:
 On Thu, 01 Sep 2011 14:02:11 +0300
 Petteri Räty betelge...@gentoo.org wrote:
 
 On 1.9.2011 13.51, Michał Górny wrote:
 On Thu, 01 Sep 2011 13:44:47 +0300
 Petteri Räty betelge...@gentoo.org wrote:

 On 1.9.2011 12.03, Michał Górny wrote:
 Hello,

 A quick idea. Right now eclasses sometimes do API changes and
 start yelling at users merging ebuilds using outdates APIs. This
 often means users start filling bugs about outdated ebuilds
 requiring maintainers either to ignore that or start updating old
 ebuilds retroactively.

 Maybe we should add some kind of devqawarn() function to
 eutils.eclass, which would trigger special QA warnings only when
 ebuild is merged by a developer? This could be triggered e.g. by
 some kind of voluntary make.conf setting.


 What's wrong with eqawarn that's already provided by eutils?

 The first paragraph?


 Have Portage defaults so that users only see if them if they read the
 merge logs and then developer profiles can set the settings to log
 them?
 
 1) that's changing existing behavior,
 2) what with non-portage users?
 

1) eqawarn == devqawarn. I don't see a reason to come up with a new
function just to avoid changing Portage configuration.

2) How messages from each e* function is shown is left to the package
manager to decide.

One thing to note is that we should get eqawarn into the next EAPI.

Regards,
Petteri



Re: [gentoo-dev] RFC: devqawarn()?

2011-09-01 Thread Petteri Räty
On 1.9.2011 17.12, Donnie Berkholz wrote:
 On 14:44 Thu 01 Sep , Petteri Räty wrote:
 One thing to note is that we should get eqawarn into the next EAPI.
 
 Why?
 

So that it wouldn't fall back on einfo where not available.

Regards,
Petteri



Re: [gentoo-dev] Including a warning to restart daemons after an update.

2011-08-21 Thread Petteri Räty
On 21.08.2011 15:27, Michał Górny wrote:
 On Sun, 21 Aug 2011 07:29:45 -0400
 Anthony G. Basile bas...@opensource.dyc.edu wrote:
 
 OpenSuse has a nice solution.  After an upgrade, it tells you that
 there are some running binaries still linking against the old
 libraries and asks you to run zypper ps to see them in a pretty
 format.  You can then restart at your discretion.

 I'm wondering if we should add something like that?  Something to be
 run post_inst() and just ewarn the user.  It could be a small eclass
 on its own that maintainers can elect to inherit and use in ebuilds
 for daemons.

 What do you think?  If its a good idea, is implementing it in an
 eclass the way to go?
 
 Rather in PM. Portage 2.2 already does some library magic due to
 preserved-libs, why it can't do something in this area too?
 

Yeah seems like something a package manager can implement and wouldn't
necessarily need anything from ebuilds.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

2011-07-27 Thread Petteri Räty
On 27.07.2011 17:30, Chí-Thanh Christopher Nguyễn wrote:
 Donnie Berkholz schrieb:
 Eclasses still shouldn't break backwards compatibility — that hasn't
 changed in the past 5 years, despite what a very small minority of
 devs appears to think. This has been a huge PITA for python.eclass in
 particular, which has broken tons of my ebuilds for no particular
 reason. (And no, a 30-day warning is not an excuse for breaking
 anything.) If you need to edit an eclass for EAPI/API changes anyway,
 updating the inherit line to python-2 instead of python isn't a
 big deal. In the general sense, I think changing the API in arbitrary
 ways based on the EAPI in use is just plain confusing, and it should
 go into a new version-bumped eclass instead. 
 
 I think making the eclass behave differently on new EAPIs is not a bad
 way to deprecate old functions. It will not break any existing ebuilds.
 Only if you touch the ebuild and change the EAPI things may break, but
 then the ebuild has your attention anyway.
 

I agree there's no problem with small deprecations with new EAPIs as
long as they are handled properly (it doesn't break backwards
compatibility) so that ebuilds authors notice they must change things.
If the eclass turns into a wholly different thing then it should rather
be a new eclass.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] useq and hasq

2011-07-08 Thread Petteri Räty
On 08.07.2011 01:21, Dane Smith wrote:
 All,
 In [1] it is noted that the 'useq' and 'hasq' functions are
 Deprecated. If this is the case, do we think it would be pertinent to
 have a repoman warning reminding people to switch to 'use' and 'has'
 respectively?
 

Sounds good. One thing we could consider in future EAPIs is starting to
make deprecated functions die and then remove in the one after.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] useq and hasq

2011-07-08 Thread Petteri Räty
On 8.7.2011 11.55, Ulrich Mueller wrote:
 On Fri, 8 Jul 2011, Michał Górny wrote:
 
 In [1] it is noted that the 'useq' and 'hasq' functions are
 Deprecated. If this is the case, do we think it would be
 pertinent to have a repoman warning reminding people to switch to
 'use' and 'has' respectively?

 Sounds good. One thing we could consider in future EAPIs is starting
 to make deprecated functions die and then remove in the one after.
 
 And what would be the advantage of removing these functions? They have
 zero maintenance cost (as already stated previously, see below).
 

Making sure people don't use them and through that removing the need to
know what the two functions do from new people.

Regards,
Petteri





Re: [gentoo-dev] keywording of new style virtuals

2011-07-06 Thread Petteri Räty
On 06.07.2011 21:55, William Hubbs wrote:
 All,
 
 from my previous discussion, I am about to put a new virtual in the
 tree. Do I need to use the same ~arch/30 day wait/stabilize cycle I
 would normally use even though the default package the virtual will
 bring in is stable everywhere?
 
 I'm thinking I can take the virtual straight to stable in this situation,,
 but I want to be sure.
 

Nothing stable should be using the virtual at the time of commit so
what's the benefit of going stable fast? Repoman should also be
preventing commits straight to stable. I would stable the virtual at the
same time as someone stable starts to use it (which probably means the
30 day period).

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] keywording of new style virtuals

2011-07-06 Thread Petteri Räty
On 06.07.2011 22:45, William Hubbs wrote:
 On Wed, Jul 06, 2011 at 10:17:28PM +0300, Petteri Räty wrote:
 On 06.07.2011 21:55, William Hubbs wrote:
 All,

 from my previous discussion, I am about to put a new virtual in the
 tree. Do I need to use the same ~arch/30 day wait/stabilize cycle I
 would normally use even though the default package the virtual will
 bring in is stable everywhere?

 I'm thinking I can take the virtual straight to stable in this situation,,
 but I want to be sure.


 Nothing stable should be using the virtual at the time of commit so
 what's the benefit of going stable fast? Repoman should also be
 preventing commits straight to stable. I would stable the virtual at the
 same time as someone stable starts to use it (which probably means the
 30 day period).
 
 Actually we could use it faster than that. I want to add a
 virtual/service-manager (see http://bugs.gentoo.org/373843) for
 sys-apps/openrc and sys-apps/systemd then add it to the system set, so
 it would be used immediately everywhere.
 
 That will also make it possible for folks using systemd to remove
 openrc from their systems if they want to do so, which they
 can't right now because baselayout has a PDEPEND on openrc.
 

I don't see why one would need to hurry with changing the system set. On
the contrary I would proceed more cautiously than usual.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The Python problem

2011-06-27 Thread Petteri Räty
On 27.06.2011 15:28, Dirkjan Ochtman wrote:
 
 So I know a bunch of people have already looked at it, and I'd like to
 know: what do you find better about the Ruby approach compared to the
 Python approach? Is it just the size of python.eclass, or are there a
 number of other issues?
 

I like the ruby approach for the reason that it doesn't require users to
run update scripts like python-updater.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The Python problem

2011-06-27 Thread Petteri Räty
On 27.06.2011 19:00, Dirkjan Ochtman wrote:
 On Mon, Jun 27, 2011 at 17:53, Petteri Räty betelge...@gentoo.org wrote:
 I like the ruby approach for the reason that it doesn't require users to
 run update scripts like python-updater.
 
 Sure, but if that means the developers now have to bump every package
 in the tree when a new version of Python comes out, I'm not sure
 that's the best trade-off.
 

And why can't this be handled by the eclass? If the ebuild is able to
specify it supports =3.0 meaning it's expected that future versions
work then the eclass can make the new values available through IUSE when
new python versions are out and ebuilds don't require any changes.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-ruby/fromcvs: metadata.xml ChangeLog fromcvs-0_pre132.ebuild

2011-06-19 Thread Petteri Räty
On 19.06.2011 11:06, Hans de Graaff wrote:
 On Sat, 2011-06-18 at 14:14 +0300, Petteri Räty wrote:
 On 18.06.2011 09:16, Hans de Graaff wrote:

 RDEPEND=dev-ruby/rcsparse =dev-ruby/rbtree-0.3.0-r2 dev-vcs/git

 The ruby-ng eclasses frob RDEPEND, so you should always add to it, e.g.

 RDEPEND=${RDEPEND} dev-vcs/git


 This stacking is automatically handled by the package manager.
 
 We also add dependencies to RDEPEND in the eclass and I seem to remember
 from previous bug hunting that just setting RDEPEND and/or DEPEND caused
 problems with these dependencies disappearing. It's been too long ago so
 I don't have details, but if that is considered a bug then I can
 probably try to track that down again.
 
 Kind regards,
 
 Hans

Yes it would be a bug. The rules are here:
http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-11600011.2

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-ruby/fromcvs: metadata.xml ChangeLog fromcvs-0_pre132.ebuild

2011-06-18 Thread Petteri Räty
On 18.06.2011 09:16, Hans de Graaff wrote:
 
 RDEPEND=dev-ruby/rcsparse =dev-ruby/rbtree-0.3.0-r2 dev-vcs/git
 
 The ruby-ng eclasses frob RDEPEND, so you should always add to it, e.g.
 
 RDEPEND=${RDEPEND} dev-vcs/git
 

This stacking is automatically handled by the package manager.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] write to filesystem in pkg_pretend

2011-06-18 Thread Petteri Räty
On 17.06.2011 20:18, Mike Frysinger wrote:
 On Friday, June 17, 2011 12:25:21 Torsten Veller wrote:
 * justin j...@gentoo.org:
 Now using the new pkg_pretend for EAPI=4

 While T is defined in all phases, PMS also says that pkg_pretend must
 not write to the filesystem.

 Is it allowed to write to T or not? Can the specs be clearer if it's
 allowed?
 
 sounds like a good reason to use emktemp as that'll utilize /tmp for files 
 when $T is unavailable
 

That approach would still write to the filesystem. With the current text
the PM is probably allowed to set the sandbox so that writing is
anywhere is denied.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

2011-06-11 Thread Petteri Räty
On 10.06.2011 14:44, Sebastian Pipping wrote:
 On 06/09/2011 03:37 PM, Rich Freeman wrote:
 do we need some kind of policy around membership on special
 project teams. QA and Devrel are the most obvious examples, Infra might
 be another.
 
 in my eyes we do.  too much power to be unregulated.
 
 what does it take to get this rolling?
 

Getting someone to write a draft GLEP and submitting it for discussion.
If you want to only cover QA then modifying GLEP 48 is enough but if we
want end up covering multiple teams I would make a new GLEP.

Regards,
Petteri

PS. this thread should be on gentoo-project



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

2011-06-11 Thread Petteri Räty
On 10.06.2011 18:33, Francisco Blas Izquierdo Riera (klondike) wrote:

 * Samuli, extremist right wing parties are gaining power in your
 country, I think this is a way better reason to rebel than a stupid file.

True Finns are not right wing. The foreign media seems to always get it
wrong. They are a populistic conservative party. On the traditional
left-right axis they are quite center. The parties with seats in the
parliament are characterized for example here:

http://www.loitto.com/tilastot/hsvaalikone11/rotaatiotulos-ellipsit.png

The article is here (don't know how well Google translate will do):
http://www.loitto.com/tilastot/hsvaalikone11/

True Finns are marked with purple (at the bottom).


 It is up to you, meanwhile I'll keep fighting for the camped
 people in Spain instead of some random piece of documentation.
 

It was a fair election and should be respected even if one doesn't like
the results. True Finns got a little below 20% of the vote so not
knowing anything about Samuli's political views (not even any of my
business any way) it's certainly possible that he voted for the cause
you are trying to rally against. They do have problematic individuals in
their ranks who can reflect badly on the party but if they break the law
they are handled according to the law is it should be.

In conclusion I don't think there's anything to rebel against with True
Finns but I agree that we could focus our energy better.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Council May Summary: Changes to ChangeLog handling

2011-05-17 Thread Petteri Räty
http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt

Please note that you must now update ChangeLog with each commit. For
more information please see the meeting log and the preceding mailing
list thread:

http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt
http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml

On behalf of the council,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Crossdev / glib news item

2011-05-17 Thread Petteri Räty
On 05/15/2011 09:24 PM, Andreas K. Huettel wrote:
 
 --
 If you are cross-compiling to a 32-bit architecture such as ARM, or if 
 you are using a 32-bit architecture and have sys-devel/crossdev installed,
 please be warned that - unless you follow the advice below - your system
 may become seriously broken.
 
 We have recently fixed bug 367351 in sys-devel/crossdev, where the size of 
 the pthread_mutex_t type was hardwired incorrectly into configure scripts.
 Unfortunately, if the size was incorrect before, switching to the correct
 value changes the ABI of libgthread. All binaries linked against the previous
 glib may thus simply crash. 
 
 You will have to ensure the ABI stability before upgrading crossdev.
 Information on how to fix this is available at the following URL:
   http://blog.flameeyes.eu/2011/05/15/
 ---
 
 Opinions?
 

Please post the full news item with headers. For example the filter
headers are quite central.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: *_iface variables in openrc network scripts

2011-05-12 Thread Petteri Räty
On 05/12/2011 04:55 AM, William Hubbs wrote:
 Yeah I know I'm replying to my own message, but I also have another idea
 about this. Another option would be that for the next release we just
 stop parsing and use config_* but without trying to do any conversions.
 
 The disadvantage of this would be that people would have to change their
 /etc/conf.d/net files immediately after they upgrade or their network
 might not come up.
 
 It is true that this would be easier from a coding perspective, but
 would it be ok for the users?
 

The ebuild could try to detect mismatch in syntax and then emerge
--config could provide migration. I don't think users will mind as long
as they are able to avoid unreachable systems :)

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-30 Thread Petteri Räty
On 04/30/2011 07:39 AM, Samuli Suominen wrote:

 
 sources.gentoo.org is for that.   ChangeLog is for users, and old is
 not useful information to them
 
 So no, I won't start cluttering up ChangeLogs and I would prefer if
 others would stop it as well
 


Individual developers (especially QA project members) should not be
ignoring policies when they feel like it.

http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html

If you want to try and change the policy then put it on the agenda of
the next council meeting as there does not seem to be a consensus
backing your opinion. Until then everyone is expected to play by the rules.

Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-30 Thread Petteri Räty
On 04/30/2011 10:22 AM, Andreas K. Huettel wrote:
 
 I'd suggest having repoman force a changelog entry on ebuild removal.
 

Opened yesterday:
http://bugs.gentoo.org/show_bug.cgi?id=365361

Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-30 Thread Petteri Räty
On 04/30/2011 11:12 AM, Samuli Suominen wrote:
 
 It no where in the link you provided mentions ChangeLog is required for
 removals. Removing an unused ebuild is not the same as making changes to
 an ebuild.
 
 We have no policy for logging removals. And that's like it should be.
 

It doesn't explicitly mention adding new ebuilds either so that's
optional too? I thought this issue would already be covered by common
sense but as it doesn't seem so we can clarify the issue in the next
council meeting.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-30 Thread Petteri Räty
On 04/30/2011 11:35 AM, Ulrich Mueller wrote:
 On Sat, 30 Apr 2011, Petteri Räty wrote:
 
 Individual developers (especially QA project members) should not be
 ignoring policies when they feel like it.
 
 http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
 
 While I'm all for adding a ChangeLog entry when removing an ebuild,
 this devmanual section doesn't say anything about it. It mentions only
 changes to ebuilds, not removals.
 

For me a removal is a change to the set of ebuilds in a package. Any way
I will start a new thread for a clearer text.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Devmanual text on ChangeLogs

2011-04-30 Thread Petteri Räty
http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html

There doesn't seem to be a common opinion on what the policy for
ChangeLog entries is. See:

http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml

I propose a simple new text: Every commit should have an entry in
ChangeLog. If we eventually autogenerate them from git logs this would
happen any way (unless some kind of filtering system is in the middle)
so we could already start now. I think it's better to have more than
less information available to users.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rejecting unsigned commits

2011-03-24 Thread Petteri Räty
On 03/24/2011 11:59 PM, Mike Frysinger wrote:
 is there any reason we should allow people to commit unsigned
 Manifest's anymore ?  generating/posting/enabling a gpg key is
 ridiculously easy and there's really no excuse for a dev to not have
 done this already.
 

Also submitting the quizzes require you to have a GPG key. This probably
hasn't been a priority before all the tree can be signed. I think it
would be idea to start preparing for that by requiring people sign as
you said.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] updating GLEP 1

2011-03-09 Thread Petteri Räty
On 03/10/2011 12:19 AM, Mike Frysinger wrote:
 the first GLEP is listed as Active, yet its information is out of date.  it
 talks about GLEP editors and Gentoo Managers, neither of which exist anymore. 
 basically, it still refers to the old management structure and not the
 Council.  so rather than confuse people (since we explicitly quiz people on
 this), how about this update:
 
 --- glep-0001.txt 5 Jun 2008 06:05:32 -   1.12
 +++ glep-0001.txt 9 Mar 2011 22:18:07 -
 @@ -98,21 +98,20 @@ the form of code, patch, or URL to same 
  
  GLEP authors are responsible for collecting community feedback on a GLEP
  before submitting it for review.  A GLEP that has not been discussed on
 -gentoo-...@gentoo.org and/or the Gentoo Linux forums [#FORUMS]_ will not be
 +gentoo-...@gentoo.org and the Gentoo Linux forums [#FORUMS]_ will not be
  accepted.  However, wherever possible, long open-ended discussions on public
  mailing lists should be avoided.  Strategies to keep the discussions 
 efficient
  include setting up a specific forums thread for the topic, having the GLEP
  author accept private comments in the early design phases, etc.  GLEP authors
  should use their discretion here.
  

Have GLEPs in practice been sent to the forums? I think this requirement
could be dropped and just have a single place for discussion.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Bugzilla - New Default Status Workflow

2011-03-06 Thread Petteri Räty
On 03/06/2011 02:22 PM, Christian Ruppert wrote:
 Hey guys,
 
 in bugzilla-4.x they did change the Status Workflow[1].
 
 snip
 This will convert the status of all bugs using the following
 system:
 

   REOPENED will become CONFIRMED (and the REOPENED status will be
 removed)

We would be loosing information here (at least you would need to go
looking at bug history to find it). Would it be possible to have the new
workflow + REOPENED? Would other statuses continue to exist like before?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Rewrite java-config in C++ or python

2011-02-26 Thread Petteri Räty
On 02/26/2011 07:08 PM, Daniel Pielmeier wrote:
 2011/2/21 Uditha Galgamuwa nandun8...@gmail.com:
 Hi dev,
I am Uditha Galgamuwa from university of moratuwa,Sri Lanka.I am
 interested in the project idea Rewrite java-config in C++ or python which
 was in last year Gsoc.As I saw this project has not been implemented in Gsoc
 2010.Will this be available for this year's idea list from Gentoo
 foundation? I have good knowledge on programming with java and some
 knowledge on C++  and a basic understanding about XSLT as well.
 
 It is on the list for 2011 (1), so I guess you can apply for it.
 
 (1) http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas
 

The list started out with a copy of ideas from last year that were not
finished successfully. This means no-one might be interested in
mentoring for the projects listed there this year. It should also be
remembered that you don't need to restrict yourself to the ideas
presented there. For any further discussion I suggest reading the Read
this first section and noticing that there is a gentoo-soc mailing list.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News item: Dropping Java support on ia64 (retry)

2011-02-15 Thread Petteri Räty
On 02/15/2011 05:15 PM, Vlastimil Babka wrote:
 Hi,
 
 since Betelgeuse didn't actually commit the news item in November,
 here's my try. Slightly reworded the text, comments welcome. Otherwise I
 plan to commit this on Friday.
 

Thanks for picking this up again.

Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Make sound a global USE flag?

2011-02-07 Thread Petteri Räty
On 02/07/2011 03:15 PM, Samuli Suominen wrote:

 
 
 +1 with exception that those using USE=sound for libcanberra should be
 split into it's own USE flag called USE=libcanberra
 and USE=sound should be kept for the generic ones
 

libcanberra describes the means and not the results so we should try to
come up with something else.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Make sound a global USE flag?

2011-02-07 Thread Petteri Räty
On 02/07/2011 08:08 PM, Samuli Suominen wrote:
 On 02/07/2011 07:55 PM, Petteri Räty wrote:
 On 02/07/2011 03:15 PM, Samuli Suominen wrote:



 +1 with exception that those using USE=sound for libcanberra should be
 split into it's own USE flag called USE=libcanberra
 and USE=sound should be kept for the generic ones


 libcanberra describes the means and not the results so we should try to
 come up with something else.

 Regards,
 Petteri

 
 The means are commonly used as USE flag names with result in USE
 flag description.  Think of gstreamer, or xine for example.
 
 But I'm open to suggestions...
 

How about event-sounds?

libcanberra is an implementation of the XDG Sound Theme and Name
Specifications, for generating event sounds on free desktops, such as
GNOME.

http://0pointer.de/lennart/projects/libcanberra/#overview

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Suggestion: Portage should not mask packages globally, but only for some arches

2011-02-03 Thread Petteri Räty
On 02/02/2011 11:42 PM, Theo Chatzimichos wrote:

 
 For the record, Kacper told me today that every developer is allowed to touch 
 ppc/ppc64 profiles. Archies that don't want others to touch their profiles 
 should mention it in the devmanual. I was not aware of that, I thought that 
 !arch member is not allowed to touch arch-specific profiles. Anyway, KDE 4.6 
 will be unmasked tomorrow.


The general rule I have been using is that if the profile change only
has an effect on the package you maintain then it's ok to do it
yourself. This is probably something that should be nailed down
somewhere. I think I will propose it for the next council meeting.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

2011-01-31 Thread Petteri Räty
On 01/31/2011 07:04 AM, Jeroen Roovers wrote:
 
 2.  I don't think it makes sense for QA to discipline developers
 permanently in these cases.  They should suspend access pending Devrel
 resolution of the issue.  Devrel should of course strongly consider
 the input of QA.
 
 That should be anyone's input, really. If a Gentoo Linux user finds a
 nasty `rm -rf /' timebomb, I suppose he could point that out to infra
 directly. And it's infra that suspends access, by the way. And devrel
 should be the intermediate between developers. And QA aims to keep the
 portage tree in a consistent state[1]. Wait, everyone is already in
 place?
 

Actually recruiters can also suspend commit access and DevRel lead has
used that to safe guard the tree in the past.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

2011-01-29 Thread Petteri Räty
On 01/29/2011 12:42 AM, Rich Freeman wrote:

 
 Finally, if Devrel, QA, and the Council have already talked this out
 and agree that QA is in the best place to police technical commit
 issues, then pipe this email to /dev/null...
 

The diff proposed in this thread has not yet been talked about within
either Council or DevRel. The next council meeting should be at most
about talking about the diff and not making a decision as I wrote to the
council agenda thread on gentoo-project. I am rather busy this weekend
so I will have to get back to this thread next week.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] app-emulation/virtualbox-ose got renamed to app-emulation/virtualbox

2011-01-08 Thread Petteri Räty
On 01/07/2011 11:15 PM, Lars Wendler wrote:
 Sorry guys,
 
 after thinking about it I definitely chose the wrong lists. Won't happen 
 again...
 

Also I wonder why the moderators thought this was appropriate for
-dev-announce?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?

2011-01-03 Thread Petteri Räty
On 01/03/2011 04:40 PM, Samuli Suominen wrote:
 Quoting PMS, Chapter 8:
 
 All ebuild-defined variables discussed in this chapter must be defined
 independently of any system, profile or tree dependent data, and must
 not vary depending upon the ebuild phase.
 
 http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
 
 
 
 This is very inconvinent rule for example, github tarballs where the
 directory changes with every release. I've used this:
 
 src_unpack() {
   unpack ${A}
   cd *-${PN}-*
   S=`pwd`
 }
 

This code could be simplified as:
S=*-${PN}-*

 $ mkdir foo-1.2.3
 $ PN=foo
 $ S=foo-*
 $ echo $S
foo-1.2.3

 
 
 Far as I know, S= isn't used to generate metadata cache, so it's PMS
 that need fixing for it's wording:
 
 All ebuild-defined variables used to generate metadata cache, discussed
 in this chapter...
 

It can be done retroactively if Portage has always worked with S being
defined inside phases and if that doesn't work then it can always be
part of EAPI 5. I opened a bug to track the request:

https://bugs.gentoo.org/show_bug.cgi?id=350478

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

2011-01-02 Thread Petteri Räty
On 01/02/2011 05:19 PM, Jorge Manuel B. S. Vicetto wrote:

 
 
 One way we could drop EAPI 0 would be if we do a major review of tree
 and repo formats to improve upgrade paths, which would however likely
 require breaking backwards compatibility at such point.
 I believe such a change would only be acceptable, if we would pack
 enough features and safety measures that it would ensure another break
 would not need to be done for a long time.
 

It's quite likely that if you are currently on a system with Portage
that does not understand EAPI 1 there's so many obstacles along the
upgrade path that a clean install makes more sense. Maybe someone is
willing to test this so that we actually know if there is an upgrade
path from EAPI 0 available any more.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

2011-01-02 Thread Petteri Räty
On 01/02/2011 11:04 PM, Joshua Saddler wrote:
 
 Whatever you folks eventually settle on, please send patches and
 suggestions to the GDP for our upgrade guide. I'd prefer that users
 have a possible upgrade path from *any* profile/version of Gentoo up
 through the present. If you decide not to support anything older than
 version X and require reinstalling or some other set of procedures,
 please let the GDP know via our ML or bugzilla.


The current hard requirement is one year:
http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt

The follow up discussion probably didn't end up in any concrete
decisions. If we want to actually make sure upgrades from old installs
(1 year) work then we should setup some kind of a bot doing upgrades.
It would then provide the documentation for the upgrade path and make
sure it keeps working.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] EAPI 4 specification approved

2011-01-01 Thread Petteri Räty
On 12/31/2010 12:29 PM, Zac Medico wrote:
 On 12/30/2010 07:37 AM, Petteri Räty wrote:
 As the text was just approved it will take a while before Package
 Managers release new versions that declare support for EAPI 4. As such,
 the new EAPI 4 can't yet be used in the main tree. You will be notified
 as soon as you can start reaping the benefits.
 
 There are portage-2.1.9.27 and 2.2.0_alpha11 releases with EAPI 4
 support in the tree now. Please test them.

For these who are wondering about the current status we need to have
these two bugs (at least) resolved before allowing usage in the tree:

https://bugs.gentoo.org/show_bug.cgi?id=322049
https://bugs.gentoo.org/show_bug.cgi?id=211529

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

2010-12-31 Thread Petteri Räty
On 12/31/2010 01:02 PM, Ulrich Mueller wrote:
 Hi,
 
 after approval of EAPI 4, there are now 5 different EAPIs available,
 and it's hard to remember what features are offered by which EAPI.
 
 So maybe it's about time that we deprecate EAPIs 0 and 1 for new
 ebuilds. As a first step, a warning could be added to repoman that
 would be triggered whenever a new ebuild with an EAPI less than 2 is
 committed.
 

First we need to be sure that all relevant eclasses support upgrading to
EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some
eclasses are too. But I do second the idea of trying to limit the set of
active EAPIs in the tree. Please open a repoman bug if there are no
objections.

 At a later time, the warning could be changed to an error. When most
 of the tree has been updated to EAPI 2 or newer, we could also think
 about actively converting the remaining ebuilds. (Currently this
 doesn't look feasible though, as about half of the tree is still at
 EAPI=0. [1])
 

EAPI 0 might stick around for quite a while but for example deprecating
EAPI 1 shouldn't be as hard.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] EAPI 4 specification approved

2010-12-30 Thread Petteri Räty
To finish the year with a bang the Gentoo council has approved the
specification for EAPI 4. You can get the text via app-doc/pms (as soon
as a new ebuild hits the mirrors) or from the git repository. The gitweb
for PMS can be found here:
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git

As the text was just approved it will take a while before Package
Managers release new versions that declare support for EAPI 4. As such,
the new EAPI 4 can't yet be used in the main tree. You will be notified
as soon as you can start reaping the benefits.

On behalf of the Gentoo Council,
Petteri Räty



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-geosciences/mapserver: mapserver-5.4.2-r1.ebuild ChangeLog

2010-12-26 Thread Petteri Räty
On 12/24/2010 11:19 AM, Justin (jlec) Lecher wrote:
 On 24/12/10 02:18, Arfrever Frehtes Taifersar Arahesis wrote:
 What do you mean about python.eclass?
 python.eclass doesn't define python_src_unpack().

 
 No it doesn't, but calling the default() function in a phase will make
 the default phase be called. And this is implemented in the python.eclass.
 

default calls the PM implementation, not the eclass implementation.

From PMS:

default

Calls the default_ function for the current phase (see section 10.1.17).
Must not be called if the default_ function does not exist for the
current phase in the current EAPI. Only available in EAPIs listed in
table 12.14.

10.1.17:

DEFAULT-In EAPIs listed in table 10.8 as supporting default_ phase
functions, a function named default_(phase) that behaves as the default
implementation for that EAPI shall be defined when executing any ebuild
phase listed in the table. Ebuilds must not call these functions except
when in the phase in question.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Death to old-style virtuals!

2010-12-26 Thread Petteri Räty
On 12/17/2010 08:08 PM, Ciaran McCreesh wrote:
 Old-style virtuals are extremely messy and introduce an awful lot of
 complexity. They were supposed to be on the way out several years ago,
 with GLEP 37, but that seems to have stalled.
 
 Is there anything in particular holding back replacing most or all of
 the remaining old-style virtuals with new 'package' virtuals?
 

I would create a tracker bug for getting rid of the old style things.
Then perhaps EAPI 5 could not support old style virtuals.

 
 There's still that stupid !virtual/blah thing to deal with. Old style
 virtual providers are allowed to block their own virtual to mean there
 must not be any other provider of this installed (although it's not
 clear what that means if anything other than a simple !virtual/pkg is
 used). Anything doing that would now have to explicitly list its own
 blocks. Arguably, this is a good thing, since you'd have to say exactly
 what you do and don't work with.
 

The cases where this is needed could declare the full list of providers
in an eclass. Are there any problems with this approach besides the
increased maintenance burden?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Technical talk ideas for FOSDEM

2010-12-15 Thread Petteri Räty
On 12/13/2010 11:00 PM, Roy Bamford wrote:
 
 Markos,
 
 Interesting - How can you address future strategy and plans without 
 addressing Gentoos meta structure too. It could not be a purely 
 technical talk ... but thats what interests me.
 

There's no restriction for the talks to be technical but since I posted
on gentoo-dev I thought I would keep this thread more in the technical
domain.

 It might be very Gentoo specific though.
 

There's no requirement for all the talks to apply to multiple
distributions so being Gentoo specific is not a problem. Of course it
should attend some audience too to be useful.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Technical talk ideas for FOSDEM

2010-12-12 Thread Petteri Räty
I tried getting input for talks from gentoo-user but so far there have
been no responses. Currently there aren't that many talks proposed for
the distribution miniconf so it should be easy to get purely Gentoo
related topics in. So what kind of Gentoo related talks would you like
to see and possibly would attend at FOSDEM? Please present your ideas
and I will then try and find speakers + get them submitted.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Masking automake-1.9?

2010-12-02 Thread Petteri Räty
On 2.12.2010 3.03, Diego Elio Pettenò wrote:
 Hi all,
 
 Not sure if you know but we're currently experiencing a spur of build
 failures related to eautoreconf (in particular, eaclocal) and
 libtool-2.4 The new libtool release only works with automake 1.9 and
 later. [1]
 

Maybe we should start with !automake-1.9 for libtool =2.4 ebuilds?
This would force action but people could still keep installing stuff
needing older automake version by masking latest libtool.

Regards,
Petteri



Re: [gentoo-dev] Re: Masking automake-1.9?

2010-12-02 Thread Petteri Räty
On 2.12.2010 15.38, Diego Elio Pettenò wrote:
 Il giorno gio, 02/12/2010 alle 10.19 +0200, Petteri Räty ha scritto:

 Maybe we should start with !automake-1.9 for libtool =2.4 ebuilds?
 This would force action but people could still keep installing stuff
 needing older automake version by masking latest libtool. 
 
 As Mike said it makes no sense because automake is slotted, and in
 particular it makes even less sense because you can still use automake
 1.6 just fine, as long as you don't use libtool _with_ it.
 

Ok thanks for clarifying the last point. Doesn't this go against your
original wish to mask it though?

Regards,
Petteri



Re: [gentoo-dev] Re: Re: Masking automake-1.9?

2010-12-02 Thread Petteri Räty
On 2.12.2010 17.31, Diego Elio Pettenò wrote:
 Il giorno gio, 02/12/2010 alle 17.24 +0200, Petteri Räty ha scritto:

 Ok thanks for clarifying the last point. Doesn't this go against your
 original wish to mask it though? 
 
 If you read my first mail, I said I want them masked, and not removed
 because they are still useful for upstream work.
 

In my mind I associate masking with eventual removal.

 Being useful for upstream work, I don't want them being unavailable or
 unusable, which would happen if you were to block them on newer libtool
 just as much as it would happen by removing them.
 
 The mask might be something along the lines of
 
 # Obsolete automake packages, only useful for upstream work.
 # Do not depend on them, and don't install them unless you really
 # need to use them.
 
 (And having them masked, repoman will complain if somebody was to use
 WANT_AUTOMAKE=1.4).
 

Sounds like an ok compromise.

Regards,
Petteri



Re: [gentoo-dev] Extending EAPI=4

2010-11-28 Thread Petteri Räty
On 11/28/2010 11:56 PM, Arfrever Frehtes Taifersar Arahesis wrote:

 It seems like the problem here is that we don't have separate profiles
 for stable and unstable keywords. The obvious solution would be to have
 separate profiles, mask the flags in the stable profiles, and unmask the
 flags in the unstable profiles. That way, repoman would continue to
 protect stable profile users from unsatisfiable dependencies, without
 unnecessarily masking those choices from unstable profile users.
 
 I would prefer small number of additional files instead of huge proliferation 
 of profiles.
 You also suggested using EAPI=4-specific profiles instead of EAPI-versioned 
 files, so eventually
 we might have about 4 times more profiles :) .
 

There's no requirement to keep old profiles around indefinitely. Old
profiles will eventually go away once the new ones are the recommended
option. As for this particular case I haven't really taken a close
enough opinion to say if new profiles make the best sense or not.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] News item: Dropping Java support on ia64

2010-11-14 Thread Petteri Räty
Any improvements to the text are welcome.

Regards,
Petteri
Title: Pending Removal of Java support in ia64
Author: Petteri Räty betelge...@gentoo.org
Author: IA64 Arch Team i...@gentoo.org
Content-Type: text/plain
Posted: 2010-11-14
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: ia64
Display-If-Installed: dev-java/java-config

The IA64 arch team does not have the resources to maintain Java support so we
agreed that support will be dropped unless more man power becomes available.
If you are willing to help maintaining support please contact i...@gentoo.org.
If there is no interest the removal of Java support well be done during week
50 of year 2010.

The removal is tracked in bug #345433.


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] mercurial.eclass: change clone destination

2010-11-13 Thread Petteri Räty
On 11/10/2010 07:16 PM, William Hubbs wrote:
 On Mon, Nov 08, 2010 at 10:05:17PM +0200, Petteri R??ty wrote:
 On 11/08/2010 06:17 AM, Donnie Berkholz wrote:
 On 16:42 Sun 07 Nov , Petteri R??ty wrote:
 On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
 Hello,

 I'm sending this patch for discussion, what it changes? The change is to 
 where
 the final clone of repository will be placed, it used to be 
 ${WORKDIR}/${module}
 (where module usually is the last component of source URI) to 
 ${WORKDIR}/${P}
 (essentially ${S}). This has few effects:
  - ebuilds using mercurial.eclass don't need to set S any longer
  - mercurial.eclass behaves more like git.eclass
  - it breaks all existing ebuilds using this eclass

 Which means that the doing the chance is not allowed as eclasses must
 remain backwards compatible.

 Is that really still the case now that full environments have been saved 
 for a number of years? Clearly breaking things is unacceptable, but I 
 could envision someone simultaneously updating the eclass and all 
 consumers.


 There's no full environment saved before the package is installed and I
 don't see why we should break overlays.
 
 I didn't think we had to care about overlays since they aren't the main
 tree?  After all, how can we be sure what is happening in all overlays
 out there?
 
 I could see this, like Donnie says, if he wasn't going to fix all of the
 ebuilds.  However I don't see a problem with it since he said he is
 going to fix all of the ebuilds.
 

If there are options that don't require breaking with no big downsides
then we should rather go with them. There usually are.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News item for restructuring of hardened profiles.

2010-11-10 Thread Petteri Räty
On 11/10/2010 02:42 PM, Peter Volkov wrote:
 В Втр, 09/11/2010 в 18:20 -0500, Anthony G. Basile пишет:
 Title: Restructuring of Hardened profiles
 [...]
 Display-If-Profile: hardened/linux
 
 Is it possible to restrict this news item to be shown on affected
 profiles only?
 

Yeah it shouldn't show up in new installs that are already using the
migrated profiles.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] mercurial.eclass: change clone destination

2010-11-08 Thread Petteri Räty
On 11/08/2010 06:17 AM, Donnie Berkholz wrote:
 On 16:42 Sun 07 Nov , Petteri Räty wrote:
 On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
 Hello,

 I'm sending this patch for discussion, what it changes? The change is to 
 where
 the final clone of repository will be placed, it used to be 
 ${WORKDIR}/${module}
 (where module usually is the last component of source URI) to 
 ${WORKDIR}/${P}
 (essentially ${S}). This has few effects:
  - ebuilds using mercurial.eclass don't need to set S any longer
  - mercurial.eclass behaves more like git.eclass
  - it breaks all existing ebuilds using this eclass

 Which means that the doing the chance is not allowed as eclasses must
 remain backwards compatible.
 
 Is that really still the case now that full environments have been saved 
 for a number of years? Clearly breaking things is unacceptable, but I 
 could envision someone simultaneously updating the eclass and all 
 consumers.
 

There's no full environment saved before the package is installed and I
don't see why we should break overlays.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] mercurial.eclass: change clone destination

2010-11-07 Thread Petteri Räty
On 11/06/2010 11:22 AM, Krzysztof Pawlik wrote:
 Hello,
 
 I'm sending this patch for discussion, what it changes? The change is to where
 the final clone of repository will be placed, it used to be 
 ${WORKDIR}/${module}
 (where module usually is the last component of source URI) to ${WORKDIR}/${P}
 (essentially ${S}). This has few effects:
  - ebuilds using mercurial.eclass don't need to set S any longer
  - mercurial.eclass behaves more like git.eclass
  - it breaks all existing ebuilds using this eclass
 

Which means that the doing the chance is not allowed as eclasses must
remain backwards compatible.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Changes in server profiles

2010-10-29 Thread Petteri Räty
On 29.10.2010 15.02, Jorge Manuel B. S. Vicetto wrote:

 
 2) Furthermore I would like to drop the following use flags from default
 IUSE
 
 -apache2
 -ldap
 
 A minimal server installation does requires neither apache2 nor ldap 
 
 Although one can install a server without apache or ldap, I'd say the
 server profile seems the natural choice to have them enabled.
 If we had the statistics for it, we could check how many people have
 apache installed with that profile vs not having it. As there's nothing
 preventing one from having USE=-apache2 -ldap when required and I
 don't use the server profiles, I don't really have a strong opinion
 about this.
 

And enabling a use flag should be question of is it wanted when a
package actually support those flags. On a server when you are
installing a package with a apache use flag it's certainly possible to
you would like to have it enabled more often than not.

Regards,
Petteri



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass

2010-10-25 Thread Petteri Räty
On 10/25/2010 02:54 PM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
 arfrever10/10/25 11:54:19
 
   Modified: python.eclass
   Log:
   Set IUSE in EAPI =4.
   Rename _parse_PYTHON_DEPEND() to _python_parse_PYTHON_DEPEND() and unset it 
 after its using.
   Ban NEED_PYTHON variable.
   Add python_abi_depend().
   Fix exporting of python_pkg_setup() in EAPI =4.
 

Please revert these until council has approved EAPI 4 for main tree
usage or risk the consequences. There is no guarantee that IUSE will be
in EAPI 4 although it's likely. If you want such pre-emptive actions in
the main tree you should seek our approval first.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Extending EAPI=4

2010-10-25 Thread Petteri Räty
On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote:
 I would like to request that 2 additional features are added to EAPI=4.
 These features will be needed for further development of python.eclass.
 
 1. Support for . characters in names of USE flags

Ideally we should have consistency across languages so if we go down
this road then for example ruby should eventually support it too. Ruby
people: can you provide your input.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Patch for python.eclass

2010-10-24 Thread Petteri Räty
On 10/23/2010 11:54 PM, Arfrever Frehtes Taifersar Arahesis wrote:
 Subpatch #11 adds temporary support for EAPI=0 in 
 python_get_implementational_package() to work
 around a part of bug #340395.
 This subpatch is very small, so I'm planning to commit it with the rest of 
 subpatches.
 

Please respond to my comment about EAPI 4 before committing.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Patch for python.eclass

2010-10-24 Thread Petteri Räty
On 10/24/2010 09:49 PM, Arfrever Frehtes Taifersar Arahesis wrote:
 2010-10-18 17:26:13 Petteri Räty napisał(a):
 On 10/18/2010 04:33 AM, Arfrever Frehtes Taifersar Arahesis wrote:

 Subpatch #10 fixes exporting of python_pkg_setup() in EAPI =4.

 There will be other changes in API of python.eclass in EAPI =4, so 
 python.eclass still doesn't
 support EAPI=4.


 EAPI 4 is not approved yet. Ebuilds can't use it yet so I don't think we
 should start migrating eclasses before it's final.
 
 Porting of python.eclass to EAPI=4 has started some months ago and will 
 take at least
 1 additional month, so it's better to perform it earlier.
 

Usage of new EAPIs in the tree is not allowed before council approval.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] QA last rites: media-video/elltube

2010-10-23 Thread Petteri Räty
On 10/23/2010 08:51 PM, Markos Chandras wrote:
 On Sat, Oct 23, 2010 at 08:39:22PM +0300, Petteri Räty wrote:
 On 10/23/2010 04:16 PM, Markos Chandras wrote:
 # Markos Chandras hwoar...@gentoo.org (23 Oct 2010)
 #  on behalf of QA team
 #
 # Does not work with recent versions of ffmpeg.
 # Does not work with youtube anymore due to API changes.
 # Dead upstream.
 # Removal in 15 days.
 # Alternatives:
 # media-video/minitube
 # media-video/xvideoservicethief
 media-video/elltube


 I think whenever faster than the standard 30 days is used then there
 should be a reason in the mask entry.

 Regards,
 Petteri

 You need more reasons that those I already mentioned? The package is
 broken, can't be fixed in any way, since there is no upstream anymore and 
 plus there
 are more featureful programs to view youtube videos than this one. Imho, the 
 30
 days does not make sense here.
 

My point was to have something along the lines of Removal in 15 days
because of the above.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: QA last rites: media-video/elltube

2010-10-23 Thread Petteri Räty
On 10/23/2010 08:59 PM, Diego Elio Pettenò wrote:
 Il giorno sab, 23/10/2010 alle 20.58 +0300, Petteri Räty ha scritto:
 My point was to have something along the lines of Removal in 15 days
 because of the above. 
 
 It would just be a formula to use, and a silly one. _Obviously_ the
 removal is because of the above, and if the time is shorter, the reason
 _is_ the one above.
 

I didn't consider it obvious. I could be alone of course but doesn't
hurt to be explicit.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New PUEL license

2010-10-17 Thread Petteri Räty
On 10/16/2010 05:26 PM, Lars Wendler wrote:
 Hi folks,
 
 a couple of weeks ago I was told that the PUEL license we have in our license 
 pool is outdated. We currently have version 6 from July 28, 2008 but latest 
 virtualbox releases come with version 8 from April 19, 2010.
 A quick glance at the diff between both licenses revealed nothing but 
 replacement of SUN with Oracle and some small wording changes but as english 
 is not my native language I find it quite hard to understand licenses written 
 in english and distinguish between wording changes with big or rather small 
 impact on the license. Last but not least IANAL of course.
 So I'd appreciate if someone could have a deeper look at the differences and 
 tell me if it's okay to just drop the old license and add the new one of if 
 we 
 need to keep both, old and new one in our license pool.
 

We can drop the old one if we have no versions in tree that would use
that particular text.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree

2010-09-30 Thread Petteri Räty
On 09/30/2010 06:25 PM, Zac Medico wrote:
 On 09/30/2010 12:41 AM, Dirkjan Ochtman wrote:
 As another dev who generally runs stable (except things that I hack
 on), another question: is it actually possible, as Diego seems to
 suggest, to have two portages installed?
 
 You can run portage directly from a checkout if you export modified
 versions of the PATH and PYTHONPATH variables as described here:
 
   http://www.gentoo.org/proj/en/portage/doc/testing.xml

This could also just be a unpacked release.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Portage to die on sure-enough _FORTIFY_SOURCE overflows

2010-09-28 Thread Petteri Räty
On 09/28/2010 12:43 PM, Diego Elio Pettenò wrote:

 
 So if you want to have your say, gentoo-qa is there for that.
 

You should not cross post like this. Following the recent discussion the
only list allowing cross posting is gentoo-dev-announce.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Improve devaway system

2010-09-26 Thread Petteri Räty
On 08/31/2010 11:03 AM, Robin H. Johnson wrote:
 How about this as an idea:
 1. Include a parsaable return date I suggest (Returning:/MM/DD,
 Returning:Unknown)
 2. Automated emails when:
 2.1. It's after the return date (weekly).
 2.2. You start committing again.

Sounds good:
https://bugs.gentoo.org/show_bug.cgi?id=338829

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] openrc stabilization update

2010-09-26 Thread Petteri Räty
On 09/26/2010 07:30 PM, Joshua Saddler wrote:
 On Sun, 26 Sep 2010 08:37:35 -0400
 Jacob Godserv jacobgods...@gmail.com wrote:
 
 On Mon, 20 Sep 2010 14:32:49 -0400
 Mike Frysinger vap...@gentoo.org wrote:

 man, fix your line length.  what a nub you are.

 Or adjust your mail client. Then you could save yourself the name
 calling, which changes the mood of the mailing list and causes
 issues for more people than just your target.

 
 It's okay. We go back some years. We've met in person. I can read
 Mike's text tone. We're just playin'. Besides, I learned
 something important, namely that despite my configs, Claws Mail
 wasn't behaving properly, so I had to make a few changes. S'all good.
 At no point was I hurt by the nub label. I think I replied NO
 U, which is of course how we handle things off-list.

Yeah but I was also wondering why Mike was calling you names like that.
As 99% of people on this list don't get the inside joke maybe this is
not the best media for it.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)

2010-09-26 Thread Petteri Räty
On 08/16/2010 08:45 PM, Mike Frysinger wrote:
 On Mon, Aug 16, 2010 at 12:11 PM, Gilles Dartiguelongue wrote:
 Le lundi 16 août 2010 à 16:07 +0400, Peter Volkov a écrit :
 This was discussed many times here and since every time we had same
 consensus the policy is in place. It's just not written in devmanual
 or
 gentoo.org/doc.

 Preceeding didn't seem to make it through (yet), so here it goes:
 please write that down. A policy that is not written down is not
 something you can expect people to know and follow, even if it seems
 falls under common sense from your or QA's point of view.
 
 true, but that doesnt mean the current situation cannot be fixed
 -mike
 

There's an open repoman bug about this:
http://bugs.gentoo.org/show_bug.cgi?id=311629

Patches welcome,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries

2010-09-19 Thread Petteri Räty
I assume many of us have wrapper scripts to automatically generate
matching ChangeLog and CVS commit messages. When we eventually move to
git the plan is for the ChangeLog to be automatically generated from
git. To unify developer practices and to ease the transition to git it
has been proposed to make repoman automatically generate ChangeLog
entries. If you have any objections or thought please raise them. One
open question is what should repoman do if there is already a
modification to the ChangeLog file.

Regards,
Petteri

Bugzilla bug:
http://bugs.gentoo.org/show_bug.cgi?id=337853



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygtkhelpers: pygtkhelpers-0.4.1.ebuild

2010-09-14 Thread Petteri Räty
On 09/14/2010 05:50 PM, Arfrever Frehtes Taifersar Arahesis wrote:
 2010-09-13 00:53:19 Mark Loeser napisał(a):
 Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org said:
 arfrever10/09/12 20:43:13

   Removed:  pygtkhelpers-0.4.1.ebuild
   Log:
   Delete older ebuild.

 Please update the Changelog when you remove versions of the package.
 
 When multiple commits in one package are made during e.g. 10 minutes, then it 
 should
 be sufficient to describe all changes in one commit in ChangeLog. Deletion of
 pygtkhelpers-0.4.1.ebuild is mentioned in ChangeLog of 
 dev-python/pygtkhelpers.
 

It's hard to review commits if they are spread across multiple emails.
Why not just commit with a single repoman invocation? At least the way I
do things is I take my CVS commit message from the ChangeLog entry and
if it has something like Version bump and remove old ebuild then it
first fine as a cvs commit message.

 By the way, 2 QA members usually don't update ChangeLog when they delete old
 ebuilds, so maybe the policy should be changed.
 

If you have a problem with a policy then start a thread to change the
policy to see where the majority opinion lies. Jaywalking with other
people does not make your action any more legal (assuming a country
where its never legal). Rules should be changed/improved when they don't
make sense any more instead of ignored (for example some countries allow
jaywalking if there's no traffic in sight).

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: use_echo() as a universal '?:' operator-like function

2010-09-11 Thread Petteri Räty
On 09/11/2010 09:44 PM, Michał Górny wrote:
 On Sat, 11 Sep 2010 20:26:17 +0200
 Francesco R viv...@gmail.com wrote:
 
 echo $(use_case useA,echoA useB,echoB ,echoC)
 
 I would personally rather use:
 echo $(use_case useA,echoA useB,echoB echoC)
 
 but AFAICS your implementation should support both.
 
 PS I suggest using [[ -z ${u} ]] instead.
 

How often do we need multiple arguments like that? We could just as well
have multiple calls like with use_enable. I think we should keep
consistency with use_enable (and it would also result in a simpler
implementation).

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Closing bugs

2010-09-11 Thread Petteri Räty
On 09/11/2010 09:51 PM, justin wrote:
 Hi all,
 
 is the following comment an adequate way to close bugs with
 RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
 
 
 virtual/os-headers:  2.6.35 (sys-kernel/linux-headers)
 ACCEPT_KEYWORDS=amd64
 
 you mix stable  unstable - your problem
 
 

Only if the problem will not eventually manifest itself with a pure
~arch or arch setup. Even then if it's easy to fix I would myself fix it
although we don't officially support it.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild

2010-09-11 Thread Petteri Räty
On 09/11/2010 01:39 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
 arfrever10/09/10 22:39:27
 
   Modified: ChangeLog
   Added:hachoir-parser-1.3.4.ebuild
   Log:
   Version bump.
   
   (Portage version: 2.2_rc79_p5/cvs/Linux x86_64)
 
 Revision  ChangesPath
 1.8  dev-python/hachoir-parser/ChangeLog
 
 file : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?rev=1.8view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?rev=1.8content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?r1=1.7r2=1.8
 
 Index: ChangeLog
 ===
 RCS file: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v
 retrieving revision 1.7
 retrieving revision 1.8
 diff -u -r1.7 -r1.8
 --- ChangeLog 17 Apr 2010 21:32:00 -  1.7
 +++ ChangeLog 10 Sep 2010 22:39:27 -  1.8
 @@ -1,6 +1,12 @@
  # ChangeLog for dev-python/hachoir-parser
  # Copyright 1999-2010 Gentoo Foundation; Distributed under the GPL v2
 -# $Header: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v 1.7 
 2010/04/17 21:32:00 arfrever Exp $
 +# $Header: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v 1.8 
 2010/09/10 22:39:27 arfrever Exp $
 +
 +*hachoir-parser-1.3.4 (10 Sep 2010)
 +
 +  10 Sep 2010; Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org
 +  -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
 +  Version bump.
  

Deleting an older version is relevant so it should also be mentioned in
the ChangeLog message.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyQt4: PyQt4-4.7.6.ebuild ChangeLog

2010-09-11 Thread Petteri Räty
On 09/11/2010 01:02 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
 arfrever10/09/10 22:02:28
 
   Modified: PyQt4-4.7.6.ebuild ChangeLog
   Log:
   Update EAPI. Fix dependencies.
   

This message does not tell why the EPREFIX stuff was removed.

   (Portage version: 2.2_rc79_p5/cvs/Linux x86_64)
 
 Revision  ChangesPath
 1.2  dev-python/PyQt4/PyQt4-4.7.6.ebuild
 
 file : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild?rev=1.2view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild?rev=1.2content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild?r1=1.1r2=1.2
 
 Index: PyQt4-4.7.6.ebuild
 ===
 RCS file: /var/cvsroot/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- PyQt4-4.7.6.ebuild8 Sep 2010 23:30:31 -   1.1
 +++ PyQt4-4.7.6.ebuild10 Sep 2010 22:02:27 -  1.2
 @@ -1,8 +1,9 @@
  # Copyright 1999-2010 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
 -# $Header: /var/cvsroot/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild,v 1.1 
 2010/09/08 23:30:31 hwoarang Exp $
 +# $Header: /var/cvsroot/gentoo-x86/dev-python/PyQt4/PyQt4-4.7.6.ebuild,v 1.2 
 2010/09/10 22:02:27 arfrever Exp $
  
 -EAPI=2
 +EAPI=3
 +PYTHON_DEPEND=*
  PYTHON_EXPORT_PHASE_FUNCTIONS=1
  SUPPORT_PYTHON_ABIS=1
  
 @@ -50,8 +51,6 @@
  )
  
  src_prepare() {
 - use prefix || EPREFIX=
 -
   if ! use dbus; then
   sed -i -e 's,^\([[:blank:]]\+\)check_dbus(),\1pass,' \
   ${S}/configure.py || die
 @@ -70,7 +69,7 @@
   python_copy_sources
  
   preparation() {
 - if [[ ${PYTHON_ABI:0:1} == 3 ]]; then
 + if [[ $(python_get_version --major) == 3 ]]; then
   rm -fr pyuic/uic/port_v2
   else
   rm -fr pyuic/uic/port_v3
 @@ -84,8 +83,6 @@
  }
  
  src_configure() {
 - use prefix || EPREFIX=
 -
   configuration() {
   local myconf=$(PYTHON) configure.py
   --confirm-license
 
 
 




signature.asc
Description: OpenPGP digital signature


  1   2   3   4   5   6   7   8   9   >