Re: [gentoo-dev] UTF-8 locale by default
02.08.2012 04:20, Walter Dnes wrote: > That's right... the poster was running a POSIX locale for several > years ***AND DID NOT HAVE ANY PROBLEMS RELATED TO IT***. This discussion is very similar with one, that i have seen in Russian Linux community some years ago about migrating from ru_RU.KOI8-R to ru_RU.UTF-8. Arguments from "KOI8-R guys" were the same - "Why we should change something if it works?" and they are also did not notice fundamental problems with some vitally important packages, which can not be replaced or need to be heavily patched to work properly. Arguments from "UTF-8 guys" were not ideal, but locale change brokes only old or unsupported packages, so they win. P.S. I do not think that comparison with 'initramfs and separate /usr problem' is correct in this case. Default locale change is evolution, not revolution... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] doheader function for EAPI 5?
31.08.2012 12:35, "Paweł Hajdan, Jr." wrote: > I'm somewhat interested. Here's the current code dev-lang/v8 uses to > install headers: > > insinto /usr > doins -r include || die > > Using e.g. "doheader include/*" is slightly prettier IMHO, but it's not > a big deal. I am also voting for such function. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
10.09.2012 05:55, Doug Goldstein wrote: > Hey all, > > Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to > app-emulation/qemu at some point this week. The app-emulation/qemu > ebuilds will effectively die and be replaced by the > app-emulation/qemu-kvm ebuilds. I've brought this up before and there > was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The > fact of the matter is that the app-emulation/qemu just isn't getting > the same maintenance care that app-emulation/qemu-kvm is. I've really > only got the bandwidth to handle one at a time. Additionally this will > bring us inline with a few other distros use of qemu as they're really > building their binaries from qemu-kvm. > > For those that want pure qemu builds, I recommend creating an overlay > and replacing the URL. The ebuilds will otherwise aim to be 100% > compatible. > It seems that qemu-kvm will be merged into main qemu source tree(i have heard that fact... do not really remember where :-D), so your decision maybe concerned as preparations for this merge. I am strongly agreed with it.
Re: [gentoo-dev] Packages up for grabs due spatz retirement
07.10.2012 14:31, Pacho Ramos wrote: > app-text/lodgeit > media-plugins/gimp-resynthesizer > net-analyzer/namebench > x11-themes/pulse-glass > > Feel free to get them > > Thanks > > > netmon will take care of net-analyzer/namebench -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] New desktop subproject: desktop-effects
It's my pleasure to announce a new desktop's subproject: desktop-effects. The goal of this project is to maintain compiz and other 3D window managers. Actually there is a herd with same name for a some years, but herd maintainers was inactive and compiz was masked. I think that such kind of software must have better support in Gentoo, that's why i decide to start a project(permission on this was granted by jmbsvicetto, who took care about compiz for a quite long time). First of all, project will be focused on supporting compiz in actual state. For now it will be 0.8.x branch, because 0.9.x is quite unstable (but it is already in our project's overlay, so feel free to build and test it). Also we are always look for some cool stuff, which brings nice 3D and compositing features into Gentoo Linux desktop. More information about this project is at http://www.gentoo.org/proj/en/desktop/effects/index.xml -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
11.10.2012 23:22, Mike Frysinger wrote: > On Thursday 11 October 2012 14:56:11 Ben Kohler wrote: >> I would like to suggest that the "server" profile variants >> (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so >> that they do not show up in "eselect profile list" for new users. As far >> as I know, this server target is unmaintained, undesirable, and somewhat >> silly, if you look at its make.defaults. If this target is being kept >> around just so we don't break older setups, then simply removing from >> profiles.desc would allow these systems to keep using the profile, without >> presenting it as a viable option for new users. > sounds like something to fix rather than punt. i don't know why you think > having server profiles is "undesirable", but i certainly desire it on many > systems. like servers. the desktop and developer profiles are not > appropriate. > -mike Indeed. Hardened server profile does not fit in all cases, some non-hardened server profile should exist, BUT without this warning(if it's usable, of course), and probably with better support. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] esetshell in user.eclass
22.10.2012 01:20, Diego Elio Pettenò wrote: > Anybody has a problem with adding an esetshell function to user.eclass ? > > I'd need it for munin... > I think that having such function would be nice signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OUTAGE: {get,planet,packages,devmanual,infra-status,bouncer,}
20.10.2012 17:44, Alec Warner wrote: > p.g.o is fixed, but the dns TTL was set to half a day, so it will be > that long before users get the fixed experience. > > Now i am receiving such error while opening packages.gentoo.org: "Empty Page! If you expected a real website instead something must be wrong. :-( " Is this related to DNS resolving to wrong address on my side? nslookup show me: packages.gentoo.org canonical name = brambling.gentoo.org. Name: brambling.gentoo.org Address: 140.211.166.178 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
31.10.2012 16:39, Michael Palimaka пишет: > 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? > > Best regards, > Michael > > [1]: https://bugs.gentoo.org/show_bug.cgi?id=304435 > [2]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml > [3]: http://devmanual.gentoo.org/ > As a new developer , I think this is a good idea. When i was a recruit it was not so easy to find some information(well, at least for me). Now i am more familiar with Gentoo website internals and it's not a problem anymore(at least, generally :-)). I think recruiters would be also agreed with this point of view(at least hwoarang does :-D) -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
29.10.2012 18:39, Rich Freeman wrote: > On Mon, Oct 29, 2012 at 10:13 AM, Rick "Zero_Chaos" Farina >> but would anyone be interested in blocking using lbzip2 >> by default? It seems pretty safe and I've done dozens of full system >> builds etc. > > Why not just make it an option to start, advertise it by all means, > and then see how it turns out with volunteers before we make it the > default. Going from nobody-has-heard-of-it to default overnight seems > a bit much. > +1 for that -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due beandog retirement
19.11.2012 02:33, Pacho Ramos wrote: > app-misc/dailystrips > app-misc/gramps > dev-php/PEAR-PEAR > dev-php/pear > games-misc/fortune-mod-mormon > games-misc/fortune-mod-scriptures > media-libs/libbluray > media-tv/ivtv-utils > media-tv/ivtv > media-video/mplayer-resume > sys-fs/mhddfs > x11-themes/gdm-themes > > Some of them are co-maintained but, if you want to take care of them, > feel free to add you to metadata > > Thanks I have picked up sys-fs/mhddfs some time ago -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
04.12.2012 21:28, Rick "Zero_Chaos" Farina wrote: > A quick "site:devmanual.gentoo.org proxy" search indicates no > documentation of this at all. > > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable > > This page exists, but doesn't really mention anything about proper bug > assignment. I know a lot of you have been doing this a very long time > and there is a 'standard' way of doing things, but for us new guys if > there is no documentation there is no policy. > Agreed. I add description field to metadata for proxying packages, cause i see such field in other packages' metadata. That is it. But it would be better when this became official policy. At least - define actual maintainer first, even if he is not developer - this would never confuse scripts for automated bug filing -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: new package category: net-vpn
17.03.2017 19:05, Jason A. Donenfeld пишет: > On Fri, Mar 17, 2017 at 4:05 PM, Michał Górny wrote: >> On pią, 2017-03-17 at 14:57 +0100, Jason A. Donenfeld wrote: >>> Done. >> >> It's nice that you waited for people to actually wake up around >> the world to give you feedback. > > Yep, sorry. Already chastised and discussed at length on IRC. Duly noted. > Hm, i should probably move net-dialup/pptpd to this category... Not sure about net-dialup/accel-ppp, cause it has IPoE now, so it is more like generic NAS/ solution, rather than regular VPN Thanks for moving vtun, though ;-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
09.04.2017 19:15, William L. Thomson Jr. пишет: > Not sure if this is practical, it may be less work if the use of > Python and Ruby versions ( maybe others ) is reversed. Rather than > adding all the versions that the ebuild supports. What if it only > included versions it did not support? It was like that before we switch to python-r1 and it was major PITA. Please, do not do this! -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Future of Desktop-effects project
Hi. It is sad to say, but i have no time for compiz anymore. Personally, I do not use it anymore for around six months(i have migrated from KDE with compiz as WM to pure fluxbox on both of my workstations). And, to be honest, there is no progress in desktop-effects overlay either[1]. As i am the only member of project i suggest this masterplan: - set timeout for a week from current date(so, deadline would be Jul 19, 2017); - if any of the developers want to take maintainership - please join the project - if no developers will volunteer, but there will be user, who would like to fix stuff and work with proxy maintainers - please set maintainership correctly - after deadline happens and no other of developers join the project, i will request disbanding it and move all packages, that are still under project maintenance to maintainer-needed Not sure what to do with overlay when project will be disbanded though. Packages, that are maintained by desktop-effects project[2]: dev-python/compizconfig-python x11-apps/fusion-icon x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-misc/3dfb x11-misc/3dfm x11-misc/ccsm x11-misc/simple-ccsm x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald Open bugs on these packages can be seen by this query[3] [1] - https://gitweb.gentoo.org/proj/desktop-effects.git/ [2] - listed using 'portageq --no-filters --maintainer-email=desktop-effe...@gentoo.org -n' [3] - https://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&list_id=3587404&namedcmd=desktop-effects -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] taking a break from arches stabilization
10.07.2017 20:22, Agostino Sarubbo пишет: > Hi all. > > every time that I attach my tmux session to see what happens on irc, I always > see the same discussion about the 'minor' arches status. > Since I joined gentoo(2011) I worked on all arches except hppa, I put more > effort in amd64 and less where I saw other people work on it (arm,alpha) > But every time the magic phrase is that those arches are unmaintained. > > Now, since I work on these arches just to help, i.e. I don't have any > business > and I do non have any installation of those arches and the work I'm doing is > not appreciated at all I decided to stop for now. > If your dream is to put sparc and ia64 to ~arch, go ahead, I have no > objections. > I will take a break also from amd64 and x86...let's see how things will > change. > It's sad, i wish you will return to this - you are doing great job for all arches! I know how tedious this work could be - i was active arch team member some time ago(but not anymore :-(). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
The following packages are up for grabs: app-text/yagf dev-util/bsdiff dev-util/skipfish games-fps/serious-sam-tfe games-fps/serious-sam-tse sys-process/procexp -- Best regards, Sergey Popov Gentoo developer Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Due to disbanding of Desktop-effects project[1], these packages are up for grabs: dev-python/compizconfig-python x11-apps/fusion-icon x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-misc/3dfb x11-misc/3dfm x11-misc/ccsm x11-misc/simple-ccsm x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald [1] - https://bugs.gentoo.org/show_bug.cgi?id=625712 -- Best regards, Sergey Popov Gentoo developer Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] AMD64 Arch Testers needed urgently
13.12.2017 21:20, Lucas Ramage пишет: > What about running a stable chroot? Are there any tools that can be > used to automate this process? Try gentoo-chrootiez[1], it is written by our fellow gentoo developer - slyfox. And it is damn simple to use. [1] - https://github.com/trofi/gentoo-chrootiez -- Best regards, Sergey Popov Gentoo developer Gentoo Quality Assurance project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Ban dolib and libopts in EAPI 7
13.10.2016 16:53, Ulrich Mueller пишет:
> Hi all,
>
> I suggest that we ban the dolib and libopts commands in EAPI 7.
>
> Rationale:
> 1. There are about 60 instances of dolib in the tree. At least one
>third of them appears to be wrong (e.g., should be replaced by
>dolib.so for correct mode).
> 2. libopts affects only dolib, while the more special commands dolib.a
>and dolib.so install libraries with fixed modes 0644 and 0755,
>respectively. (The latter is also consistent with dobin installing
>with fixed mode 0755, i.e., there is no binopts command.)
> 3. There is no newlib command corresponding to dolib, whereas
>newlib.{a,so} commands exist.
> 4. libopts is not used at all in the tree, which strongly indicates
>that there is no need for it.
>
> Replacement:
> Use dolib.a or dolib.so instead.
>
> Comments?
>
> Ulrich
>
Fine by me. I can not remember right now if i ever used dolib instead of
dolib.so or dolib.a(probably i did), but i do not see any caveats in
your arguments.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Quality Assurance project lead
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-misc/ttysnoop
# Sergey Popov (2022-04-05) # Upstream is dead long time ago # SRC_URI and HOMEPAGE are gone(bug #680362) # Has file collision with dev-util/bcc(bug #834093) # Suggested modern replacement is incorporated in dev-util/bcc # Removal in 30 days app-misc/ttysnoop
[gentoo-dev] Packages up for grabs
Dear all. Due to limited time i can spent for work on Gentoo, the following packages are up for grabs: app-admin/logmon (no open bugreports) app-admin/logstalgia (one open bugreport) app-misc/clockywock (one open bugreport) app-shells/ccsh (no open bugreports) app-shells/rrs (no open bugreports) dev-lang/esco (no open bugreports) dev-libs/bitset (no open bugreports) dev-libs/confuse (no open bugreports) dev-libs/jthread (no open bugreports) dev-libs/libx86 (two open bugreports) dev-libs/log4sh (one open bugreport) dev-python/daemonize (no open bugreports) games-arcade/orthorobot (no open bugreports) games-strategy/spaz (no open bugreports) media-libs/jbig2enc (one open bugreport) net-irc/iroffer-dinoex (no open bugreports) net-firewall/rtsp-conntrack (no open bugreports) net-libs/rtrlib (three open bugreports) net-misc/linux-eoip (no open bugreports) net-misc/sgopherd (no open bugreports) net-misc/socket (no open bugreports) net-misc/yandex-disk (no open bugreports) net-misc/zssh (one open bugreport) sys-fs/reiserfs-defrag (no open bugreports) x11-misc/dex (no open bugreports) x11-misc/set_opacity (no open bugreports) x11-misc/xgestures (no open bugreports) x11-misc/whaw (no open bugreports) -- Best regards, Sergey Popov Gentoo developer
[gentoo-dev] Obsolete package atoms in package.mask files
Some time ago, there was one bugreport[1] about obsolete mask entries in package.mask files in diffirent profiles. Bug is assigned to QA team, but only amd64 no-multilib profile was cleaned up, as i know. Maybe we should add arch teams, whose profiles contains deprecated entries, to CC on this bug? [1] - https://bugs.gentoo.org/show_bug.cgi?id=444181 -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Obsolete package atoms in package.mask files
10.12.2012 11:05, Sergey Popov пишет: > Some time ago, there was one bugreport[1] about obsolete mask entries in > package.mask files in diffirent profiles. Bug is assigned to QA team, > but only amd64 no-multilib profile was cleaned up, as i know. > > Maybe we should add arch teams, whose profiles contains deprecated > entries, to CC on this bug? > > [1] - https://bugs.gentoo.org/show_bug.cgi?id=444181 Ok, now, i have got permission from QA team to clean things up. I will try to cleanup all obsolete atoms except: - gnome 3.6 and mysql atoms in base profile (they was added for a reason and i do not want to broke things) - hppa profile. As i know HPPA guys are not happy when not-arch-team developer touches their profile, so i will leave decision to clean up things directly to them -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Drop the Perl Modules Guideline?
25.12.2012 18:30, Mike Gilbert wrote: > On Tue, Dec 25, 2012 at 7:09 AM, Torsten Veller wrote: >> Let's discuss the "specific guideline" for Perl modules. It's as follows: >> >> ,- >> http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2 >> | Perl >> | >> | New Perl modules are to be added to portage only when one of the following >> | conditions is met: >> | >> | a) The module(s) fulfill a dependency >> | b) The module(s) cannot be handled by g-cpan >> | c) The module(s) add functionality to existing ebuilds >> | d) The module(s) provide tools, applications or other features (i.e. more >> |than what their .PM offers) >> | >> | Please make sure that at least one member of the perl herders approves >> | your addition. >> `- >> >> Recently the proxy-maintainer project is repeatedly adding packages >> which aren't following these guideline AFAIK. So maybe we should change >> it. >> >> 444974 a) dev-perl/Text-Format - Various subroutines to format text >> 2012-12-07 >> 444976 a) dev-perl/Roman - Perl module for conversion between Roman and >> Arabic numerals.2012-12-03 >> 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos >> 2012-12-12 >> 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon 10:12 >> >> Ad a): This requirement is a little problematic: >> Sometimes perl modules are needed for maintainer-wanted packages. >> Sometimes the perl modules are added to the tree while the >> maintainer-wanted package never are or will be. Sometimes the maintainer >> are waiting for the perl team to do their work. >> >> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really >> reliable these days. I always wanted to test/verify it. But ... (random >> excuse: time, motivation,...) >> >> I guess I don't have no problem with modifying or dropping the >> requirements. The perl overlay contains hundreds of packages which >> should be added to the main tree. >> >> The dev-perl category currently already contains the most packages >> (1140 per packages.g.o). >> >> -- >> Best regards >> Torsten >> > > I'm sure I skimmed that section of the handbook at some point for the > quizzes, but I don't remember it. I think it is possible that the > proxy commiter (pinkbyte) forgot about it too. No, i do not, i have read this guideline, and yes - it is not mentioned directly in Handbook or Devmanual. Some of these modules was added cause they are dependencies for other packages(which are still waiting for adding in tree, cause they have no maintainer yet), others - cause g-cpan generate very ugly ebuilds for them. > I think that all of those requirements make sense. We might want to > formalize a similar guideline for the python herd. > > Perhaps the requirements list could be copied somewhere more visible? > The perl project page might get more traffic for people looking to > write perl ebuilds. > Truly, i do not really understand such hard policy for NOT including perl modules in tree. I know that perl herd is understaffed, but i do not think that this is generally a problem, cause they do not maintain recently added packages, but proxy maintainers do. So, basically, yes, i vote for easing policy a bit. P.S. CCing maintainer of modules, that i have commited as a proxy, maybe he also wants to say something regarding this. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposed removal of service: torrents.gentoo.org
23.12.2012 22:49, Robin H. Johnson пишет: > torrents.gentoo.org has been down for a few months now, and there have > been very few comments about it. Up until a few years ago, it was still > quite useful, but I believe that we have sufficient bandwidth and > mirror-coverage around the world that it's become a moot point. > > (snip) > > If we need torrents in future, we should use public trackers, as there > is no further need to run our own BitTorrent tracker. The .torrent > files themselves should live on our own mirrors, with GPG signatures to > prove authenticity (we actually only need to sign the infohash value). Personally i have agreed with this point of view. Our own torrent service is unneeded anymore - we do not lose anything important if we use public trackers for this -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please guys use checkpath in init scripts
06.01.2013 23:30, "Paweł Hajdan, Jr." пишет: > On 1/6/13 8:30 AM, Diego Elio Pettenò wrote: >> I just gave a quick look at the init scripts installed on the tinderbox, >> and the amount of them that use mkdir to create the directories in /run >> and similar is astounding. >> >> Please check `man runscript` and use the checkpath helper instead. > > Should this be documented in devmanual or something? :) > > Paweł > +1. It seems that i have followed wrong way for fixing this scripts, but it is not entirely my fault - i was taken this manner from scripts in other packages. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] January stabilization candidates
13.01.2013 02:49, "Paweł Hajdan, Jr." wrote: > Please review attached automatically generated stabilization candidates > for January. > # pinkbyte > app-shells/ccsh-0.0.4-r3 > app-shells/rrs-1.70-r1 > dev-libs/jthread-1.3.1 Ok for them > # netmon > dev-libs/geoip-1.4.8-r2 Ok for it And thanks for your work. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] removing the server profiles...
16.01.2013 03:36, Andreas K. Huettel wrote: > > Hi, > > several people have pointed out to me that the 10.0 -> 13.0 transition would > be a good moment to finally remove the (also in my opinion rather useless) > server profiles. > > The easiest way to do this would be to > * just not copy the server profiles from 10.0 to 13.0 and > * have the deprecation warning for "10.0/server" point to "13.0" (i.e. prompt > users to upgrade from the 10.0 server profile to the 13.0 base profile). > > Opinions? > [I'm not doing anything with this regard unless a clear consensus is found > here on the list. Otherwise I'll copy the dirs 1:1.] > > Cheers, A > > I remember, that hwoarang was strongly against removal of server profile. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] revdep-rebuild bikeshedding
17.01.2013 00:43, Paul Varner wrote: > Here is where the bikeshedding begins: > 1. What variable name do we prefer? REVDEP_DEFAULT_OPTS or > REVDEP_EMERGE_DEFAULT_OPTS REVDEP_REBUILD_DEFAULT_OPTS seems fine, IMO. > 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace > EMERGE_DEFAULT_OPTS replace is better -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About dropping comm-fax herd
20.01.2013 13:10, Pacho Ramos wrote: > Only one package is inside it: > net-misc/capi4hylafax Personally, i think that keeping herd only for one package(if it's not god-damn-hard-to-maintain) is a bit overkill. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
22.01.2013 08:23, Mike Gilbert wrote: > I guess this change is ok, given that I can opt-out fairly easily. Zac's > workaround for binary packages makes me feel better too. I am curious, can not this check be added to eclass? Or eclass does not know about type of merged package? -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] splashutils needs a maintainer
28.01.2013 23:26, Pacho Ramos пишет: > Then, looks like no alternative is in good shape on Gentoo. What is > Sabayon using? They look to have plymouth ebuilds in their overlay (but > not in "for-gentoo" one, then, it probably has some incompatibility > Gentoo :/) We have plymouth ebuilds in tree, but they are outdated(see https://bugs.gentoo.org/show_bug.cgi?id=430478). -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] "frozen" overlay Re: Please stop useless removals
01.02.2013 12:53, Michael Weber wrote: > BENEFIT > >User can choose whether or not layman -a frozen. > >Non-trivial ebuilds are preserved. > >Tarballs are preserved. > >Nobody gets hurt. Well, we can move such software to sunrise, can't we? But proposition of splitted mirrors makes sense, cause quite often dead upstream means dead links to original tarballs too. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due lack of time
03.02.2013 16:46, Pacho Ramos wrote: > dev-libs/confuse I will pick up this one. I use it in one of my projects -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Gentoo Bugday
28.02.2013 01:30, Peter Stuge пишет: > Tom Wijsman wrote: >> his sole two bugs > > Is there a rule in Gentoo that forbids a dev to fix a bug assigned to > someone else? That would make absolutely no sense to me. Without primary contact to bug's assignee(personally, of, if bug is assigned to project - to member of this project) - no, it's not good. Exception - maintainer-needed@ bugs. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make inotify a global USE flag?
21.03.2013 16:10, Peter Stuge wrote: > That was not at all clear, but that's great! Then you could fix those > ebuilds. Except there's that rule to not fix bugs in others' ebuilds, > so even though you've found a bug you're not allowed to fix it.. :\ To be honest - last statement is not correct, but, please, do not start this useless discussion about common sense in touching others' packages again. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-text/cuneiform
24.03.2013 13:15, Róbert Čerňanský пишет: > And that is why I now appeal to users: > > _Do not report bugs to Gentoo unless a package is completely broken._ > > Because what you will get in return? Package removed. If package is broken, upstream is dead/unresponsive and nobody wants or can fix it - yeah, it will be treecleaned. Sooner or later. Cause we should keep some QA standarts that are expected by users. > A package with bugs has a greater user value than no package at all. > Until Gentoo does not understands that and does not change its removal > policy accordingly, and provides technical means to reflect it*, it is > the only user-viable** way how to keep a package in the tree as long as > possible. > > * Which could be e. g. masking a package until it is completely > broken. > > ** No, I do not want to become a developer. No, I do not want to >maintain a package. I am the user, I want using it. (It does not >mean that I do not contribute to the community, I just have other >ways/projects to do so.) If you, as user, want to use package that does not fullfill minimum QA requirements, nobody can stop your from installing it from your local overlay. You can not rely on support through bugzilla from that moment, but if package was removed because lack of maintainership it does not matter, does not it? Main tree is not place for dead AND(not or, and!) not working packages. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Minor change in pkg-config behavior, starting with 0.28, late heads up for maintainers
29.03.2013 10:30, Samuli Suominen пишет: > This is from Fedora Devel Mailing List. I found it to be news worthy > also for Gentoo maintainers. So here it is: > > > > Remi Collet Fedora at FamilleCollet.com > Thu Mar 28 10:39:52 UTC 2013 > > Previous versions > > $ echo "==$(pkg-config --cflags-only-I openssl)==" > == == > > New version > $ echo "==$(pkg-config --cflags-only-I openssl)==" > > > This space to empty string output can breaks some poorly written > autoconf script. > > > > Remi. > > > P.S.1: I hope it could helps some packager... > avoid losing too much time on this... > P.S.2:example of broken script > > http://git.php.net/?p=php-src.git;a=commitdiff;h=640e72ce91d8e591b92cd93c18d1bfe3befe3424 > > > > I have discovered this behaviour change due to resolving bug #455984, where custom configure script was unaware of new pkgconfig. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Expanding categories' descriptions
01.04.2013 11:52, Michael Palimaka пишет: > On 1/04/2013 04:29, Denis M. wrote: >> Hello, >> >> (I was redirected from gentoo-doc@ to ask this here.) >> >> I think it's a good idea to expand the categories' descriptions (found >> in the corresponding metadata.xml files) with more accurate descriptions >> of which packages are welcome to fit in which categories. >> >> The current descriptions are very vague and aren't probably in the best >> shape to bring users' a good idea what certain category is about and >> what packages are to be found there. >> >> This can also be an issue for (new) ebuild-writers (either >> user-contributed ebuilds or just gentoo developers that are not >> sure0-000-p >> about it either). >> hat t >> This is of course checked by a gentoo developer if new ebuilds are to be >> submitted via the bugzilla, but I still think we should provide a better >> understanding of the categories. >> >> If expanding the metadata.xml files does not seem a good idea, we should >> at least make a little bit more comprehensive description somewhere in >> the gentoo.org/doc/ or wiki.gentoo.org pages. >> >> What do you think about it? >> >> >> Regards, >> Denis M. (Phr33d0m) >> > > Sounds good to me. From time to time I see even experienced developers > not sure as to which category a package belongs. > > There is also inconsistency with packages of a certain type being spread > over multiple categories. For example, packages containing "password > manager" in the description currently exist in three different categories. +1 for that. I was really confused(tbh, i am confused even now) about x11-apps/x11-misc categories, for example. Sometimes it is really not clear where package should goes. Another example - app-admin/ansible. Some devs thinks that it should be sys-cluster/ansible, but i put it into app-admin/, relying on app-admin/puppet as an example. So, some sort of clarification for such noobs, like me, would be really appreciated :-) -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] libpng 1.6 upgrade and subslotting (and misuse of subslotting when there is also normal slotting)
06.04.2013 00:44, Samuli Suominen wrote: > $ grep -r 'media-libs/libpng' */*/*.ebuild |grep -v ':.*=' > output -> http://bpaste.net/show/89268/ Thanks. app-admin/logstalgia and x11-wm/compiz are fixed. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] alsaconf removal?
11.04.2013 11:10, Samuli Suominen пишет: > alsaconf should die as it's useful only for ISA/PCMCIA and currently broken > > see, http://bugs.gentoo.org/456214 > > does anyone have problems with dropping alsaconf and patching the > gentoo's alsa-guide.xml to tell users to edit /etc/modprobe.d/alsa > directly if they need? > udev will autoload the modules just fine even without touching the whole > file for PCI, USB, ... devices > > all feedback appericiated > > - Samuli > Fine by me too. I saw it working last time two years ago, so i do not mind of removing it. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About src_test() in perl-modules
20.04.2013 22:02, Mikle Kolyada пишет:
> Lately, i saw many bugs like =dev-perl/
> ${packagename}: fails test. Me just interested proper way to fix those
> bugs? Sure, it's good when we have clear version for bump w/o problem.
> But this is not always What common ways to fix those bugs? (I know
> that we can disable bad tests)
Well, my 2 cents here are simple: either fix tests yourself(by disabling
SOME of them or make them behave properly) or restrict them. Note, that
RESTRICT="test" is not the way that you should use to fix the bug(e.g.
bug should NOT be closed on bugzilla) - it's just a workaround
--
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] extending metadata.xml to support CPE information
08.05.2013 07:59, Mike Frysinger пишет: > the guys who maintain the security CVE project [1] [2] (designed to be the > authority when it comes to indexing security related vulnerabilities in > projects) have a CPE specification [3] to make tracking CVEs back to a > canonical source in a machine parseable format. > > the ChromiumOS project wants to be able to tie CPEs to a specific package. > this would probably also be a good thing for our own security team to tie > into > the GLSA process. the Debian project too is extending their database to > include CPE information [4]. > > we've already got a database for maintaining this sort of thing on a per- > package basis: metadata.xml. so let's extend the DTD to cover this. the > existing remote-id field looks like a pretty good fit, so the proposal is > simple: add a new "cpe" type. the entries for net-misc/curl would be: > > cpe:/a:curl:curl > cpe:/a:curl:libcurl > > > or the gzip package: > > cpe:/a:gnu:gzip > > > for most packages, there will probably be only one cpe entry, but as you can > see here, sometimes more than one can track back to a single package. > > we have some scripts running on the CrOS side to try and do an initial seed > (at least, for all the packages we're using), so i'll probably take care of > merging that into the main tree. i'm not proposing this be required or > anything (since not all packages will have one). > > thoughts ? Reasonable improvement, that can make tracking security issues more easily and automatically. +1 for that -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
29.05.2013 03:01, David Carlos Manuelda пишет: > El Martes, 28 de mayo de 2013 14:03:52 Mike Frysinger escribió: >> On Tuesday 28 May 2013 13:53:54 Michał Górny wrote: >>> On Tue, 28 May 2013 16:43:10 +0200 David Carlos Manuelda wrote: >>>> I posted a bug about that along with a suggestion, despite sometimes I >>>> do >>>> not explain myself correctly (I am very sorry): bug #471590 >>>> >>>> Many packages are bundling its own libraries rather than link against >>>> system ones, and there is a bug tracker for that (bug #251464) >>>> [...] >>>> What I propose for example, is a very good and simple approach: to have >>>> an option in portage's make.conf, something like that (the name may >>>> change): >>>> >>>> 1.- USE_SYSTEM_LIBRARIES="cairo sqlite XXX" >>>> 2.- USE_SYSTEM_LIBRARIES="* -cairo" >>>> 3.- USE_SYSTEM_LIBRARIES="*" >>> >>> I don't think we should do it like this. >>> >>> Bundling libraries is a pathological case. In general, we should work >>> on fixing this and getting rid of bundled libraries. In that general >>> case, the flags are not required. >> >> +1 >> -mike > Ok, thinking it better I agree, that having them use system libraries is far > better, but why then those affected ebuilds have corresponding USE disabled > by > default? > How do you imaging use of system library( called "foo", for example) if foo, bundled in program(called "bar", for same reason :-)) is fork with new features that is suitable only for "bar"? It's ideal situation when "bar" works also with system "foo"(not all features works, however). Sometimes(and it happens very often, to be honest) "bar" can not work with system "foo" at all! For example, look at quake3-1.36-r1.ebuild, at commented "use system jpeg" patch. If you uncomment it, quake3 will be built against system jpeg. It will build successfully, but textures will be a big mess of polygons. So, unfortunately, it's not even an option here, unless somebody will do a great work for splitting this library and write a huge patch, that will be totally rejected by upstream(so he will have to maintain this patch on his own). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
29.05.2013 18:51, Michael Palimaka пишет: > Would it be possible to add repoman checks for this, and other common > failures like missing PYTHON_USEDEP? +1 for repoman check on PYTHON_REQUIRED_USE and PYTHON_DEPS -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About lafilefixer removal
05.06.2013 01:16, Samuli Suominen пишет: > On 05/06/13 00:09, Pacho Ramos wrote: >> It lacks a maintainer for a long time, also has some opened bugs and I >> am unsure if it's still needed. I am not using it for months and never >> saw any problem, also, portage fixes .la files by itself, and paludis >> people don't approve lafilefixer. >> >> Do we still need it? > > +1 for dropping it as... > > - gentoo-x86/ has been massively cleaned up with punting of .la files > - -Wl,--as-needed is enabled by default for ages > - portage's own .la file fixing > - emptying of some dependency_libs='' in tree > - the 'coming' GNU gold linker being even more stricter than > -Wl,--as-needed > - majority of `lafilefixer` users propably emerged it by accident, > thinking it's some magic bullet for their .la file problem, which it's not > I have masked it. And by the way, i have discovered installed lafilefixer on one of my desktops(but not on servers), so yeah, probably i forgot to unmerge it a long time ago ;-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC how to handle disappearing USE in (portage) dependency calculation
07.06.2013 15:26, viv...@gmail.com пишет: > Hi everybody, > sometimes a package depend from another with a particular USE flag > turned on, example llvm-3.2 on dev-libs/udis86 +pic > Sometimes a new ebuild can change IUSE, indeed udis86-1.7-r1 removed pic > use which was present in 1.7-r0. > > This RFC is to understend what we (you actually) want the packages > manager to do in this situation, as I see it there are mainly two options. > > 1) when consider the dependency _always_ satisfied, if the requested USE > is not in IUSE. > this will make user life easier, since portage now barf conflicts but > the "wrong" dependency goes unnoticed and nobody will clean the ebuilds. > > 2) error out always, both if requested USE flag should have been enabled > or not, since it's a bug and should be fixed. > emerge -uDavNt will not that easy but the tree is cleaner as a > consequence, also the developer are forced^Wencouraged to look at the > reason the USE flag disappeared analizing if their package will continue > to work. > > finally the depend in llvm ebuild has this form: > DEPEND="udis86? ( dev-libs/udis86[pic(+)] )" > and the diff between udis86 ebuilds is like this: > -IUSE="pic test" > +IUSE="test" What's the question here? How to handle this? Read about USEDEP_DEFAULTS in PMS. If you see broken packages(somebody forgot to change dependency) - file a bug about it. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
09.06.2013 18:22, Alex Legler пишет: > I'd appreciate some input on below plan to move project pages to the Wiki: > > Motivation > -- > > The main motivation is to reduce the contents on the main website, > allowing for an easier makeover. Also, the Wiki exposes the contents and > an editing capability to more people, allowing for better collaboration. > Finally, this is an opportunity for projects to go through the contents > in their project spaces and update/remove outdated contents as well > Gentoo as a whole to remove orphaned projects. Err, i do not want to say that wiki is not suite for this purpose, but what's wrong with current situation? Is there something wrong with gorg? Well, it is not always clear how to use some of it's features, but apart of that, why we should migrate to wiki? Just to clear orphaned project pages? Why we can not just have official project pages, maintained as usual through gorg and additional info in wiki(if it is needed, for example, like we do on Gentoo Qt project page? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
10.06.2013 19:15, Alex Legler пишет: > On 10.06.2013 14:36, Sergey Popov wrote: >> 09.06.2013 18:22, Alex Legler пишет: >>> I'd appreciate some input on below plan to move project pages to the Wiki: >>> >>> Motivation >>> -- >>> >>> The main motivation is to reduce the contents on the main website, >>> allowing for an easier makeover. Also, the Wiki exposes the contents and >>> an editing capability to more people, allowing for better collaboration. >>> Finally, this is an opportunity for projects to go through the contents >>> in their project spaces and update/remove outdated contents as well >>> Gentoo as a whole to remove orphaned projects. >> >> Err, i do not want to say that wiki is not suite for this purpose, but >> what's wrong with current situation? Is there something wrong with gorg? > > The software is unmaintained, and the website template is next to > unmaintainable. I could go on a bit more about this, but I think these > two points *alone* justify moving away from it. > >> Well, it is not always clear how to use some of it's features, but apart >> of that, why we should migrate to wiki? >> >> Just to clear orphaned project pages? > > No, I described multiple points. Again: > - Less contents on www.g.o -> we can much more easily relaunch it > - Users can more easily contribute to project documentation > - Update/purge project documentation > - Remove orphaned projects > I did not know that gorg is not maintained. So yeah, in that case, i understand your decision. >> >> Why we can not just have official project pages, maintained as usual >> through gorg and additional info in wiki(if it is needed, for example, >> like we do on Gentoo Qt project page? >> > > In case it wasn't clear enough yet: This is step 1 of n to get rid of > gorg and GuideXML for the website (read: not main docs) aspects of Gentoo. > Running two project page venues increases maintenance instead of > lowering it. I intend to have less work after this change, not more. > > Do you have any concerns beyond 'never change a running system'? > For now - no, i am not. Thanks for clearing things for me. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
16.06.2013 13:49, Pacho Ramos пишет: > Due ferringb retirement the following packages are up for grabs:> > > dev-util/bsdiff I will take care of it... -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last time touched bugs by year
21.06.2013 23:08, Andreas K. Huettel пишет: > Am Freitag, 21. Juni 2013, 14:50:29 schrieb Markos Chandras: >> On 21 June 2013 12:44, Tomáš Chvátal wrote: >>> 2013/6/21 Pacho Ramos >>> >>>> Could "maintainer-wanted" assigned bugs be filtered? Otherwise we see a >>>> ton of that kind of bugs that, I think, we already know can become >>>> really old ;) >>>> >>>> Thanks! >>> >>> You can do such yourself. Just clone the repo [1] and commit the updated >>> links. >>> >>> Also my plan was to list even m-w bugs, because even those suckers get >>> obsoleted often so we should close them. >>> >>> Cheers >>> >>> Tom >>> >>> [1] >>> http://git.overlays.gentoo.org/gitweb/?p=proj/qa-scripts.git;a=summary >> >> That is true. There is nothing special about there m-w bugs. They are >> still unresolved bugs, for many years. No need to treat >> them differently. >> > > How can a m-w bug be resolved? Adding the package is unlikely to happen if > last request came years ago. > > My suggestion would be (this is how I handled it in printing): > > 1) leave message on bug > "Is anyone still interested in this?" > > 2) if noone replies in 2 months, resolve as obsolete > > IMO maintainer-wanted@ bugs can be resolved only in two ways: 1) package accepted into main tree, bug is closed as FIXED. If package sits in sunrise - it's not a solution and bug should not be closed; 2) package has dead upstream, does not build with current gcc/glibc/binutils/whatever and can not be fixed - bug is closed as OBSOLETE. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last time touched bugs by year
21.06.2013 23:22, Sergey Popov пишет: > 2) package has dead upstream, does not build with current > gcc/glibc/binutils/whatever and can not be fixed - bug is closed as > OBSOLETE. > Of course i am talking about long-standing bugs, that assigned to maintainer-wanted@. That's why OBSOLETE seems to be a better decision, but WONTFIX is reasonable too :-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
24.07.2013 22:16, Peter Stuge пишет: > It seems that for this package Gentoo QA can not realistically add > any value to this package, hence my suggestion not to pretend that > they can, and just remove the distinction between ~arch and arch for > v-s, and make the latest version available to users by default. As were said before, blindly stabling vanilla-sources when gentoo-sources is stabilized is not an option. "Remove the distinction between ~arch and arch" for any package is not apropriate, as stable keywords were made for a reason, period... -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
01.08.2013 01:01, Pacho Ramos пишет: > El mié, 31-07-2013 a las 19:42 +, Robin H. Johnson escribió: >> As both a member of base-system, and the lvm2 maintainer, I'm going to >> go and look at fixing them, because I'd prefer to keep them available as >> static builds. >> > > But, what is requiring it? > https://bugs.gentoo.org/show_bug.cgi?id=478110#c33 > > Looks like the static stuff isn't needed (that would allow us to not > need to keep static stuff in sys-apps/udev) > >> On Wed, Jul 31, 2013 at 09:07:39PM +0200, Pacho Ramos wrote: >>> El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió: >>>> On 29/07/13 23:57, Pacho Ramos wrote: >>>>> Hello >>>>> >>>>> As discussed at: >>>>> https://bugs.gentoo.org/show_bug.cgi?id=478476 >>>>> >>>>> Upstream is dropping static libs from udev and, then, sys-apps/udev is >>>>> currently reverting that commit downstream (even if upstream says some >>>>> problems could appear in the future as nobody is taking care of static >>>>> stuff there). >>>>> >>>>> Grepping in the tree, looks like only some old genkernel versions are >>>>> depending on it. Apart of that, what is requiring static libs in >>>>> cryptsetup and lvm2? >>>>> >>>>> Thanks a lot >>>>> >>>> >>>> cryptsetup upstream installed minimal Gentoo setup and tested our >>>> handling of 'static' and was disappointed finding them broken >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre >>>> fails >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup >>>> static+selinux fails >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl >>>> fails >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs >>>> missing library >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag >>>> missing proper description, yes this is minor >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due >>>> to missing -lrt, likely related to linking against libudev, yes the >>>> feature we are discussing to be dropped has been completely broken for ages >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails >>>> >>>> So we are not talking about removing anything that works, but something >>>> users get hit by reading outdated guides that instruct them to enable >>>> USE=static >>>> >>>> +1 for punting broken features >>>> >>>> >>> >>> We should drop that broken support I guess, but will CC its maintainers >>> here too (they are CCed in bug report already) >>> >> > > > > Some cluster things in lvm does not work in mine setup with shared builds. Only USE="static static-libs" is only working combination. Something related with cluster file locking library - it does not load if it is build shared. Probably i should file bugreport about this -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Global USE flag: git
03.08.2013 02:38, Michael Weber пишет: > Hello, > > we have "subversion" and "cvs" ad global flags, but not "git" (or > hg|mercurial). I'm about to add the 14th [1] package using this flag. > > I propose a description > "git - Enable git (version control system) support" > in use.desc. Heh, i thought this was already a global one. I am for it -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] systemd team consensus?
11.08.2013 23:10, Tom Wijsman пишет: > There is a mismatch between the people listed on the project page [1] > and on the e-mail alias; the former lists 3 people, the latter 8. There > surely is some inconsistency here; so, who is actually part of the > team and who is just following along the mail alias? > > [1]: http://www.gentoo.org/proj/en/base/systemd/ > Project team members are listed on project's page. They all should be subscribed to apropriate alias(to get info about bugs), but also, other devs(and even users) can be subscribed to alias too. So, alias is not a source of getting list of project members :-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sets in the tree
14.08.2013 16:05, Rich Freeman пишет: > On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka > wrote: > Right now, however, > it might be useful if only to get a sense for how they're being used, > trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. Any thoughts, leechcraft guys ;-)? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sets in the tree
14.08.2013 17:02, Michał Górny пишет: > Dnia 2013-08-14, o godz. 16:53:17 > Sergey Popov napisał(a): > >> 14.08.2013 16:05, Rich Freeman пишет: >>> On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka >>> wrote: >>> Right now, however, >>> it might be useful if only to get a sense for how they're being used, >>> trade ideas, etc. >> >> Well, we can use sets as replacement for metapackages(for example, >> qt-meta, leechcraft-meta). >> >> Well, as for leechcraft-meta, we can not simply replace metapackage with >> set, cause we have unstable USE-flag there. > > No, we can't. Sets are portage-specific, the tree needs to follow PMS. > I am all for the standarts, but as we did not brought sets to PMS yet(when we updated it for EAPI changes), my question is: 'why?'. It is one of the long-standing feature of quite experimental 2.2_alpha branch, that should finally come to release(Thanks to portage team, by the way :-)). Why it was not added as a part of the PMS? Some implementation flaws? Or maybe, architecture problems? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sets in the tree
14.08.2013 23:34, hasufell пишет: > PMS is a waste of time, we should drop it until people are able to > maintain it properly. They are obviously not. No, it is not. If we have no clear implementation-agnostic background about how things should work, then we will be screwed for no good reason, sorry for harsh words. But yeah, PMS is not ideal. We should improve it, thus i do not really understand how :-( -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2
01.08.2013 21:50, Pacho Ramos пишет: > El jue, 01-08-2013 a las 14:05 +0400, Sergey Popov escribió: > [...] >> Some cluster things in lvm does not work in mine setup with shared >> builds. Only USE="static static-libs" is only working combination. >> Something related with cluster file locking library - it does not load >> if it is build shared. Probably i should file bugreport about this >> > > You certainly should report it as looks like we are the only downstream > willing to still keep that option and, once upstream has dropped it and > people from other distributions won't likely help us fixing the bugs, > would be better to try to fix it (in a long term perspective) > > I have time(at last!) to check with new stable lvm/udev. All things are fine without static and static-libs USEs. Do not know, what is changed, probably this was some fault from my side :-/ -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
20.08.2013 14:26, Michał Górny пишет: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to you, it's > worth the hassle. > > The features are off by default since they need proper testing and can > break a lot of ebuilds. And FEATURES=network-sandbox does. > > It should be noted that all of the features follow the systemd idea of > supporting Linux only and require fancy kernel features. Great features, i will definitely try them! -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 16:08, hasufell пишет: > I don't see how defining phases explicitly improves readability which > even increases chances of overwriting phases by accident and having > further complications especially in multilib eclasses. > > DOCS=( foo* ) > > looks pretty readable to me > I am not for nor against this feature, but it would be nice to add support for directories in DOCS variable. Cause, overwriting install phase just to install directory with docs(instead of files) seems a bit odd for me. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 17:02, Michał Górny пишет:
> Is there a future-eapi bug open for it? If not, please open one.
I will, thanks
> I myself don't have anything against plain 'dodoc -r'. But I wonder if
> this isn't going to end up with people considering 'what if my
> directory has .svn/CVS in it?'
>
{ecvs,esvn}_clean FTGJ :-)
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] gtk2/gtk3 use flags
16.08.2013 21:15, hasufell пишет: > https://bugs.gentoo.org/show_bug.cgi?id=420493 > > gtk2 and gtk3 useflags are discouraged and should only be used in > special cases > > file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer will quit if i keep things that way :-/ [1] - https://bugs.gentoo.org/show_bug.cgi?id=463578 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
20.08.2013 22:28, Ian Stakenvicius пишет: > I see a few issues with ~arch -> table migrations: > > #1 - things just sit in ~arch. The auto-stablereq script should help > with this one I think; we should give it some time to see if it works out. My personal opinion on this - there is some package, that should not go into stable. Do not get me wrong, but i presumes that stable gives user ability to run well-working applications. If package can fail in some stupid untrivial ways and maintainer can reproduce this - then this version should not go into stable. And you know that some packages can be in such state, well, for years of active development. But it does not mean that some subset of users needs them. That's why - ~arch(or, if they are broken in some security-related things - hardmasked). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
20.08.2013 23:48, Tom Wijsman пишет: > Yes, +1; last time this came up on chat, I asked whether it would be a > nice idea to have something between stable and ~, what you propose > sounds similar and might make sense. Though, on the other hand, doing > it this way we don't get the advantages that filing bugs give; if we > do it this way, I'd assume we need some other implementation to > cover that (for things like the "depends on", "blocks", ... fields)... Why we should bring new half-stable, half-testing keyword for this? I think that this is no way to go. We should improve current situation with arches by some other ways(e.g., recruiting people). Maybe drop some damn-bad understaffed arches to unstable only(i do not point finger on anyone, they know, who they are... :-)) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
20.08.2013 23:42, Tom Wijsman пишет: > On Tue, 20 Aug 2013 14:29:09 -0400 > Wyatt Epp wrote: >> What manner of bitrot? > > They might ... > > 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 00:06, Tom Wijsman пишет: > On Tue, 20 Aug 2013 15:41:42 -0400 > Rich Freeman wrote: > >>> Let me dig up an example... >>> >>> Our last sys-kernel/gentoo-sources stabilization was 3 months ago: >> >> I don't really see a problem with stable package being all of 3 months >> old. Contrast that with youtube-dl which pull from ~arch and rebuild >> about 3x/week. > > For something that releases once to twice a week, it is a problem; > we're not talking about a package that gets some slow commits here, no, > let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233 And you are dead sure that shiny new versions does not need testing in Gentoo for a reasonable amount of time(30 days)? If yes, then we have a problem in definitions here(thus, i am not talking about security stabilizations, they should be done as quickly, as bug reveals) > That's a lot of commits; now you need to realize that every single > commit in this means something, a lot of them are bug fixes (stability, > security, reliability, anti corruption, ...) whereas of course a part of > it also introduces parts of new features and refactoring. > > Desktop users might not care for all of these, but sysadmins will; > actually, that's what this thread is about, they are switching to ~ > because of things like this. Who are we stabilizing for then?! You should undestand that stabilizing new kernel should also imply that some important modules, presenting in tree will also work with them. I really do not like slow upstreams and situations like with nvidia-drivers, but i understand that this is not kernel team matter, it is upstream problem. And that fact, that you can successfully build and run kernel for a couple of hours, does not make it "good, well tested stable candidate" > > Bitrot due to a lack of resources. > Such problem is exists, yeah, i agree. But do not overcomplicate things. We should fight with lack of resources, not with turning stable into "just more old, but also breakable testing" -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 00:00, Alan McKinnon пишет: > Hey, maybe you guys are doing your job in ~arch *too well*, to your own > detriment :-) Something to consider? ~arch should not break every day, yeah(we have hardmasked for that :-P), but it means that breakages are ALLOWED and it is NORMAL if they are not severe. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 12:17, Tom Wijsman пишет: > On Wed, 21 Aug 2013 11:57:22 +0400 > Sergey Popov wrote: > >> 20.08.2013 23:42, Tom Wijsman пишет: >>> On Tue, 20 Aug 2013 14:29:09 -0400 >>> Wyatt Epp wrote: >>>> What manner of bitrot? >>> >>> They might ... >>> >>> 2. ... contain security bugs that later versions have fixed. >> >> There should be security bug on our bugzilla with quick stabilization >> on it and(probably) GLSA. > > Not all security bugs are visible; the older a piece of software, the > higher the chance that some people know about one or another exploit > that the rest of the world does not know about. > True. But blindly bringing new versions into stable(without testing) cause it POSSIBLY(without ChangeLog notes or CVES or whatever) contains LESS security problems is not an option. Stable should be reasonable -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 12:13, Tom Wijsman пишет: > Recruiting shows to be a hard task; so, the suggestions I am doing are > assuming that that doesn't work out. In which case, I wonder what "by > some other ways" you would think of... Dropping some keywords to unstable on minor arches. And about recruiting, it is the only way we can keep moving with getting distro, which makes bigger and bigger all the time. I would have joined recruiters unless i knew how difficult job they are doing. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 12:25, Tom Wijsman пишет: > > 3.10 is not a shiny new version, it has been in the Portage tree for 7 > weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's > almost double the time you are suggesting. > Current stabilization target(3.10.7) was added to tree: *gentoo-sources-3.10.7 (15 Aug 2013) 15 Aug 2013; Tom Wijsman +gentoo-sources-3.0.91.ebuild, +gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild, -gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild, -gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild, -gentoo-sources-3.4.54.ebuild: Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip) So it is definitely NOT 7 weeks(30 days period counting from time when ordinary user can install it through portage, thus - after hitting portage tree). You know, that we can lighten stabilization requirements of 30 days sometimes, but let's be honest. > Why should an external proprietary module that does not fix what is > broken for 7 weeks now block stabilization; it has never blocked > stabilization before, and I do not see a reason it should now... > >> And that fact, that you can successfully build and run kernel for a >> couple of hours, does not make it "good, well tested stable candidate" > > Having people run it for 7 weeks is not a couple of hours. > First of all, as i said early - it is NOT 7 weeks(thus - not a couple of hours either). And example with Nvidia drivers is not point of beginning a flamewar. We ARE a distro. Then, we should propose INTEGRATION of some kind. If some open-source modules with active upstreams, included in portage, do not support yet 3.10.* which will lead to unbootable system for some stable users - what you should say? "Oops, sorry, guys?" That's not how stable should work. We should either mark such modules as forever unstable(or even mask?), saying "guys, shit happens, do not use this in Gentoo, unless you are dead sure, that you can handle problems with updates" or slowing down stabilization(i am not talking about security stabilization right now). And as for security stabilization, if you say that version bump BRINGS security fixes, you KNOW what they are, and you do NOT file a security bug about old stable(and now - vulnerable!) kernel on Gentoo bugzilla, then current stabilization bug has no relation to security(as Gentoo Security team does not know about security problems), period. > Well, my thoughts is that the way we are doing it now we aren't going to > be able to deal with the lack of resources; so, a different approach is > necessary and I don't see how it is "old, but also breakable"... > I undestand your disturbance as Gentoo Kernel team member. But your proposal does not seem good to me. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 12:39, Tom Wijsman пишет: > "The latest distros seemed to be just a bunch of same old stuff. > Nothing new -- nothing innovative." ~ Larry's frustration. :( > > "Then Larry tried Gentoo Linux. He was just impressed. ... He > discovered lots of up-to-date packages ..." ~ Larry's happiness. :) > > http://www.gentoo.org/images/poster.jpg > And how that regards about stable, huh? If you want to raise problem that ~arch has too less version bumps, well, that's other topic(but with same reason - lack of manpower :-(). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 13:28, Tom Wijsman пишет: > That is 3.10.7, not 3.10; please look into how kernel releases work, > minor releases are merely a small number of "backported" "known" fixes. > > What you propose, waiting 30 days for a minor; simply doesn't work > when there are one to two minors a week, it puts us even more behind... > We considered stabilizing package relying on it's version. Policy says that we should wait reasonable amount of time, no matter which version it is. And yes, minor release MAY bring breakages, do not tell me that they are not, i hit such breakages at least 4 times for kernel(no matter gentoo or vanilla, so problem is NOT genpatches) for past 5 years. And do you really want to stabilize EVERY minor release of some upstream stable branch? Maybe you want to bring some stable well tested version for some period and let unstable users choose another if they want to? And then - jump to next stable branch. >>> Why should an external proprietary module that does not fix what is >>> broken for 7 weeks now block stabilization; it has never blocked >>> stabilization before, and I do not see a reason it should now... >>> >>>> And that fact, that you can successfully build and run kernel for a >>>> couple of hours, does not make it "good, well tested stable >>>> candidate" >>> >>> Having people run it for 7 weeks is not a couple of hours. >>> >> >> First of all, as i said early - it is NOT 7 weeks(thus - not a couple >> of hours either). > > It is 7 weeks. As i said early - it is not. Kernel team may have different policies on stabilization, that's OK IMO, but do not bend facts. This is release, and it should be considered as release, no matter minor or major. And stabilizations counts from it, not from 3.10.0. Following your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc are "minor". They are not. >> If some open-source modules with active upstreams, included in >> portage, do not support yet 3.10.* which will lead to unbootable >> system for some stable users - what you should say? "Oops, sorry, >> guys?" That's not how stable should work. > > That's how it has always worked, we do not see a need to change this. No it is not. We considered such things as serious flaws. At least - i consider. >> And as for security stabilization, if you >> say that version bump BRINGS security fixes, you KNOW what they are, >> and you do NOT file a security bug about old stable(and now - >> vulnerable!) kernel on Gentoo bugzilla, then current stabilization >> bug has no relation to security(as Gentoo Security team does not know >> about security problems), period. > > Actually, those are constantly filed by ago; please look at the picture > first before you describe it, because you are drawing assumptions here. > I do not see any dependant bugs in your current stable request, but you keep telling me about security, so i do not drawing any assumptions - it is not security stabilization in terms of Gentoo(probably it becomes so if you can find apropriate security flaws). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 13:17, Manuel Rüger пишет: > > Security team could maintain its own p.accept_keywords in profiles/ and > add testing keyworded ebuilds that fix security issues there. > Users who are interested skipping the stabilization process could link > it into their /etc/portage/p.accept_keywords directory. No, it is not an option. Masking current stable because it is broken was not successful also(i heard, that this was usual practice earlier). Please, let's not reinvent the wheel around evident problem: lack of manpower. Easing stabilization procedure makes stable more, well, unstable. Bringing some workarounds like this brokes consistency of keywording. Keywords are things, that chosen by user. Overlays maintains keywords lists, yeah, but that can be reasonable only on vast amount of packages(like KDE). As i said earlier, we should recruit more people -> then problem will go away. Both for security(that have a VAST amount of work, that i am saying as a rookie security developer :-)) and arch teams. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 13:13, Tom Wijsman пишет: > On Wed, 21 Aug 2013 12:32:35 +0400 > Sergey Popov wrote: > >> 21.08.2013 12:13, Tom Wijsman пишет: >>> Recruiting shows to be a hard task; so, the suggestions I am doing >>> are assuming that that doesn't work out. In which case, I wonder >>> what "by some other ways" you would think of... >> >> Dropping some keywords to unstable on minor arches. > > If we grow (like you said below), then doing less seems like a decision > that we shouldn't take; it is rather about "doing it different" to use > our resources in a better way. Crowd sourcing users is an option here... What crowd sourcing do you talking about? We have Arch Tester for that. Do you see vast interest in this initiative? I think not(thus, for major arches we have some amount of testers, some of them are became developers lately). And if you want to move stabilization checks to unqualified users, then it is way to nowhere. > Came across three types of people already trying to find a mentee: > > 1. The first one doesn't want to go through the amount of time it takes; >this depends a bit on the queue, but it can take months. > > 2. The second one's interest to become a Gentoo Developer depends from >time to time; so, tries to start over and over to become one. > > 3. The third one writes a lot of ebuilds (and has an overlay that >looks like a gold mine), but there is a language barrier that keeps >the user from contributing; so, we take things slowly instead... > > 4. The fourth one leaves a message on IRC and quits before you return. > > 5. ... > > So, recruiting in the terms of "finding recruits" appears to be hard. > But, at my POV, it is only one way that we can improve current situation. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 14:36, Tom Wijsman пишет: > On Wed, 21 Aug 2013 13:54:51 +0400 > Sergey Popov wrote: > >> 21.08.2013 13:13, Tom Wijsman пишет: >>> On Wed, 21 Aug 2013 12:32:35 +0400 >>> Sergey Popov wrote: >>> >>>> 21.08.2013 12:13, Tom Wijsman пишет: >>>>> Recruiting shows to be a hard task; so, the suggestions I am doing >>>>> are assuming that that doesn't work out. In which case, I wonder >>>>> what "by some other ways" you would think of... >>>> >>>> Dropping some keywords to unstable on minor arches. >>> >>> If we grow (like you said below), then doing less seems like a >>> decision that we shouldn't take; it is rather about "doing it >>> different" to use our resources in a better way. Crowd sourcing >>> users is an option here... >> >> What crowd sourcing do you talking about? We have Arch Tester for >> that. Do you see vast interest in this initiative? I think not(thus, >> for major arches we have some amount of testers, some of them are >> became developers lately). > > Yes, it is a large share of users that run ~, they "want to test". But it seems that they do not want to become Arch testers and bring things to stable, do not you think? >> And if you want to move stabilization checks to unqualified users, >> then it is way to nowhere. > > No, because there would be much more users giving feedback. Feedback is good. But if it simple "works for me" without tests on CFLAGS/LDFLAGS respect regression, cross-compile breakage regression or any other regressions, than it is pointless. I would suggest increase number of arch testers... Or, i repeat myself(in infinite time), "recruit more people" >>> So, recruiting in the terms of "finding recruits" appears to be >>> hard. >> >> But, at my POV, it is only one way that we can improve current >> situation. > > Sorry, I do not understand (language barrier), do you mean that 1) that > should be the way to improve it or do you mean that 2) this is just one > approach and that we should look at different ones? > Yeah, my grammar sucks, i know. So, let's summarize what i mean. To deal with our current problems with arches we have only two ways: 1) drop some arches to unstable -> lower the burden to arch teams; 2) recruit more arch testers/arch team members; -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 14:29, Tom Wijsman пишет: > On Wed, 21 Aug 2013 13:42:56 +0400 > You do draw assumptions, because you don't take a look; please do: > > https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org > > Sort by "Changed" such that the newest appear on top. > And how should i must knew that these bugs related to particular versions if they do not contain affected versions(i know that ALL versions may be affected in particular time, but we are talking about new stable kernel which bring fixes) and no dependant bugs in stable request? How can i, not beeing member of Gentoo Kernel Team, discover that it is security stabilization and which security bugs, registered in our bugzilla, will gone when i will upgrad to it? Honestly, we should revive Kernel Security subproject somehow, cause this mess may confuse even ordinary developers. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sets in the tree
15.08.2013 12:12, Pacho Ramos пишет: > El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: > > Ah, looks like I was too optimistic and we are (again) with the usual > blocking (and blocker) issues -_- (PMS refusing to include something > because of "lack of documentation" :S) > > And they are right at this point. How you can include something into standard, that is not documented? Documentation of how to use sets(for users) is not enough in this case, IMHO. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 15:04, Markos Chandras пишет: > Hi, > > It's time of year again to consider moving a few arches to dev-only status. > > I propose the following arches to lose their stable keywords > > - s390 > - sh > - ia64 > - alpha > - m68k > - sparc > > The manpower on these arches is below acceptable levels and they often > block stabilizations > for many months. This also causes troubles to developers trying to get > rid of old versions of > packages. > > I am CC'ing Mike and on this to draw his attention since he seems to > be doing stabilizations and > keywording on a few of them. Moreover, Agostino is also doing a lot of > work on these arches. > Consider what will happen if he ever goes MIA or decides to retire ;) > We will probably end up > with a pile of stabilization bugs like the good old days. > > In my opinion, having these arches be ~arch only, will improve the > overall user experience > since the arch teams will only have to test a single tree. It will > also help developers get rid of > old ebuilds and keep the portage tree healthy and reasonably updated. > > If I get enough positive feedback on this, I will propose this in the > next Council's agenda. > +1 for that. Unless we have more manpower on them, their 'stable' state can bring false expectations to users. Do not get me wrong, i am all for choice, but if we can not bring quality stabilization on those arches(as we have no hardware, no manpower, etc.) - they should go to unstable. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 17:22, Sergey Popov пишет: > 20.08.2013 17:02, Michał Górny пишет: >> Is there a future-eapi bug open for it? If not, please open one. > > I will, thanks Here it is: https://bugs.gentoo.org/show_bug.cgi?id=481980 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 17:38, Wyatt Epp пишет: > Fundamentally, I see this as a problem of tooling. I think that no tool can cover all cases of checking that software WORKS. I mean - in generic, for all kinds of software. You can guarantee if it builds, if it follow some QA rules about CFLAGS/LDFLAGS/whatever, but there is only one 100% way to guarantee that software works - run and do something useful :-). Yeah, i know about testsuites, that can help in that case. Unfortunately: 1) they do not cover all cases, but that's not so important; 2) often they are badly broken; 3) not every program carries test suite. So, we stuck at automation in run-time checks right at the beginning :-). But yeah, we could automate build-time checks, surely. > > I'd like to point out something that jumped out to me as a red flag > earlier (not to pick on you specifically, Tom; this is just the > cleanest example I saw), and turn it into an example: > > On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman wrote: >> >> Well, they are listed there; but it's quite some work to actually go >> through that list, that is, manually check the bugs of ~2000 packages >> as well as file a STABLEREQ bug, takes quite a while... >> > This right here is a real problem. Any time you're talking about > doing anything on this scale "manually", you've already lost the > battle. You need a tool to minimise the overhead of time and > cognitive load. What would that tool look like? Think about the > steps involved and how you can reduce them to only the parts that > absolutely require decisions on your part. > >>> At least in the areas I usually work, I have found a combination of >>> the automatic stabilisation requests and imlate have definitely cut >>> back on the bitrot. >> >> A single unimportant bug can prevent the automatic STABLEREQ bug from >> getting filed; as for imlate, not everyone seems to know that tool, not >> everyone seems to run it. Attention for some stabilizations is lost... >> > First off, why do developers not know about the tools? How can this > be addressed? For a start, I'd suggest making sure the tools are at > least mentioned in the docs. Somewhere other than the amd64 Arch > Testing guide from 2006. [1] That's the only concrete (i.e. actually > in the DOCS rather than the ML archives) documentation I've found so > far, and it only references the file, rather than the tool. Maybe in > the devmanual Tools Reference? [2] > Good point, i agree. > But, imlate is a good example of a tool that could ease the time cost > of grindy crap. You showed before that it can get an ordinary count > bounded on n days. That's handy, but only a little. Build out: > - How many of those stablereq bugs reference versions no longer in the > tree? Those can probably get closed. > - How many have newer STABLE versions in the tree in the same slot? > Probably fine to close those, too. > - Of the remaining, how many have patches or ebuilds attached? Those > may be solved problems waiting for closure; shortlist them. > - How many are packages with newer versions that have been in the tree > for >30 days? Consider changing the target version, then. > - How many have open blockers, and what are those blockers (w/link and > summary)? Scan for low-hanging fruit jumping out in that list. > - Get views by category; are there categories where updates are more > important? Things in @system, and things with security concerns > (stuff in net-*) should probably get higher priority; games... > probably less so. > - Are there bugs with certain keywords in the body that should raise > priority? Things like "security" or "overflow" might be good > candidates. > - Are there bugs with certain keywords in the body that indicate it'll > be really easy to decide? e.g. "trivial" or "minor" might turn up some > of those super-small version bumps that you pretty much know aren't > going to affect stability. > > These are just examples off the top of my head, and by no means > bulletproof, but these are in the class of improvements that have ROI > because they reduce a task that previously took developer time to one > that takes CPU time. CPU time is essentially free compared to the > value of dev time. That's what i called constuctive criticism. Congratulations :-) > And I'm not saying more recruiting shouldn't happen, but relying on it > is no better than hoping at $deity for bugs to close themselves. ;) > > Cheers, > Wyatt > > [0] Okay, maybe in the "glory days" when we were higher up on > Distrowatch and thing were really kicking. (I know, I know, &q
Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 22:28, Alexis Ballier пишет: > > Instead of dropping them entirely to ~arch, maybe something in between > could be done: Said arches could start moving to ~arch the leaf and > less important packages. E.g. we have (had?) a lot of sparc keywords on > sound packages or ppc keywords on ocaml ones because at some point > (~10 years ago) some dev was interested in these on this architecture > but I'm pretty sure nobody uses them. > > In short: Reduce stable coverage to reduce the workload. > > Also, from what I've seen in the thread, you are talking about keywords > only, right ? Do these arches keep their stable mark in profiles.desc? > I like this way much more. Let's clarify stabilization policy for some minor arches, e.g. policy about stabilization requests for huge packages. Cause dropping entire arch to ~arch maybe sometimes a bit overkill. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
22.08.2013 16:26, Markos Chandras пишет:
> On 22 August 2013 13:17, Michael Weber wrote:
>>
>> Having a mixed setup isn't that absurd as you want it to be.
>> And forcing users to not use it renders all package.{accepted_,}keywords
>> granularity moot.
>>
>> It's like nailing them to debian stable or debian testing w/o backports
>> or anything.
>>
>> Please stop dooming this possibility. Mixing together software versions
>> isn't that much of a magic as you make of it.
>
> I said that it is a combination not well tested so we do not encourage
> this. Users are free to do whatever they want.
>
> When did I say the opposite? However they should not expect much
> support if they use a mixed system and they run into
> troubles. Someone who does that, should know what he is doing and be
> prepared to run into problems.
> And I will stop here because this discussion is off-topic.
>
>>
>>> It's also a bit ehm, funny, to give them a stable stage3 and then tell
>>> them that for everything else, please use ~arch.
>>
>> (I'm not saying that it doesn't hurt in some places, but it's
>> manageable, as is living on arches with stable core and very few stable
>> leave packages, like I've been doing on sparc, ppc and arm.)
>>
> This is yet to be decided.
>
I have mixed setup for years:
pinkbyte@oas1 ~ $ ls /etc/portage/package.accept_keywords/ -1 | wc -l
19
At home this number is above 40, iirc.
And i do not think that refusing bugreports from such systems is a
proper way.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
22.08.2013 06:05, Albert Hopkins пишет: > This sounds like cool stuff... I wonder if this could be a step towards > unprivileged users being able to use portage for user-installed apps. > Try Prefix[1], it works very well in some cases ;-) [1] - http://www.gentoo.org/proj/en/gentoo-alt/prefix/ -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SDL2 update
28.08.2013 20:06, hasufell пишет:
> On 08/28/2013 05:53 PM, "Paweł Hajdan, Jr." wrote:
>>>
>>> S=${WORKDIR}/SDL2_mixer-${PV}
>
>> Why no quotes? ("")
>
>
>>> S=${WORKDIR}/${MY_P}
>
>> Why no quotes? ("")
>
>
>>> S=${WORKDIR}/SDL2_ttf-${PV}
>
>> I suggest quotes ("").
>
>
>
> Those are variable assignments and don't need a quote.
>
And if WORKDIR will contain whitespace(s), does this code still be
working? :-)
// sorry for bikeshedding, can not resist
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dialup/sendpage: sendpage-1.1.0-r2.ebuild ChangeLog sendpage-1.1.0-r1.ebuild
02.09.2013 19:29, Ian Delaney (idella4) пишет:
> idella4 13/09/02 15:29:57
>
> Modified: ChangeLog
> Added:sendpage-1.1.0-r2.ebuild
> Removed: sendpage-1.1.0-r1.ebuild
> Log:
> revbump -> EAPI 5, remove old
>
> (Portage version: 2.2.0/cvs/Linux x86_64, signed Manifest commit with key
> 0xB8072B0D)
>
> Revision ChangesPath
> 1.13 net-dialup/sendpage/ChangeLog
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?r1=1.12&r2=1.13
>
> Index: ChangeLog
> ===
> RCS file: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- ChangeLog 14 Jun 2012 01:50:05 - 1.12
> +++ ChangeLog 2 Sep 2013 15:29:57 - 1.13
> @@ -1,6 +1,12 @@
> # ChangeLog for net-dialup/sendpage
> -# Copyright 2000-2012 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.12
> 2012/06/14 01:50:05 zmedico Exp $
> +# Copyright 2000-2013 Gentoo Foundation; Distributed under the GPL v2
> +# $Header: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.13
> 2013/09/02 15:29:57 idella4 Exp $
> +
> +*sendpage-1.1.0-r2 (02 Sep 2013)
> +
> + 02 Sep 2013; Ian Delaney +sendpage-1.1.0-r2.ebuild,
> + -sendpage-1.1.0-r1.ebuild:
> + revbump -> EAPI 5, remove old
>
>14 Jun 2012; Zac Medico sendpage-1.1.0-r1.ebuild:
>inherit user for enewgroup and enewuser
>
>
>
> 1.1 net-dialup/sendpage/sendpage-1.1.0-r2.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&content-type=text/plain
>
> Index: sendpage-1.1.0-r2.ebuild
> ===
> # Copyright 1999-2013 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header:
> /var/cvsroot/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild,v 1.1
> 2013/09/02 15:29:57 idella4 Exp $
>
> EAPI=5
>
> inherit perl-module eutils user
>
> MY_P=${PN}-1.001
> DESCRIPTION="Dialup alphapaging software."
> HOMEPAGE="http://www.sendpage.org/";
> SRC_URI="http://www.sendpage.org/download/${MY_P}.tar.gz";
> S="${WORKDIR}/${MY_P}"
>
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS="~amd64 ~ppc ~x86"
> # This package warrants IUSE doc
> IUSE=""
>
> DEPEND="!net-misc/hylafax
> >=dev-perl/Device-SerialPort-0.13
> >=dev-perl/MailTools-1.44
> >=virtual/perl-libnet-1.11
> >=dev-perl/Net-SNPP-1.13
> dev-perl/DBI"
>
> mydoc="FEATURES email2page.conf sendpage.cf snpp.conf"
>
> pkg_setup() {
> enewgroup sms
> enewuser sendpage -1 -1 /var/spool/sendpage sms
> }
>
> PATCHES=( "${FILESDIR}"/${PV}-makefile.patch )
>
> src_install() {
> perl-module_src_install
> insinto /etc
> doins sendpage.cf
> newinitd "${FILESDIR}"/sendpage.initd sendpage
> diropts -o sendpage -g sms -m0770
> keepdir /var/spool/sendpage
> # Separate docs/ content from ${mydoc[@]}
> docompress -x /usr/share/doc/${PF}/text/
> docinto text/
> dodoc docs/*
> }
>
>
>
>
EAPI=5 has no implicit RDEPEND="${DEPEND}". Does this package really has
no run-time dependendies?
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Improve the security of the default profile
05.09.2013 14:47, Tom Wijsman пишет: > On Thu, 05 Sep 2013 12:13:28 +0200 > Agostino Sarubbo wrote: > >> Hello, >> >> during an irc debate, me and other people just noticed that the >> default profile could use more flags to enhance the security. >> >> An hint is here: >> https://wiki.ubuntu.com/ToolChain/CompilerFlags >> >> Please argue about what we _don't_ use. >> >> Note: please CC me in your response. > > What I wonder about here is at which cost this does come, when looking > at the fstack-protector then I see that it "emits extra code"; so, now > the question is what kind of overhead this causes. > > I am pretty sure security might not be that important on a real time > system that perhaps isn't connected to the internet; so, besides making > it the default, we might want to introduce the necessary means to turn > it off again, by the very least perhaps documentation would suffice. > > Do you intend to discuss that flag or more generally any security flag? > Regarding -fstack-protector - it can be used at least in hardened profiles(but i have some sort of bad expirience with it and uclibc[1]). Also kernel has apropriate option to enable it during build. However, i am not skilled with GCC internals, so i can say nothing about perfomance impact this flag may have. Maybe toolchain guys can bring light on this ;-) [1] - https://bugs.gentoo.org/show_bug.cgi?id=470608 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dialup/sendpage: sendpage-1.1.0-r2.ebuild ChangeLog sendpage-1.1.0-r1.ebuild
04.09.2013 18:01, Ian Stakenvicius пишет:
> On 04/09/13 01:28 AM, Sergey Popov wrote:
>> 02.09.2013 19:29, Ian Delaney (idella4) пишет:
>>> idella4 13/09/02 15:29:57
>>>
>>> Modified: ChangeLog Added:
>>> sendpage-1.1.0-r2.ebuild Removed:
>>> sendpage-1.1.0-r1.ebuild Log: revbump -> EAPI 5, remove old
>>>
>>> (Portage version: 2.2.0/cvs/Linux x86_64, signed Manifest commit
>>> with key 0xB8072B0D)
>>>
>>> Revision ChangesPath 1.13
>>> net-dialup/sendpage/ChangeLog
>>>
>>> file :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&view=markup
>>>
>>>
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&content-type=text/plain
>>> diff :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?r1=1.12&r2=1.13
>>>
>>>
>>>
> Index: ChangeLog
>>> ===
>>>
>>>
> RCS file: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v
>>> retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12
>>> -r1.13 --- ChangeLog14 Jun 2012 01:50:05 - 1.12 +++
>>> ChangeLog 2 Sep 2013 15:29:57 - 1.13 @@ -1,6 +1,12 @@ #
>>> ChangeLog for net-dialup/sendpage -# Copyright 2000-2012 Gentoo
>>> Foundation; Distributed under the GPL v2 -# $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.12
>>> 2012/06/14 01:50:05 zmedico Exp $ +# Copyright 2000-2013 Gentoo
>>> Foundation; Distributed under the GPL v2 +# $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.13
>>> 2013/09/02 15:29:57 idella4 Exp $ + +*sendpage-1.1.0-r2 (02 Sep
>>> 2013) + + 02 Sep 2013; Ian Delaney
>>> +sendpage-1.1.0-r2.ebuild, + -sendpage-1.1.0-r1.ebuild: +
>>> revbump -> EAPI 5, remove old
>>>
>>> 14 Jun 2012; Zac Medico
>>> sendpage-1.1.0-r1.ebuild: inherit user for enewgroup and
>>> enewuser
>>>
>>>
>>>
>>> 1.1
>>> net-dialup/sendpage/sendpage-1.1.0-r2.ebuild
>>>
>>> file :
>>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&view=markup
>>>
>>>
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&content-type=text/plain
>>>
>>> Index: sendpage-1.1.0-r2.ebuild
>>> ===
>>>
>>>
> # Copyright 1999-2013 Gentoo Foundation
>>> # Distributed under the terms of the GNU General Public License
>>> v2 # $Header:
>>> /var/cvsroot/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild,v
>>> 1.1 2013/09/02 15:29:57 idella4 Exp $
>>>
>>> EAPI=5
>>>
>>> inherit perl-module eutils user
>>>
>>> MY_P=${PN}-1.001 DESCRIPTION="Dialup alphapaging software."
>>> HOMEPAGE="http://www.sendpage.org/";
>>> SRC_URI="http://www.sendpage.org/download/${MY_P}.tar.gz";
>>> S="${WORKDIR}/${MY_P}"
>>>
>>> LICENSE="GPL-2" SLOT="0" KEYWORDS="~amd64 ~ppc ~x86" # This
>>> package warrants IUSE doc IUSE=""
>>>
>>> DEPEND="!net-misc/hylafax >=dev-perl/Device-SerialPort-0.13
>>>> =dev-perl/MailTools-1.44 >=virtual/perl-libnet-1.11
>>>> =dev-perl/Net-SNPP-1.13 dev-perl/DBI"
>>>
>>> mydoc="FEATURES email2page.conf sendpage.cf snpp.conf"
>>>
>>> pkg_setup() { enewgroup sms enewuser sendpage -1 -1
>>> /var/spool/sendpage sms }
>>>
>>> PATCHES=( "${FILESDIR}"/${PV}-makefile.patch )
>>>
>>> src_install() { perl-module_src_install insinto /etc doins
>>> sendpage.cf newinitd "${FILESDIR}"/sendpage.initd sendpage
>>> diropts -o sendpage -g sms -m0770 keepdir /var/spool/sendpage #
>>> Separate docs/ content from ${mydoc[@]} docompress -x
>>> /usr/share/doc/${PF}/text/ docinto text/ dodoc docs/* }
>>>
>>>
>>>
>>>
>
>> EAPI=5 has no implicit RDEPEND="${DEPEND}". Does this package
>> really has no run-time dependendies?
>
>
>
> Well, perl-module.eclass adds an RDEPEND of dev-lang/perl , so there's
> that. If it's just perl scripts, though (and I haven't checked if it
> is or not), then that probably would be the only hard RDEPEND...
>
Package contents are EXACTLY the perl scripts that needs specified
modules in runtime. Fixed that now.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
23.09.2013 22:29, Markos Chandras пишет: > On 09/23/2013 03:07 PM, Alexis Ballier wrote: >> >> we have 'stable', 'dev' and 'exp'; the difference between 'dev' and >> 'exp' is unclear to me. it could be changed so that broken deps in >> 'dev' profiles are a repoman error (without -d) but without stable >> keywords. >> >> Alexis. >> > I believe the 'exp' profile makes no sense. It might did in the past, > but I believe we are fine having only 'stable' and 'dev'. So unless I am > missing something obvious, 'dev' can be used to express ~arch only > architectures whether they are in a good or bad state. > I think current dedication of pure-unstable arches on well-maintained and dependency consistent arches in dev and arches where dependency consistency is someway broken(Prefix) makes sense. Unless somebody wants to clean up some mess i have seen in Prefix deps by fulling package.use.mask in prefix profiles with tons of deps. Anyway, we have apropriate options in repoman for checking on dev and exp profiles, and, regarding the Prefix, i think we can try to move prefix profiles to dev when Prefix tree will be merged with gentoo-x86 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
24.09.2013 23:07, Markos Chandras пишет: > On 09/24/2013 07:28 PM, Agostino Sarubbo wrote: >> On 09/23/2013 22:41, Markos Chandras wrote: >>> (unless of course you want to increase your number of cvs commits >>> which is a worrying argument on its own) > >> 11:16 #gentoo-bugs: <+bonsaikitten> ago: do me a favour and >> de-keyword all affected packages for s390 > >> Also, nobody give me an award for the commits, so I really don't >> understand what you mean. > > I don't understand why you quote something from Patrick. > > All I am saying, is to avoid mass-commits for no reason. The stable > keywords will be lost during time by removing old version of the packages. > > I think optimal solution here is to СС unstable arches on stable requests for new versions of packages to let them drop stable keywords. And if they are silent - dropping keywords with all revdeps by maintainer itself when other arches are done with stabilization. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] stabilizing libraries without testing reverse deps
30.09.2013 01:41, hasufell пишет: > Arch teams do not test them, so this is the business of the maintainer > or the dev who requested stabilization. > I hope you are kidding, cause when i was joining to arch teams, i was taught to test reverse dependencies of libraries. Of course, maintainer should test this also when bringing new version to tree to prevent breakages. But stabilizing is different story and those who putting apropriate version to stable should be 100% sure that it would not break revdeps. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
13.10.2013 11:46, Sven Eden пишет: > Am Samstag, 12. Oktober 2013, 08:45:15 schrieb Pacho Ramos: >> Due pebenito retirement: >> dev-libs/ustr > > I've never heard of that package before, but the description sounded > interesting. So I went to their site and read what it is about, and it looks > like a project that seems to be ideal for my work. > And while I'll be at introducing ustr into our existing projects (about 90% > are pure C99 on debian servers), I could proxy maintain it. The integration > will need me to have it usable, valid and stable anyway. ;) > Honestly, there are at least three big projects at my work that suffer in > many > places from the problems ustr solves. > > Cheers > > Sven > There are no open bugs for it, so - no problem. Library development seems stalled, but new ebuild revision was out - with some fixes for test phase(thanks to Jeroen Roovers). But i can not find your e-mail in our bugzilla database. Does "Sven Eden " appear to be your profile? Anyway, please contact proxy maintainers team[1] by e-mail or IRC and tell us about your wish to maintain this lib, thanks. [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] media-sound/beets up for grabs
15.10.2013 02:38, Stanislav Ochotnicky пишет: > Any takers? Feel free to add yourself to the top of metadata.xml and ping me > on > IRC. Unless I'll find some other primary maintainer I'll move to package to > maintainer-wanted so that bugs don't accidentally end up in black hole. Little clarification - i hope you mean "move to maintainer-needed@", cause maintainer-wanted is for new packages only ;-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] official games repository
20.10.2013 18:31, hasufell пишет: > Gamerlay is not related to the games team I am sorry, but it is games team not related to gamerlay. No offense, but gamerlay guys sometims just do their job. So, MAKE it related to Games team and fix stuff, considered broken. > gamerlay which is a project that has failed. Please, do not throw such sentences without objective clarification, thanks. > I have zero interest to work on gamerlay. So, this is your personal attitude to be against of gamerlay. We have got this, thanks. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] official games repository
20.10.2013 19:22, hasufell пишет: > I am not sure if you have read my list of arguments in the first post. > Sunrise is based on that very concept. No user has direct commit > access to the reviewed repository, for good reason (not sure what you > mean with "developer-only"). > So, what's the problem about adding such reviewed repo(more specifically - a branch) to gamerlay except your personal negative attitude to whole project itself? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] official games repository
20.10.2013 20:12, hasufell пишет: > This thread is derailed and I have no further interest in discussing here. > And again, no offense, but it is not the first time when you are jumped, said, "Everything in X is wrong!" and then said "I have lost interest". It is very "mature" position to propose enhancement and then - hides, do not you think? Sorry if i am saying harsh words, just talking how it looks like from side view. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OT: user-developer/privileges in IRC
22.10.2013 07:19, Peter Stuge пишет: > I should have included bugzilla among mailing lists+IRC, users can > indeed also have elevated privileges on IRC, but never equal to > developers. It is radical exclusion and I'm reminded of it every > time the #gentoo-dev channel mode catches my eye, painfully so if > there's a discussion I could perhaps contribute to. Most of the time > it is easy enough to say something privately to a relevant developer, > but that's still very different from actual participation. > Yes, and i think that it was done for a reason. But nobody stops you from requesting temporarily voice on #gentoo-dev and when you contributions will be marked as significant - gentoo/contributor cloak, that will give you permanent voice in #gentoo-dev. You should understand that #gentoo-dev is channel for developer's communication primarily and it is not so restricted, as you think. For example, #gentoo-infra is totally restricted to developers only, other interested parties should be added to channel ACLs explicitly or should get invite there. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo Scire project - plans?
Hello, i just want to raise question: should we add deprecation on project page of Scire[1] or even remove this project entirely? Cause project seems slightly abandonded, leader(agaffney) is in progress of retiring[2], other project member(blackace) has no commit access to tree[3]. CCing all interested parties [1] - http://www.gentoo.org/proj/en/scire/ [2] - https://bugs.gentoo.org/show_bug.cgi?id=68900 [3] - https://bugs.gentoo.org/show_bug.cgi?id=45816 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
