=== Jacky is now known as GLaDOS
=== Ursinha is now known as Ursinha-zz
=== Ursinha-zz is now known as Ursinha-zzz
=== GLaDOS is now known as Guest12539
=== emma is now known as em
=== Guest12539 is now known as Jacky
=== Adri2000 is now known as Guest74775
=== Ursinha-zzz is now known as Ursinha
[08:18] <geser> mdeslaur: Hi, is bug #1004845 interesting for the security team?
[08:18] <ubottu> Launchpad bug 1004845 in python-keyring (Ubuntu) "python-keyring CryptedFileKeyring is insecure (was: doesn't work with python-crypto 2.6-1 (ValueError: IV must be 16 bytes long))" [Undecided,Confirmed] https://launchpad.net/bugs/1004845
=== jml` is now known as jml
[09:33] <doko> cjwatson, graphviz
[09:33] <doko>  - debian/patches/linkage: Add more explicit library linkage to cope with
[09:33] <doko>       'ld --no-copy-dt-needed-entries'.
[09:34] <doko> wondering why this is still needed
[09:37] <diwic> TheMuso, still up?
[09:40] <diwic> Or - for anyone who listens - I'm having the trouble that "dpkg-buildpackage -S" complains about "the diff modifies the following upstream files" and then lists the entiere .bzr directory
[09:41] <diwic> ah wait
[09:41] <tumbleweed> what's the .bzr directory doing in your orig tarball?
[09:41] <cjwatson> doko: I didn't look very hard since the dh_python2 patch is still needed; I'm about to look at the build failure
[09:42] <diwic> tumbleweed, I used "dpkg-buildpackage -S" instead of "bzr builddeb"
[09:42] <diwic> inside a merge-mode branch
[09:42] <tumbleweed> right
[09:42] <diwic> problem solved
[09:42] <cjwatson> dpkg-buildpackage -S -I.bzr would probably have fixed it too
[09:43] <cjwatson> or indeed just -I
[09:43] <cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -uc -us"  in ~/.devscripts, debuild -S
[09:43] <cjwatson> may as well use the available tools :)
[09:44] <doko> cjwatson, thanks. maybe the changelog entry is wrong, and it should be --as-needed
[09:45] <cjwatson> I thought I was fairly careful about writing that entry
[10:13]  * diwic is about to upload to the Ubuntu archive for the first time in his life, feels a little scary :-)
[10:17] <StevenK> diwic: The upload processor does not bite.
[10:17] <StevenK> diwic: Hard, at least.
[10:18] <diwic> StevenK, but the bug reports will if I did something wrong ;-)
[10:18] <diwic> StevenK, but not that many use quantal yet I assume
[10:18] <Laney> most of them are probably in here :-)
[10:19] <diwic> Laney, :-)
[10:19]  * diwic anxiously waiting for the upload processor's reject or accept
[10:21] <diwic> accepted :-)
[10:26] <xnox> diwic: on my laptop, my mic now disappeared
[10:27] <diwic> xnox, please clarify "now" :-)
[10:28]  * xnox wait.... diwic's package is not build yet. Prank fail!
[10:28] <diwic> xnox, haha
[10:31] <Laney> zul: Daviey: Are you aware of the nova-common upgrade failure? There is a typo in nova-common.postinst on line 26.
[10:32] <Laney> /var/lib/dpkg/info/nova-common.postinst: 33: /var/lib/dpkg/info/nova-common.postinst: Syntax error: "fi" unexpected (expecting "then")
[10:33] <Laney> actually even if I fix that it bails trying to parse my config file
[10:33] <Laney> bah humbug
[10:59] <directhex> Laney, nova-common?
[11:00] <directhex> oh, cloud lala
[11:29] <l3on> some core developer here? I need a sru sponsor for bug 921430
[11:29] <ubottu> Launchpad bug 921430 in qwt (Ubuntu) "Package libqwt-dev wants to upgrade every time" [Undecided,Fix released] https://launchpad.net/bugs/921430
[11:38] <zul> Laney: please open up a bug and ill get to it today
[11:44] <mdeslaur> geser: yes, thank
[11:44] <mdeslaur> thanks
[11:50] <Laney> zul: did, bug #1005479
[11:50] <ubottu> Launchpad bug 1005479 in nova (Ubuntu) "Upgrades to 2012.2~f1-0ubuntu1 fail due to syntax error in nova-common.postinst and error in config migrator" [Undecided,New] https://launchpad.net/bugs/1005479
[11:54] <zul> Laney: thanks
[11:54] <Laney> np
=== Guest10379 is now known as zumbi
=== zumbi is now known as Guest72020
=== Guest72020 is now known as zumbi_
[12:17] <Laney> zul: Don't forget the nova-manage half of the bug. The commit I see only fixes the syntax error.
[12:17] <zul> Laney: yeah
[12:20] <Laney> cool, thought you might have missed it due to the Fix Committed. :-)
[12:25] <Daviey> Laney: i was no.. no.. thanks for identifying it
=== _salem is now known as salem_
[12:39] <ahasenack> hi guys, could I interest a sponsor in #1004678? :)
[12:59] <Daviey> ahasenack: have you seen the lintian output? http://pb.daviey.com/DhW0/
[13:00] <ahasenack> no, I haven't
[13:00]  * ahasenack checks
[13:26] <ahasenack> Daviey: should I add overrides for the ones that don't apply?
[13:26] <ahasenack> Daviey: or just explain them in the bug?
[13:28] <Daviey> ahasenack: well, it's only guidance really.. i just saw a large volume.. where most or normally easily resolvable.. which ones are not?
[13:29] <geser> ahasenack: which ones do you intend to override?
[13:29] <ahasenack> Daviey: I have to check them all, but for example the one about dh_python isn't, because the rules file checks the ubuntu release and then decides which python system to use
[13:30] <ahasenack> this package builds on lucid, natty, oneiric, precise and quantal
[13:30] <Daviey> ah!
[13:30] <ahasenack> that probably also explains the "ancient standards version"
[13:30] <ahasenack> since we can't (easily) adjust the control file depending on the target release
[13:31] <Daviey> nah, that one can be ignored.. that is Standards: in debian/control.. we don't really follow that.
[13:31] <ahasenack> about the diff, I will have to check, since we build from branches, I guess it's looking for the 12.04.X previous orig file or something
[13:31] <ahasenack> substvar we need
[13:32] <ahasenack> it's the only way to adjust dependencies depending on the target release
[13:32] <ahasenack> (that I know of)
[13:32] <Daviey> Ubuntu policy is wedged at 3.8.2 :)
[13:32] <ahasenack> what is the one for lucid? How do I find that out?
[13:32] <Daviey> ahasenack: what about the patched files? Are they needed?
[13:32] <Daviey> ahasenack: lucid is 3.8.2
[13:33] <Daviey> anyway, that isn't an issue.
[13:33] <ahasenack> ok, I can bump that to 3.8.2 then
[13:33] <ahasenack> about the patched files, I'll have to check
[13:33] <ahasenack> I basically just did a dpkg-buildpackage -S
[13:33] <ahasenack> actually, hm, that didn't generate a diff file here
[13:33] <ahasenack> but a landscape-client_12.05-0ubuntu1.tar.gz
[13:34] <ahasenack> like a native package
[13:34] <ahasenack> what is the base tarball your build used? 12.04.3?
[13:34] <Daviey> ahasenack: bzr bd -S
[13:36] <ahasenack> so, this "Looking for a way to retrieve the upstream tarball"
[13:36] <ahasenack> it looks for a specific "make" target, right? Something like get-upstream-source
[13:36] <ahasenack> which I don't think we have
[13:37] <ahasenack> so it does "Using pristine-tar to reconstruct landscape-client_12.05.orig.tar.gz."
[13:37] <ahasenack> how does that bit work? What is pristine-tar?
[13:37] <ahasenack> sorry if these are basic questions, we can take this elsewhere, or just point me somewhere
[13:38] <geser> ahasenack: for the substvar warning: check if you need ${source:Version} or ${binary:Version} instead of ${Source-Version} which is deprecated (see also http://manpages.ubuntu.com/manpages/lucid/en/man5/deb-substvars.5.html and http://lists.debian.org/debian-mentors/2006/09/msg00230.html)
[13:38] <ahasenack> geser: ah, thanks. I'll see also if those work in lucid, our minimum version
[13:40] <geser> the linked manpage is from lucid, so it should work there too
[13:40] <ahasenack> thanks
[13:40] <Daviey> ahasenack: you really should apply for per package upload for this :)
[13:40] <ahasenack> Daviey: with all these mistakes?
[13:40] <ahasenack> Daviey: and I will, but after our june release
[13:41] <Daviey> ahasenack: hah, there isn't anything significant here.. I only raised it because there were a fair few.  There are many packages in the archive in a worse state.  What matters more is the interest to incrementally improve it, which is what you are doing :)
[13:42] <ahasenack> Daviey: ok, so let me address some
[13:42] <ahasenack> Daviey: I should unsubscribe sponsor while I do this, right?
[13:44] <Daviey> ahasenack: ok.. Yes, unsubscribe.. i'll follow this through.
[13:44] <ahasenack> Daviey: ok, thanks for the review
[13:49]  * apw has just scratch installed a precise system without the 'third party' box ticked and now rhythmbox fails to see mp3s and the button to 'installed the required ...' just fails, clearly not intended behaviour; its looking for a python2.7 id3 muxer, any idea what its called?
[13:50] <Daviey> apw: ubuntu-restricted-extras ?
[13:51] <apw> Daviey, will give it a go, so i know what to report in the bug
[13:52] <Daviey> apw: scrub that, bug 888847
[13:52] <ubottu> Launchpad bug 888847 in gnome-codec-install (Ubuntu) "rhythmbox can't find ID3 tag muxer for MP3 support" [Undecided,Confirmed] https://launchpad.net/bugs/888847
[13:58] <apw> Daviey, gah thats a real sucky user experience indeed, install bad then ugly will install from the button in rhytmbox ... ick
[14:08] <ScottK> xnox: We use version specific build-deps for boost much more than Debian, so it ends up being a bit different.
[14:08] <xnox> ScottK: ok, thanks. good to know.
[14:41]  * xnox open browser window, type into the address bar `apt-cache search package<RET>`, stare at the google results, experience the utter confusion of not seeing terminal output.
[14:42] <geser> did google find anything useful?
[14:51] <tumbleweed> cjwatson: care to merge fonts-tlwg? it being out of date is responsible for at least 2 FTBFS packages
[14:53] <cjwatson> tumbleweed: I think I've tried but it was tediously hard; I'll have another go ...
[14:53] <tumbleweed> yay :/
[14:54] <cjwatson> or maybe that was the indic font cluster
[14:54] <tumbleweed> it's responsible for cjk not building on i386 which creates other tex uninstallability problems
[14:57] <cjwatson> oh, hey, I think this can be a sync actually
[14:57]  * cjwatson test-builds to check
[15:09] <cjwatson> tumbleweed: yep, it was a sync after all - done, thanks for the prod
[15:09] <tumbleweed> thanks
[18:51] <ahasenack> hi, any idea why lintian (invoked by debuild -S) would be complaining about the original-maintainer field?
[18:51] <ahasenack> W: landscape-client source: unknown-field-in-dsc original-maintainer
[18:52] <ahasenack> and it's in fact XSBC-Original-Maintainer in the control file
[18:52] <ahasenack> (no clue what XSBC means, other than maybe a bank in Hong Kong ;)
[18:53] <broder> ahasenack: you can safely ignore that
[18:53] <broder> XSBC- means that the field is an extension ('X') and should be copied to the .dsc ('S' - source), .deb ('B' - binary), and .changes ('C') files
[18:53] <broder> when it gets copied it's without the XSBC- prefix
[18:54] <broder> so the dsc file ends up with "Original-Maintainer"
[18:54] <ahasenack> ok, and lintian is wrong then?
[18:54] <broder> yeah. the version of lintian in quantal shouldn't complain anymore
[18:54] <ahasenack> so a bug was filed already I assume?
[18:55] <ahasenack> or, is unneeded
[18:59] <ahasenack> broder: thanks, I added a lintian override for now
[18:59] <Laney> there's no need to override for that
[19:01] <ahasenack> well, I didn't know about this "bug", and my colleagues who are going to review my branch probably also don't
[19:01] <ahasenack> so I added an override with a comment
[19:01] <ahasenack> better than having this question pop up again in the future when someone new comes along I think
[19:02] <ahasenack> ah, found the bug
[19:02] <ahasenack> #158667
[19:02] <ahasenack> but
[19:02] <ahasenack> that's old
[19:03] <Laney> anyone uploading the package will be used to seeing it
[19:41] <hallyn> hey - seabios until now has been tracked separately in debian and ubuntu.  i'm syncing from debian.  do i use the ubuntu changelog with debian entries with newer entries above that?  Or is that not good enough because older debian entries are not really reflected?
[19:41] <hallyn> i.e. ubuntu version is at 0.6.2-0ubuntu3, debian had jumped from 0.6.1-something to 1.6.3.
[19:42] <hallyn> so i was thinking i would just have the 1.6.3+ entries prepended to the ubuntu changelog, and that's it
[19:42] <geser> hallyn: "sync" like taking the Debian package without any additional Ubuntu delta or are you merging?
[19:44] <hallyn> geser: well we'll see, but so far it looks like a sync will work
[19:45] <geser> if it's a sync then all Ubuntu delta (including the changelog entries) get dropped
[19:45] <hallyn> geser: oh really?  I didn't know that.  cool.  thanks.
[19:46] <geser> for a sync the package gets copied as is from Debian
[19:46] <geser> we merge only the old Ubuntu changelog entries when merging
[19:46] <hallyn> that makes sense.  i'd just never sync'd :)  thanks
[19:49] <hallyn> geser: I'm googling, but not seeing a howto (only for merging).  Do I do a 'dch -i' and say sync from debian, or not even that?  Do I just pull-debian-source; debuild -S; dput ?
[19:50] <geser> hallyn: "syncpackage --force seabios"
[19:51] <hallyn> geser: thanks again
[19:51] <geser> I usually do a test build to check that it builds before syncing
[19:52] <geser> test build in a quantal pbuilder
[19:52] <hallyn> right.
[19:59] <goddard> my program won't build because I think some libraries changed location after my upgrade or something.  How do I keep my development enviornment from breaking?
[20:01] <geser> can you be a little more precise?
[20:05] <goddard> i am using find_package to find the GL header files and other required files
[20:06] <goddard> http://pastebin.com/yG8DWTwc
[20:07] <goddard> it isn't working
[20:07] <goddard> it says I have the package installed but when I do apt-file glu.h or gl.h it finds nothing
[20:08] <goddard> im new to all this stuff so it would be cool to know some tricks so this doesn't happen
[20:08] <goddard> one of the most annoying parts of c/c++ is library linking at least for me especially after an OS upgrade
[20:10] <Daviey> ahasenack: Hey, any progress?
[20:11] <ahasenack> Daviey: finished a branch against our trunk addressing several of those
[20:11] <ahasenack> Daviey: it will need to go through the review process we have
[20:11] <ahasenack> Daviey: I'm a bit confused with native vs non-native packages, our trunk has debian/* in it, so it's a native package in that regard
[20:12] <ahasenack> Daviey: but ubuntu has a diff and an orig.tar.gz, so it's non-native there. And the diff is about debian/changelog, debian/control and some po files
[20:12] <ahasenack> Daviey: I'm thinking about releasing a tarball without the debian/* stuff
[20:13] <ahasenack> Daviey: and in this branch I also made it explicit that our upstream build is native, let's see how that goes (debian/source/format with "3.0 (native)")
[20:14] <ahasenack> just pushed, btw: lp:~ahasenack/landscape-client/client-package-lintian-fixes
[20:19] <Daviey> ahasenack: yeah, a native package shouldn't have a *debian*.tar.gz
[20:19] <ahasenack> Daviey: it wasn't even version 3
[20:19] <Daviey> ahasenack: Okay, i'll take a look in the morning, unless you are in a hurry?
[20:20] <ahasenack> Daviey: oh, no, it's fine, and that's not even the upload proposal yet, it's just to address these issues in our trunk first
[20:20] <ahasenack> Daviey: then I will redo the branch in that bug asking for the upload
[20:22] <Daviey> ok, super.
=== soren_ is now known as soren
[21:35] <stgraber> cjwatson: can you let the TB minutes through? (devel-announce)
[21:37] <cjwatson> stgraber: done
[21:41] <stgraber> cjwatson: thanks
[21:55] <sladen> stgraber: +1 for the minutes
=== Adri2000 is now known as Guest35099
=== salem_ is now known as _salem
=== Guest35099 is now known as Adri2000
[23:41] <RAOF> SpamapS: Doing/done an SRU sweep?