[01:07] <broder> spock:~/patches.ubuntu.com broder$ grep -l -r -e '-U_FORTIFY_SOURCE' -e '-D_FORTIFY_SOURCE=0' .  | wc -l
[01:07] <broder> 18
[01:07] <broder> i wonder how many of those honestly really and truly need fortification turned off
[01:08] <micahg> 18 isn't such a bad number
[01:08] <micahg> but in a lot of cases, I'd guess it's in the rules file and not a patch
[01:08] <broder> that should show up on patches.ubuntu.com, right?
[01:08] <broder> i thought that was debdiffs between our package and the debian merge base
[01:10] <broder> hmm, ok. well, the first one i looked at (scheme2c) built successfully but failed with a fortification error running the test suite. that seems like it could be legitimate
[01:12] <broder> ...and kees disabled fortification on the second one (sysklogd)
[01:12] <micahg> broder: might not be a diff :)
[01:13] <broder> haha. fair enough. i suppose i could just grep my lintian lab
[01:13] <broder> or wait until kees gets hardening-check merged into lintian
[01:14] <kees> sysklogd is a craaaazy one
[01:15] <kees> fwiw, anything that is disabling hardening is supposed to have a) a bug open, and b) a line with details in https://wiki.ubuntu.com/ToolChain/CompilerFlags
[01:16] <kees> e.g. https://wiki.ubuntu.com/ToolChain/CompilerFlags#sysklogd https://wiki.ubuntu.com/ToolChain/CompilerFlags#scheme2c
[01:16] <kees> broder, micahg: ^^
[01:16] <broder> kees: ah, cool. i got curious about this when i was reviewing a merge for cdebootstrap
[01:16] <broder> where -U_FORTIFY_SOURCE was used as a bad way of expressing -Wno-warn=unused-result
[01:16] <kees> eeeeeew
[01:16] <broder> yeah
[01:17] <broder> (this is an old patch - not the merger's fault)
[01:17] <micahg> kees: cool, I"ve seen several uploads disabling this, so now I know where to check to make sure they're being tracked
[01:18] <kees> micahg: yeah, I've tried to catch them in the past, but I forgot to subscribe to oneiric-changes (and now precise-changes) until the bulk of stuff went in. I wish those lists would auto-sub everyone
[01:18] <micahg> kees: FWIW, you can download an archive of it
[01:19] <kees> micahg: right, that's what I usually do once I realize I forgot to subscribe. :)
[01:19] <kees> but I have procmail rules set up to toss anything with "fortify" in it into my inbox so I'd see it right away.
[01:20] <kees> but yeah, hopefully there will be more auto-nagging happening once lintian gains some smarts about this. I've got a fair bit of work left on that front, though.
[01:21] <broder> it sounded like niels was largely receptive
[01:21] <broder> though i guess the arch-dependent stuff will probably be annoying
[01:39] <kees> broder: yeah, for once, my hurdles are technical. :)
[01:39] <broder> hehe
[01:39] <micahg> broder: is there any reason why there can't be a lintian-arch package?
[01:40] <broder> micahg: it'd be a bit unfortunate. right now i can run lintian on packages of any architecture
[01:41] <broder> (lintian.uw.o actually scans both amd64 and i386 packages now, not that you can tell because that information doesn't show up in the html report anywhere)
[01:42] <broder> i'd vaguely like to add armel, armhf, and powerpc at some point
[01:42] <micahg> broder: it might be possible to use the arch specific package on any other arch (multiarch FTW) if it's only needed for generation
[01:44] <broder> possibly, although wouldn't we know at build-time the arch-specific information? seems silly to do 5 builds as a mechanism to sort out information we already know
[01:45] <micahg> broder: no idea :)
[01:48] <broder> kees: ^?
[01:48] <broder> you were planning to code in all of the arch-specific information, right?
[05:14] <broder> geez. i want to revoke freeimage's upstream's right to write makefiles
[05:18] <broder> evan@caron:~/src/freeimage/freeimage$ perl -ne 'BEGIN{$max_len = 0;} END {print $max_len."\n";} $max_len = $max_len < length() ? length() : $max_len;' Makefile.srcs.OTHER
[05:18] <broder> 10195
[05:18] <broder> their makefile lists every source file on a single line!
[05:28] <kees> O_o
[05:29] <broder> it makes merging........extraordinarily painful
[05:55] <EvilResistance> broder:  ouch, that sounds terrible!
[06:14] <broder> it's a mess. i've at least gotten something to compile now, though it still doesn't link
[06:19] <broder> ah, hopefully it's just because oneiric didn't transition to libjpeg8
[06:35] <EvilResistance> bah i forgot the syntax for the backport package thing
[06:39] <broder> EvilResistance: try backportpackage --help or the manpage
[06:40] <EvilResistance> thanks
[06:45] <EvilResistance> hey broder, can you help be diagnose an upload failure to a ppa for backporting using backportpackage?
[06:45] <broder> EvilResistance: sure. pastebin the failure?
[06:46] <EvilResistance> it went through everything... except this step:
[06:46] <EvilResistance>   Uploading php5_5.3.8.0-1ubuntu2~lucid1~ppa1_source.changes: 3k/4k550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
[06:46] <EvilResistance> that's the error
[06:46] <EvilResistance> any idea what the heck is happening here?
[06:46] <broder> ah, yeah, that's not actually an error
[06:46] <broder> it's an lp bug
[06:47] <broder> the upload actually succeeded
[06:47] <broder> you should get mail about it momentarily
[06:47] <broder> bug #798957
[06:48] <EvilResistance> here's the full output: http://pastebin.com/SuXH9PfG
[06:48] <EvilResistance> oh really?
[06:48] <EvilResistance> (btw lag spike)
[06:49] <EvilResistance> huh
[06:50] <EvilResistance> yep that worked...
[06:50] <EvilResistance> (and yes, its another Precise backport xD)
[06:50] <EvilResistance> but thankfully *not* one i'm going to actually submit for official backporting :P
[06:51] <micahg> EvilResistance: yeah, you'd run into some issues with that :) >100 rdepends
[06:51] <EvilResistance> mhm
[07:01] <EvilResistance> micahg:  i *did* notice that my Backports PPA did take into account that swig2.0 *was* backported from Oneiric to Natty :P
[07:01] <EvilResistance> as i had requested ;P
[07:02] <micahg> EvilResistance: yes, that's built
[07:18] <EvilResistance> micahg:  who do i bug to cancel a dep-wait'd build?
[07:19] <micahg> EvilResistance: why would you want to cancel it as opposed to fixing the dep-wait (unless you have to reupload, which will supersede the depwait build)
[07:20] <EvilResistance> micahg:  because https://launchpadlibrarian.net/86583318/buildlog_ubuntu-lucid-i386.php5_5.3.8.0-1ubuntu2~lucid1~ppa1_MANUALDEPWAIT.txt.gz
[07:20] <EvilResistance> take a look at what's missing
[07:20] <EvilResistance> like, literally *missing*
[07:21] <micahg> heh, that seems like a bug in packaging almost...
[07:21] <micahg> EvilResistance: fix it and upload a new version, it'll supersede it
[07:21] <EvilResistance> yeeeah
[07:21] <EvilResistance> i'm not in the mood to :P
[07:21] <EvilResistance> MTecknology:  you do it xD
[07:22] <micahg> EvilResistance: it'll only retry if it detects the depwait fixed I think, so not to worry
[07:22] <EvilResistance> can i cancel the amd64 one though
[07:22] <EvilResistance> which hasnt started?
[07:23] <micahg> EvilResistance: if you don't have the option on the page, then no, it's not really worth bothering someone for it sidnce it's a 2 minute or less buil
[07:27] <MTecknology> EvilResistance: do what?
[09:43] <tumbleweed> Laney: import complete, merged.tar.gz is updated
[09:45] <tumbleweed> (don't forget to merge my git branch)
[09:58] <Laney> url?
[09:58] <Laney> to the tarball
[10:01] <tumbleweed> http://people.ubuntuwire.org/~stefanor/merged.tar.gz
[10:01] <Laney> merci
[10:02] <Laney> tar cjvf ubuntu-changes-difficult-teenage-years.bz2 ubuntu-changes
[10:02] <tumbleweed> heh
[10:05] <Laney> ImportError: No module named dateutil.parser
[10:05] <Laney> nooooooooooo!
[10:06] <Laney> how essential is that? i am loathe to bother dsa again
[10:07] <tumbleweed> it's the only way to parse times with timezones
[10:07] <tumbleweed> but you can hack around it locally with PYTHONPATH until dsa install it
[10:08] <tumbleweed> dateutil has no other dependencies, and is pure-python...
[10:09] <Laney> arkle, ok, in a bit
[10:21] <Laney> importing
[10:26] <Laney> epic fail
[10:28] <Laney> Closes: 282717 143536 281671 281672 271232 258698 210932 237109 233980 228298 225936 223579 221483 43538 100330 161947 205608 221483 221148 220275 219621 219336 217533 206559 203280 204790 205606 202189 190886 120704 171163 169501 161020 147408 144165 111752 111752 115200 113621 110563 98974 98974 98986 98670 98672 63012 70142 72075 85809 88108 95447 96149 91315 80561 87687 54740; urgency=medium 25193; urgency=low
[10:28] <Laney> ?!?!?!?!??!?!?!
[10:30] <Laney> oh, I remember
[10:38] <tumbleweed> lol
[10:39] <Laney> I remember → ignored 2005 from LP last time
[10:40] <Laney> doesn't explain how it got in there :P
[11:52] <tumbleweed> Laney: looks like two issues:
[11:53] <tumbleweed> dpkg-parsechangelog's --since looks for that exact version, not <=
[11:55] <tumbleweed> and this entry: autoconf (2.13-17) unstable; closes=54740; urgency=medium
[11:57] <Laney> wow, was that valid?
[11:58]  * tumbleweed doesn't know BTS history, it's from 2000
[11:59] <tumbleweed> http://lists.debian.org/debian-devel/1999/01/msg02650.html
[11:59] <tumbleweed> doesn't look like it
[12:01] <tumbleweed> thing is, we probably have too much data in the Closes lines
[12:02] <tumbleweed> I don't think I want to do another full import quite yet
[12:02] <Laney> ffs
[12:02] <Laney> SELECT DISTINCT signed_by_name from ubuntu_upload_history where signed_by_name like '%<N/A>%';
[12:04] <tumbleweed> that's not too bad
[12:04]  * tumbleweed wonders how Piotr is signing uploads for Ubuntu
[12:05] <tumbleweed> oh, I see
[12:10] <Laney> oh
[12:10] <Laney>           if current['Signed-By'].find('@') != -1:
[12:10] <Laney>             current['Signed-By_name'], current['Signed-By_email'] = aux.parse_email(current['Signed-By'])
[12:10] <Laney>           else:
[12:10] <Laney>             current['Signed-By_name'] = current['Signed-By']
[12:10] <Laney>             current['Signed-By_email'] = ''
[12:22] <tumbleweed> Laney: grumble, finding a bunch of problems here
[12:22] <tumbleweed> we're donig version comparison with strings...
[12:23] <Laney> yeah that sounds like a bad idea
[12:25] <jtaylor> hm we should remove psyco from precise, it only works with python 2.6
[12:26] <tumbleweed> jtaylor: please
[12:26] <jtaylor> requries blacklisting or?
[12:28] <tumbleweed> not entirely sure what the best answer there is. There's an RFA bug for it in Debian that says "maybe the package should be removed from Debian altogether"
[12:28] <tumbleweed> so maybe it'll go away
[12:30] <tumbleweed> Laney: also doesn't look like we have superseded spph entries in ancient releases
[12:31] <jtaylor> hm yes debian will probably remove it before wheezy, I'll check up on it if it was not done before precise release
[12:31] <tumbleweed> it's not in wheezy
[12:31] <jtaylor> ah
[12:33] <Laney> what goes wrong if we remove status="Superseded"?
[12:33] <tumbleweed> slows down
[12:33] <tumbleweed> that was a performance hack
[12:33] <Laney> would it be that much worse?
[12:34] <tumbleweed> naah, screw lp
[12:34] <Laney> doesn't feel like it would pick up /that/ many more spphs
[12:34] <Laney> most should be superseded anyway
[12:35] <tumbleweed> yup
[12:42] <Laney> let's see if those changes work
[12:52] <tumbleweed> ok, so why does POX turn up as a signer
[12:52]  * tumbleweed goes digging
[12:55] <Laney> no more <N/A> in signed_by_name
[12:56] <Laney> http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=Micah+Gersten&sponsoree_search=name looks better
[12:58] <tumbleweed> um, distribution=unstable in upload history?
[12:59] <Laney> syncs
[12:59] <tumbleweed> right, but we want the target distribution, surely?
[12:59] <tumbleweed> that I can actually fix up quite easily without re-importing
[13:00] <Laney> probably. it uses the changelog currently
[13:01] <tumbleweed> :/ it's so hard to find problems in the data until you start playing with it...
[13:02]  * tumbleweed needs a zsed
[13:06] <Laney> used to have some code to construct the distribution, but it  must have been before the initial commit :(
[13:22] <tumbleweed> heh, jaunty has zodb 1:3.6.0-4, edgy had 3.6.0-4
[13:22] <tumbleweed> recipe for changelog confusion
[13:23] <Laney> good job those debs weren't in the archive at the same time
[13:23] <tumbleweed> looks like even the changelogs in the librarian got messed up by that
[13:26] <tumbleweed> looks like we need some de-duplication of Launchpad-Bugs-Fixed. Look at kernel uploads
[13:28] <Laney> how did they get there?
[13:29] <tumbleweed> haven't got that far yet
[13:32] <Laney> pushed spph distribution usage
[13:33] <tumbleweed> ok, manually fixed that up
[13:33] <Laney> how did you map back?
[13:33] <tumbleweed> because I had improted each release into a separate directory
[13:33] <Laney> oh you cunning fox
[13:34] <tumbleweed> new merged.tar.gz published
[13:34] <Laney> i'll start a reimport and then i have to go do some christmas shopping
[13:34] <tumbleweed> you just freaked me out. That's not something I want to be thinking about, yet
[13:35] <Laney> last night I had a dream that it was December 24th and I hadn't got any presents yet
[13:35] <Laney> taking that as a sign from my subconscious
[13:37] <Laney> ok then, reimporting
[13:37] <Laney> ttyl
[13:48] <tumbleweed> Laney: so, POX is the package_creator of sqlalchemy 0.2.8-1 in the SPPH (it's a sync, in edgy) https://api.launchpad.net/devel/ubuntu/+archive/primary/+sourcepub/134477
[13:53] <tumbleweed> Laney: and nobody is the creator or signer of https://api.launchpad.net/devel/ubuntu/+archive/primary/+sourcepub/1835055 (which is an early native-sync)
[13:54] <tumbleweed> generating 11 lines of text for each upload shouldn't be so rediculously error-prone
[14:52] <l3on> Hi all, someone could help to figure out if NO_PKG_MANGLE is still mandatory with cdebootstrap ?
[14:52] <l3on> I found this bug debian 486899
[14:53] <l3on> and I'm building without NO_PKG_MANGLE..
[14:53] <l3on> what should I look for ?
[14:53] <tumbleweed> didn't we discuss this a while ago?
[14:58] <l3on> tumbleweed, yes... but the discussion was only "Hey l3on, you forgot to add NO_PKG_MANGLE" :D
[14:58] <l3on> so, I don't know what reply in the bug
[14:59] <tumbleweed> well, after the last message in that bug, do you really think the maintainer has changed his mind?
[15:00] <l3on> tumbleweed, no but it's a 2008 msg...  :)
[15:01] <tumbleweed> you can try, I guess, but I expect no reply or a NACK
[15:02] <l3on> tumbleweed, wait... problem here is that Felix was asking me to figure out if NO_PKG_MANGLE is still necessary ...
[15:03] <l3on> and I would like to know how to reply him :)
[15:03] <tumbleweed> l3on: I can't answer that, I don't know enough about pkgbinarymangler.
[15:03] <l3on> I'm building cdeboostrap without that, and then I should check mangle packages, but... what do I have to look for ?
[15:04] <l3on> ah ok :)
[15:04] <l3on> in any case, thanks :)
[15:05] <l3on> ah tumbleweed other thing... :P
[15:05] <l3on> Should we prefer "-Wno-warn=unused-result" o "-Wno-error=unused-result"
[15:05] <l3on> ?
[15:06] <tumbleweed> no-error, so that you can still see the warnings
[15:06] <l3on> oki :)
[15:10] <l3on> fabrice_sp, ping :)
[15:25] <effie_jayx> hello all,
[15:26] <effie_jayx> can anyone give me some advise on how packaging separate branding for an app like firefox works?
[16:08] <JanC> effie_jayx: I think that depends highly on the application itself (how easy does the application make this?)
[16:09] <JanC> also, hi, long time since we chatted last time, I think  ☺
[16:09] <effie_jayx> JanC hey :)
[16:09] <effie_jayx> JanC: well I did mention about firefox, kinda hoping any mozilla ubuntu ninja responded
[16:10] <JanC> I think Firefox has some infrastructure to make this reasonably easy
[16:10] <JanC> effie_jayx: you might also want to ask in #ubuntu-mozillateam then
[16:10] <effie_jayx> thanks JanC, won't be a stranger :)
[16:11] <JanC> but AFAIK Firefox allows you to put branding into one file with references and/or a separate directory or something
[16:12] <fabrice_sp> l3on, pong
[16:14] <l3on> fabrice_sp, hey... hi! It's about bug 884185... I don't know how to figure out if NO_PKG_MANGLE is still required... could you give me some input?
[16:16] <fabrice_sp> Hey l3on, I would build it with and without. What tool do you use to build packages?
[16:17] <JanC> effie_jayx: also, maybe some people in -locoteams can help (some of them make their own modified live/install CDs)
[16:17] <l3on> fabrice_sp, debomatic ..
[16:17] <effie_jayx> JanC: thanks
[16:18] <fabrice_sp> l3on, can you check if pkgbinarymangler is installed or not?
[16:18] <l3on> fabrice_sp, here you can find cdebootstrap with NO_PKG_MANGLE=1
[16:18] <l3on> http://debomatic.debian.net/precise/pool/cdebootstrap_0.5.8ubuntu1/
[16:18] <l3on> fabrice_sp, yes... pkgbinarymangle is installed
[16:19] <fabrice_sp> l3on, I can see that in the build log :-)
[16:19] <l3on> :)
[16:20] <l3on> fabrice_sp, let me know when I can upload the other version... (without NO_PLK_MANGLE)
[16:20] <fabrice_sp> l3on, why don't you just upload a 2.1 version to be able to compare both?
[16:20] <l3on> fabrice_sp, yes your' right :P
[16:21] <fabrice_sp> :-)
[16:29] <fabrice_sp> l3on, the problems that was fixed that was was with pkgstriptranslations (see https://launchpad.net/ubuntu/+source/cdebootstrap/0.3.15ubuntu1 ), so if it FTBFS without NO_PKG_MANGLE, that's it
[16:30] <l3on> eh ?!
[16:30] <tumbleweed> why was that a problem, though? cdebootstrap isn't main
[16:31] <fabrice_sp> yeah, I know
[16:31] <fabrice_sp> I assume it was FTBFS in feisty
[16:31] <fabrice_sp> that's why I think it's not useful anymore
[16:31] <l3on> well now it builds fine
[16:31] <tumbleweed> and the nested deb looks ok?
[16:32] <l3on> tumbleweed, I looked into and they present same files
[16:33] <fabrice_sp> with the same sizes?
[16:38] <l3on> I didn't check :/
[16:38] <l3on> Ok... here NO_PKG_MANGLE=1 enabled: http://debomatic.debian.net/precise/pool/cdebootstrap_0.5.8ubuntu1/
[16:39] <l3on> here NO_PKG_MANGLE dropped: http://debomatic.debian.net/precise/pool/cdebootstrap_0.5.8ubuntu2/
[16:40] <fabrice_sp> l3on, tks! I'm checking the files
[16:44] <l3on> broder, ping
[16:44] <l3on> fabrice_sp, you're welcome :)
[16:53] <fabrice_sp> l3on, seems identical. Did yo utest the package without NO_PKG_MANGLE ?
[16:53] <l3on> fabo, nu
[16:53] <l3on> ops... fabrice_sp nu
[17:24] <fabrice_sp> l3on, cdebootstrp-static works fine, so I think that NO_PKG_MANGLE can be dropped
[17:26] <l3on> fabrice_sp, thanks... I'll work on it :)
[17:26] <fabrice_sp> l3on, thank you to work on it!
[18:14] <jtokarchuk> howdy, I just submitted an app for mentorship, I have used ubuntu for a while but have now fully made the jump from Windows. Will take a little to get used to the programming environment of Linux, but excited to help out.
[18:14] <Laney> tumbleweed: ah, fun. I can live with it if the problem is Launchpad's, not ours.
[18:16] <tumbleweed> yeah, so take this data with a pinch of salt...
[18:16] <Laney> "it is what it is"
[18:17] <tumbleweed> "pull requests accepted"
[18:17] <tumbleweed> the massive lists of bugs come from the .changes files, so no point de-duplicating them
[18:18] <Laney> well, that's cheap to do isn't it?
[18:18] <Laney> list(set(foo))
[18:19] <tumbleweed> it is
[18:20] <Laney> I don't mind fixing problems with the data if it is clearly wrong and there is a relatively-non-hackish fix
[18:21] <Laney> but when LP just holds plain incorrect data I also don't mind living with it
[18:21] <Laney> basically we should make it as good as we can and no better
[18:24] <l3on> Daviey, ping
[18:28] <l3on> someone knows how I can check if xen_netback and xen_netback are built in for the server and generic-pae kernel in precise ?
[18:37] <broder> l3on, tumbleweed, fabrice_sp: for what it's worth, pkgbinarymangler does a bunch more things for real archive builds than PPA or local builds, so this may just not be possible to test easily
[18:37] <broder> ...i guess you might be able to create a /CurrentlyBuilding file that would fool it...
[18:40] <tumbleweed> Laney: committed
[18:42] <l3on> cjwatson, ping
[18:49] <Laney> tumbleweed: I already did that!
[18:50] <Laney> without sorted() though
[18:50] <tumbleweed> the curse of DVCS :P
[19:01] <Laney> merged
[19:01] <tumbleweed> ta
[19:01] <Laney> oops
[19:01] <Laney> mismerged :P
[19:01] <tumbleweed> indeed
[19:02] <Laney> who needs to test?
[19:02] <tumbleweed> I tested on a single record
[19:03] <tumbleweed> it fails now, with the mismerge, btw
[19:03] <Laney> never!
[19:03] <Laney> there
[19:04] <Laney> WTF
[19:09] <Laney> ok, crons back on
[19:16] <tumbleweed> Laney: http://people.ubuntu.com/~stefanor/upload_activity/ (Jan 2006)
[19:17] <tumbleweed> that's around your cutoff for the new data, right?
[19:17] <tumbleweed> well, duh
[19:17] <tumbleweed> but why the old data island
[19:22] <Laney> i started with new stuff from 2006-03
[19:24] <Laney> it deduplicates within a run
[19:24]  * tumbleweed wonders what's going on with the first 3 weeks of 06, then
[19:24] <Laney> so if there was some overlap between old and new it probably chose the new?
[19:24] <tumbleweed> right, but then ther's 2 weeks of old again
[19:25] <broder> hmm...i wonder why dpkg-source adds the debian-changes-blah patch to the end of the quilt series. that seems backwards
[19:25] <Laney> yes
[19:25] <Laney> there was a test import of some kind into soyuz
[19:25] <Laney> before it was opened to everyone
[19:25] <Laney> it's probably to do with that
[19:25] <tumbleweed> broder: newer ones don't
[19:25] <Laney> gorra go out, ttyl
[19:25] <broder> tumbleweed: you mean because they refuse to add the patch, or because they add it to the beginning?
[19:26] <tumbleweed> broder: what's wrong with the end of the quilt series?
[19:26] <tumbleweed> you can't put it at the beginning, if all the patches are applied
[19:26] <tumbleweed> end is the only place it can go
[19:26] <broder> tumbleweed: because it's finding the remaining changes after unapplying the patches
[19:27] <tumbleweed> broder: yeah, that'd probably be wrong
[19:27] <tumbleweed> although, conceptually, you'd expect dpkg-source --commit to put it at the end
[19:28] <broder> as a side note, debian qa uploads are allowed to make arbitrary improvements to packages, right?
[19:28] <tumbleweed> sure
[19:55] <verwilst> hi guys,trying to build mysql-server-5.5 in my ppa, but it fails..
[19:55] <verwilst> https://launchpadlibrarian.net/86557173/buildlog_ubuntu-lucid-i386.mysql-5.5_5.5.17-4ubuntu6ppa1_FAILEDTOBUILD.txt.gz
[19:55] <verwilst> it built fine on my test machine
[19:55] <verwilst> i just changed gcc-4.5to gcc-4.4 because im compiling for lucid
[19:55] <verwilst> which went fine in my testing
[19:56] <verwilst> CMake Error at /usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake:44 (MESSAGE):  Could not find compiler set in environment variable CC:  i686-linux-gnu-gcc-4.4.
[19:56] <verwilst> any idea?
[21:06] <jtaylor> does someone have a native ppc machine running unstable or precise?
[21:10] <micahg> jtaylor: I have access to a porter box as should the DDs in this channel
[21:11] <micahg> jtaylor: do you need to check something runtime or build time?
[21:11] <jtaylor> build time
[21:12] <jtaylor> a package crashes gcc on my pbuilder-dist
[21:16] <jtaylor> micahg: ~jtaylor-guest/public_html/pyzmq_ppc_compiler-error.c.gz on wagner, the commandline to build is the second line in the file
[21:18]  * micahg guesses this is a host he doesn't have access to
[21:19] <micahg> or was this part of the alioth break out
[21:21] <jtaylor> not sure alith = wagner or vask?
[21:22] <Zhenech> both :)
[21:22] <jtaylor> alioth.org gets me on wagner
[21:23] <jtaylor> or is it balanced?
[21:23] <Zhenech> ssh is wagner, ~ is shared iirc
[21:23] <Zhenech> vasks is static (anongit etc)
[21:24] <jtaylor> public_git is not shared
[21:24] <jtaylor> I always push to the wrong host ^^
[21:25] <micahg> jtaylor: sorry, can't access that easily at the moment, maybe one of the DDs can help
[21:25]  * Zhenech looks idly
[21:26] <jtaylor> I'll ask in a debian channel
[21:26] <Zhenech> /srv/home/users/jtaylor-guest/public_html/pyzmq_ppc_compiler-error.c.gz: Permission denied
[21:26] <Zhenech> i should at least have read perms :P
[21:26] <jtaylor> ups
[21:27] <jtaylor> fixed
[21:30] <Zhenech> yeah
[21:30] <Zhenech> lets see which porterbox i need
[21:30] <jtaylor> some powerpc
[21:33] <jtaylor> recent unstable, if it is a real issue it was probably introduced in the latest gcc -5
[21:34] <Zhenech> ew
[21:34] <Zhenech> did you erase the file?
[21:34] <Zhenech> just wanted to scp it to pescetti
[21:35] <jtaylor> I decompressed it
[21:35] <Zhenech> ah
[21:35] <Zhenech> k
[21:35] <Zhenech> got it
[21:35] <jtaylor> srym, just tried if the compile command works on wagner
[21:37] <Zhenech> compiling *drumroll*
[21:37] <Zhenech> takes too long now, I bet something will crash :)
[21:38] <jtaylor> its a large file :)
[21:38] <Zhenech> (sid)evgeni@pescetti:~$ ls
[21:38] <Zhenech> pyzmq_ppc_compiler-error.c  pyzmq_ppc_compiler-error.o
[21:38] <Zhenech> na worked
[21:38] <jtaylor> gcc version?
[21:39] <jtaylor> so probably an issue with the VM then, thx
[21:39] <Zhenech> http://paste.debian.net/148111/
[21:39] <jtaylor> hm thats -4
[21:39] <jtaylor> -5 is recent
[21:40] <jtaylor> porterbox is on testing?
[21:40] <Zhenech> that's what installed in the sid dchroot
[21:43] <Zhenech> i could fetch my ppc, but tooo lazy *g*
[21:43] <jtaylor> :) thanks for the help
[21:43] <jtaylor> if you have time it would be great if you could retry it when -5 is in that chroot
[21:44] <jtaylor> its not urgent
[21:59] <micahg> YokoZar: I noticed that we just got a wine-gecko-unstable package (versioned 1.0.0+dfsg-1), could you file for removal/blacklist if it's not need
[22:00] <YokoZar> micahg: from sync I presume?  yeah it's probably blacklist
[22:00] <micahg> YokoZar: yeah, most likely
[22:18] <effie_jayx> Guys, good evening. now that most peopel use VCS to manage packages, are deb-src  a thing of the past?
[22:18] <effie_jayx> I mean making a apt-get source X is only needed when?
[22:19] <micahg> effie_jayx: depends on your workflow and purpose of apt-get source as well as if it's maintained in a VCS or not
[22:20] <effie_jayx> micahg: with regards distributions, lets say I have an ubuntu derivative, Do I really need to publish deb-src eventhough the sources are maintained in a VCS?
[22:20] <effie_jayx> or is it two separate things?
[22:21] <micahg> effie_jayx: 2 separate things, deb-src is showing what source produced which binary, the VCS shows the history of the package
[22:25] <effie_jayx> ok thanks
[22:26] <effie_jayx> also micahg when stablishing differences in source packages debdiff and apt-get source would be more suitable than just cloning a repo and then building a source package
[22:26] <effie_jayx> it is not integral