=== micahg_ is now known as micahg
=== almaisan-away is now known as al-maisan
[09:35] <micahg> siretart: is there any reason for me to not sync lame from Debian testing?
=== al-maisan is now known as almaisan-away
[10:11] <ari-tczew> hello
[10:11] <ari-tczew> is following traceback ok? http://paste.debian.net/139051/
[10:16] <ari-tczew> tumbleweed:  ^^
[10:17] <siretart> micahg: I didnt' check yet, but I don't know of a reason for divergence either
[10:19] <micahg> siretart: well, it builds on both i386 and amd64 w/no soname change...
[11:33] <Laney> afternoon
[11:51] <nigelb> ohai Laney
[11:51] <Laney> alright?
[11:56] <ajmitch> hi
[11:56] <nigelb> Yeah, lazy sunday evening :)
[11:56] <nigelb> You?
[11:57] <Laney> digesting me lunch before swimming
[11:57] <Laney> ajmitch is up late!
[11:57] <nigelb> Nice
[11:58] <ajmitch> Laney: yeah there are noisy people out in the street
[11:58] <Laney> hah
[11:58] <ajmitch> something about the rugby world cup :P
[11:59] <Laney> wonder why?
[12:05] <nigelb> who won?
[12:06] <ajmitch> nigelb: NZ
[12:10] <nigelb> ajmitch: Neat.
[12:14] <Laney> hoorah
[12:14] <Laney> python-launchpadlib is installed on samosa (udd.debian.org)
[12:15] <ajmitch> yay
[12:34] <Laney> gah
[12:34] <Laney> no dpkg-dev
[12:37] <nigelb> Laney: "samosa" makes me laugh :)
[12:37] <nigelb> http://en.wikipedia.org/wiki/File:Samosachutney.jpg
[12:38] <Laney> yeah i do like a samosa
[12:40] <nigelb> I should go out and grab a few.
[12:41]  * Laney proposes dosa.debian.org
[12:41] <Laney> yum yum
[12:41] <nigelb> heh
[12:42] <Laney> http://paste.debian.net/139085/
[12:42] <Laney> tumbleweed: ^ :-)
[12:43] <Laney> & so to swim, bye bye
[12:43] <nigelb> laters!
=== yofel_ is now known as yofel
[12:58] <tumbleweed> Laney: :) any chance of slipping the component in there?
[13:08] <jtaylor> do we really want to enable format-security without doing it in debian? :/
[13:08] <jtaylor> there will be hundreds of failures
[13:08] <jtaylor> there already are, and those are only the new packages
[13:09] <jtaylor> it will be worse than as-needed :/
[13:11] <tumbleweed> jtaylor: there was some discussion on #ubuntu-release the other day http://irclogs.ubuntu.com/2011/10/19/%23ubuntu-release.html#t11:25
[13:21] <Ceno3x> Hello everyone. I've just finished writing a Qt application in Qt Creator and would like to publish  a deb package, maybe even set up a ppa. Could anyone give me a pointer to the right place to start?
[13:22] <tumbleweed> Ceno3x: http://developer.ubuntu.com/resources/tools/packaging/
[13:23] <tumbleweed> althogh, if you want a beginner guide to packaging, I really like this one http://wiki.debian.org/IntroDebianPackaging
[13:24] <Ceno3x> tumbleweed: thx, I am totally in need to a "complete idiot's guide" to debian packaging
[13:40] <kees> jtaylor: it is already enabled in debian
[13:40] <jtaylor> no
[13:41] <jtaylor> at least not yesterday
[13:42] <jtaylor> the exporting of hardened flags must be enabled by the maintainer
[13:43] <jtaylor> I submitted bugs until N for the existing failures
[13:43] <jtaylor> but there will probably hundreds more on the next archive rebuild :/
[13:43] <kees> jtaylor: hrm? we must be misunderstanding eachother
[13:44] <kees> the -Werror=format-security comes from dpkg-buildflags in Debian.
[13:44] <kees> any ftbfses will mirror those in debian
[13:44] <jtaylor> yes but almost no packages uses that
[13:44] <jtaylor> with the new dpkg
[13:44] <jtaylor> it must be enabled by the maintainer
[13:44] <jtaylor> see http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html
[13:45] <jtaylor> in precise is it enabled for all packages
[13:45] <kees> right but those that do are the same between debian and ubuntu. it's just that ubuntu is rebuilding stuff now with the new dpk, so things like cdbs, dh(1) packages are seeing the flag now in ubuntu when they haven't been rebuilt yet in debian
[13:45] <jtaylor> no they don't fail in debian
[13:45] <kees> how is it wnabled for all packages in precise?
[13:45] <jtaylor> unless you enable it
[13:45] <jtaylor> no idea
[13:46] <tumbleweed> we are still exporting flags in dpkg-buildpackage in precise
[13:47] <kees> tumbleweed: ah, so ubuntu's change is that dpkg-builpackage is doing an addition export of the dpkg-buildflags output?
[13:48] <tumbleweed> yes, like debian used to, before debian had hardening flags in there
[13:48] <kees> that's the piece I was missing. interesting. that really will be a lot of packages with busted builds.
[13:48] <jtaylor> yes just look at the list of ftbs
[13:48] <kees> though it is interesting, a lot of those breakages are real problems. not all, but enough.
[13:49] <jtaylor> disabling werror=format-security will fix pretty much all failures
[13:49] <jtaylor> but the issues can be fixed easily too, its just a lot of bug filing ._.
[13:50] <kees> well, if there's a delta on how dpkg-buldflags is used, that's going to be a problem. filtering it out of the export (what cjwatson suggested) might be a good idea.
[13:50] <kees> the point was to make this change incrementally in debian. :P
[13:50] <tumbleweed> yeah, that sounsd like the way of least breakage
[13:50] <kees> yeah, several hundred bugs are in the debian bts too.
[13:51]  * kees must run
=== med_out is now known as medberry
=== medberry is now known as med_out
[16:07] <jtaylor> tumbleweed: can you attach the patch in debian bug 646369 to http://bugs.bitlbee.org/bitlbee/ticket/786? I'm to lazy to make an account ;)
[16:07] <ubottu> Debian bug 646369 in bitlbee "bitlbee: incorrectly linked when built with --as-needed" [Wishlist,Open] http://bugs.debian.org/646369
[16:07] <jtaylor> concerns bug 879730 and bug 757008
[16:07] <ubottu> Launchpad bug 879730 in bitlbee (Ubuntu) "/usr/lib/bitlbee/otr.so: undefined symbol: otrl_init" [Medium,Triaged] https://launchpad.net/bugs/879730
[16:07] <ubottu> Launchpad bug 757008 in BitlBee "/usr/lib/bitlbee/otr.so: undefined symbol: otrl_init" [Unknown,New] https://launchpad.net/bugs/757008
[16:08] <jtaylor> afk 15 min
[16:08] <tumbleweed> sure, guess I can
[16:09] <tumbleweed> jtaylor: no account needed
[16:19] <Ceno3x> hey guys, how can I generate a source package for a custom kernel? I'm using make-kpkg kernel_image for the image .deb, but I need a source package to upload it to launchpad
[16:19] <jtaylor> re
[16:20] <jtaylor> oh nice
[16:24] <tumbleweed> Ceno3x: ubuntu kernels aren't build with make-kpkg. Read all about it at wiki.ubuntu.com/KernelTeam (they also have an IRC channel)
[16:25] <Ceno3x> tumbleweed: oh. ok, thanx, I'll look into it. Thanks for the links you gave earlier today, already got a couple of packages on launchpad : -)
[16:26] <tumbleweed> np
[16:29] <jtaylor> Submission rejected as potential spam (Akismet says content is spam)
[16:29] <jtaylor> yey ._.
[17:20] <Laney> bah
[17:20] <Laney> this launchpad-supplied data is worse
[17:20] <Laney> you don't get the email they uploaded with
[17:20] <Laney> you aren't even guaranteed to be able to get an email address at all
[17:21] <Laney> Changed-By: Debian Tryton Maintainers <N/A>
[17:21] <geser> from the LP API?
[17:21] <Laney> yeah
[17:21] <tumbleweed> people can hide their e-mail addresses
[17:22] <tumbleweed> you can search by e-mail address, but not see all addresses
[17:22] <tumbleweed> Laney: if you read the changes file, you can get addresses
[17:23] <Laney> i can get ~changed-by from the parsed changelog
[17:23] <Laney> dpkg-parsechangelog calls it Maintainer for some reason
[17:23] <tumbleweed> you download the changelog?
[17:23] <Laney> aye
[17:23] <tumbleweed> :/
[17:24] <Laney> to get the closed bugs
[17:24] <tumbleweed> yeah, I remember now
[17:25] <tumbleweed> although with the changelog method on LP that wgrant just added, that wouldn't be necessary for bugs
[17:25] <tumbleweed> (err is adding)
[17:25] <Laney> what's that then?
[17:25] <tumbleweed> but probably wouldn't give you uploaders
[17:26] <tumbleweed> bug 833384
[17:26] <ubottu> Launchpad bug 833384 in Launchpad itself "API access to debian changelog" [Low,In progress] https://launchpad.net/bugs/833384
[17:28] <Laney> that will give text or a librarian url?
[17:29] <tumbleweed> dunno
[17:30] <Laney> I would probably be lazy and give it to parsechangelog anyway :-)
[17:30] <Laney> unless there is a nice function that can take a string and give me a list of closed bugs
[17:31] <tumbleweed> LP internally uses a couple of regexes for that
[17:31] <Laney> sure
[17:53] <jtaylor> wouldn't it make sense to set -Werror=implicit-function-declaration? the builds fail due to that anyway
[17:53] <jtaylor> only latter
[17:55] <tumbleweed> sounds like it, but I'm no expert there
=== emma is now known as em
[18:32] <Laney> ok there we go
[18:32] <Laney> it uses changesfiles now
[18:32] <Laney> if it can
[18:34] <cjwatson> kees,jtaylor: I'm definitely thinking of filtering out -Werror=format-security, but doko wants to get test rebuild results first
[18:34] <cjwatson> jtaylor: you can stop complaining about it, I've got the message :-)
[18:35] <cjwatson> the thing I noticed today that may tip the balance is that exporting CFLAGS=-Werror=format-security causes some configure tests to fail; so far I've only noticed this when it causes builds to fail as a knock-on effect, but I'm concerned that we might be silently disabling features in a few cases
[18:35] <cjwatson> that's the sort of thing a real maintainer is more likely to notice
[18:36] <tumbleweed> cjwatson: when are we expecting the first rebuild?
[18:38] <cjwatson> tumbleweed: it's not on the release schedule, so I'm not sure.  ask doko when he's around?
[18:38] <tumbleweed> will do, thanks
=== almaisan-away is now known as al-maisan
[18:44] <Laney> anyone remember how to get the syncer of a copyPackage synced SPPH?
[18:44] <Laney> ah, creator
[18:44] <tumbleweed> yeah
[18:44] <tumbleweed> in devel only
[18:45]  * Laney gets something with 1.0
[18:45] <tumbleweed> can't argue with that :P
[18:45] <Laney> hmm
[18:45] <tumbleweed> it'd make life a lot easier if we required everyone who did uploads to have a public e-mail addresses...
[18:46] <Laney> so I'll just set Signed-By as creator if it is set, otherwise you get N/A
[18:47] <Laney> might make it difficult to do analysis, having to look at Signed-By for syncs but Changed-By for other stuff
[18:47] <tumbleweed> that's how things are already, though
[18:47] <Laney> also you don't get it for autosyncs
[18:48] <tumbleweed> can you identify autosyncs?
[18:48] <Laney> yeah
[18:48] <Laney> Ubuntu Archive Auto whateveritis
[18:48] <tumbleweed> katie
[18:50] <tumbleweed> I don't think there is any way to tell a sponsored sync (Changed-By is the sponsoree) from a non-sponsored sync (Change-By is debian uploader)
[18:50] <Laney> what is Signed-By for those syncs?
[18:50]  * tumbleweed better find an example
[18:54] <cjwatson> autosyncs shouldn't have Signed-By
[18:54] <cjwatson> don't recall offhand about syncpackage ones
[18:54] <Laney> what about non-auto AA syncs?
[18:55] <cjwatson> nor should they - sync-source.py syncs go through a special queue with a policy that doesn't require signatures
[18:55] <Laney> same, just with Changed-By set to the user IIRC
[18:55] <cjwatson> right
[18:55] <cjwatson> (I think)
[18:56] <Laney> wondering how best to represent syncpackaged syncs
[18:56] <Laney> overriding Changed-By with the syncer would be more in line with this then
[18:59] <tumbleweed> Laney: currently syncpackaged syncs have signed-by = syncer, and changed-by = debian uploader in -changes. That's probably wrong, and doesn't match previous AA syncs
[18:59] <tumbleweed> AA manual syncs had changed_by = syncer, signed_by = N/A
[18:59] <Laney> right, I just added this
[18:59] <Laney>     if spph.creator is not None:
[18:59] <Laney>         changedby = person_to_name_email(spph.creator)
[19:00] <Laney> if sponsored syncs get done then we can put that into Signed-By
[19:00] <Laney> providing it is exposed …
[19:00] <tumbleweed> yeah, that'd match the old world
[19:01] <tumbleweed> question is, do we want the current -changes mail for mat for native syncs to be changed?
=== al-maisan is now known as almaisan-away
[19:10] <Laney> soz, got to go to the cinema. My initial feelings are that Signed-By is a more correct representation of what we're doing, but it's not so much better that it makes breaking backwards compat worthwhile
[19:10] <Laney> seeya
[19:10] <tumbleweed> enjoy
=== almaisan-away is now known as al-maisan
[19:39] <stevecrozz> I'm getting this lintian warning: "debian-watch-file-in-native-package", but I'm not intending to build a native package
[19:40] <stevecrozz> how do I tell debuild that my package is non-native?
[19:42] <ajmitch> check the version in debian/changelog, and check that you have a matching .orig.tar.gz
[19:42] <tumbleweed> two ways. Either put '3.0 (quilt)' to have a 3.0 format non-native package, or have a .orig.tar.gz in ..
[19:42] <ajmitch> what tumbleweed said ^
[19:42] <ajmitch> :)
[19:42] <tumbleweed> check the version, too. And you need the .orig.tar.whatever no matter which source format you want to use
[19:46] <stevecrozz> the original ubuntu changelog entry says: "inspircd (1.1.22+dfsg-4ubuntu1)", and now I've added a new entry: "inspircd (2.0.5~stevecrozz2)"
[19:46] <stevecrozz> what name will it look for under .orig.tar.gz?
[19:47] <tumbleweed> that's a native version number. you probably want to use something more like 2.0.5-0~stevecrozz+2
[19:49] <stevecrozz> cool! i think that's done it... now I have even more lintian warnings :)
[19:50] <tumbleweed> according to debian bug 620960, there is already some progress in packaging the 2.x series, but they haven't finished it yet
[19:50] <ubottu> Debian bug 620960 in inspircd "inspircd: 1.1 no longer supported, package not maintained actively" [Serious,Open] http://bugs.debian.org/620960
[19:50] <tumbleweed> but there is a link to the current packaging progress
[19:51] <tumbleweed> I'm sure patches are welcome
[20:00] <stevecrozz> i'll check that out
=== al-maisan is now known as almaisan-away
[20:19] <stevecrozz> the ppa build machines seem to be taking a lot longer than they used to
[20:19] <stevecrozz> i haven't built anything for over a year, but i used to get builds within the hour pretty easily
[20:20] <micahg> stevecrozz: all depends on how many machines available vs how large the queue is, some builders were MIA for a bit, but have come back now
[20:22] <tumbleweed> if you are doing any significant amount of work, you'll probably want to test build locally, rather than in PPAs
[20:27] <Sp4rKy> W/ 14
[22:21] <wgrant> tumbleweed, Laney: There'll be a new SPPH.changelogUrl(), which returns a path like https://launchpad.net/ubuntu/+archive/primary/+sourcepub/1234/changelog, that redirects to the librarian file.
[22:21] <wgrant> tumbleweed, Laney: (that redirect is necessary to handle private changelog)
[22:21] <wgrant> +s
[22:23] <Laney> wgrant: do you keep track of lp bugs closed with a particular publication?
[22:24] <wgrant> Laney: No.;
[22:24] <Laney> okies
[22:24] <wgrant> It's not exactly clear what that would mean.
[22:24] <Laney> Really? When an upload causes bugs to be closed ...
[22:25] <wgrant> Right, but what about copies, overrides, etc?
[22:25] <wgrant> Does only the initial publication close the bugs? Or is it any publication of that version in that suite?
[22:25] <Laney> LP knows when it closes bugs
[22:25] <wgrant> Sure, but how do we report them?
[22:26] <wgrant> We could reasonably simply provide a list on the first publication, but is that useful?
[22:29] <Laney> I don't know how that's different to "what is in Launchpad-Bugs-Fixed" (besides filtering out bugs on different source packages / nominated bugs?)
[22:29] <Laney> anyway, I can work it out another time, got to go to bed
[22:29] <tumbleweed> also filtering already closed bugs
[22:29] <wgrant> It's not clear how announcements work either :)
[22:30] <wgrant> Currently we only announce some things.
[22:30] <wgrant> Usually the initial introduction of a version into an archive.
[22:30] <wgrant> So that doesn't answer which SPPHs should be blamed for bug closures.
[22:31] <wgrant> Launchpad-Bugs-Fixed doesn't help, since we don't have changes file for copies.
[22:31] <wgrant> And changes file don't make sense for copies.
[22:32] <tumbleweed> I think they make sense for copies. Certainly the sync-sources changes files made sense
[22:33] <wgrant> To a limited extent.
[23:14] <TheMuso> /c/c
=== emma is now known as em