[01:14] <broder> bdrung: what's the issue with debug-symbols-directly-in-usr-lib-debug? i'm having a hard time understanding it from reading the bug
[02:22] <broder> cjwatson: do you know what uid/gid was showing up in the broken builds? lintian doesn't seem to have an explicit tag for this, but the lintian lab has enough information for me to scrape out a report manually
[02:29] <broder> also, does anybody remember when the buildd sudo issue was, even roughly?
[02:45] <broder> wc -l ~/non-root-files -> 11534
[02:45] <broder> might require a little more pruning
[02:50] <wgrant> broder: https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures?
[02:53] <broder> wgrant: excellent. thanks
[02:57] <broder> actually, bdrung's example of audacity was built 4 weeks ago, so it's clearly not fallout from the sudo incident
[02:58] <wgrant> broder: Link?
[03:00] <broder> wgrant: https://launchpad.net/ubuntu/+source/audacity/1.3.13-5 is triggering non-standard-file-perm from lintian - http://lintian.ubuntuwire.org/full/pkg-multimedia-maintainers@lists.alioth.debian.org.html#audacity
[03:01] <broder> there are about 21000 warnings from cases where lintian expects the file permissions to be 0644 but they are actually 0664
[03:01] <broder> http://web.mit.edu/broder/Public/non-standard-file-perm is the full list
[03:02] <broder> (that last link is just instances of the lintian warning that are not present in debian's lintian instance)
[03:40] <broder> wgrant: looks like just about all of those broken uploads happened after precise opened (http://paste.ubuntu.com/736896/), though it's certainly not universal to all builds
[03:42] <wgrant> broder: Which arches?
[03:42] <broder> wgrant: i'm just looking at i386
[03:44] <wgrant> broder: Ah, so most of this are stuff that would have been done by pkgbinarymangler.
[03:44] <wgrant> pngs/svgs mostly
[03:45] <broder> oh, good point. i wonder if optipng started screwing up permissions
[03:45] <micahg> umm, there was a bug last cycle about images having issues with permissions as well...
[03:45] <wgrant> That's normally a bad umask issue.
[03:45] <wgrant> So we may have some non-virt builders with the sudo issue still/again.
[03:45] <wgrant> (LP people have very little visibility into our builders, unfortunately :/)
[03:46] <broder> fyi http://paste.ubuntu.com/736898/ is just non-png and non-svg
[03:46] <wgrant> In fact, they're almost all pngs and svgs.
[03:46] <wgrant> Thanks.
[03:46] <wgrant> Do those appear in Debian too?
[03:46] <broder> no, all of these should be unique to us
[03:46] <wgrant> k
[03:46] <broder> (assuming i didn't screw up the queries)
[03:46] <wgrant> Although I think some of these packages are Ubuntu-specific.
[03:46] <broder> the brother-* ones were uploaded in february, so could be early uncaught fallout from the sudo thing
[03:47] <wgrant> I thought we caught everything from that, but I was working on second-hand information on which buildds were affected and when.
[03:47] <broder> right, the incident report says it was first caught 2/25, but the brother-* uploads were 2/20
[03:49] <wgrant> Hmm.
[03:49] <wgrant> At least vernadsky and rothera have been bad in the last week.
[03:49] <wgrant> But there are so few affected builds that it can't really be a general issue.
[03:56] <broder> ok. you're on your own for cross-referencing builds. the ultimate debian database doesn't have that
[03:56] <wgrant> I figured :)
[03:57] <wgrant> Hmm
[03:57] <wgrant> readline-common is interesting
[03:57] <wgrant> debian/readline-common.overrides is 664 in both Ubuntu and Debian.
[03:57] <broder> i...probably didn't filter out overridden tags
[03:57] <broder> one moment...
[03:58] <wgrant> No, it's correct.
[03:58] <wgrant> In the Ubuntu binary it's 664
[03:58] <wgrant> But in Debian it's 644
[03:58] <broder> oh, i see
[03:58] <wgrant> The source is 664 in both.
[03:58] <broder> though i still think i included overridden tags, though i doubt we have any of those
[04:01] <wgrant> Hmmm
[04:01] <wgrant>         cp -p debian/readline-common.overrides \
[04:01] <wgrant>                 $(d_comm)/usr/share/lintian/overrides/readline-common
[04:04] <broder> hmm. do you think debian's binaryful upload of readline was for i386?
[04:04] <wgrant> Hah
[04:04] <wgrant> That is a good theory.
[04:04] <broder> looking...
[04:04] <wgrant> It was.
[04:04] <wgrant> Architecture: source all i386
[04:04] <broder> awesome
[04:04] <wgrant> Perhaps we should check powerpc or something instead. Or do you only have lintian results for i386?
[04:05] <broder> i only have debian's results for i386
[04:05] <wgrant> Ah, but it's readline-common, so it didn't matter anyway.
[04:06] <wgrant> In fact, an awful lot of them are arch-indep packages.
[04:07] <wgrant> eg debdelta seems to be the same thing.
[04:07] <wgrant> source.conf is 664 in the source
[04:07] <wgrant> sources.conf, that is.
[04:07] <broder> how is cp -p supposed to interact with umask?
[04:08] <wgrant> Seems to ignore it.
[04:11] <broder> huh - i'm surprised that we're still triggering issues on images. i see a patch in pkgbinarymangler to deal with that
[04:11] <wgrant> Yeah, I'm just trying to track that down now.
[04:11] <wgrant> It's odd.
[04:12] <wgrant> There are certainly svgs from the last week.
[04:12] <wgrant> But pkgbinarymangler doesn't do that.
[04:12] <broder> and the pkgbinarymangler changelog says it was fixed in oneiric
[04:12] <wgrant> Hmmm.
[04:12] <wgrant> What is touching the svgs, if not pkgbinarymangler...
[04:12] <broder> i thought pkgbinarymangler compressed both svgs and pngs
[04:12] <wgrant> grepping for svg yields nothing.
[04:12] <wgrant> But I thought the same.
[04:13] <wgrant> HMm
[04:13] <wgrant> But gbrainy is on the CDs.
[04:13] <wgrant> Maybe it has a patch to do it.
[04:13] <wgrant> Doesn't seem to.
[04:13]  * broder goes and tries to hunt down old uds discussions
[04:13] <wgrant> Although it's cdbs.
[04:14] <wgrant> So who knows what evil is going on there.
[04:15] <broder> "scour" is the program you're looking for
[04:15] <broder> ah - pitti created a dh_scour
[04:15] <broder> https://blueprints.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint
[04:16] <broder> aha - and patched /usr/share/cdbs/1/rules/debhelper.mk
[04:16] <broder> sneaky
[04:16] <wgrant> Ahhh
[04:16] <wgrant> That's why I couldn't find it.
[04:16] <wgrant> Sneaky indeed :(
[04:16] <broder> "if grep -q '^Component:[[:space:]]*main' /CurrentlyBuilding 2>/dev/null; then dh_scour -p$(cdbs_curpkg) $(DEB_DH_SCOUR_ARGS); fi"
[04:20] <wgrant> scour respects umask
[04:20] <broder> is that a good thing or a bad thing?
[04:20] <wgrant> gbrainy built on zirconium, which is an ex-lpia builder so I don't trust it at all.
[04:20] <wgrant> I'd prefer that it preserved the original mode, but I guess it's OK.
[04:23] <wgrant> Hmmmmm.
[04:23] <wgrant> Our sbuild has had umask(022) at the top since the incident.
[04:23] <wgrant> So the sudo config shouldn't matter so much.
[04:23] <wgrant> Oh
[04:24] <wgrant> Except yes it does, because sbuild still calls sudo itself.
[04:24] <wgrant> -rw-rw-r-- 1 wgrant wgrant 113 2011-11-13 15:23 ./deb-specific/pkginfo.inc.php
[04:25] <wgrant> Looks like fusionforge may be another binary upload issue.
[04:25]  * wgrant kicks Debian a bit.
[04:25] <broder> haha
[04:25] <wgrant> zirconium and roseapple at least have had the scour issue in the last week.
[04:25] <wgrant> I'll get their sudo checked out on Monday, hopefully.
[04:26] <wgrant> See if we can blame that.
[04:27] <wgrant> broder: Is it easy enough to produce http://web.mit.edu/broder/Public/non-standard-file-perm with dates as well?
[04:28] <broder> wgrant: probably. you want package, filename, date? give me a few to remember how to write sql :)
[04:29] <wgrant> broder: Version might be handy too, and is probably pretty trivial :)
[04:30] <wgrant> But I don't know the UDD schema any more.
[04:30] <broder> yeah, i think i can do this
[04:34] <broder> wgrant: http://web.mit.edu/broder/Public/non-standard-file-perm-with-dates
[04:35] <wgrant> broder: Thanks!
[04:35] <broder> np
[04:36] <wgrant> It looks like *all* the recent stuff is scour.
[04:36] <wgrant> Except for two dirs in sip4, and the readline6 issue which probably affects Debian too.
[04:38] <wgrant> However, what's our policy now on how builds have to cope with umasks?
[04:38] <wgrant> Since we've changed the default...
[04:39] <broder> i have no idea
[04:46] <wgrant> broder: So, I'll get sudo configs checked out this week. I guess we also want a bug against scour (dh_scour seems like it really should preserve the mode), and probably against readline6 and fusionforge in Debian.
[04:46] <wgrant> For now, at least.
[04:47] <broder> that all sounds reasonable
[06:00] <ben_> Does Ubuntu have a place like Debian's WNPP?
[06:01] <broder> ben_: not generally. we have a needs-packaging tag for bugs for new packages, but since ubuntu doesn't have maintainers in the sense of debian, there's not as strong of a concept of orphaned, etc packages
[06:01] <ben_> broder: Ok, are there other places besides the WNPP site?
[06:01] <broder> ben_: what do you mean?
[06:01] <broder> what are you trying to figure out?
[09:50] <alkisg> Hi, where can I find the final decision about a UDS session called "FreeRDP and Remmina to replace rdesktop, vinagre and tsclient"?
[09:51] <alkisg> I'd like to know if remmina will replace vinagre, so that I change my app to take advantage of the default Precice packages
[10:13] <iceroot> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502  can you have a look here? specially https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/94  the changelog says that you did the change
[11:28] <cjwatson> iceroot: You are confused.  The only change I made was to deliver the existing firmware to the installer.
[11:28] <cjwatson> iceroot: I am not a kernel hacker and cannot help you.
[11:30] <cjwatson> iceroot: You'll need to ask somebody who actually works on the kernel ...
[11:47] <Fusionite> Hey
[11:52] <iceroot> cjwatson: and where did the firmware came before it was inside "linux-firmware"
[11:53] <iceroot> so that i know where i have to look
[11:56] <cjwatson> iceroot: I have no idea
[11:56] <cjwatson> sorry, I really don't have the ability or knowledge to help you here
[11:58] <iceroot> cjwatson: ok no problem
[11:59] <cjwatson> the change I made had no effect on installed systems
[12:01] <iceroot> cjwatson: ok, i was just looking where rt2860.bin is coming from and apt-file told me "linux-firmware", because the bug we are facing comes from rt2860.bin  and i saw a changelog from you about rt-cards, so i asked you
[12:03] <cjwatson> right, I'm sorry that the changelog was confusing, but my change is not the change you were looking for
[12:03] <iceroot> cjwatson: ok, thank you for the info
[15:08] <dr3mro> hello can any one tell me how to merge bazzar branch into trunk ... i own the branch but i am not a amember of trunk
[15:10] <tumbleweed> dr3mro: that's pretty OT for this channel. But if you don't have permission to write to the trunk, then you can't do the merge. You could create a proposal on launchpad, though
[15:10] <dr3mro> create a proposal is what i look for but how ?
[15:12] <tumbleweed> push the branch to LP, and click on the button on it's page, labelled Propose for mering
[19:39] <broder> hmm. the rsync daemon on one of the archive.ubuntu.com servers (91.189.92.170) seems to be down. who do i contact about that?
[19:45] <tumbleweed> broder: you should be using rsync.archive.ubuntu.com (although both hosts in archive.ubuntu.com also appear in rsync.a.u.c)
[19:45] <tumbleweed> generally #ubuntu-mirrors for this kind of issue
[20:02] <lifeless> ok, semi random question tinme
[20:02] <lifeless> is launchpadlib included on the Ubuntu installer CD these days ?
[20:02] <JackyAlcine> lol
[20:03] <lifeless> broder: #canonical-sysadmins if I remember the channel name correctly
[20:05] <lifeless> broder: or #ubuntu-mirrors
[20:09] <infinity> lifeless: Which lplib bits are you looking for?
[20:10] <infinity> lifeless: But if you check apt-cache, you'll note that liblaunchpad-integration-3.0-1 (for instance) is in every *-desktop seed.
[20:10] <lifeless> infinity: python-launchpadlib
[20:10] <infinity> adconrad@cthulhu:~$ apt-cache show python-launchpadlib | grep ^Task
[20:10] <infinity> Task: cloud-image, ubuntu-desktop, server, ubuntu-usb, kubuntu-desktop, kubuntu-mobile-desktop, edubuntu-desktop, edubuntu-usb, xubuntu-desktop, mythbuntu-backend-master, mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend, lubuntu-desktop, ubuntustudio-desktop
[20:11] <lifeless> thanks
[21:51] <broder> tumbleweed: hmm, ok. debmirror defaults to archive.ubuntu.com (i'm not actually specifying it explicitly). i'll file a bug
[21:58] <tumbleweed> broder: is rsync the default method?
[21:58] <broder> hmm, no it's not
[21:59] <tumbleweed> although I know it does always rsync some extra bits, unless you tell it not to
[21:59] <tumbleweed> but those are small enough, that the load shouldn't be problematic on a.u.c
[22:02] <broder> what's the difference between r.a.u.c and a.u.c? it looks like all the same IPs
[22:03] <tumbleweed> broder: r.a.u.c is a much bigger pool
[22:04] <broder> really? the pool looks exactly the same from where i am
[22:05] <tumbleweed> I only see two IPs in a.u.c
[22:05] <broder> yeah, i used to, but i just started seeing 6
[22:05] <tumbleweed> but then US, is problematic, because you don't have ab ig countrywide mirror
[22:05] <tumbleweed> ok, yes 7 here now
[22:05] <broder> from here, us.a.u.c, rsync.a.u.c, and a.u.c are all the same set of IPs
[22:06]  * broder shrugs
[22:09] <tumbleweed> broder: hrm, found the mail where rsync.releases.ubuntu.com was announced and we were asked to use it, but that was private, not on a list. Can't find anything mentioning rsync.archive.ubuntu.com. Maybe I just discovered it existed and started using it
[22:26] <lool> Hmm I'm getting an upload error to a PPA
[22:26] <lool>   Uploading powertop-1.13_1.13-1ubuntu2_source.changes: 1k/2k550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
[22:26] <lool> gpg --verify works on the .changes file
[22:26] <lool> and on the .dsc
[22:28] <lool> ah intermittent Launchpad bug apparently
[22:29] <micahg_> yeah, that's an old bug
[23:42] <BiosDestroyer> Take care all