Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 11:31 AM, Pacho Ramos wrote: > Due ramereth lack of time: > sys-block/megacli As a very unhappy owner of hardware that uses it, I'll take it. Cheers, Kacper signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On Saturday 15 June 2013 04:39:10 Vadim A. Misbakh-Soloviov wrote: > # @DESCRIPTION: > # Unpack nixstaller generated files needs a period at the end. content in @DESCRIPTION is normalized. > # They're shell scripts with the blob package tagged onto > # the end of the archive. In the blob placed tarballs with > # actual content. "They're shell scripts with a tarball appended to them." > # Please note, if you need additional dependecies make sure to unpack > subarch > # archive as first argument. no idea what this means > nixstaller_unpack() { this does not follow the API naming convention ("unpack" comes first) > local unpack_files="$@" this doesn't work. you normalized the input into a string. just inline the "$@" below. or don't specify it at all ... this does the same thing (albeit, correctly): local src for src ; do > unpack_banner "$i" > # Make sure that file exists > [[ -f "./$i" ]] && ( > local type=$(file -b ${i}) > case ${type} in > data) > tar -xJf "./$i" why doesn't the bzip2 detect as bzip2 ? > ;; > gzip*) > tar -xzf "./$i" > ;; > esac > ) || die "Failed to unpack $i" the subshell should go away -- you don't even need it: [[ $? -eq 0 ]] || die ... i wish we could merge with the file detection in unpack_makeself somehow -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] evar_push/pop helpers
here's v2 -mike --- eutils.eclass 22 May 2013 05:10:29 - 1.421 +++ eutils.eclass 17 Jun 2013 05:41:58 - @@ -146,6 +146,79 @@ estack_pop() { eval unset ${__estack_name}\[${__estack_i}\] } +# @FUNCTION: evar_push +# @USAGE: [more vars to save] +# @DESCRIPTION: +# This let's you temporarily modify a variable and then restore it (including +# set vs unset semantics). Arrays are not supported at this time. +# +# This is meant for variables where using `local` does not work (such as +# exported variables, or only temporarily changing things in a func). +# +# For example: +# @CODE +# evar_push LC_ALL +# export LC_ALL=C +# ... do some stuff that needs LC_ALL=C set ... +# evar_pop +# +# # You can also save/restore more than one var at a time +# evar_push BUTTERFLY IN THE SKY +# ... do stuff with the vars ... +# evar_pop # This restores just one var, SKY +# ... do more stuff ... +# evar_pop 3 # This pops the remaining 3 vars +# @CODE +evar_push() { + local var val + for var ; do + [[ ${!var+set} == "set" ]] \ + && val=${!var} \ + || val="${___ECLASS_ONCE_EUTILS}" + estack_push evar "${var}" "${val}" + done +} + +# @FUNCTION: evar_push_set +# @USAGE: [new value to store] +# @DESCRIPTION: +# This is a handy shortcut to save and temporarily set a variable. If a value +# is not specified, the var will be unset. +evar_push_set() { + local var=$1 + evar_push ${var} + case $# in + 1) unset ${var} ;; + # Can't use `printf -v` as that does not set $var when $2 is "". + 2) eval ${var}=\$2 ;; + *) die "${FUNCNAME}: incorrect # of args: $*" ;; + esac +} + +# @FUNCTION: evar_pop +# @USAGE: [number of vars to restore] +# @DESCRIPTION: +# Restore the variables to the state saved with the corresponding +# evar_push call. See that function for more details. +evar_pop() { + local cnt=${1:-bad} + case $# in + 0) cnt=1 ;; + 1) isdigit "${cnt}" || die "${FUNCNAME}: first arg must be a number: $*" ;; + *) die "${FUNCNAME}: only accepts one arg: $*" ;; + esac + + local var val + while (( cnt-- )) ; do + estack_pop evar val || die "${FUNCNAME}: unbalanced push" + estack_pop evar var || die "${FUNCNAME}: unbalanced push" + # Can't use `printf -v` as that does not set $var when $2 is "". + [[ ${val} == "${___ECLASS_ONCE_EUTILS}" ]] \ + && unset ${var} \ + || eval ${var}=\${val} + done +} + # @FUNCTION: eshopts_push # @USAGE: [options to `set` or `shopt`] # @DESCRIPTION: @@ -218,6 +291,18 @@ eumask_pop() { umask ${s} || die "${FUNCNAME}: sanity: could not restore umask: ${s}" } +# @FUNCTION: isdigit +# @USAGE: [more numbers] +# @DESCRIPTION: +# Return true if all arguments are numbers. +isdigit() { + local d + for d ; do + [[ ${d:-bad} == *[!0-9]* ]] && return 1 + done + return 0 +} + # @VARIABLE: EPATCH_SOURCE # @DESCRIPTION: # Default directory to search for patches. @@ -344,8 +429,11 @@ epatch() { local EPATCH_SUFFIX=$1 elif [[ -d $1 ]] ; then - # Some people like to make dirs of patches w/out suffixes (vim) + # We have to force sorting to C so that the wildcard expansion is consistent #471666. + evar_push_set LC_COLLATE C + # Some people like to make dirs of patches w/out suffixes (vim). set -- "$1"/*${EPATCH_SUFFIX:+."${EPATCH_SUFFIX}"} + evar_pop elif [[ -f ${EPATCH_SOURCE}/$1 ]] ; then # Re-use EPATCH_SOURCE as a search dir signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] evar_push/pop helpers
On Sunday 02 June 2013 03:48:17 Tom Wijsman wrote: > On Sun, 2 Jun 2013 03:29:33 -0400 Mike Frysinger wrote: > > except you aren't handling edge cases (like set vs unset) > > You've got me there, though this is quite an exception; I don't see > why we have to introduce something that's barely used... > > `qgrep -eH '^\s*\bset\b' | wc -l` > yields 150 > > `qgrep -eH '^\s*\bset\b' | sed 's/:.*//g' | sed > 's/\/[a-zA-Z0-9_.-]*$//g' | sort -u | wc -l` > yields 34 > > Only 34 packages, and do these all _really_ need a 'set'? I doubt it. i've got at least 4 consumers in mind, and that's more than enough imo to implement it right than half-ass it every time > > > Much like fixing tiny bug and trying to > > > avoid checking whether anything else is affected. > > > > yeah, because forcing specific behavior for an entire function is > > always the correct answer. it's like telling people to export > > LC_ALL=C in make.conf so they never hit locale related problems. > > Actually, bug wranglers stopped asked for English build logs because > setting LC_ALL=C ended up breaking things. i know it doesn't work which is why i was providing it as an example -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: evar_push/pop helpers
On Sunday 02 June 2013 13:38:04 Steven J. Long wrote: > On Sat, Jun 01, 2013 at 11:03:20PM -0400, Mike Frysinger wrote: > > --- eutils.eclass 22 May 2013 05:10:29 - 1.421 > > +++ eutils.eclass 2 Jun 2013 03:00:46 - > > @@ -146,6 +146,77 @@ estack_pop() { > > eval unset ${__estack_name}\[${__estack_i}\] > > } > > Just in passing, one of the places you don't want nullglob messing things > up. not sure what you mean. that escapes the [] so that bash doesn't accidentally glob things. when the code actually executes, you don't need to escape things. touch f i d x unset arr declare -A arr arr[f]=1234 arr[idx]=4321 echo "${arr[f]}" "${arr[idx]}" __estack_name=arr __estack_i=f eval unset ${__estack_name}\[${__estack_i}\] echo ${#arr[@]} __estack_i=idx eval unset ${__estack_name}\[${__estack_i}\] echo ${#arr[@]} seems to work > > +# is not specified, the var will be unset. > > +evar_push_set() { > > + local var=$1 > > + evar_push ${var} > > + case $# in > > + 1) unset ${var} ;; > > + 2) eval ${var}=\$2 ;; > > I wish you wouldn't use eval for this. I know it's technically okay here, > or would be if you verified the parameter, but bash has printf -v for this > purpose: interesting, i hadn't seen that before ... looks new to bash-3.1. /me tucks that into his tool belt. although it doesn't quite work in the edge case where the value is an empty string. consider: unset x printf -v x '' echo ${x+set} that should show "set", but it does not. i'll have to keep `eval ${var}=` when the value we're setting is empty. or just keep the eval code since i have to do eval anyways at that point. i'll report it upstream to the bash guys. > printf -v "$1" '%s' "$2" 2>/dev/null || die "unable to set: '$1' to: '$2'" > > Note you should verify the variable name, ime, irrespective of a die on the > printf (or eval in sh.) It's much better feedback to the developer using > the routine. i don't think it's worth it. if you screw up the name, it tends to be a one- time cost, and the error shown is pretty clear as to where it's coming from. > printf -v also works with array members btw, if you do decide to extend in > that direction: i don't think i will, but i probably can convert the other core stack code to use this ... > > + : ${cnt:=bad} > > + [[ -n ${cnt//[0-9]} ]] && die "${FUNCNAME}: first arg must be a > > number: $*" > > + ;; > > Though a generic is_int function comes in much handier, ime. yeah, and we have other code that wants this (a simple grep for 0-9 in eclass/ shows a bunch of hits) > > - # Some people like to make dirs of patches w/out suffixes (vim) > > + # We have to force sorting to C so that the wildcard expansion > > # is consistent #471666. > > + evar_push_set LC_COLLATE C > > + # Some people like to make dirs of patches w/out suffixes (vim). > > set -- "$1"/*${EPATCH_SUFFIX:+."${EPATCH_SUFFIX}"} > > + evar_pop > > Have to say I'd just do this in a function adding to a locally-scoped > array, if it were me, eg local args; foo "$1" "$EPATCH_SUFFIX"; set -- > "${args[@]}"; unset args > foo() { > local LC_COLLATE=C > args=("$1"/*${2:+."$2"}) > } since i plan on using these funcs in other places, using the existing api keeps things simple > though I'd prefer it if EPATCH_SUFFIX were allowed to be a list, > personally. wouldn't really make this any easier -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
It's low maintenance; only thing needed is either to rebase to my libtransform work, or add proper xz support. Either way, any questions, let me know. ~brian On Mon, Jun 17, 2013 at 1:16 AM, Sergey Popov wrote: > 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 > >
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] How to spread intltool fixes to all packages
On Tuesday 11 June 2013 05:55:14 Pacho Ramos wrote: > Because of: > https://bugs.gentoo.org/show_bug.cgi?id=432848 > > We discovered an old bug affecting intltool that causes prefix of > localedir to be always hardcoded to the same location instead of > respecting configure flags. > > The patch is fixed by intltool upstream in their master branch but still > no new version was released including it. Anyway, we now have > dev-util/intltool-0.50.2-r1 with the bug fixed. > > The problem of this issue (and most involving intltool) is that we need > to run: > intltoolize --copy --automake --force > (it doesn't seem to trigger maintainer mode in all ebuilds I have tried, > then, doesn't look to require eautoreconf to be run) > > for all packages to get new and fixed ${S}/po/Makefile.in.in copied to > the sources, otherwise bundled file is used and, then, the one unfixed. > As it's unreliable to ping all upstreams involving intltool (they are a > ton) and this kind of problem will likely re-appear again in the future > (since the Makefile.in.in will be fixed in intltool upstream tarball but > will take a lot of time to reach all affected packages) we were > considering to run above command always at eclass level -> that way we > would stop using bundled ${S}/po/Makefile.in.in and, then, we would > always use the one provided by our intltool package (that should get > fixed and updated more often). > > Other possible solution would be to use ELT-PATCHES to achieve that, but > I am still unsure about how would it work. ELT-PATCHES is only used by elibtoolize which means it requires an explicit call to patch things you're basically talking about the same type of problem that https://bugs.gentoo.org/220040 tried to address. maybe we should update autotools.eclass to have a general patching mechanism since any EAPI based one is doomed to failure. and then we rebase elibtoolize to that. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
On Sun, Jun 16, 2013 at 6:49 AM, Pacho Ramos wrote: > Due ferringb retirement the following packages are up for grabs: > ... > dev-util/diffball > I'll take it. -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 6/16/13 12:36 AM, Alexander V Vershilov wrote: > In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that > Chromium and co. it not a development library this is a end user application. > End user applications should be in tree (except for some testing reasons), if > not just ignore this letter. And thanks for your work. Nice. :) Note however that v8 and ninja (the build system) are also maintained by the project in the tree. There is also libsrtp... Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-06-16 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-06-16 23h59 UTC. Removals: kde-misc/ktouchpadenabler 2013-06-12 18:19:14 johu Additions: sys-devel/heirloom-devtools 2013-06-10 00:10:32 ryao app-text/jmupdf 2013-06-10 08:45:58 xmw dev-python/sphinxcontrib-httpdomain 2013-06-10 09:07:30 idella4 www-apache/mod_auth_xradius 2013-06-10 09:12:25 chainsaw dev-ruby/source_map 2013-06-10 12:58:36 graaff dev-ml/core_kernel 2013-06-10 13:23:17 aballier dev-ml/textutils2013-06-10 14:34:18 aballier sci-physics/geant-data 2013-06-10 16:34:20 bicatali dev-python/discogs-client 2013-06-10 18:02:46 idella4 dev-lang/ats2013-06-11 03:54:55 patrick dev-java/jama 2013-06-11 13:55:47 tomwij app-leechcraft/lc-imgaste 2013-06-11 14:25:18 maksbotan dev-tex/circuit_macros 2013-06-11 14:41:06 calchan gnome-extra/gnome-shell-extensions-topicons 2013-06-12 10:15:16 pacho dev-python/tdaemon 2013-06-12 14:06:53 idella4 dev-ruby/state_machine 2013-06-13 05:28:46 graaff dev-python/itsdangerous 2013-06-14 03:17:21 rafaelmartins sys-fs/squashfuse 2013-06-14 08:23:09 zmedico net-libs/libblkmaker2013-06-14 18:11:59 blueness dev-python/send2trash 2013-06-15 04:19:08 idella4 dev-lang/nwcc 2013-06-15 06:20:36 patrick net-firewall/sanewall 2013-06-15 11:07:43 radhermit dev-java/hamcrest-generator 2013-06-15 19:54:51 tomwij dev-python/recaptcha-client 2013-06-16 11:38:33 idella4 dev-util/reviewboard2013-06-16 16:02:06 idella4 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: kde-misc/ktouchpadenabler,removed,johu,2013-06-12 18:19:14 Added Packages: sys-devel/heirloom-devtools,added,ryao,2013-06-10 00:10:32 app-text/jmupdf,added,xmw,2013-06-10 08:45:58 dev-python/sphinxcontrib-httpdomain,added,idella4,2013-06-10 09:07:30 www-apache/mod_auth_xradius,added,chainsaw,2013-06-10 09:12:25 dev-ruby/source_map,added,graaff,2013-06-10 12:58:36 dev-ml/core_kernel,added,aballier,2013-06-10 13:23:17 dev-ml/textutils,added,aballier,2013-06-10 14:34:18 sci-physics/geant-data,added,bicatali,2013-06-10 16:34:20 dev-python/discogs-client,added,idella4,2013-06-10 18:02:46 dev-lang/ats,added,patrick,2013-06-11 03:54:55 dev-java/jama,added,tomwij,2013-06-11 13:55:47 app-leechcraft/lc-imgaste,added,maksbotan,2013-06-11 14:25:18 dev-tex/circuit_macros,added,calchan,2013-06-11 14:41:06 gnome-extra/gnome-shell-extensions-topicons,added,pacho,2013-06-12 10:15:16 dev-python/tdaemon,added,idella4,2013-06-12 14:06:53 dev-ruby/state_machine,added,graaff,2013-06-13 05:28:46 dev-python/itsdangerous,added,rafaelmartins,2013-06-14 03:17:21 sys-fs/squashfuse,added,zmedico,2013-06-14 08:23:09 net-libs/libblkmaker,added,blueness,2013-06-14 18:11:59 dev-python/send2trash,added,idella4,2013-06-15 04:19:08 dev-lang/nwcc,added,patrick,2013-06-15 06:20:36 net-firewall/sanewall,added,radhermit,2013-06-15 11:07:43 dev-java/hamcrest-generator,added,tomwij,2013-06-15 19:54:51 dev-python/recaptcha-client,added,idella4,2013-06-16 11:38:33 dev-util/reviewboard,added,idella4,2013-06-16 16:02:06 Done.
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16/06/13 04:36 PM, Andreas K. Huettel wrote: > Hi Kent, >> >> IMHO, the criteria for being able to edit the wiki should be lower than the >> present requirements on "being a Gentoo Dev". > > Only a small subset of official pages is locked, everything else is free to > edit for anyone who signs himself up. > >> >> I'd be interested in seeing if theres' a way to have "vetted" edits of some >> kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to >> edit a page as they see fit, but the changes are only visible to them until >> they mark their edits "done" where it can be pushed to a moderation queue >> for somebody trusted to check over. >> > > That exists and is used in the German Wikipedia. > (Basically, you get the last "vetted" page by default, with a small message > saying "newer versions available".) > MediaWiki has a builtin "flag" mechanism for revisions, but this serves only to try to get all revisions reviewed by at least one person. "Pending Changes" as implemented by the English Wikipedia uses Extension:FlaggedRevs [0] which, in the most common configuration, allows anyone to edit but hides their changes from the general public until an authorized user approves the changes. [1] [0] https://www.mediawiki.org/wiki/Extension:FlaggedRevs [1] https://en.wikipedia.org/wiki/Wikipedia:Pending_changes signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [2&3]/3 API & files
On 16/06/13 03:44 PM, Robin H. Johnson wrote: Image resources: > >> These can be uploaded to the Wiki. >>> > > How can we ensure later that the media files don't get deleted? >> > Deletion is restricted to administrators, mediawiki also keeps old >> > versions around in case someone reuploads a file. >> > To prevent even that, we can restrict editing certain assets to developers. > See my other comment about git-mediawiki maybe, that would satisfy my > needs, just having old versions of the images around as needed (not > admin-deletable). > With modern MediaWiki, it is impossible to permanently remove a page or file without the system administrator (I mean SSH access, not MW sysop) intentionally permitting it or deleting the file archive. https://www.mediawiki.org/wiki/Manual:Image_administration#Undeleting_files https://www.mediawiki.org/wiki/Extension:Oversight https://www.mediawiki.org/wiki/Manual:RevisionDelete signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Packages up for grabs
On Mon, 17 Jun 2013 00:07:57 +0200 Tom Wijsman wrote: > That's assuming you would go threaded, but you can also aim for lower > algorithmic complexities; the complexity makes the CPU the bottleneck. Dependency solving is NP-hard in theory and better than quadratic in practice. The resolution algorithms also aren't the problem in terms of runtime (and still won't be if we started using more sophisticated algorithms for better decision making). The problem is simply that the model is large and messy, and the problem being solved has all kinds of awful corner cases that have to be considered. (As one example, every user has somewhere between a hundred and a thousand packages installed, each of which depends directly or indirectly upon every other package in this collection.) There are certainly improvements to be made, both in terms of efficiency and correctness, but if you're looking for a big leap forward then the most useful thing we could do is reduce or eliminate some of the requirements that make dependency resolution such a fiddly (not hard) problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013 14:57:32 -0700 Zac Medico wrote: > It's actually not bad, since all of the subslot rebuilds are triggered > in a single backtracking run. Anyway, I welcome having people work on > competing package managers, trying to do all of this stuff more > efficiently. :-) I'm starting to think we're all doing this wrong by going for a naive "single choice then backtrack" model, fully consistent or otherwise. Perhaps we're going to have to bite the bullet and go for stronger propagation models and one of the many better alternatives to backtracking... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [2&3]/3 API & files
On 16.06.2013 21:44, Robin H. Johnson wrote: > […] >>> - How can we better encourage these to move to an API site? >> Not sure what you mean with that. > It needs to be really easy for any developer to throw up a new data > source w/ scripts onto the API site. > > Even qa-reports is somewhat stalled, and doesn't have good visibility, > because it's not that easy for any dev to add something new to it. > Currently, it's files in CVS, soon to be files in a Git. That's at least the same reachability as before. I think solving this problem is a separate task. >Image resources: These can be uploaded to the Wiki. >>> How can we ensure later that the media files don't get deleted? >> Deletion is restricted to administrators, mediawiki also keeps old >> versions around in case someone reuploads a file. >> To prevent even that, we can restrict editing certain assets to developers. > See my other comment about git-mediawiki maybe, that would satisfy my > needs, just having old versions of the images around as needed (not > admin-deletable). Um, got a link for that extension? I didn't clarify, the Wiki can be configured to keep a revision even if someone deletes a file. > Other files and downloads: Until proper project file hosting is implemented, again a simple git-backed static site, possibly projects.gentoo.org. >>> Please don't put lots of binary files in Git. >>> >> How do we expose that site to developers then? Akin to the mirroring >> system on d.g.o? > I need to dust off the project hosting proposal, because there are a lot > of files that need to move to it (like all the elections & PR > materials). > …or that. -- Alex Legler Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Packages up for grabs
On Sun, 16 Jun 2013 22:38:56 +0100 Ciaran McCreesh wrote: > On Sun, 16 Jun 2013 23:24:27 +0200 > Tom Wijsman wrote: > > I have one; it's great to help make my boot short, but it isn't > > really a great improvement for the Portage tree. Better I/O isn't a > > solution to computational complexity; it doesn't deal with the CPU > > bottleneck. > > If the CPU is your bottleneck, Python won't help you. Python's threads > are fine for making IO easier, but the GIL prevents them from being of > any use for CPU intensive calculations. > > Having said that, the CPU isn't your bottleneck. That's assuming you would go threaded, but you can also aim for lower algorithmic complexities; the complexity makes the CPU the bottleneck. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 11:23 AM, Tom Wijsman wrote: > Ignoring that call graph, you could look at what has recently been > introduced to increase the amount of time needed to calculate the > dependency graph; you don't have to look far. > > http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/ > > While I don't want point out the contents of that blog post, the title > is relevant; implementing features like subslots on an algorithm that > was not written with subslots in mind introduces a lot of inefficiency. It's actually not bad, since all of the subslot rebuilds are triggered in a single backtracking run. Anyway, I welcome having people work on competing package managers, trying to do all of this stuff more efficiently. :-) > And it's not just subslots, newer features keep getting added to the > dependency graph calculation and it gets slower and slower over time. > It feels like revdep-rebuild moved into the dependency calculation! I guess the main things that make it slower than it has been historically would be things like --autounmask, --backtrack, --complete-graph-if-new-use and --complete-graph-if-new-ver. Note that you can use EMERGE_DEFAULT_OPTS to disable these things if you would prefer to live without them. You might use something like --backtrack=2 if you want it to bail out early for all but the simplest backtracking cases. Use --ignore-built-slot-operator-deps=y if you want to disable all rebuilds involving subslots and slot-operators. -- Thanks, Zac
Re: [gentoo-dev] Re: Packages up for grabs
On Sun, 16 Jun 2013 23:24:27 +0200 Tom Wijsman wrote: > I have one; it's great to help make my boot short, but it isn't really > a great improvement for the Portage tree. Better I/O isn't a solution > to computational complexity; it doesn't deal with the CPU bottleneck. If the CPU is your bottleneck, Python won't help you. Python's threads are fine for making IO easier, but the GIL prevents them from being of any use for CPU intensive calculations. Having said that, the CPU isn't your bottleneck. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Packages up for grabs
On Sun, 16 Jun 2013 19:33:53 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > TL;DR: SSDs help. =:^) TL;DR: SSDs help, but they don't solve the underlying problem. =:-( I have one; it's great to help make my boot short, but it isn't really a great improvement for the Portage tree. Better I/O isn't a solution to computational complexity; it doesn't deal with the CPU bottleneck. Sadly, an improvement to the CPU as good as the switch from HDD to SSD, I'm yet to see such a hardware improvement. Maybe if we stack the transistors into the third dimension, something Intel was working on. > Quite apart from the theory and question of making the existing code > faster vs. a new from-scratch implementation, there's the practical > question of what options one can actually use to deal with the > problem /now/. Don't rush it: Do you know the problem well? Does the solution properly deal with it? Is it still usable some months / years from now? > FWIW, one solution (particularly for folks who don't claim to have > reasonable coding skills and thus have limited options in that > regard) is to throw hardware at the problem. Improvements in algorithmic complexity (exponential) are much bigger than improvements you can achieve by buying new hardware (linear). > I recently upgraded my main system to SDD. ... SNIP ... Between that > and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy > with portage's current performance, ... SNIP ... Ironically, you don't even fully use the CPU, but only one core of it; I'm glad you have a 6-core processor, but to Portage it is a 1-core during dependency tree calculation. Portage becomes slower at a faster rate than your hardware get faster; this will continue to be that way until you make Portage benefit of it, or failing that you would need to come up with an alternative PM. I didn't get my short boot from upgrading hardware alone; quite the opposite, it was rather the results of the efforts spent on it. > --- > [1] I'm running ntp and the initial ntp-client connection and time > sync takes ~12 seconds a lot of the time, just over the initial 10 > seconds down, 50 to go, trigger on openrc's 1-minute timeout. Why do you make your boot wait for NTP to sync its time? How could hardware make this time sync go any faster? > [2] ... SNIP ... runs ~1 hour ... SNIP ... Sounds great, but the same thing could run in much less time. I have worse hardware, and it doesn't take much longer than yours do; so, I don't really see the benefits new hardware bring to the table. And that HDD to SSD change, that's really a once in a lifetime flood. > [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs. Sounds all cool, but think about your CPU again; saturate it... Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a huge difference; most people follow the latter instructions, without really thinking through what actually happens with the underlying data. The former queues up jobs for your processor; so the moment a job is done a new job will be ready, so, you don't need to wait on the disk. Something completely different; look at the history of data mining, today's algorithms are much much faster than those of years ago. Just to point out that different implementations and configurations have much more power in cutting time than the typical hardware change does. Though, this was pretty much OT; we're talking about the dependency tree calculation, not about emerging which is rather a result of building (eg. your compiler) than it has anything to do with the package manager. PS: A take home thought: What if the hardware designers decided to not R&D storage, then we wouldn't have a SSD; same story, different level. Another level higher; we have physics, maybe CERN can improve hardware? But when will that happen? Can we rely and wait on that to happen? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Gentoo: growing pains & the future.
(Please reply on the gentoo-project list, I have set the Reply-To header for this mail appropriately). === TL;DR: - Does GLEP39 still serve all the needs of Gentoo? Devrel useful? - How to improve ourselves as a distribution (technical) and as people (personal interactions)? - Would EVERY developer please start acting professionally in all fora? === I would like us to thank (and remember those no longer with us) all of the past trustees and council members (a near-complete list is included as footnote [9]), for what they have done to try and grow the distribution. Regardless of whoever who decides to run for council and trustees this year, I would like to ask developers and foundation members to look at the history of Gentoo, prior councils and prior trustees, and ask themselves: What value does the distribution, Council, and Trustees provide to you? Why they are voting for any given candidate; is this the best for the future of Gentoo, or does it really even matter? Of candidates: Is it because of their technical prowess; ability to reach compromises; they can manage people well; possibly because you simply like or respect them; or because they're a hothead and you want to shake things up? Regardless of why you pick them, all of the above are things they may have to do on the council and trustees. I have contributed just over a decade of my life to Gentoo at this point, many times choosing consulting work or jobs because they enabled me to contribute more. I'm one of the very few developers that has been both a council member and a trustee, the others are: dberkholz, seemant, swift, agriffis, azarah, wolf31o2 In 2006, I ran for council, on a platform of improving the security of the Portage tree, via my tree-signing GLEPs. http://thread.gmane.org/gmane.linux.gentoo.devel/39928/focus=40610 I would call that project a long-term failure; the standards were completed, but like many GLEPs, mostly become forgotten and left by the wayside. In that original goal, I would consider my term on the council to be a failure, but extremely enlightening as to the politics and human aspect of a technical organization. I left at the end of my term, not seeking re-election. In 2009, I ran for trustees on a platform of radical transparency, that manifesto is also still available http://dev.gentoo.org/~robbat2/robbat2-foundation2009-manifesto.txt My goals were somewhat less quantifiable at the time, but I feel that I did help bring trustees to the same well-documented level as council; our financial & legal affairs are in good shape (many thanks to quantumsummers), and well-visible to the member base (yes, I would like a return to visible quarterly accounting or more detailed granularity, but we don't have that many transactions). I ran again successfully in 2011, because I wasn't done my work yet. I choose to not nominate anybody for either body this time; not because I have no faith in my fellow developers, but because I think we as a distribution have needs beyond our present structure of Council and Trustees, *Rel and the projects. Many of our early organizational issues have been replaced with those of a more mature organization. I think to a degree, we have grown beyond GLEP39. Go ahead, read GLEP39 again, and think about it from the perspective of a new(er) developer, vs. The Old Ones (as I saw it put recently). Now go to the projects that you're in, and tell me, when was the last time you had a real discussion about who lead a given project (the GLEP was careful to say 'selection' rather than 'election'). Does who "leads" a project actually matter in all cases? If a more established dev refuses a change, what can you do? The council, originally founded as technical body in 2005, has been running for 8 years, and in that time GLEP submissions have been replaced by EAPI changes to a minor degree, but overall we are no longer adapting to change as we once were. GLEP submissions have dropped dramatically, and instead we have a lot less highly visible change (unless it breaks things). Does this mean I expect everything to be a GLEP? No, the GLEP process in itself can be a hindrance to getting what you want done, and regardless of how great an idea it is, it doesn't guarantee adoption. Should we scrap GLEPs entirely? No, we should push even more of our changes through them, because they are a lot less personal than other proposals on the mailing lists. They are TECHNICAL improvements, and need to be considered PROFESSIONALLY, without any personal malice. Put the GLEPs to the council if they need more consensus, and the council needs to consider/approve them more often. If it's just smaller technical changes, let any developer feel free to do it; and take responsibility for their actions if they cause any breakage. Herds were created to group related ebuilds together (not developers), nor to stop development. Many times in our history, we have tried to grapple with the human problems in our distribution,
Re: [gentoo-dev] Packages up for grabs
On 2013-06-16 06:55, Brian Dolbec wrote: > > > Due ferringb retirement the following packages are up for grabs: > > > dev-python/snakeoil > > > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained > > > and neither has eapi5 support) > I'll take pkgcore (if somehow we can get eapi 5 finished.) > I'll take snakeoil. I'm adding some of it's libs into catalyst I can help with pkgcore, pkgcore-checks, and snakeoil as well. I've got most of the EAPI 5 resolver work done in a local fork and have been fixing other bugs I've found along the way. Tim
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
Hi Kent, > > IMHO, the criteria for being able to edit the wiki should be lower than the > present requirements on "being a Gentoo Dev". Only a small subset of official pages is locked, everything else is free to edit for anyone who signs himself up. > > I'd be interested in seeing if theres' a way to have "vetted" edits of some > kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to > edit a page as they see fit, but the changes are only visible to them until > they mark their edits "done" where it can be pushed to a moderation queue > for somebody trusted to check over. > That exists and is used in the German Wikipedia. (Basically, you get the last "vetted" page by default, with a small message saying "newer versions available".) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16 June 2013 16:01, "Paweł Hajdan, Jr." wrote: > On 6/9/13 7:22 AM, Alex Legler wrote: > > I'd appreciate some input on below plan to move project pages to the > Wiki: > > Alex, thanks for working on this! Some feedback: > > 1. How will the project pages be protected against "unwanted" edits? I > think it's valuable to have some official pages where you know only > Gentoo devs can edit them. > > 2. How will the staffing needs page be updated after dropping gorg? > > 3. How secure is the wiki? Do we have regular backups and security > updates procedures in place? I know you're member of the security team > and infra team is doing its job well, but I just wanted to check. > Dynamic web applications arguably have bigger attack surface than > effectively a bunch of static files only editable after you gain server > access. > > Paweł > > > IMHO, the criteria for being able to edit the wiki should be lower than the present requirements on "being a Gentoo Dev". There should still be some degree of vetting, but the risk a person poses being able to make doc updates is significantly less than the risk a person poses by throwing them a CVS bit. I'd be interested in seeing if theres' a way to have "vetted" edits of some kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to edit a page as they see fit, but the changes are only visible to them until they mark their edits "done" where it can be pushed to a moderation queue for somebody trusted to check over. Because otherwise, I feel you're missing out on the benefits of wiki. A game I play, tribalwars.com, has a wiki, but the purpose of having a wiki is incredibly redundant, because most the documentation there is grossly out of date, and the tribalwars staff (the only people who can edit it) don't edit anything themselves much, and as a result, there are huge chunks of the wiki that are blatantly wrong, and I would edit them if I could, and there is no good reason to suggest my edits would be likely "malevolent" in fixing this, but alas, due to fear of abuse to security, the wiki hugely misses its intended audience and is practically useless, and the rigmarole that is required for any casual user correcting finding a minor flaw is so great, it simply never occurs.
Re: [gentoo-dev] [2&3]/3 API & files
On Sun, Jun 16, 2013 at 02:08:00PM +0200, Alex Legler wrote: > On 16.06.2013 03:21, Robin H. Johnson wrote: > >> Special pages and contents > >> -- > >> herds.xml, repositories.xml, etc.: > >> As these are intended for other applications to use, these should go to > >> a new site, possibly api.gentoo.org, initially fed from a git repository. > >> This site should get backed by SSL. > > Here's a partial list of the ones I know about: > > http://www.gentoo.org/proj/en/overlays/repositories.xml > > http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml > > http://www.gentoo.org/main/en/mirrors3.xml > > Both of these are broken I think: > > http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml > > http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml > > > > - Do you know of more? > > http://www.gentoo.org/proj/en/metastructure/herds/herds.xml > > > - How can we better encourage these to move to an API site? > Not sure what you mean with that. It needs to be really easy for any developer to throw up a new data source w/ scripts onto the API site. Even qa-reports is somewhat stalled, and doesn't have good visibility, because it's not that easy for any dev to add something new to it. > >> Image resources: > >> These can be uploaded to the Wiki. > > How can we ensure later that the media files don't get deleted? > Deletion is restricted to administrators, mediawiki also keeps old > versions around in case someone reuploads a file. > To prevent even that, we can restrict editing certain assets to developers. See my other comment about git-mediawiki maybe, that would satisfy my needs, just having old versions of the images around as needed (not admin-deletable). > >> Other files and downloads: > >> Until proper project file hosting is implemented, again a simple > >> git-backed static site, possibly projects.gentoo.org. > > Please don't put lots of binary files in Git. > > > How do we expose that site to developers then? Akin to the mirroring > system on d.g.o? I need to dust off the project hosting proposal, because there are a lot of files that need to move to it (like all the elections & PR materials). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013 20:23:24 +0200 Tom Wijsman wrote: > Is it possible to reasonable enhance the Portage code to improve dep > calculations in a reasonable amount of time? Before you start looking at speed, you should make it do full, correct dependency enforcing. Get it right first, and fast later. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Packages up for grabs
Am Sonntag, 16. Juni 2013, 21:33:53 schrieb Duncan: > Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted: > > On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos wrote: > >> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: > >> [...] > >> > >> > Thank you for considering helping. I have stayed away form the > >> > intricate details of package management in the past, but I also do > >> > not like how long portage is taking now for dep calculations. > >> > >> And, cannot that efforts be put in enhancing portage instead? > > > > To make you see the problems and decisions, I'm going to elaborate a > > little and would like you to ask yourself some questions. > > > > Is it possible to reasonable enhance the Portage code to improve dep > > calculations in a reasonable amount of time? > > TL;DR: SSDs help. =:^) > Some more RAM too. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On Sun, Jun 16, 2013 at 12:53:16PM +0200, Alex Legler wrote: > > 2. How will the staffing needs page be updated after dropping gorg? > You create a subpage for each staffing need, filling in information > using a form. Semantic magic aggregates these, and you'll get a template > to include for your project page to list the ones for your project > specifically. This should probably also feed back to the qa-reports site. > > 3. How secure is the wiki? Do we have regular backups and security > > updates procedures in place? I know you're member of the security team > > and infra team is doing its job well, but I just wanted to check. > > Dynamic web applications arguably have bigger attack surface than > > effectively a bunch of static files only editable after you gain server > > access. > It's part of the usual infra backup, and I follow upstream release > announcements and update accordingly. A somewhat crazy idea, but could the git-mediawiki extension be used to create a downloadable archive of every revision as well? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: Packages up for grabs
Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted: > On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos wrote: > >> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: >> [...] >> > Thank you for considering helping. I have stayed away form the >> > intricate details of package management in the past, but I also do >> > not like how long portage is taking now for dep calculations. >> >> And, cannot that efforts be put in enhancing portage instead? > > To make you see the problems and decisions, I'm going to elaborate a > little and would like you to ask yourself some questions. > > Is it possible to reasonable enhance the Portage code to improve dep > calculations in a reasonable amount of time? TL;DR: SSDs help. =:^) Quite apart from the theory and question of making the existing code faster vs. a new from-scratch implementation, there's the practical question of what options one can actually use to deal with the problem /now/. FWIW, one solution (particularly for folks who don't claim to have reasonable coding skills and thus have limited options in that regard) is to throw hardware at the problem. I recently upgraded my main system to SDD. As it happens, my primary boot didn't speed up much[1], but having both the main system partition (bindirs/libdirs/etc) and the portage tree and overlays on SSD *DRAMATICALLY* improved portage's update-ask-deep-newuse-@world dependency resolution time, both for the cold-tree-cache case, and, surprisingly, even (apparently, I've not timed it but I was sometimes annoyed by the time before especially for hot-cache case, and it hasn't bothered me at all since the upgrade) for the hot-cache case. Between that and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy with portage's current performance, even doing routine rebuilds of the perhaps half of kde I have installed, plus some other packages with @live-rebuild.[2] The SSD doesn't have to be particularly big, either, but fast (if you're running SATA3 to use it) is nice. I figured ~64 gig usage here, tho I wanted some overprovisioning, so thought I'd do 128 gig or so. I ended up with 256 gig, only ~60% partitioned (130-some gig) even with duplicate backup partitions for everything. System, tree, /home, etc, on SSD, but still doing spinning rust for my media partitions and third-copy (second backup) partitions, on demonstrated reliable here reiserfs, while the SSD is all still-development-so-keep-your-backups-updated btrfs. --- [1] I'm running ntp and the initial ntp-client connection and time sync takes ~12 seconds a lot of the time, just over the initial 10 seconds down, 50 to go, trigger on openrc's 1-minute timeout. [2] 131 packages in @live-rebuild, with kde-live-branch, currently 4.10.49., being low 120-some, plus choice bits of of X/mesa/drivers and a few other packages including openrc, btrfs-progs and pan. The @live-rebuild typically takes ~20 minutes with ccache, a good portion of which is kdelibs, so the whole update including the sync and change/git- logs check for interesting stuff, @world update, @live-rebuild, etc- update and revdep-rebuild/depclean, runs ~1 hour, often less, sometimes more if there's a new mozilla-overlay firefox build or something in addition to the kde-libs long-build update. [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013 19:27:12 +0200 hasufell wrote: > On 06/16/2013 07:21 PM, Pacho Ramos wrote: > > El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: > > [...] > >> Thank you for considering helping. I have stayed away form the > >> intricate details of package management in the past, but I also do > >> not like how long portage is taking now for dep calculations. > > > > And, cannot that efforts be put in enhancing portage instead? > > > > How many forks do we got now? How much longer are we going to hold on to something that suffers from feature creep and is based on a design invented years ago that doesn't take into account the new features (eg. subslots) that are added today? See my reply to Pacho for more insight why we can't enhance Portage. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos wrote: > El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: > [...] > > Thank you for considering helping. I have stayed away form the > > intricate details of package management in the past, but I also do > > not like how long portage is taking now for dep calculations. > > And, cannot that efforts be put in enhancing portage instead? To make you see the problems and decisions, I'm going to elaborate a little and would like you to ask yourself some questions. Is it possible to reasonable enhance the Portage code to improve dep calculations in a reasonable amount of time? Let's take a call graph, demonstrating the amount of calls on the arrows and the amount of ticks spend in the call in the boxes: http://i.imgur.com/A93CdNR.png Which part do you think is problematic? What can we do to get an improvement in time that you can actually benefit from? Which improvements are reasonable to implement? ...? Ignoring that call graph, you could look at what has recently been introduced to increase the amount of time needed to calculate the dependency graph; you don't have to look far. http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/ While I don't want point out the contents of that blog post, the title is relevant; implementing features like subslots on an algorithm that was not written with subslots in mind introduces a lot of inefficiency. And it's not just subslots, newer features keep getting added to the dependency graph calculation and it gets slower and slower over time. It feels like revdep-rebuild moved into the dependency calculation! A combination of these two above arguments ("where do we start?" and "why try to fix something broken by design?") makes me feel that there is need for a huge refactoring; ask yourself another question, what if these systems were written from scratch with subslots in mind? Exactly, if you write a system with the features in mind you can write it much more efficient and don't have to deal with historical decisions that you have made in the past; you can continue writing without having to change half of your code, because you though about it in advance. But well, this is true in the start; some EAPIs later, history repeats! So, when we acknowledge that it is useless to waste effort on fixes that are unlikely to have a huge benefit or rewriting something that might as well get replaced some years later; we should instead look for better opportunities to do, there are multiple options: 1) Spend an awful lot of time refactoring our well known Portage; this doesn't only involve moving code around, but also nuking legacy code you can't deal with (see my earlier response) as well as writing new code where it is needed. It may sound easy, it isn't. 2) Write a system from scratch that is certain to be future proof; it is designed with the current and future specifications in mind, not based on specifications that were awesome some time in the past. 3) Spend time on learning how pkgcore is implemented, then improve it; pkgcore can be somewhat seen as a a mix from (1) and (2). Then, which option would you pick? I'm not saying Portage or the team behind it is bad; it is just a bit at the end of its time, I'm afraid of what the future will do to it. For option (1), I've thinked slightly further than to just generate the dependency graph, there are two things that came to mind that might be interesting _if_ we can get it to somehow work: A) Multiple threads I think the way trees work (branches), threads are a huge benefit. Maybe zmedico can elaborate on this again, but there were some problems that make it not easy to introduce these threads; there was something regarding a global interpreter lock, but I can't recall the details and am not that acquainted with Python. Besides that, the threads will have to be organized; so properly designing the threads, locks and inter-thread interactions might be an interesting task that could require some effort. B) Additional caching Some of the parts of the dependency graph calculation could benefit from a bit of caching; implementing caching right might be a tricky thing, too small cache is useless and too large cache is overhead. Let me take one example part; resolving the USE flags to consider which packages are dependencies, this happens again and again. For example, let's say you have >=dev-libs/glib-2.33:2 gnome-keyring? ( >=app-crypt/libsecret-0.5 ) introspection? ( >=dev-libs/gobject-introspection-1 ) then Portage has to go and turn that into maybe something like >=dev-libs/glib-2.33:2 because the user has neither USE flag set; and it is not only the USE flags the user has set, but also the USE flag in profiles, the default USE flags, the REQUIRED_USE and sometimes even other USE flags like "use1
Re: [gentoo-dev] Packages up for grabs
On Sun, 2013-06-16 at 19:21 +0200, Pacho Ramos wrote: > El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: > [...] > > Thank you for considering helping. I have stayed away form the > > intricate details of package management in the past, but I also do not > > like how long portage is taking now for dep calculations. > > And, cannot that efforts be put in enhancing portage instead? > > > Many of the speed improvements currently in portage CAME from Brian's work in pkgcore. But there comes a time when you can do only so much with the framework that portage is based upon. Pkgcore's base framework is done differently and more efficiently, which is a good deal of why it is so much faster than portage. It has been long past due for gentoo to switch to the newer, better base framework that is pkgcore and enhance it. But, as you can see in gentoo's package management history for portage and pkgcore, development tends to be a lonely endeavour, with the brunt of it lying solely on one developer. That has currently been the case for portage for the past many years as well. Others have chipped in, including myself, but it is Zac that is doing most of it. Too many others have started a PM in c, c++, to replace portage, with only paludis having come into usable existence.
Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 07:21 PM, Pacho Ramos wrote: > El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: > [...] >> Thank you for considering helping. I have stayed away form the >> intricate details of package management in the past, but I also do not >> like how long portage is taking now for dep calculations. > > And, cannot that efforts be put in enhancing portage instead? > > > How many forks do we got now? And I know of at least another gentoo dev who is working on his own.
Re: [gentoo-dev] Packages up for grabs
El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió: [...] > Thank you for considering helping. I have stayed away form the > intricate details of package management in the past, but I also do not > like how long portage is taking now for dep calculations. And, cannot that efforts be put in enhancing portage instead?
Re: [gentoo-dev] Packages up for grabs
On Sun, 2013-06-16 at 16:44 +0200, Tom Wijsman wrote: > On Sun, 16 Jun 2013 06:55:23 -0700 > Brian Dolbec wrote: > > > I'll take pkgcore (if somehow we can get eapi 5 finished.) > > Here's the catch: it's not only about finishing EAPI 5, but also about > implementing the upcoming EAPI 6 changes and fixing any bugs that arise. > > For it to be feasible to use it would need an upstream maintainer > for that package; it goes a little further than "let's implement X or > fix Y", the code has to be understood to gain the necessary insight. > > If one just hacks in things to make it work, he'll waste efforts. > Think before anyone plans to pick this up, it is quite a commitment. > > http://c2.com/cgi/wiki?LegacyCode > > http://www.amazon.com/books/dp/0131177052 > > I sincerely have interest in working on a heavily refactored PM or a PM > from scratch; but, I can't see myself pick up a big Python project as > I'm not really used to anything beyond average Python scripts. Or maybe > I'm afraid of nothing, I can't tell in advance not knowing its code. > > I'll take it into consideration though; there is quite a huge choice > between applying software re-engineering practices (mostly reverse > engineering) to pkgcore, applying those practices (mostly refactoring) > to Portage or implementing an all new PM from scratch. > Thank you for considering helping. I have stayed away form the intricate details of package management in the past, but I also do not like how long portage is taking now for dep calculations. So, I am going to look into what it needs to be completed. I know there are others out there that would also like to see pkgcore keep going. If we (that means I want help, so please speak up) can get EAPI 5 finished. Then EAPI 6 will be that much easier when the time comes, which is hopefully not too soon. For the record, I have admin capability to pkgcore's repo, so if we can get things ironed out. It will be possible to push the changes to the main repo and release it. But, I also admit that pkgcore may have to move to an overlay to get it up to speed with current required functionality.
Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 08:27 AM, Pacho Ramos wrote: El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió: On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped: Due ramereth lack of time: net-misc/stunnel Pretty sure my (dead, eventually to be revived) server uses stunnel. I've never officially maintained anything, is there some documentation somewhere as to what exactly I'm agreeing to, if I take on proxy maintainer-ship? Also, of how proxy maintainer-ship actually works? I.e.: would I need some particular person to agree to be my commit-bitch or can I just sign off on patches, somehow, and expect a pool of commit-bitches to magically push commits for me? -gmt I think you will need to simply contact proxy-maint people (CCing them) http://www.gentoo.org/proj/en/qa/proxy-maintainers/ arg sorry! I already took this, cleaned it up and bumped it to 4.56 for an outstanding security issue, bug #460278. gmt, I'd be happy to work with you in the future. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] vmware herd is empty
Am Sonntag, 16. Juni 2013, 14:20:38 schrieb Pacho Ramos: > Will drop it in two weeks if nobody joins > > Thanks I've added myself to the vmware herd for now. However, I don't have much time and only really care about vmware-workstation, so additional help is more than welcome. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013 06:55:23 -0700 Brian Dolbec wrote: > I'll take pkgcore (if somehow we can get eapi 5 finished.) Here's the catch: it's not only about finishing EAPI 5, but also about implementing the upcoming EAPI 6 changes and fixing any bugs that arise. For it to be feasible to use it would need an upstream maintainer for that package; it goes a little further than "let's implement X or fix Y", the code has to be understood to gain the necessary insight. If one just hacks in things to make it work, he'll waste efforts. Think before anyone plans to pick this up, it is quite a commitment. http://c2.com/cgi/wiki?LegacyCode http://www.amazon.com/books/dp/0131177052 I sincerely have interest in working on a heavily refactored PM or a PM from scratch; but, I can't see myself pick up a big Python project as I'm not really used to anything beyond average Python scripts. Or maybe I'm afraid of nothing, I can't tell in advance not knowing its code. I'll take it into consideration though; there is quite a huge choice between applying software re-engineering practices (mostly reverse engineering) to pkgcore, applying those practices (mostly refactoring) to Portage or implementing an all new PM from scratch. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutec
El dom, 16-06-2013 a las 14:09 +, Duncan escribió: > Pacho Ramos posted on Sun, 16 Jun 2013 15:19:26 +0200 as excerpted: > > > El dom, 16-06-2013 a las 12:42 +, Duncan escribió: > >> Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted: > >> > >> [Snipped as my comment refers to the subject] > >> > >> Could you split-up announcements like this into multiple announcements, > >> so the subject lines remain a reasonable length, please? > > > > I am not sure it deserves the effort, or do you have any idea about how > > to send all this in splitted mails easily (currently, I need to simply > > add all the mask entry and copy it to the mail body) :/ > > If it's a (semi-)manual process as the "simply add all" seems to imply, > you could just do it in smaller chunks, say no more than number, simply eyeballing it's fine> a half-dozen packages at a time, so > the subject length stays reasonable. Or as I said if the packages are > all related, don't worry about the length as it'd then be reasonably easy > to glance at and say "oh, that's nothing I care about anyway" or "that > interests me I better look closer". It's a manual process, then, will try to divide them. Currently, length depends on how many opened bugs are pending each time I review the queue ;)
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 08:24 PM, Zac Medico wrote: > On 06/15/2013 06:05 AM, Michał Górny wrote: >> Dnia 2013-06-15, o godz. 15:56:53 >> "Vadim A. Misbakh-Soloviov" napisał(a): >> >>> And, moreover, I guess, SRC_URI can even be used for VCS: >>> >>> SRC_URI=" >>> git+ssh://github.com/lol/moo.git >>> hg+ssh://bitbucket.org/lol/moo >>> svn+ssh://assembla.com/lol/moo >>> " >> >> It simply can't work. Don't even try to implement, it's waste of time. >> Just grep the tree, see how various packages use VCS-es. There's too >> many differences, too many needs and -- most importantly -- VCS-es >> change over time much more quickly than, say, unpackers. >> >> Even *if* we get a SRC_URI VCS support that works for all consumers, >> and that'd be awfully hard to do properly, it will eventually stop >> being 'good enough' and require further changes. It will just become >> never-ending story for a minor benefit. > > How about it we add a src_fetch phase, so that the VCS intricacies can > be delegated to ebuilds/eclasses (like they are now, but without having > to abuse src_unpack). If we include a way for src_fetch to communicate > changes in VCS revisions to the package manager, then we'll be able to > integrate functionality like smart-live-rebuild directly into the > package manager (as discussed in bug 182028 [1]). > > [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 +1 on src_fetch in or out of the context of this thread. +1 on more granular fetch/mirror restrictions +-0 on VCS in SRC_URI, as I already stated I'm fine with the current functionality (aside from a vast desire for src_fetch phase). - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG 6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1 NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n 1PD6mk8hNr9C3aV14QzM =7DTn -END PGP SIGNATURE-
[gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutecom,
Pacho Ramos posted on Sun, 16 Jun 2013 15:19:26 +0200 as excerpted: > El dom, 16-06-2013 a las 12:42 +, Duncan escribió: >> Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted: >> >> [Snipped as my comment refers to the subject] >> >> Could you split-up announcements like this into multiple announcements, >> so the subject lines remain a reasonable length, please? > > I am not sure it deserves the effort, or do you have any idea about how > to send all this in splitted mails easily (currently, I need to simply > add all the mask entry and copy it to the mail body) :/ If it's a (semi-)manual process as the "simply add all" seems to imply, you could just do it in smaller chunks, say no more than a half-dozen packages at a time, so the subject length stays reasonable. Or as I said if the packages are all related, don't worry about the length as it'd then be reasonably easy to glance at and say "oh, that's nothing I care about anyway" or "that interests me I better look closer". If it's an automated script, that could be more difficult, but at the same time, I'd /guess/ that if there's a script doing most of it already, adding logic to split by category and fire off one for each if there's more than a half-dozen individual packages to deal with at once, shouldn't be but an incremental add. Using this one as an example, by my count there's 20 packages listed, which would split into ~3-4 separate announcements using the eyeballed half-dozen method, or ~7 announcements using a crude group by first category-segment (rox-*(2), sys-*(2), media*(1), dev-*(4), gnome-*(2), net-*(5), app-*(3) ) automated method. Using an incrementally more advanced "combine groups until you hit a half-dozen max" method, rox/sys/ media would combine for one announcement, dev/gnome combine, net by itself, app by itself, four separate announcements total. If nobody else finds the long subjects worth worrying about, maybe it's just me and don't worry about it. But I'd think it'd be easier to follow threads just from an "I'll take this one" reply context as well, as even just that gets confusing to follow when there's 20 unrelated packages in the same thread, such that a dev interested in just one now has to look at all the replies to see if there's an "I'll take this" on his target package already, instead of just scanning subjects and seeing there isn't a reply yet to the thread naming the single package he's interested in. But maybe it /is/ just me... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Packages up for grabs
On Sun, 2013-06-16 at 14:48 +0200, Dirkjan Ochtman wrote: > On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos wrote: > > Due ferringb retirement the following packages are up for grabs: > > dev-python/snakeoil > > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained > > and neither has eapi5 support) > > Looks like these should go together, with pkgcore-checks (currently > maintained by python, but I'm not sure that makes sense). There's also > app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~ > on woodpecker. > > Cheers, > > Dirkjan > I'll take pkgcore (if somehow we can get eapi 5 finished.) I'll take snakeoil. I'm adding some of it's libs into catalyst maintainer-helper also did not work for my testing. I needed to patch it just to get it to start.
[gentoo-dev] Re: [RFC] SRC_URI behaviour
On 16/06/2013 10:24, Zac Medico wrote: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 This sounds interesting. It definitely would be nice to have proper package manager support for VCS. I don't think that this will somehow "legitimise" live ebuilds. We use policies to prevent inappropriate things from entering the tree, not by preventing tools that might facilitate it. Best regards, Michael
[gentoo-dev] Re: Packages up for grabs
On 16/06/2013 23:02, g...@malth.us wrote: There'd be no problem resurrecting it from the grave, if need be, would there? Please note that being unmaintained does not mean the package will be removed. That would only happen if there are long term unresolved issues with the package. Best regards, Michael
Re: [gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutec
El dom, 16-06-2013 a las 12:42 +, Duncan escribió: > Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted: > > [Snipped as my comment refers to the subject] > > Could you split-up announcements like this into multiple announcements, > so the subject lines remain a reasonable length, please? I am not sure it deserves the effort, or do you have any idea about how to send all this in splitted mails easily (currently, I need to simply add all the mask entry and copy it to the mail body) :/
RE: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013, at 05:27, Pacho Ramos thusly quipped: > El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió: >> On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped: >>> Due ramereth lack of time: >>> net-misc/stunnel >> >> Pretty sure my (dead, eventually to be revived) server uses stunnel. I've >> never > officially maintained anything, is there some documentation somewhere as to > what exactly I'm agreeing to, if I take on proxy maintainer-ship? Also, of > how > proxy maintainer-ship actually works? I.e.: would I need some particular > person > to agree to be my commit-bitch or can I just sign off on patches, somehow, and > expect a pool of commit-bitches to magically push commits for me? >> >> -gmt >> > > I think you will need to simply contact proxy-maint people (CCing them) > http://www.gentoo.org/proj/en/qa/proxy-maintainers/ Maybe I shouldn't do this just yet. I need to figure out whether the box in question gets its stunnel from gentoo or some other distribution (it has a severe multiple personality disorder). If I take on maintainer-ship and it turns out I don't actually use the ebuild in-house, dereliction of duty on my part is almost an inevitability. On the other hand, if I am relying on the ebuild, I'll almost certainly want to proxy-maintain, once I get my hardware issues sorted out. There'd be no problem resurrecting it from the grave, if need be, would there? -gmt
Re: [gentoo-dev] Calling die in a subshell
> On Sat, 15 Jun 2013, Ulrich Mueller wrote: >>> PMS doesn't guarantee that die works correctly in a subshell: >>> http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3 >>> >>> So the devmanual agrees with the spec, and the eclasses need to be >>> fixed. >> How does that make any sense? > It makes perfect sense. The specification doesn't require that the > package manager's die function works in a subshell, so ebuilds and > eclasses cannot rely on such behaviour. It turns out that killing the main process (as both Portage and Paludis do) isn't sufficient in all cases, thanks to Ciaran for pointing this out. It will already fail for something simple like: foo | ( bar || die ) See bug 465008 comment #2 and following. > If you want a different behaviour for future EAPIs, then PMS > needs to be changed. Ulrich
Re: [gentoo-dev] Packages up for grabs
On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos wrote: > Due ferringb retirement the following packages are up for grabs: > dev-python/snakeoil > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained > and neither has eapi5 support) Looks like these should go together, with pkgcore-checks (currently maintained by python, but I'm not sure that makes sense). There's also app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~ on woodpecker. Cheers, Dirkjan
[gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutecom,
Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted: [Snipped as my comment refers to the subject] Could you split-up announcements like this into multiple announcements, so the subject lines remain a reasonable length, please? Particularly when there's lots of unrelated packages. If they're all in the same pkg-category or are otherwise obviously related, it's not so bad. But here we have rox packages, firmware, cluster, media, office, gnome, dev-sharp... all combined in the same very long subject that's well beyond any reasonable single-line subject length, making it very easy to miss something critical for the very people who are otherwise targeted, those who could be interested in maintaining those packages, as well as any remaining users who might like an early heads-up before they find their @world update broken due to now-masked packages that they'd have otherwise caught in the last-rites announcement. That request made, thanks for helping to de-cruft the tree. I'm glad someone's putting in the effort. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Packages up for grabs
El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió: > On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped: > > Due ramereth lack of time: > > net-misc/stunnel > > Pretty sure my (dead, eventually to be revived) server uses stunnel. I've > never officially maintained anything, is there some documentation somewhere > as to what exactly I'm agreeing to, if I take on proxy maintainer-ship? > Also, of how proxy maintainer-ship actually works? I.e.: would I need some > particular person to agree to be my commit-bitch or can I just sign off on > patches, somehow, and expect a pool of commit-bitches to magically push > commits for me? > > -gmt > I think you will need to simply contact proxy-maint people (CCing them) http://www.gentoo.org/proj/en/qa/proxy-maintainers/
Re: [gentoo-dev] Packages up for grabs
On 06/16/2013 02:19 PM, g...@malth.us wrote: > On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped: >> Due ramereth lack of time: >> net-misc/stunnel > > Pretty sure my (dead, eventually to be revived) server uses stunnel. I've > never officially maintained anything, is there some documentation somewhere > as to what exactly I'm agreeing to, if I take on proxy maintainer-ship? > Also, of how proxy maintainer-ship actually works? I.e.: would I need some > particular person to agree to be my commit-bitch or can I just sign off on > patches, somehow, and expect a pool of commit-bitches to magically push > commits for me? > > -gmt > > > http://www.gentoo.org/proj/en/qa/proxy-maintainers/ Afaik any of the proxy maintainers listed there can be contacted whenever you need to apply changes to the ebuild. They will do some kind of minimal review to check that coding style and general ebuild rules are respected. But basically any developer can be your proxy.
[gentoo-dev] vmware herd is empty
Will drop it in two weeks if nobody joins Thanks
RE: [gentoo-dev] Packages up for grabs
On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped: > Due ramereth lack of time: > net-misc/stunnel Pretty sure my (dead, eventually to be revived) server uses stunnel. I've never officially maintained anything, is there some documentation somewhere as to what exactly I'm agreeing to, if I take on proxy maintainer-ship? Also, of how proxy maintainer-ship actually works? I.e.: would I need some particular person to agree to be my commit-bitch or can I just sign off on patches, somehow, and expect a pool of commit-bitches to magically push commits for me? -gmt
Re: [gentoo-dev] [RFC] SRC_URI behaviour
I'd like that behaviour! 16.06.2013 07:24, Zac Medico пишет: > How about it we add a src_fetch phase, so that the VCS intricacies can > be delegated to ebuilds/eclasses (like they are now, but without having > to abuse src_unpack). If we include a way for src_fetch to communicate > changes in VCS revisions to the package manager, then we'll be able to > integrate functionality like smart-live-rebuild directly into the > package manager (as discussed in bug 182028 [1]). > > [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013/6/16 Zac Medico : > How about it we add a src_fetch phase, so that the VCS intricacies can be > delegated to ebuilds/eclasses (like they are now, but without having to > abuse src_unpack). If we include a way for src_fetch to communicate changes > in VCS revisions to the package manager, then we'll be able to integrate > functionality like smart-live-rebuild directly into the package manager (as > discussed in bug 182028 [1]). As a side note from a developer of an app that keeps various loosely coupled modules in one repo — it'd be great if there would be a way to also tell whether the changed revision actually affects the given package. The default, of course, should be to assume that every change in the repo affects a given package, but when it can be proved that package doesn't need to be rebuilt — why bother rebuilding it? Of course, the task of the proof lies on exact ebuild maintainer. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] [2&3]/3 API & files
On 16.06.2013 03:21, Robin H. Johnson wrote: >> Special pages and contents >> -- >> herds.xml, repositories.xml, etc.: >> As these are intended for other applications to use, these should go to >> a new site, possibly api.gentoo.org, initially fed from a git repository. >> This site should get backed by SSL. > Here's a partial list of the ones I know about: > http://www.gentoo.org/proj/en/overlays/repositories.xml > http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml > http://www.gentoo.org/main/en/mirrors3.xml > Both of these are broken I think: > http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml > http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml > > - Do you know of more? http://www.gentoo.org/proj/en/metastructure/herds/herds.xml > - How can we better encourage these to move to an API site? Not sure what you mean with that. > - Some of these are meant for human consumption, others are meant for > tool consumption, should be differentiate? Human consumption -> qa-reports.g.o > >> Image resources: >> These can be uploaded to the Wiki. > How can we ensure later that the media files don't get deleted? > Deletion is restricted to administrators, mediawiki also keeps old versions around in case someone reuploads a file. To prevent even that, we can restrict editing certain assets to developers. >> Other files and downloads: >> Until proper project file hosting is implemented, again a simple >> git-backed static site, possibly projects.gentoo.org. > Please don't put lots of binary files in Git. > How do we expose that site to developers then? Akin to the mirroring system on d.g.o? -- Alex Legler Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/16/2013 02:24 AM, Zac Medico wrote: > How about it we add a src_fetch phase, so that the VCS intricacies > can be delegated to ebuilds/eclasses (like they are now, but without > having to abuse src_unpack). If we include a way for src_fetch to > communicate changes in VCS revisions to the package manager, then > we'll be able to integrate functionality like smart-live-rebuild > directly into the package manager (as discussed in bug 182028 [1]). Sounds interesting. Still please notice that the initial and misdelivered point about live ebuild being NOT for everybody beside who develops software should be clear. lu
Re: [gentoo-dev] Packages up for grabs
On 16/06/2013 11:03, Pacho Ramos wrote: > media-gfx/iscan-plugin-gt-f720 I'll clean it up so that it behaves like the other iscan-plugins but if somebody has hardware that would be nice to co-maintain (including users) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16.06.2013 06:01, "Paweł Hajdan, Jr." wrote: > On 6/9/13 7:22 AM, Alex Legler wrote: >> I'd appreciate some input on below plan to move project pages to the Wiki: > > Alex, thanks for working on this! Some feedback: > > 1. How will the project pages be protected against "unwanted" edits? I > think it's valuable to have some official pages where you know only > Gentoo devs can edit them. The Project: namespace is restricted to only allow users in the developer group to edit. > > 2. How will the staffing needs page be updated after dropping gorg? You create a subpage for each staffing need, filling in information using a form. Semantic magic aggregates these, and you'll get a template to include for your project page to list the ones for your project specifically. > > 3. How secure is the wiki? Do we have regular backups and security > updates procedures in place? I know you're member of the security team > and infra team is doing its job well, but I just wanted to check. > Dynamic web applications arguably have bigger attack surface than > effectively a bunch of static files only editable after you gain server > access. It's part of the usual infra backup, and I follow upstream release announcements and update accordingly. > > Paweł > > -- Alex Legler Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grabs
El dom, 16-06-2013 a las 12:03 +0200, Pacho Ramos escribió: > Due elvanor lack of time the following packages are up for grabs: > app-office/openerp-server > net-print/xerox-drivers > media-gfx/iscan-plugin-gt-f720 > net-libs/pjsip > Also: app-office/openerp-client app-office/openerp-web
Re: [gentoo-dev] About moving "vala" to global USE flags
El lun, 03-06-2013 a las 21:48 +0200, Pacho Ramos escribió: > It's widely used in gnome related packages with similar purposes, its > description could be: > Enable bindings for dev-lang/vala > > Are you ok with moving it to global? Done
Re: [gentoo-dev] mono-env.eclass: set a default SRC_URI
El vie, 24-05-2013 a las 21:19 +0200, Pacho Ramos escribió: > I noticed the following addition to mono-env.eclass would be needed to > let us kill go-mono.eclass (setting now obsolete SRC_URI and build > phases relying on base.eclass) > > Patch attached > Done
[gentoo-dev] Packages up for grabs
Due elvanor lack of time the following packages are up for grabs: app-office/openerp-server net-print/xerox-drivers media-gfx/iscan-plugin-gt-f720 net-libs/pjsip
[gentoo-dev] Packages up for grabs
Due ferringb retirement the following packages are up for grabs: app-arch/tarsync dev-python/snakeoil dev-util/bsdiff dev-util/diffball sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained and neither has eapi5 support)
[gentoo-dev] gdesklets herd is empty
Feel free to join to it or will be removed in two weeks Thanks!
[gentoo-dev] Packages up for grabs
Due nixphoeni lack of time the following package is up for grabs: app-misc/gourmet
[gentoo-dev] Packages up for grabs
Due ramereth lack of time: sys-block/megacli net-misc/stunnel app-admin/mcollective
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On Sat, 15 Jun 2013 21:01:00 -0700 ""Paweł Hajdan, Jr."" wrote: > On 6/9/13 7:22 AM, Alex Legler wrote: > > I'd appreciate some input on below plan to move project pages to > > the Wiki: > > Alex, thanks for working on this! Some feedback: > > 1. How will the project pages be protected against "unwanted" edits? I > think it's valuable to have some official pages where you know only > Gentoo devs can edit them. Pages can be protected and limited by group using Page Protection. http://en.wikibooks.org/wiki/MediaWiki_Administrator%27s_Handbook/Page_Protection#Page_Protection_in_MediaWiki_1.5_and_later Pages can be watched for changes using a Watchlist. http://www.mediawiki.org/wiki/Manual:Watchlist Watchlist notifications can be send by mail. http://www.mediawiki.org/wiki/Extension:Email_notification You could probably use a Procmail rule to filter whom you want to track. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/cont
El dom, 16-06-2013 a las 11:38 +0800, Patrick Lauer escribió: > On 06/16/2013 04:37 AM, Pacho Ramos wrote: > > # Pacho Ramos (15 Jun 2013) > > # Upstream dead for ages, nothing requires it, wrongly > > # generated .la files (#201440). Removal in a month. > > rox-base/rox-clib > > > > No :) > > I've commented out that mask in package.mask because: ah, I missed the dependency from eclasses :S Thanks!
Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013-06-15 17:51 Rich Freeman napisał(a): > Plus, right now with Gentoo there is no way to set an overlay as being LOWER > priority than the main tree - so that you can grab packages not supported in > main from an overlay but still use the main packages when available. Portage has been supporting setting of priority in /etc/portage/repos.conf for about 2.7 years. $ cat /etc/portage/repos.conf [name_of_overlay] priority = -1001 (`emerge --info -v` shows repositories with their priorities.) -- Arfrever Frehtes Taifersar Arahesis
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 16 June 2013 08:08, "Paweł Hajdan, Jr." wrote: > On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: >> Still seems like working in gentoo-x86 without doing stabilization >> would cover most of those bases. Working in the unstable main tree is >> still a lot better than keeping stuff out there in an overlay, IMO. > > +1 > > This works really well for the Gentoo Chromium team, where we have just > hard masked packages and ~arch packages right in the tree. In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that Chromium and co. it not a development library this is a end user application. End user applications should be in tree (except for some testing reasons), if not just ignore this letter. And thanks for your work. -- Alexander