Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On 31 May 2015 at 12:59, Alexis Ballier aball...@gentoo.org wrote: nice, but can't we add the lfs flags to our default toolchain flags or even better patch glibc headers to always redefine these functions to the 64bits variants? No, because that can easily break ABI of programs that actually want the non-LFS one (for instance anything that wraps around function calls, including but not limited to padsp, aoss, and similar wrappers.) FreeBSD has removed the symbols on an ABI bump, which hopefully could happen for glibc in a far and remote future, too. But as long as the symbols are there, the defines shouldn't be forced. Mike, thanks for doing this, it has been a pain in my shoe since 2008 https://blog.flameeyes.eu/2008/11/who-wants-to-support-largefile. I'm looking forward to the protests that 64-bit inodes don't exist, though. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On 31 May 2015 at 14:33, Philip Webb purs...@ca.inter.net wrote: Do users with 64-bit systems have to pay attention to this ? Only as far as multilib is concerned. The 64-bit ABIs are (AFAIR) all LFS with no opt-out. x86-64 is definitely LFS. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
On 25 April 2015 at 16:57, Duncan 1i5t5.dun...@cox.net wrote: Of course, one thing that could make the process faster would be if C++ based packages were marked some way. revdep-rebuild --soname 'libstdc\+\+.so.*' should do the trick. Stuff that does not link the library (statically linked or using libsupc++) should not really matter.
Re: [gentoo-dev] libressl status
On 6 April 2015 at 23:06, Paul B. Henson hen...@acm.org wrote: What are the downsides of the approach pkgsrc is tentatively taking, where there are no modifications to libressl but the libraries are installed in an alternative location? Packages that require libressl can just use the appropriate linker options to find those libraries rather than the openssl ones? https://blog.flameeyes.eu/2014/07/libressl-drop-in-and-abi-leakage Let's say you have program foo that uses libtls and libssl functions *and* CURL. Now you built CURL against openssl, but foo requires libtls, so you link it against libressl. What happens when you run foo? Symbols from openssl's libssl and libressl's libssl have the same name for API compatibility, right? So whichever of the two is loaded first (I *think* that's libressl but it is of course loader-dependent and in the case of glibc it depends on the environment variables too) will provide the symbols. But their ABIs are different so the calls coming from CURL (built against OpenSSL) will provide different data structures and parameter size than expected by libressl, or vice-versa. Given these are security functions, the collisions are even riskier than just crashing, especially as *most* of the functions will likely work either way, as long as the same set of allocators/users/deallocators are used… Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] libressl status
On 6 April 2015 at 23:07, Jason A. Donenfeld zx...@gentoo.org wrote: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. Doesn't work, you'd have to rebuild *all* the packages built with one or the other when switching, or (if the SONAME were the same) they would be built against a different ABI that they are built against, which can be possibly causing security issues as data structure size (and thus meaning of the content) changes. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] libressl status
On 5 April 2015 at 05:44, Paul B. Henson hen...@acm.org wrote: I guess I'll just let this simmer for now and see how things develop. My preference (I think, at least at the moment) would be for both implementations to be able to coexist, like openssl and gnutls. It looks like that's the way it's heading in pkgsrc (the other place I'm maintaining openntpd), which should make things relatively simple there. If that's not going to be an option with Gentoo hopefully the best alternative will become clearer at some point ;). The problem with that is that now you have to make sure that transitive dependencies are still functional. Since as you point out the two packages are vastly API compatible, it makes them ABI incompatible and conflicting. The functions can have the same name, and vastly the same parameters, but they may be using different size for data, for instance. I pointed this out last year[1][2] already. Symbol collision is a nasty problem because it's almost invisible as long as the API/ABI is close enough, but for libraries like OpenSSL/LibreSSL, this is a huge security risk, too. [1] https://blog.flameeyes.eu/2014/07/libressl-drop-in-and-abi-leakage [2] https://blog.flameeyes.eu/2014/07/libressl-and-the-bundled-libs-hurdle Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] libressl status
On 5 April 2015 at 19:59, Rich Freeman ri...@gentoo.org wrote: It seems unlikely that this would make much of a difference. I think that allowing this package to create another ffmpeg vs libav mess is a mistake. To be honest, the upstream developers should be fairly in the known regarding my opinion expressed in the blog posts, as they replied and read them before. We could also find other ways to deal with this by installing the packages as different library names and subverting pkg-config to choose between the two, but that would only work for packages using pkg-config to begin with and does not solve the transitive dependencies problem. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] Should Gentoo do https by default?
On 27 March 2015 at 19:14, Rich Freeman ri...@gentoo.org wrote: StartSSL in fact refuses to revoke certificates even when people publish their private keys publicly. If you buy a previously-used domain you might want to make sure that there isn't a StartSSL certificate floating around for it which is still valid... Uh? They don't do it for free, but they do revoke certificate if you pay for it. xine-project.org has a revoked cert from last year due to heartbleed. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
On 14 March 2015 at 23:30, Manuel Rüger mr...@gentoo.org wrote: iirc most deb and rpm based distributions use main for their central repository, so +1 for gentoo-main. Add me for gentoo-main too. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] [warning] the bug queue has 89 bugs
You *should* have the information to assign the bug in the build log, provided it's available, as the metadata.xml maintainer information should be printed at the top of it. I think automating assignment for properly defined package names in bug summaries is something that has been discussed before but never properly implemented. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/ On 27 February 2015 at 03:07, Andrew Savchenko birc...@gentoo.org wrote: On Thu, 26 Feb 2015 14:00:04 -0800 (PST) Alex Alexander wrote: Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 BTW, maybe this process can be partially automated? In most cases we have to look for category/package in a bug title and add/cc mails from metadata.xml to this bug. Of course, in some cases bug may have references to several packages or no valid references at all; false assignments are also possible as well as not properly submitted bugs (e.g. missing build logs and so on) . But in general such tool should reduce workload greatly. Another approach will be to allow users to assign bugs themselves. Best regards, Andrew Savchenko
Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
On 23 February 2015 at 22:11, Sebastian Pipping sp...@gentoo.org wrote: I have streamlined those into ebuilds and a dedicated overlay Thanks! So whoever needs to render Blender files from 2003 again at some point should find working ebuilds to do that. Feel free to join keeping them in good installable shape. Maybe it's time to rethink the logo and get someone to make a more future-proof SVG? :)
Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
But they don't. See my two blog posts on the matter. ABI compatibility is explicitly not. What they care about. On 23 Jan 2015 05:56, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-23, o godz. 01:51:24 hasufell hasuf...@gentoo.org napisał(a): Regarding the last libav discussion I think we should also go with a libressl USE flag instead of creating a virtual that makes handling SUBSLOTs impossible. If libressl and openssl would have matching ABIs, that wouldn't be necessary and you could what virtual/libudev does, i.e. explicit subslot deps. -- Best regards, Michał Górny
Re: [gentoo-dev] proposed update to toolchain.eclass
Yes, yes, yes, please fix this eight years old wish entry for me ;)
https://gcc.gnu.org/ml/gcc-help/2007-02/msg00314.html
Diego Elio Pettenò — Flameeyes
https://blog.flameeyes.eu/
On 18 January 2015 at 21:50, Anthony G. Basile bluen...@gentoo.org wrote:
Hi everyone, I'd like to make a commit to toolchain.eclass in a few days.
mgorny noticed some code which can be improved. Basically gcc creates
fixed include files from system headers because of the requirement that
it have ansi c compliant headers. These are fixed via shells scripts
during the build process, but we just delete them afterwards. Rather than
generate and then delete them, just don't generate them in the first
place. Its bug number #536878. I've tested on gcc-3 to the latest and
both approaches yield the same results. Here's the patch so you don't have
to go hunting for it:
diff -u -B -r1.647 toolchain.eclass
--- toolchain.eclass15 Nov 2014 08:45:33 - 1.647
+++ toolchain.eclass18 Jan 2015 20:36:08 -
@@ -595,6 +595,13 @@
einfo ${f%%...}
done
fi
+
+ # we don't want fixed includes :)
+ if tc_version_is_at_least 4.0; then
+ echo : ${S}/fixincludes/fixinc.in || die
+ else
+ echo : ${S}/gcc/fixinc/fixincl.sh || die
+ fi
}
guess_patch_type_in_dir() {
@@ -1598,9 +1605,6 @@
toolchain_src_install() {
cd ${WORKDIR}/build
- # Do allow symlinks in private gcc include dir as this can break
the build
- find gcc/include*/ -type l -delete
-
# Copy over the info pages. We disabled their generation earlier,
but the
# build system only expects to install out of the build dir, not
the source. #464008
mkdir -p gcc/doc
@@ -1611,13 +1615,6 @@
fi
done
- # Remove generated headers, as they can cause things to break
- # (ncurses, openssl, etc).
- while read x ; do
- grep -q 'It has been auto-edited by fixincludes from'
${x} \
-rm -f ${x}
- done (find gcc/include*/ -name '*.h')
-
# Do the 'make install' from the build directory
S=${WORKDIR}/build emake -j1 DESTDIR=${D} install || die
--
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] Doomsayers needed
On 26 Nov 2014 11:07, Michael Orlitzky m...@gentoo.org wrote:
On 11/26/2014 01:43 PM, Sergey Popov wrote:
Standart - cross-compilation and prefix. If you do not care about the
latter(not having keywords for your package) - it's ok.
Cross-compilation, or compilation into another root is trickier - you
should support it.
With ping and ping6 coming from net-misc/iputils, wouldn't the command
syntax be the same under prefix, except with $EROOT instead of $ROOT?
And with the command set to ${ROOT}bin/ping, building for a Gentoo
system under another root should work, right?
No, $ROOT should not seep into the compiled code.
[gentoo-dev] tb logs attacher
Hi, did you end up running the script only for RESO/NEEDINFO or for all of them? If you have a chance to run it for every bug I will just turn down the S3 account afterwards. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 20 November 2014 at 16:04, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/11/14 09:47 AM, Ian Stakenvicius wrote: On 19/11/14 09:51 PM, Rich Freeman wrote: On Wed, Nov 19, 2014 at 8:41 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Guys, can we please give the volunteers who are going around uploading logs time to do their jobs before we go closing bugs as invalid? The logs are going to get attached. If somebody is in a mad rush to actually resolve the bug (heaven forbid), then just click on the link. My script is running every 10 minutes; I can do it more often than that but I don't want to hammer b.g.o if I don't have to. Also, as of now, it *does not* upload to bugs that are marked RESOLVED. I think I'll adjust that so it will upload to bugs marked RESO/NEEDINFO (and re-open them), but please, ^^^ And finally, if anyone sees an issue, including if bugs are not getting their attachments in a timely manner, please attach the bug to tracker bug 527870 and I'll do my best to fix things. Thanks, Ian Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRuESgACgkQ2ugaI38ACPDR8AEAgdIvuivmg++PiDlUPfLOy7SR XUL5q4H+PFWRz077musA+gIbaPVFRBivJg11IXHHZtJVxj924iz/uyvNV+NlQyVF =YNpA -END PGP SIGNATURE-
Re: [gentoo-dev] tb logs attacher
On 26 November 2014 at 02:19, Rich Freeman ri...@gentoo.org wrote: Would it make sense to start logging the URLs that have been uploaded and send them to you in batches? That could be used with a script to purge no-longer-needed logs. It's a bit tricky. Becuase the vast majority of the logs were never filed a bug against, so I could easily just remove them and will probably end up well below S3's freebie quota. I'm more hoping that since there won't be any *new* bug logged, processing the past would be easy. I don't mind waiting even an year to turn it off: it would account to maybe 5% of the cost of one month of bare server hosting. For myself, this is just closure. I was tired already of the situation and I just want to get over it now. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Packages up for grab
Trying to dump first the packages I no longer use/I'm no longer interested in: app-crypt/sgeps app-emacs/actionscript-mode dev-java/jcommander dev-perl/CHI dev-perl/Data-Uniqid dev-perl/Digest-JHash dev-perl/Filesys-SmbClient dev-perl/google-api-adwords-perl dev-perl/Hash-MoreUtils dev-perl/String-RewritePrefix dev-perl/Test-MockModule games-board/cockatrice media-gfx/entangle media-gfx/pixie net-misc/lksctp-tools net-misc/miredo net-misc/teamviewer net-misc/tsclient net-proxy/c-icap net-proxy/squidclamav net-proxy/ufdbguard sys-apps/timer_entropyd sys-block/hpacucli x11-themes/constantine-backgrounds x11-themes/gentoo10-backgrounds x11-themes/goddard-backgrounds x11-themes/laughlin-backgrounds x11-themes/leonidas-backgrounds x11-themes/lovelock-backgrounds x11-themes/solar-backgrounds x11-themes/verne-backgrounds (Proxy maintained by Pavel Stratil) dev-db/drizzle dev-db/haildb dev-db/mydumper dev-php/pecl-drizzle dev-php/pecl-gearman sys-cluster/gearmand www-apache/mod_auth_token Please update the metadata and get the bugs if you want to maintain them, otherwise they'll stay assigned to me untl either I retire or I find time to fix them for good.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Before I reply with a simple four letter words let me restate one thing and than that will be it, and my next move unless council/devrel stops this for good my time will be spent better: playing Baldur's Gate. The problem is not that I don't know python. Because I do know python (now). The problem is that pybugz DOES NOT SOLVE A FREAKING THING. I scan between 100 to 500 logs a day, any second it takes me to open a new bug adds to the likeliness I have no time to do so. Right now the filing is done purely through the browser so my Bugzilla authentication never leaves it. I get the failed log, I click on the open bug button, it prefills it, I leave a proper summary to point out what the problem is and block the proper bug. If the app were to just open the bug for me, the app would have to have the credentials, which means I have to have the app behind authentication. And as I pointed out multiple time I have no time or interest in supporting a properly authenticated app FOR ONE PERSON REFUSING TO READ A LOG. Because sure, it's not an impossible amount of work, but it's a disproportionate amount of work when only one person requires it, and another 200 are perfectly fine with clicking on a link to read a log. Same thing with pybugz as a CLI tool; sure I could have it store a copy of my credentials on my laptop and now copy-paste the bug ID after opening and the log URL. But no thanks because it makes opening a bug a 40 seconds operation and prone to more mistakes and, once again, this is disproportioned to ONE person refusing to accept a setup. So really, I'm tired to be insulted, and this was the last drop. Goodbye. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 21 November 2014 07:51, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 11/20/14 5:04 PM, Ian Stakenvicius wrote: Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. +1, and thanks Ian for your script! Paweł
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Running repoman on the portage tree
On 19 November 2014 02:17, Alec Ten Harmsel a...@alectenharmsel.com wrote: * So many (~3MB output) warnings, especially upstream parallel compilation bug... thought autoconf handled this, but I guess not Autoconf has little to nothing to do with parallel make. If you're curious: https://blog.flameeyes.eu/tag/foraparallelworld has some posts on the topic, otherwise https://blog.flameeyes.eu/tag/parallelmake (there is some duplication as lots of the former posts are tagged for the latter too). Have fun. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/teamviewer: teamviewer-9.0.30203-r1.ebuild ChangeLog
Also feel free to pick up the package, I no longer have a license or a reason to buy one :( Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 12 November 2014 23:00, hasufell hasuf...@gentoo.org wrote: You have just done a full version bump, so the ebuild file name is wrong. The new version is untested too. On 11/12/2014 11:51 PM, Ian Stakenvicius (axs) wrote: axs 14/11/12 22:51:13 Modified: ChangeLog Added:teamviewer-9.0.30203-r1.ebuild Log: conversion to full gx86-multilib dependencies, updated manifest as upstream distfile apparently changed. Note, distfile for 7.x not found, maybe should be removed? (Portage version: 2.2.8-r2/cvs/Linux x86_64, signed Manifest commit with key 2B6559ED)
Re: [gentoo-dev] RFC: new QA_NEEDED variable for files installed by pre-built binary packages with broken soname dependencies
On 7 November 2014 13:04, Zac Medico zmed...@gentoo.org wrote: In bug 528086 [1] we have a pre-built games package with a soname dependency on libSDL_mixer-1.2.so.0. The maintainer reports that the game works fine without this library, so he doesn't want to add a dependency on sdl-mixer. Ehm no this is absolutely ludicrously a bad idea. If the library is in NEEDED of binary, there is no need that said binary will run. If whatever package works fine without that binary being able to run, maybe the binary should not be installed. Just shoving this under the rug is preposterous. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: new QA_NEEDED variable for files installed by pre-built binary packages with broken soname dependencies
On 7 November 2014 13:50, Zac Medico zmed...@gentoo.org wrote: Yeah, I figured that we'd get a reaction like this. I just thought I'd start by proposing some sort of compromise, and then let others fight it out. :) Since we got to a positive conclusion on the bug, let's not consider this proposal worth our time any more, shall we? Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: new QA_NEEDED variable for files installed by pre-built binary packages with broken soname dependencies
On 8 Nov 2014 01:35, Kent Fredric kentfred...@gmail.com wrote: On 8 November 2014 13:59, Zac Medico zmed...@gentoo.org wrote: Okay, sure. I'll save it for the day when someone finds a valid reason to install binaries with broken soname deps (not likely). Another candidate for a possible valid reason: https://bugs.gentoo.org/show_bug.cgi?id=460468 There's probably a better way of solving that too. Don't make the javafx install automagic
Re: [gentoo-dev] terminal spreadsheet - sc fork
Beside being off-topic. And beside SCIM being a well-known opensource projector for IME. If you're inventing a new license, that's simply wrong. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 3 November 2014 13:24, Andrés Martinelli andma...@gmail.com wrote: Hello there. Thanks for your time and taking a look at the app. About the license, my idea was to start scim with its own license, and keep it as simple as could be, but keeping in line with the points mentioned in it. I believe it will always suit best something particular and written for it, than something more general, but take in mind that this license can suffer modifications since this project is just starting! Since SCIM can be modified and redistributed with other license, such as any other GPL compatible, I believe is not as restrictive as it seems. Please, I am interested in hearing what points you dislike or consider are restrictive. Thanks! 2014-11-03 9:01 GMT-03:00 Matthias Maier tam...@gentoo.org: Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli andma...@gmail.com: I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Just out of curiosity. The original sc program is public domain [1]. You have chosen to relicense your fork of the codebase under a custom license that you labeled SCIM license. A quick peek at the license [2] reveals quite a cumbersome number of issues (forced contact, contact possibility, redistribution in form of tarballs and patches). Such a license usually prevents any meaningful number of external contributions and packaging. Not to mention that layman's licenses are almost always fundamentally flawed. Why not using an FSF-approved, OSI-approved, and/or DFSG compatible license instead? I'm sure that there is something available that fits your taste. (You can e.g. license under GPL 2 or later and ask for a special (non binding) courtesy to inform you of changes/patches.) Best, Matthias [1] http://metadata.ftp-master.debian.org/changelogs//main/s/sc/sc_7.16-3_copyright [2] https://github.com/andmarti1424/scim/blob/master/LICENSE -- Andrés Martinelli
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Excuse the top posting. You don't need to strip the HTML. Change the extension to whatever.log and it's already there in unmangled text. On 2 Nov 2014 01:10, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/11/14 03:53 PM, Pacho Ramos wrote: El sáb, 01-11-2014 a las 14:54 -0400, Ian Stakenvicius escribió: On 31/10/14 10:37 PM, Ian Stakenvicius wrote: Sorry for top posting. I volunteer to write something to get the logs attached to bugs. I'll do it next week. Whether it be something the tinderbox can run or something separate that will use pybugz to find bugs and then attach whatever logs are pointed to by URLs, etc, I'll figure it out. OK, i've cobbled something together that looks like it'll work. I'll be putting this thing on a cronjob on one of my systems, and hopefully it'll be able to keep up with Diego's tinderbox runs and bug filing with as little delay as possible. I've already started running it on all bugs filed by Diego after October 20th. If anybody sees any issues with the attached build.log's, please let me know by adding the bug with the issue to a tracker I made for this purpose, bug 527870 Thanks, Ian At least for the bugs I have read, it looks to work nice. Thanks a lot :D Is the script placed somewhere? (for learning purposes :)) Thanks Not at the moment ; I'm going to want to do a fair bit of cleanup before i let anyone else's eyes on it.. :) It's just a bash script, though -- i use 'pybugz search' to get a list of the bugs Diego's filed (using --offset and --limit to restrict the list returned), get the content of each one, and if it has no attachments but has a URL with 'https://tinderboxlogs' in the comment, then i wget the URL to a temp file, strip the HTML out, and attach it (compressing if necessary to save space) to the bug with 'pybugz attach'. Add in a couple of files that lets me keep track of the current search offset i should be using as well as the bug#'s the script has processed and skipped, and that's about it. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRVhG8ACgkQ2ugaI38ACPBRIAD+J0eZvjhRBcQ2KfxWKs3AozBL dhCZQ+sUCwtIb5dpemgA/RiwAabfqsG41o8CsitjIbzz/Q2MBZC4r/3q/3rkgP4H =LHOX -END PGP SIGNATURE-
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
How do you strip the html code? I was unsure about to do that :/ You should have asked. There is no need to strip. I upload both HTML and text alike.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 1 November 2014 00:18, Rich Freeman ri...@gentoo.org wrote: So, if there is a better way, I'm all ears for constructive suggestions. By constructive I mean that somebody who comes up with a script that automatically retrieves build logs and attaches them to bugs is being more helpful than somebody who says that somebody else should come up with such a script, and so on. That doesn't mean that we can't talk about solutions before we build them - only that it isn't helpful when we basically demand that others build them for us. Let me try to be clear (once again) of what the problem is. Even just spending time rewriting this irks me because I have written, repeated, re-explained, described the problem a number of times, between bugs, this ML and my blog ( https://blog.flameeyes.eu/tag/tinderbox ). The problem with it's trivial to do that in python so just do it is that first of all Python is not my language of choice, so the whole infrastructure is currently not written in Python at all. And all the people, including Luca, who promised they can convert it to Python in no time, never delivered. Beside the point that, if it's so trivial for somebody, I would expect it'll take them less time to provide me with the tool, rather than complain about it. Another suggestion that happens fairly often is oh just do it after opening the bug with a script, and the answer is - no way. Because right now it's all self contained in a browser for good reasons: I open these bugs when I'm at work waiting for a meeting, at home waiting to sleep, or while watching TV. I do it from laptops and tablets, and if I have to start copy-pasting things between browser and console to run a script, I'd rather just leave things broken because it *is* too much work by the amount of bugs I open. And it's not something I can do on a tablet or at work. Which would mean that not only it'll take me more time , and I would also have less time available. Not a good deal. Since the bugs are opened through a pre-filled form template, it's not easy for anything else to know what the bug is to attach logs to. One alternative would be to have the app that I use to show me the logs file the bug entirely for me. Unfortunately that means I'll have to figure out how to secure the app, as right now, being just a display-only thing, it's completely open to the Internet. And I'm sure Infra would rather not have a tool open to the internet that can open bugs with logs of many MBs attached. It will also slightly lower the quality of bugs because either it needs to build its own form to fill in for summary and blocking bugs, or it'll just go with the two summaries I know for sure how to get from the log (fails to build, fails tests), so no more foo[doc] fails to build or foo fails to build with ncurses[tinfo]. But let's reason a moment on the no-linked-logs policy: as Rich pointed out already, the policy is there for a reason and that reason is that we don't want people to submit bugs with pastebins or home server logs because they are bound to go away. I link logs to Amazon, which I pay for. Mike says it's unreasonable to expect me to pay Amazon for them forever... I pay $1/mo for storing viewing an adding the logs. And even that turned out to be actually an excess as I was paying between $.12 and $.20 for storing EBS snapshots from long ago that I never ended up removing. It's not even a rounding error at this point. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 1 November 2014 10:47, Diego Elio Pettenò flamee...@flameeyes.eu wrote: But let's reason a moment on the no-linked-logs policy: as Rich pointed out already, the policy is there for a reason and that reason is that we don't want people to submit bugs with pastebins or home server logs because they are bound to go away. I link logs to Amazon, which I pay for. Mike says it's unreasonable to expect me to pay Amazon for them forever... I pay $1/mo for storing viewing an adding the logs. And even that turned out to be actually an excess as I was paying between $.12 and $.20 for storing EBS snapshots from long ago that I never ended up removing. It's not even a rounding error at this point. And I forgot to add, to run the tinderbox, hosting the server costs me $600/mo — and sure, I use it to stage the packages for a bunch of my private servers too, and it runs fate instances for libav. But you can probably note how the two numbers don't even come *close* to each other. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 19 October 2014 16:57, hasufell hasuf...@gentoo.org wrote: If maintainers want to NEEDINFO or WONTFIX a tinderbox bug, well, they'll be the ones picking up the pieces when the gcc upgrade moves ahead. We are all picking up the pieces. I don't get why anybody wouldn't like seeing them. I do, it's childish and uncollaborative behavior from that person closing the bugs (any1 still wondering who we are talking about?). And that behavior is tolerated. Are you saying you want to change something about it? So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 31 October 2014 22:38, hasufell hasuf...@gentoo.org wrote: Signs of his inability to collaborate in some situations have come up repeatedly on this list, be it problems with crossdev/multilib, games team and whatnot. Most of these were either ignored or had to go through a council decision. That's not really efficient and cannot work long term. Do we treat some developers differently? And does all this social status crap really improve collaboration overall? And we lost more than one developer in the process because of that. And guess what? After someone reaching out to me off list telling me to, essentially, work around him or swallow it, I'm more convinced than ever that either someone else (Council? QA? the Pope?) fixes this, or I'll add myself to that list. Seriously, he essentially has been ignoring me altogether *when I was voted the freaking QA lead*. (To be fair, huge thanks to Rich and Jer for their help here, it does feel good to know that at least some of the colleagues do have my back.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
I can spend some time with the tinderbox on 4.9 but the maintainers will have to accept that the logs will be linked and not attached. (This being the main reason why I stopped bothering unless people asked me explicitly, given how many times someone closed my bugs with NEEDINFO because the logs were not attached.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 08:51, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 10/13/14 1:38 AM, viv...@gmail.com wrote: have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ? I'm not really suggesting to do so, but seem that most of the problems of 4.9.1 are the same of 4.8.3 so maybe it's worth considering. Il 11/10/2014 13:57, Paweł Hajdan, Jr. ha scritto: We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium starts making heavy use of C++11 language features, see http://chromium-cpp.appspot.com/ . I don't realistically see us being able to just patch chromium to work around that. for 4.9.2 the 6-12 week window could be a problem Yeah, I don't think we can go straight to 4.9 without the latter spending time in ~arch, and for now it's still hard masked. Paweł
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
If you write the code for that, be my guest. But the code is in Ruby and does not open the bug directly (only links to a pre-filled bug form). When I wrote it, Python was definitely not among my strong languages. While I can probably write it now, I don't have the time. As I said I'm happy to volunteer my time to run the tinderbox and file the bugs. But I won't do so if all I'm going to get back is bitching. It seems a fair proposal to me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 12:59, Pacho Ramos pa...@gentoo.org wrote: El sáb, 18-10-2014 a las 12:35 +0100, Diego Elio Pettenò escribió: I can spend some time with the tinderbox on 4.9 but the maintainers will have to accept that the logs will be linked and not attached. (This being the main reason why I stopped bothering unless people asked me explicitly, given how many times someone closed my bugs with NEEDINFO because the logs were not attached.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What is the main reason for not being able to attach them to the bugs (as normally is done with other bug reports not related with tinderbox)? Wouldn't be possible to, once they are stored on your amazon webservice account, use wget to download them and attach them using pybugz for example?
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
All the stack is at https://github.com/gentoo/tboxanalysis The opening of the bug report is done by a piece of meatware called me. The UI displays a link that I can click to pre-fill the bug report. The rest of the information is filled in manually and submitted. Also remember that the linked logs might be too big for Bugzilla to attach uncompressed... and some of them even compressed. I take it that at least one person (you) will object at me keeping the process as is, so for the moment I won't be wasting my time on this. Call me back if you find a way to fix that without requiring more of my time. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 17:55, Pacho Ramos pa...@gentoo.org wrote: El sáb, 18-10-2014 a las 14:15 +0100, Diego Elio Pettenò escribió: If you write the code for that, be my guest. But the code is in Ruby and does not open the bug directly (only links to a pre-filled bug form). When I wrote it, Python was definitely not among my strong languages. While I can probably write it now, I don't have the time. As I said I'm happy to volunteer my time to run the tinderbox and file the bugs. But I won't do so if all I'm going to get back is bitching. It seems a fair proposal to me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What do you use to open the bug reports? Maybe could be easily be done at that step :| (or even run some small script after the bug if filled simply re-fetching the file from amazon and attaching to the bug it's being processed)
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 18 October 2014 19:03, Michael Orlitzky m...@gentoo.org wrote: Dude... what? If this is what's holding up a tinderbox run, add me to the bug template as a CC and I'll personally download and attach every log to bugzilla. If at some point we all decide this is super silly and embarrassing, perhaps we can eliminate that step. Yeah this is essenially why I stopped spending time on tinderboxing, especially as the someone kept closing bugs that eh wouldn't have looked at anyway. Indeed, for context, the main rule about attaching logs is to avoid people filing bugs and referencing pastebin that can break in even just a week. And the complains I got are of the like of what if you decide to stop paying amazon? — that would more be the case if I end up having some more health issues and be unable to pay, as the $2/month (less now, thanks to Amazon slashing prices earlier this year) is not something I feel. Especially in comparison to the $600/month the tinderbox *hardware* costs me to host. If there is the interest, I'll start prop it up for gcc-4.9 testing even tonight. It'll take a couple of weeks to go all through it. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [EBUILD] unknown description
And if faad is *required* for aac it should not use faad as USE flag, but aac. Because in the case of mplayer it's selecting faad *over libavcodec*. In other cases faad is depended upon with aac because it is required to play back aac files. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 16 October 2014 20:57, Kent Fredric kentfred...@gmail.com wrote: On 17 October 2014 08:54, sp4ze sp...@sp4ze.net wrote: I looked the other ebuild using faad ( mpd, mplayer... ) but I see no difference with mine. grep faad /usr/portage/media-video/mplayer/metadata.xml flag name=faadUse external faad library for AAC decoding/flag grep faad /usr/portage/media-sound/mpd/metadata.xml flag name=faadUse external faad library for AAC decoding/flag -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Removing a blocker from a stable package
that's intended. repoman warns for missing *needed* dependencies, but won't bother for unknown blockers exactly for cases like this. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 15 October 2014 01:25, Michael Orlitzky m...@gentoo.org wrote: On 10/13/2014 02:41 PM, Mike Gilbert wrote: I agree with Diego and Ralph: Go with d. repoman will generate a warning (not an error) about a dependency which does not exist, but this is safe to ignore. Given that (d) didn't require me to do anything else, I just went ahead and removed app-doc/djbdns-man. Repoman doesn't even warn. Huh.
Re: [gentoo-dev] Removing a blocker from a stable package
(d) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 13 October 2014 17:58, Michael Orlitzky m...@gentoo.org wrote: I've got two obsolete packages masked currently: app-text/unix2dos and app-doc/djbdns-man. Both of them block other stable packages, app-text/dos2unix and net-dns/djbdns respectively. Fortunately, both of them have had version/revision bumps since the blocker so we can remove the blocker from the newer ebuild and then stabilize that, at which point there's no problem. But I wonder, what would be the best way to handle the situation if no version/revision bump had occurred? In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In -r29, I have, KEYWORDS=alpha amd64 hppa ~mips ppc ppc64 sparc x86 DEPEND=!app-doc/djbdns-man and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man from the tree -- what do I do about the blocker? I see a couple of options: a) Edit the stable ebuild with ones fingers crossed b) Do a revbump and wait it out c) Do a revbump and file a stablereq immediately d) Do nothing, will repoman tolerate that? (b) is obviously safest, but (c) seems reasonable as well all things considered. Will the answer change when portage drops dynamic deps?
Re: [gentoo-dev] Re: Are users forced to use PAM?
What Lars said. Although I have to admit that the fact that one full day later I'm looking at it myself after work and before getting ready for travel saddens me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 6 October 2014 05:34, Lars Wendler polynomia...@gentoo.org wrote: On Mon, 06 Oct 2014 03:53:11 +0300 Nikos Chantziaras wrote: On 05/10/14 16:20, Diego Elio Pettenò wrote: Please get upstream to apply the patch and release a new sudo version. Simple as this: -pam is not by default tested and you keep the pieces if it breaks. If you can get upstream to just apply that patch, you solve your problem. Insulting developers as it's happening on that bug will bring you nowhere. I didn't insult anyone. Yeah, we didn't mean you. Sorry if that impression might have arose. But as can be clearly seen in the bug, there is a person which thinks insults and rude behavior could speed up things. He could not be more wrong but that's a different topic and should not be discussed here. Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
Re: [gentoo-dev] Are users forced to use PAM?
Please get upstream to apply the patch and release a new sudo version. Simple as this: -pam is not by default tested and you keep the pieces if it breaks. If you can get upstream to just apply that patch, you solve your problem. Insulting developers as it's happening on that bug will bring you nowhere. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 5 October 2014 11:18, Nikos Chantziaras rea...@gmail.com wrote: In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua Kinard mentioned that Gentoo cannot support systems where PAM isn't installed. I'd like to know whether this is true or not, especially since no part of the system seems to actually require it. It is there if you need it. I don't have a use for it, personally. (The issue at hand is that sudo links against -lshadow, which should not happen and therefore that link command removed from the build.)
Re: [gentoo-dev] Are users forced to use PAM?
Thanks for looking it up Matthias. Sounds like me or someone else will get to it asap (not on my laptop right now to commit). On Oct 5, 2014 4:45 PM, Matthias Maier tamiko+gen...@kyomu.43-1.org wrote: Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò flamee...@flameeyes.eu : Simple as this: -pam is not by default tested and you keep the pieces if it breaks. Upstream bug is at [1]. According to comment 1 also upstream does not seem to test non-pam use cases all that often. I have the impression that all this fuzz around bug 524074 could have been handled in a much more civilized manner... Are users forced to use PAM? - we might want to inform upstream (politely) that we still support non-pam use cases. Otherwise the dependency might become mandatory. Best, Matthias [1] http://www.sudo.ws/bugs/show_bug.cgi?id=667
Re: [gentoo-dev] Enable format-security in the dev profiles
Any -Werror=* flag will make random autoconf checks fail for no good reason, don't use them on profiles, it's silly. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 20 July 2014 20:28, Agostino Sarubbo a...@gentoo.org wrote: Hello, I'd like to enable by default format-security at least in the dev profiles. Thought? References: https://bugs.gentoo.org/show_bug.cgi?id=259417 https://fedoraproject.org/wiki/Format-Security-FAQ -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] [PATCH] fcaps.eclass: Group name portability
I'm pretty sure we have an eclass function to get the name of the 0 group. On 12 Apr 2014 17:41, hasufell hasuf...@gentoo.org wrote: na...@gentoo.org: fcaps.eclass is using group name 'root' which is not available on BSD system. Instead you can use 0, or $(id -g -n 0) if you'd prefer group name Index: fcaps.eclass === RCS file: /var/cvsroot/gentoo-x86/eclass/fcaps.eclass,v retrieving revision 1.8 diff -u -r1.8 fcaps.eclass --- fcaps.eclass 27 Jun 2013 01:18:57 - 1.8 +++ fcaps.eclass 13 Apr 2014 00:16:44 - @@ -80,7 +80,7 @@ # Process the user options first. local owner='root' - local group='root' + local group=$(id -g -n 0) local mode='4711' local caps_mode='711' # id -g -n 0 id: 0: no such user
Re: [gentoo-dev] ImageMagick[opencl] sandbox access violations
There's a sandbox.d configuration directory on purpose; imagemagick[opencl] should probably install its own exception. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 27 March 2014 07:29, Maxim Koltsov maksbo...@gentoo.org wrote: Hello, Currently there are four open bugs (see comment 2 in bug 490457) about imagemagick tools causing access violations while trying to open GPU. There is working solution: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-icon-theme/tango-icon-theme-0.8.90.ebuild?r1=1.15r2=1.16 This must be applied to all affected ebuilds, so maybe we should move this code to some eclass (eutils?) so that ebuilds can just call the function instead of copying the code? Maxim.
Re: [gentoo-dev] Re: About pam herd status
If we limit it to the virtual, pam and pambase, I'm happy to stick maintaining them, the others I don't use, which is why I don't care about them as much. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 11 January 2014 11:01, Pacho Ramos pa...@gentoo.org wrote: El sáb, 11-01-2014 a las 10:57 +, Markos Chandras escribió: On 01/10/2014 11:14 PM, Diego Elio Pettenò wrote: On 10 January 2014 22:20, Mike Frysinger vap...@gentoo.org wrote: how would moving it to base-system make any difference ? people doing it wrong wouldn't really care which herd pam itself is owned by. I'm not saying it makes a difference, sorry I didn't make it clear. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I only suggested that as part of our usual 'drop-dead-teams' process in the retirement team. So in this case, either a 'parent' herd needs to inherit the packages or simply drop them to maintainer-needed sys-auth/pam-pgsql sys-auth/pam_dotfile sys-auth/pam_krb5 sys-auth/pam_ldap sys-auth/pam_passwdqc sys-auth/pam_ssh sys-auth/pam_ssh_agent_auth sys-auth/pambase sys-libs/pam virtual/pam This are the packages under pam team management, would be nice to know if there is somebody maintaining each of them or we need new maintainer for any Thanks
Re: [gentoo-dev] Re: About pam herd status
On 10 January 2014 22:20, Mike Frysinger vap...@gentoo.org wrote: how would moving it to base-system make any difference ? people doing it wrong wouldn't really care which herd pam itself is owned by. I'm not saying it makes a difference, sorry I didn't make it clear. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: About pam herd status
On 9 January 2014 20:20, Mike Frysinger vap...@gentoo.org wrote: well, the sep herd was kind of by design ... i didn't want it cluttering up base-system@ and it is super convenient to abdicate all PAM decisions to a single herd. Yeah the problem has been that the herd has been fundamentally a single person, and when said single person asked for the rest of the users of/providers for PAM to accentrate on a single package, they ignored/worked around problems instead of reporting/discussing them. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: About pam herd status
I stopped caring about pambase when people decided to break it. I'm still officially pam herd as maintainer of Linux-PAM, pam_ssh I don't use and care very little about. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Mon, Dec 9, 2013 at 2:20 PM, Pacho Ramos pa...@gentoo.org wrote: Hello Is pam team still active? I wonder about this as, recently, we have needed to go ahead and fix some bugs related, for example, with pambase and pam_ssh Thanks for the info :)
Re: [gentoo-dev] =net-fs/samba-4* vs. dev-libs/openssl[kerberos]
On Fri, Dec 6, 2013 at 3:24 PM, Lars Wendler polynomia...@gentoo.orgwrote: The bug reporter suggests to use bundled heimdal from samba-4 which I would like to avoid if possible. If the libraries were to expose the symbols of the embedded heimdal, it would solve the obvious build problem and create a bigger one at runtime. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 1:31 PM, Peter Stuge pe...@stuge.se wrote: Or maybe yes. :) The condition I refered to is that the system is using openrc. Sorry if my weak language skills caused confusion! What I mean is that it would be stupid to have USE=openrc to apply such a patch. Either the patch is done correctly (does not break the daemon), or is not. If the former is true, USE=openrc would be broken; if the latter is true, why not simply apply it to begin with? If you really don't want PID files (and it probably means you have never had to deal with medium-scale deployments, but never mind), you can make it so that `-p` is an optional parameter, and if not passed no pidfile is created. And voilà, you can make an unconditional patch and even send it upstream for other init systems that do rely on pidfiles that are not OpenRC. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 1:55 AM, Peter Stuge pe...@stuge.se wrote: Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. You mean unconditionally here, right? Because pid files should be there, full stop. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
Quick note: I forgot my key from this laptop does not let me commit. I had some fixes done, but I'll have to wait to get back to Ireland to commit again, as the key is physically there. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Sat, Nov 23, 2013 at 1:15 PM, Markos Chandras hwoar...@gentoo.orgwrote: On 11/10/2013 10:27 PM, Matthew Thode wrote: On 11/09/2013 09:20 AM, Diego Elio Pettenò wrote: Seems like I forgot to select reply all earlier. I'm going to look into that next week. I failed to resetup my monitoring after I left my previous customer and I've reinstalled icinga just this week. I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is. If you are interested in co-maintaining with me I'd be interested in helping with the plugins (nrpe/nsca agent/plugins and pnp4nagios). I already do the icinga packages but I feel like I am starting to spread myself thing with openstack and everything :( (picking up a random e-mail from the thread) 2 weeks later and the number bugs is pretty much the same. I suggest whoever is interested in helping out to add himself to metadata given no coordination has happened so far. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Package removal without proper last-riting
On Thu, Nov 14, 2013 at 3:08 AM, Ryan Hill dirtye...@gentoo.org wrote: I wasn't aware last-riting had become general policy. It was originally started by the treecleaner team to give people time to object to maintainer-needed removals, and others thought it was a good idea, but it was always up to the discretion of the maintainer back then. Last riting predates treecleaners by quite a bit. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
Seems like I forgot to select reply all earlier. I'm going to look into that next week. I failed to resetup my monitoring after I left my previous customer and I've reinstalled icinga just this week. I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is.
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On Sat, Nov 9, 2013 at 3:30 PM, Alex Alexander wi...@gentoo.org wrote: On Sat, Nov 9, 2013 at 5:20 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is. Herds are definitely not the solution for everything, but they make sense when you have multiple people interested in maintaining large sets of ebuilds. If nothing else, they make life easier for bug wranglers, especially when you have 2 maintainers. You read my comment the wrong way (or I wrote it too hastily to be understood). I mean I don't see the need to split sysadmin herd in three or more. Sure there is stuff in sysadmin that I don't care about because I don't use, but nothing forces me to maintain all of it. And if nobody cares about I'm perfectly fine to mark it as m-n. But I don't see the point in saying well, nobody cares about nagios but two people, so we're moving it to a nagios herd. Might as well just use the two maintainers there, then. Yes I know I haven't been active at all. My time management is terrible and even after meeting Tom Limoncelli in person I doubt I'll magically start getting better at it, but I'll try to work on it.
Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
On Fri, Nov 8, 2013 at 5:22 AM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. If made not to depend means bundle, is the bundled version any safer than the ebuild there? If the answer is no, you're now increasing the security issue. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Perfect. Seriously? Perfect because one person agrees with you? Sigh. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
As Michał said. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Sep 20, 2013 at 7:52 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-20, o godz. 19:58:51 Justin (jlec) j...@gentoo.org napisał(a): what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. Not worth the effort, and definitely not worth the confusion it will introduce (why there's FEATURES=strip here? does it install weird executables under some circumstances? did it so in the past and someone forgot to drop it?). In other words, it's awful overuse of RESTRICT for pseudo-optimization. RESTRICT is to restrict features when the package can't handle it. It's not for skipping no-ops in the name of supposed performance gain. If you really want to play like this, show us some benchmarks. Prove that it gains anything. Because as far as I can see, this is nowhere near a bottleneck for ebuild installs. Unless you can prove it's a real gain, a strong 'don't do it' from me. -- Best regards, Michał Górny
Re: [gentoo-dev] rfc: escape sequences in logs
On Mon, Sep 2, 2013 at 8:21 PM, William Hubbs willi...@gentoo.org wrote: mgorny says many people benefit from having escape codes in log files, but I see no benefit from it, and I don't like going through build.log because of them. If you load a build.log into an editor, the escape sequences are basically trash characters that get in the way. You do know that many eclasses (including the Ruby ones) have a setting that enables/disable color output? I keep it enabled on my system but I've always been disabling it for tinderboxes.. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] New license: Adaptec
On Thu, Aug 29, 2013 at 7:20 PM, Tiziano Müller dev-z...@gentoo.org wrote: good point, will go for ADAPTEC then instead Please don't. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: check-reqs* vs CFLAGS=-g
Unlikely you screwed up, -O0 makes bigger code than -O2 almost in every case; then -g annotates it. I'm expecting -ggdb to take some few GBs more. It'll be the same if not worse with almost all software, -g3 would make it even worse. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Aug 2, 2013 at 9:05 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-02, o godz. 02:07:18 Duncan 1i5t5.dun...@cox.net napisał(a): Michał Górny posted on Thu, 01 Aug 2013 13:33:48 +0200 as excerpted: LLVM has peek build space consumption around: - 400-550M without clang (depending on targets), - 950-1200M with clang, - 16G with clang USE=debug (assertions, checks). Ouch! Thanks for the heads-up. I didn't realize -g/debug added THAT much! For sure I'll have to keep that in mind if I ever decide to build llvm with debug... and the general rule in mind for building anything else with debug. Just to make it clear, USE=debug doesn't imply -g. It gets 16G with -O2. Curious enough, -O0 -g gave me 14G but maybe I screwed something up :). -- Best regards, Michał Górny
Re: [gentoo-dev] check-reqs* vs CFLAGS=-g
On Fri, Aug 2, 2013 at 1:08 PM, Andreas K. Huettel dilfri...@gentoo.orgwrote: I thought -O0 was generally discouraged, even for debugging?! As Michał said, it all depends on what you want to debug. I would say that for 90% of issues you *do not* want to use -O0. Your code might not even compile (libav for instance used to rely heavily in the DCE pass being executed, GCC disables DCE at -O0), and even if it, you're now given a different program altogether, so if you're looking for a crash, it might magically disappear (memory areas get cleared out at -O0 but they might be re-used without clearing at any other -O level). But if you're trying to step through an algorithm, an optimized version of the code will most likely reorder the code that you read from the sources. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
Because it would require us to change a whole load more than just the targets variable. Plus we actually were the first coming up with the solution... Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Sun, Jul 28, 2013 at 5:22 PM, Brian Dolbec dol...@gentoo.org wrote: On Sun, 2013-07-28 at 13:33 +0200, Dirkjan Ochtman wrote: On Sun, Jul 28, 2013 at 12:50 PM, Leho Kraav l...@kraav.com wrote: Wondering if there's any plan for proper convergence at some point? I'd guess that the value of further convergence is so small that it will not be a priority for any of the teams. Cheers, Dirkjan Ruby team has been very vocal about NOT changing it's way in the past.
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
Does this still allow me to use libav? If not I'd like to veto it. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Jul 26, 2013 at 5:22 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Currently USE=system-ffmpeg is masked for stable www-client/chromium ebuilds. However, recently a new enough media-libs/ffmpeg has been stabilized, making it possible to use system ffmpeg in stable. I'd like to make the change close to a new version of chromium being stabilized so that less rebuilds would be triggered. Here is how the dependency looks like: system-ffmpeg? ( || ( =media-video/ffmpeg-1.0:=[opus] =media-video/libav-9.5:=[opus] ) ) I know there are some controversies around ffmpeg/libav, and I wouldn't like to go into that. I prefer to ask first and have a discussion before rather than surprising people badly. Please let me know what you think about this idea (unmasking USE=system-ffmpeg for stable chromium ebuilds). Paweł
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
If you can start it I can try to get the stable tinderbox running over the weekend. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Jul 26, 2013 at 5:56 PM, Tomáš Chvátal tomas.chva...@gmail.comwrote: 2013/7/26 Diego Elio Pettenò flamee...@flameeyes.eu Does this still allow me to use libav? If not I'd like to veto it. You can use testing version. Stable is too old, be happy I fixed all those buildcrashes so we can have it in testing. If you want start some tracker to get it stable tho, i would not mind, as all my machines have it unmasked anyway. Tom
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 22/07/2013 01:50, hasufell wrote: It does not apply, because we still support it officially in our main tree as a distribution, no matter if it's p.masked or not. No we don't. P.masked software is *explicitly* not supported. Anyway... if people disagree, then it doesn't make much sense to remove it. Otherwise it will pop up in the tree sooner or later again. Which is a perfect reason to keep it p.maske din tree so that nobody can re-introduce it as they felt it missing. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Packages up for grabs
On 21/07/2013 10:10, Pacho Ramos wrote: media-gfx/iscan-data media-gfx/iscan I'll pick up these two (soon as my laptop gets back working).. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On Sun, Jul 21, 2013 at 11:16 PM, hasufell hasuf...@gentoo.org wrote: pros: - consistency of tree quality - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree - less bugs no one can do anything about - easier contribution of users in an overlay, testing of hacks or other stuff to make it work - making clear that gentoo does not support software with such low QA - making clear that this software is experimental Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe even more than half. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree
On 21/07/2013 23:38, hasufell wrote: - consistency of tree quality does not apply to p.mask'd packages p.mask says that the package is in _bad_ quality, explicitly, and you can say how, so does not apply are not really the words I'd use. - less user confusion (the checksum failures alone get us a lot of bugs every release without people realizing what it means...) and people expect packages to work in the tree maybe Not p.masked packages they don't. Just state it outright, maybe even fetch-restrict the package and warn them... - less bugs no one can do anything about does not apply *How* does making it into a semi-official one-purpose overlay reduce the number of bugs users report? Either you're banning it into a non-Gentoo-owned overlay, or you're just betting they would get the reason why it's not in an overlay, same applies to p.mask. - easier contribution of users in an overlay, testing of hacks or other stuff to make it work does not apply I'm afraid I have to agree with Michael here. Proxies would do that, and users are still free to experiment with overlaid version, I don't see how this makes much of a difference. - making clear that gentoo does not support software with such low QA does not apply It applies perfectly. It's a p.mask for a reason, and can convey reasons. It's your package, do what you want, but stop just trying to force your views into suggestions, just because you already reached your conclusion, please. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Running tests using virtualx.eclass should be allowed to be forced to run in virtual X always
On Fri, Jul 19, 2013 at 7:50 AM, Pacho Ramos pa...@gentoo.org wrote: Wouldn't be better to make that tests *always* use virtual X? As Patrick said, yes, if they don't they are broken. Especially so if Xvfb does not represent a modern X anymore, as that would mean that tests will behave differently depending on where you launch them. And non-deterministic tests are stupid, useless, broken tests. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Running tests using virtualx.eclass should be allowed to be forced to run in virtual X always
On Fri, Jul 19, 2013 at 1:20 PM, Fabio Erculiani lx...@gentoo.org wrote: Even though there is that 1% of cases in where you want to have non-deterministic tests. For instance, if you want to run the same test thousands of times and randomly pick an initial state to see if you spot a scenario in where you have problems (concurrency problems)... :-) Not during packaging. Those are developer tests. Yes there are difference between the two. But as Ian said, we're off-topic now ;) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] new category: games-adventure/
I would object... 10 games are wa too few for a new category and especially pkg moves..
Re: [gentoo-dev] new category: games-adventure/
And? Two wrongs don't make a right. And I've said the same for any other proposed category like that.
Re: [gentoo-dev] new category: games-adventure/
On 14/07/2013 18:26, Peter Stuge wrote: I don't think anyone can dispute that there exists a genre called adventure games.. How comes scummvm is not in the list then? Just saying. Seriously, a category for 10 games is *not* a good idea. There is at least one (scummvm) who could fit there. Not sure if we have rainslick still in tree but it would fit as well. Maybe consider adding a few more, and if we reach the 20 games I wouldn't object. But 10 are way too few, and a roguelike would *not* fit in the genre to begin with. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] new category: games-adventure/
On 14/07/2013 18:42, Peter Stuge wrote: I bet you a tasty beverage that it will grow over time! :) I don't believe in the future until I can see it. I'm pretty sure that's the same thing that they said about app-antivirus at some point (can somebody _kill_ that category please?!) So your number is 20. My number and the number of at least one other is lower. Yes, but unlike you, I'm a developer that needs to pick up the pieces. and a roguelike would *not* fit in the genre to begin with. Says you, while I and at least one other say that such a game does have strong focus on adventure/exploration. So either Matt is right or you should really refrain to posting without having a clue about what is being discussed. **We have a frigging games-roguelike category!** -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Gentoo Hangouts
On Mon, Jun 24, 2013 at 5:52 AM, Norman Rieß nor...@smash-net.org wrote: I do not see the benefit either, it seems like that kind of thing the PR department would come up with, which noone does actually like doing and everyone is glad when it's over and can go back to work. I honestly wonder if Pavlos ever tried having regular meetings over VC. I've worked on a VC system most of last year and I now go through regular conferences... it's barely okay from a work point of view, it takes lots of time to organize so you don't want to do that every single day for sure. And unlike IRC meetings, you can cannot multitask, say making your dinner while discussing this or that feature. A VC is a full commitment, and its attractiveness is often much higher _before_ you use it.. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Gentoo Hangouts
Pavlos, I understand what you mean, I'm just saying that organizing a real video conference takes its toil. And just opening a webcam and talking is just going to give an amateurish feeling that could be more detrimental than not. Can you please tell us if you have _any_ experience at all with VCing or just thought that it looks cool? Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Mon, Jun 24, 2013 at 11:24 AM, Pavlos Ratis daster...@gentoo.org wrote: On Mon, Jun 24, 2013 at 11:14 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Mon, Jun 24, 2013 at 5:52 AM, Norman Rieß nor...@smash-net.org wrote: I do not see the benefit either, it seems like that kind of thing the PR department would come up with, which noone does actually like doing and everyone is glad when it's over and can go back to work. I honestly wonder if Pavlos ever tried having regular meetings over VC. I've worked on a VC system most of last year and I now go through regular conferences... it's barely okay from a work point of view, it takes lots of time to organize so you don't want to do that every single day for sure. And unlike IRC meetings, you can cannot multitask, say making your dinner while discussing this or that feature. A VC is a full commitment, and its attractiveness is often much higher _before_ you use it.. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ Maybe you misunderstood my proposal, I totally agree with you about IRC meetings. I didn't propose video calls as a full replacement for IRC meetings. Also, I've never said to use video calls every single day. These team video calls would be good to exist for different reasons. These video calls are going to promote Gentoo, our team efforts and could be useful to our users and those who want to contribute. As I said before, it is optional, a team maybe choose not to do any video call, a team could do *only one* video call and stop or a team could do frequent video calls. It's up to the team to decide.
Re: [gentoo-dev] Introduce global dmalloc USE flag?
On Mon, Jun 24, 2013 at 11:37 AM, Gilles Dartiguelongue e...@gentoo.orgwrote: To be clear, the justification of USE=dmalloc being separated from USE=debug is that it is so intrusive than anyone excepts a developer would find it too cumbersome to attempt to debug a problem with the application ? I think we already got a number of packages where that holds true. It was one of the reasons why I did my best to make sure people understand that debug symbols and nostrip should *not* be conflated with USE=debug. If I'm not mistaken, app-editors/nano[debug] is hardly usable. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Gentoo Hangouts
On Mon, Jun 24, 2013 at 4:43 PM, Tobias Klausmann klaus...@gentoo.orgwrote: It depends how you run it. We have teams having a video thing open during the day with there geographically-diverse other team members and it works well for them. For those teams, it also improves cohesion. Geographically-diverse teams always have to actively fight the us-vs-them vibe that seems to be fundamental human nature. Aforementioned video link is part of that. Sure, but first of all these are private meetings, and not public ones. Even more, they are meetings private to the company, and not even with customers. You can tell that the response to a public vs private meeting is definitely different. I've witnessed before people trying go show off even more just because a camera is involved, which can be obnoxious, in my opinion. And unlike IRC meetings, you can cannot multitask, say making your dinner while discussing this or that feature. As others have pointed out, this is a double edged sword: Sometimes, having less distraction (or getting away with less distraction) is a Good Thing. Yeah sure if you can afford it. One thing that people seem to miss is that Gentoo is _not_ an employment. And while we'd like to keep professional behaviour, the system of incentives and disincentives that work for an employment position do not apply to organizations like Gentoo. A VC is a full commitment, and its attractiveness is often much higher _before_ you use it.. This does not hold true for me. I'd never used VC before joining my current company, and I love it -- iff the alternative is not meeting at all or text-only. As I pointed out above, it is crucial for team cohesion. Sure and in some ways it's a least worst option. On the other hand you and I both know that it's not as easy as saying okay let's all meet at 7 — timezones, hardware issues, connection issues, you name it. We sidestep most of these issues as the various problems have been ironed out before.. but to start doing regular hangouts between Gentoo teams? It's going to involve lots of work. If you want to have a distincly productive meeting, you need an agenda/goals and someone to _run_ the meeeting. But that is true of IRC meetings, too. About the only thing that IRC meetings are invariably better at, is logging. Note, however, that logging is no replacment for agendas or summarizing the outcome of the meeting. On the other hand, I would be _very_ much against using Hangouts for anything that involves decision-making or explanation of future planning, for the very reasons I originally pointed out: * they require too much time set aside (I can't even lurk a Hangout if I'm cooking, or working, or my phone only knows what); * they are not for everyone (English is not universal as we'd wish it is — if it wasn't for last year's experience, I wouldn't want speaking English in public; William also pointed out another reason); * I don't expect a great signal to noise, not only at the beginning but throughout: try to imagine an unmoderated IRC channel being spoken aloud, then add a bunch of can you hear/see me? from every other participant, the what did you say? I can't understand you and so on so forth. Honestly, I see as much potential to cause further issues in a team as there is to solve them.
Re: [gentoo-dev] Gentoo Hangouts
Please, let's not try to make this something either mandated or recommended. I have a personal dislike for video tutorials which tend to take half an hour to explain something you'd read in ten minutes. Besides, not all of the developers speak English well enough — heck some people have trouble writing and understanding written English, let alone spoken. Honestly, I couldn't get over reading a couple of paragraph here, because the premise itself is too much to bear for me, sorry. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Sun, Jun 23, 2013 at 10:30 PM, Pavlos Ratis daster...@gentoo.org wrote: Hello all, Everyday we talk to each other about different kind of things related to Gentoo. IRC and MLs are the primary way of our communication, but this is only a text-based communication. I think sometimes it would be better to escape from that. That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will be Google+ video Hangouts(video calls) held by teams or developers independent of a team. The main goal is to have the teams introduce themselves and discuss about different issues in their Gentoo-related projects. It's a very interactive way of communication and it helps team bonding. The first Hangout of a team would be good to include a short introduction of the team (what,who,where). Also team members will introduce themselves. Then team should start talking about how a user can contribute and what is going on in the team. Tips and tricks would be a plus and very useful to users. Finally, users will be able to ask questions at G+ and then team members will try to answer the most of these questions. Future team meetings could be also held via video hangouts or interviews like dabbot's doing in his personal blog. In addition, developers independent of the team could organize a hangout along with other developers to discuss different topics or to have a Gentoo-related chit-chat. Users could also participate into this video calls. It's very easy to decide the host of the talk. Maybe the team leads would be proper for that or someone from the PR. One of the major issues is the difference in timezone and the workload of each developer. However, I think it would be great to find 1 hour to participate. Teams could use a site like http://doodle.com to organize the Hangout and find an hour that fit to their schedule. Except from a camera and a microphone requirement is a Google account and www-client/google-talkplugin package which is already in the tree. It would be great to have teams introduce themselves and inform users in a more interactive way how to contribute and answer their questions. Finally as I said different other topics could be covered in this calls. All these video calls will be archived to a public Gentoo account in Youtube. I am looking forward to your feedback, your comments and of course for the first team that will create a video Hangout!! :) That's all folks, thanks for your time. Pavlos
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
Does this mean the QA lead finally gets to suspend people who are patently not suited for developing a stable distribution without asking devrel? Because last time we got into the same judge, jury, and executioner argument, which I guess was just sent for the gallows (pun intended). Mind, it's not like I disagree with at least one of the actions that you took recently, but given your surge approach I would like to point out that is not your task judging code quality, and yes that does make me uncomfortable, that you want to pick up the full power at once, and not collaborate with whom should have been involved in the process. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Wed, Jun 19, 2013 at 6:35 PM, Markos Chandras hwoar...@gentoo.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, It is unfortunate to observe constant bullying, insults and trolling across our public media. Developers have been warned over and over that such behaviour is not acceptable and they should try to behave properly. However, people have ignored such warnings for a very long time. This ends today. The DevRel policy states that: If the issue is deemed critical, the developer in question may have his or her access suspended while a vote takes place. In such situations, the Developer Relations lead may act without a vote of the remaining Developer Relations team; this power is granted by Council. Except in critical situations where immediate action is required, such disciplinary action is determined by members of the Developer Relations project.[1] For me, this problem is critical. Devrel is working on formalizing a new policy, and we will announce news on this soon. In the meantime, to prevent further escalations, I will use my lead powers to request immediate bans whenever I see one of you violate the CoC[2] and ignore the previous warnings. My fellow developers, it's time you finally realize that you are part of a community and you must learn to behave and respect each other even if you have different technical views. We are all people sharing a common interest: Gentoo. [1] http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2 [2] http://www.gentoo.org/proj/en/council/coc.xml - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRwev1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88CgkQAMPF0Uf8r92+ne4D1CghUQKC ujo2B9UDBx6jOs//XZ6A+az2bWQdBUm+ca6v755VasVMnDmcfHM+0+ibqtPcVMaK XHUMZhkgok9KlWptKqJOdSLlInY2KhHmA0jjktUyByIILgMKcqlL5pVd/jUN6bXU y54nDCgne4zx0fiK0QGV6hzRqCn9RFtxTsW4qIoxRIaM7oME0Zm6LmdFJrFLhpPC 9N9JDuxKdKgmN4njT3sNDa2dQD/InZm+k2ZejLFWZqmlvbo54xQTA2YvjrRa+jTr yJjLTiKvt7pZLZrF7QlzvQULR2966Jlh3wdXhDJRrvvIFgWCZCW7x1VatnLde+z0 fM5cAuBWCVHyKFJUJXlgvzPJVTmBD4mjJUzhI9Co6eJbkauZ1VKzlHzDZPsdDgrw DmuXUfSsll+1tIg8Mjq0CAO8jqvTMQKbdcrthMAvcpWw8FKa+HIddFa60H0sKeXH TmXUPLP+7RwgLIoMtTelrpb5yoJsNeFG9Hlhwhn6Sh68ItYKkeg7Qopi8IhpdmKR x3mrWXXY1k4SdChhQ4vgiQLOGA7KJquZQJ43i1phe7RGvsXHBU9M65/IHNkWxODE ZdwS20di9WoIulvep9P3b0wHsY/zL4HLmQEjPsqriGScZdJM/bcIpu1Dn34ZgXhy 6NvYvqpCfyoXN757mwOs =2cCK -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On 17/06/2013 06:55, Mike Frysinger wrote: tar -xJf ./$i why doesn't the bzip2 detect as bzip2 ? Capital J is XZ not bzip2.. still, it makes me think it needs a newer version of file to recognize it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On 17/06/2013 17:54, Rick Zero_Chaos Farina wrote: I make all my files with tar cJf zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data cJ with _current_ tar will generate XZ cJ with _past_ tar could generate lzma xJ with _current_ tar will extract both XZ and lzma zJ with _past_ tar will only extract lzma -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
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] SRC_URI behaviour
On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.namewrote: 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 Over my dead CVS access. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 1:12 PM, Rich Freeman ri...@gentoo.org wrote: Grandstanding aside, it is probably best to take this in chunks. I just don't care to repeat for the Nth time the same reasoning for which I don't want to mainstream VCS fetching. It's just not going to happen as long as I got CVS access, it's not a threat or a grandstanding, it's a simple boolean logic statement. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 13:48, Alexander V Vershilov wrote: Can you elaborate: do you object both proposals (about partial restrict and VCS-support) or only second one (VCS-support)? As I already said in my answer to Rich, the VCS support is XOR'd with my CVS access. And I've already spent too much time on it again, so don't expect further mail from me on the topic. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:06, Rich Freeman wrote: At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it At work you're also paid to for the time you spend justifying for the Nth time why a proposal is completely crazy and something that no sane people would accept. Nobody pays me to waste my time in explaining *again* why VCS ebuilds should be a corner case and not something to spend time making easier to create (because that's what it boils down to). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:11, Vadim A. Misbakh-Soloviov wrote: And I suggest you all (including Diego) to discuss about that, instead of oppositing vcs-related SRC_URI ;) Then next time don't collapse two widely different proposals, especially considering that one of the two has been already discussed to death. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:34, Ulrich Mueller wrote: restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:47, Ulrich Mueller wrote:
Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
apply to all of SRC_URI (as it is now) and use the new syntax to
specify any exceptions from the restriction.
WFM
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Calling die in a subshell
On 15/06/2013 17:06, Mike Gilbert wrote: Are there any objections to removing this warning from the devmanual? Please, go for it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Calling die in a subshell
On 15/06/2013 17:19, hasufell wrote: How does that make any sense? It does not, but I don't remember anybody trying to assert that PMS makes sense in quite a long time. (Yes I still think that the PMS is 90% a waste of time) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:17, Diego Elio Pettenò wrote: You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. Oh wait, I already know how that's going to happen.. bug #443448 is a nice example. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:21, Michael Weber wrote: Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. See, I cannot exactly voice what my opinion of you is on a public forum, or I would have done so. Maybe you should think twice about what _you_ have been doing, rather than worrying about my social skills. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On Mon, Jun 10, 2013 at 1:36 PM, Sergey Popov pinkb...@gentoo.org wrote: 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? Yes, there is something wrong with it... it's called 'gorg'. Or to put it differently, I can see why Infra would like to kill it.
Re: [gentoo-dev] devmanual moved to github
On 12/05/2013 14:27, Peter Stuge wrote: I feel strongly against github. Making something like github the primary point of contact communicates many negative things for Gentoo IMO. Oh heavens, for once I agree with Peter. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: GCC USE flag changes
On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new eclass: systemd-next.eclass
It's happening that we seem to have a bunch of crybabies in Gentoo that don't get along together and instead of figuring out their differences are going to screw up users even more. Bunch of chipmunks in our ranks as well I suppose. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Sat, Apr 13, 2013 at 10:15 PM, Rich Freeman ri...@gentoo.org wrote: On Sat, Apr 13, 2013 at 3:43 PM, William Hubbs willi...@gentoo.org wrote: I am sending this out for review so we can commit it to the tree when we commit our alternate systemd ebuild in a few days. This will be set up so that users can choose which systemd package they want to install, and it will default to the current systemd package. Did I miss some kind of announcement for what is going on here? An additional implementation in portage along with an eclass probably is worth some kind of intro on-list. I don't think you need to seek approval/etc, but it would be nice to know what your goals/etc are. Is this just a different installation/configuration approach, or is this some kind of upstream fork? Rich
