Re: [gentoo-dev] [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
On 10.6.2014 5.31, Jeroen Roovers wrote: > On Mon, 9 Jun 2014 18:16:02 -0600 > Ryan Hill 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
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
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] Temporary DevRel actions for CoC violations
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] January stabilization candidates
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
On 24.11.2012 23.12, Pacho Ramos wrote: > > # Pacho Ramos (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?)
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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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?)
On 19.11.2012 18.33, Rich Freeman wrote: > On Mon, Nov 19, 2012 at 11:10 AM, Peter Stuge 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] Merging the devrel handbook into the devmanual
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
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!
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
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 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
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
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
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
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
On 11.03.2012 04:53, Rich Freeman wrote: > On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs 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] Last rites: media-sound/minitunes
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 >>> wrote: # Markos Chandras (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
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
[gentoo-dev] libbash licensing
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] Six month major project on Gentoo
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
Re: [gentoo-dev] We need *you* for a USE="selinux" dependency
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- > 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
On 03.11.2011 17:30, Mike Frysinger wrote: > http://sources.gentoo.org/eclass/user.eclass?r1=1.8&r2=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] portability.eclass: dead egethome, egetshell, is-login-disabled funcs ?
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] Shutdown of berlios
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] Re: hardened glibc and gcc dependencies
On 28.10.2011 2.50, Mike Frysinger wrote: > On Fri, Oct 28, 2011 at 01:47, Ryan Hill wrote: >> On Thu, 27 Oct 2011 23:03:12 +0530 Nirbheek Chauhan wrote: >>> So, I honestly see no reason why toolchain should not start using EAPI 2. >> >> I await your patch to toolchain.eclass. :P > > i wouldn't bother as it's most likely not going to be accepted at this time > Why not? EAPI 2 was approved more than 3 years ago. I don't think there's a problem policy wise making all ebuilds able to use it these days. Regards, Petteri
Re: [gentoo-dev] Re: gentoo-x86/dev-libs/libffi: ChangeLog libffi-3.0.10_rc8.ebuild libffi-3.0.9.ebuild
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()?
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] RFC: devqawarn()?
On 1.9.2011 14.31, Michał Górny wrote: > On Thu, 01 Sep 2011 14:02:11 +0300 > Petteri Räty wrote: > >> On 1.9.2011 13.51, Michał Górny wrote: >>> On Thu, 01 Sep 2011 13:44:47 +0300 >>> Petteri Räty 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()?
On 1.9.2011 13.51, Michał Górny wrote: > On Thu, 01 Sep 2011 13:44:47 +0300 > Petteri Räty 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()?
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] Including a warning to restart daemons after an update.
On 21.08.2011 15:27, Michał Górny wrote: > On Sun, 21 Aug 2011 07:29:45 -0400 > "Anthony G. Basile" 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)
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
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] useq and hasq
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] keywording of new style virtuals
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] keywording of new style virtuals
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] The Python problem
On 27.06.2011 19:00, Dirkjan Ochtman wrote: > On Mon, Jun 27, 2011 at 17:53, Petteri Räty 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] The Python problem
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] Re: [gentoo-commits] gentoo-x86 commit in dev-ruby/fromcvs: metadata.xml ChangeLog fromcvs-0_pre132.ebuild
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] write to filesystem in pkg_pretend
On 17.06.2011 20:18, Mike Frysinger wrote: > On Friday, June 17, 2011 12:25:21 Torsten Veller wrote: >> * justin : >>> 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-x86 commit in dev-ruby/fromcvs: metadata.xml ChangeLog fromcvs-0_pre132.ebuild
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] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
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] Crossdev / glib news item
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
[gentoo-dev] Council May Summary: Changes to ChangeLog handling
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] rfc: *_iface variables in openrc network scripts
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
[gentoo-dev] Devmanual text on ChangeLogs
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] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild
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
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
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] rejecting unsigned commits
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
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
On 03/06/2011 02:22 PM, Christian Ruppert wrote: > Hey guys, > > in bugzilla-4.x they did change the "Status Workflow"[1]. > > > 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
On 02/26/2011 07:08 PM, Daniel Pielmeier wrote: > 2011/2/21 Uditha Galgamuwa : >> 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)
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?
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] Make "sound" a global USE flag?
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] Re: Suggestion: Portage should not mask packages globally, but only for some arches
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)
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)
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
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() ?
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?
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] Deprecate EAPIs 1 and 2?
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] EAPI 4 specification approved
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?
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
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] Death to old-style virtuals!
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] Re: [gentoo-commits] gentoo-x86 commit in sci-geosciences/mapserver: mapserver-5.4.2-r1.ebuild ChangeLog
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] Technical talk ideas for FOSDEM
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
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] Re: Re: Masking
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] Re: Masking
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 !=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] Masking
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 !=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] Extending EAPI="4"
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
Any improvements to the text are welcome. Regards, Petteri Title: Pending Removal of Java support in ia64 Author: Petteri Räty Author: IA64 Arch Team 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
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.
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
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
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
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
Re: [gentoo-dev] Extending EAPI="4"
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] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
On 10/25/2010 06:13 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-10-25 16:31:41 Petteri Räty napisał(a):
>> 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.
>
> python.eclass doesn't support EAPI="4" due to:
>
> if ! has "${EAPI:-0}" 0 1 2 3; then
> die "API of python.eclass in EAPI=\"${EAPI}\" not established"
> fi
>
All the more reason not to have the code there as no-one would be
testing it any way.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: python.eclass
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] Patch for python.eclass
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] Patch for python.eclass
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] Re: QA last rites: media-video/elltube
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] QA last rites: media-video/elltube
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 (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] QA last rites: media-video/elltube
On 10/23/2010 04:16 PM, Markos Chandras wrote: > # Markos Chandras (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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Patch for python.eclass
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. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New PUEL license
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] suspicious code snipped in gcc-4.5* ebuilds
On 10/05/2010 02:32 PM, "Paweł Hajdan, Jr." wrote: > I was just looking at some random ebuilds recently, and noticed this > snippet in gcc-4.5* ebuilds: > > SSP_STABLE="amd64 x86 ppc ppc64 arm > # uclibc need tls and nptl support for SSP support" > SSP_UCLIBC_STABLE="" > > Please note how the #-starting comment is inside the SSP_STABLE variable > declaration. It looks very obvious when seen in a syntax-coloring editor. > > I'm not sure if it breaks, as "uclibc", "need", "tls" etc. are not valid > arch names, but it's still probably not intended. > Open a bug? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
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
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] Re: Why (i.e. USE="openssl" instead of USE="ssl")
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
Re: [gentoo-dev] openrc stabilization update
On 09/26/2010 07:30 PM, Joshua Saddler wrote: > On Sun, 26 Sep 2010 08:37:35 -0400 > Jacob Godserv wrote: > >> On Mon, 20 Sep 2010 14:32:49 -0400 >> Mike Frysinger 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] Improve devaway system
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
[gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
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
