=== EvilResistance is now known as Resistance
[05:05] <micahg> ScottK: isn't pulling the dependency if it's "neeeded" what experimental does and what I suggested in the bug?  as opposed to always using the backports version which was what was occurring pre-natty
[05:05] <Resistance> anyone know if the IRC council meetings are open to the public?  at least for spectating
[05:06] <ScottK> I think Experimental only uses Experimental if it's told to, but I'm not sure.
[05:06]  * Resistance cant find anyone who knows
[05:06] <ScottK> Resistance: They are.  They are, not surprisingly, held on IRC in #ubuntu-meeting.
[05:06] <Resistance> ScottK:  know when the next meeting date is?
[05:06]  * micahg requests laney to explain experimental...
[05:06] <ScottK> No.
[05:07] <Resistance> know where i can find out?
[06:00] <AnAnt> Hello, I am preparing a package for a library that got GIR data
[06:01] <AnAnt> when I use compat level 9 (for multiarch support), the .typelib file gets installed to /usr/lib/<multiarch dir>/gireopository-1.0 instead of /usr/lib/girepository-1.0/
[06:02] <AnAnt> is this a bug or what ?
[06:03] <broder> ScottK, micahg: i thought the conclusion we came to was that experimental builds pulled build-deps from experimental if said build-deps carried a versioned build-dep that could only be satisfied by experimental
[06:03] <broder> AnAnt: did you mark the gir1.2- package as multi-arch?
[06:03] <micahg> broder: right, that's what I thought, hence what I requested in the bug
[06:03] <AnAnt> broder: nope
[06:08] <AnAnt> broder: you know of an example library package so that I can follow ?
[06:09] <broder> AnAnt: nope, not off the top of my head. i don't think we've multiarched much in the stack above gtk at this point, and gtk certainly isn't a good example
[06:13] <broder> AnAnt: yeah, gtk doesn't really solve this well. they move the library out of the multiarch path during the dh_install stage
[06:14] <broder> AnAnt: it looks like `pkg-config --variable=typelibdir gobject-introspection-1.0` will spit out where the typelibs are supposed to go, so the best solution might be to get the typelibdir from there, instead of building ot from libdir
[06:14] <broder> *building it
[06:14] <micahg> isn't /usr/lib/<triplet>/girepository-1.0 appropriate for a multiarch package?
[06:14] <broder> micahg: i don't *think* so. i think the typelib files are supposed to be arch-independent
[06:14] <micahg> then why are they in /usr/lib?
[06:15] <broder> hmm. good questoin
[06:15] <broder> fine, i revise my statement: i bet gobject-introspection hasn't been made multiarch-aware yet
[06:16] <micahg> broder: take a look at #1: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/gobject-introspection/debian/policy.txt?revision=27188&view=markup&pathrev=27188, /usr/lib is for binary typelibs :)
[06:17] <broder> micahg: yeah, i think gobject-introspection just isn't multiarch aware. slangasek completely side-stepped the typelibs when he multiarched gdk-pixbuf: http://lists.debian.org/debian-gtk-gnome/2011/07/msg00016.html
[06:20] <broder> needing multiarched typelibs would be a bit screwy anyway - it'd have to be something like "my javascript interpreter is 32-bit but my python interpreter is 64-bit and i want to use GI bindings in each"
[06:26]  * micahg hasn't dove into typelibs yet, so can't really speculate
[06:39] <AnAnt> aren't typelib arch-indep ?!
[07:15] <broder> AnAnt: the fact that typelibs are in /usr/lib suggests that they are not arch-inde
[07:15] <broder> *indep
[07:17] <micahg> AnAnt: according to the policy quoted above, the xml definitions are and are in /usr/share, the binary format ones are in /usr/lib
[07:18] <broder> i can't actually find a spec on the typelib format to verify that it's arch-dependent, but both GNOME and Debian have concluded that they belong in /usr/lib, so it seems very likely
[07:19] <AnAnt> if they are arch-dep, then they wouldn't have worked on 64-bit machines (since arch-all packages are usually built on i386)
[07:19] <broder> evan@caron:~$ apt-cache show gir1.2-gtk-3.0  | grep Arch
[07:19] <broder> Architecture: amd64
[07:19] <micahg> according to policy, the binary typelib needs to be in architecture dependent package
[07:19] <broder> the packages with the typelibs aren't arch-indep
[07:21] <AnAnt> hmmm, I thought I saw one that is arch-indep
[07:21] <AnAnt> I'm wrong
[07:22] <AnAnt> in that case they should be in /usr/lib/<multiarch>/girepository-1.0
[07:22] <broder> AnAnt: no, they should not, because there is not currently a specification for multiarched typelib files
[07:22] <AnAnt> ah, ok
[07:24] <AnAnt> ok, so I've got 2 options for my package: either manually move the typelib file to /usr/lib/girepository-1.0/, or simply not to multiarch the package
[07:25] <broder> AnAnt: i'd recommend the former
[07:25] <AnAnt> ok
[07:25] <broder> that would be consistent with other multiarched libraries that ship typelibs
[07:26] <AnAnt> broder: btw, to multiarch a lib, is it required that it's run-time dependencies are multiarched as well ?
[07:27] <broder> you won't be able to install a foreign-arch library unless all of its dependencies have been multiarched as well, but you're allowed to multiarch it anyway in anticipation of the dependencies getting converted
[07:33] <cemc> micahg: https://bugs.launchpad.net/hardy-backports/+bug/888627, I'm not sure what this means in your last comment
[07:33] <ubottu> Launchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]
[07:35] <micahg> cemc: so, basically I believe that overrides were added in 7.0.50, so any version less than that or its backports (hence using 7.0.50~), require the rules file to be expanded to its previous status, you might want to look at previous versions of the package pre-debhelper 7 to see what that should look like
[07:36] <micahg> err, status isn't quite correct, former larger self?
[07:36] <cemc> I've looked at 3.3-1 in Oneiric which has a totally different debian/rules
[07:37] <micahg> right, you probably want to got back before the package was converted to debhelper 7, maybe lucid?
[07:37] <micahg> s/got/go
[07:37] <broder> micahg: compat 7 still had a mechanism for doing overrides, it just wasn't as good
[07:38] <broder> it was something like %:\n\tdh $@ --before dh_install; dh_install --m-custom-args; dh $@ --something
[07:38] <broder> i forget the exact syntax
[07:38] <micahg> broder: ok, could you help cemc dig up the changes needed for pdns-recursor then, that should easier than turning the 10 line file back into 50
[07:39] <micahg> * be easier
[07:39]  * broder fetches source
[07:39] <micahg> thanks, I'm still trying to get an update out before bed
[07:40] <cemc> if the package builds as it is on Hardy, why is there a need to revert debian/rules?
[07:40] <broder> cemc: it probably builds, but you are probably silently dropping the changes to the arguments to dh_strip and dh_installinit specified in the rules file
[07:41] <broder> so i would guess that the dbg package is empty, plus a handful of other small issues
[07:42] <cemc> I see
[07:43] <AnAnt> OFFTOPIC: can anyone help me with autoconf/automake or direct me to a channel for so ?
[07:46] <dholbach> good morning
[07:47] <cemc> morning
[07:48] <AnAnt> hello
[07:52] <dholbach> hi cemc
[07:52] <dholbach> AnAnt, صباح الخير :)
[07:52] <AnAnt> dholbach: how are you ?
[07:53] <broder> micahg: ugh, i'm not sure whether i'm more offended by directly applying all of the patches in a .diff.gz or explicitly enabling quilt in the build system. i guess the latter is more in the spirit of the backport
[07:53] <dholbach> AnAnt, good good, thanks - how about you?
[07:53] <broder> also, debian/compat is 5! i don't even know what that means with a dh rules file! :)
[07:53] <AnAnt> dholbach: fine
[07:53] <dholbach> great :)
[07:54] <micahg> broder: for personal backports, I usually just leave them applied, not sure how I feel about it for archive backports
[07:54] <dholbach> hi micahg, hey broder
[07:54] <micahg> hi dholbach
[08:07] <broder> cemc: ok, i've attached a patch that i think should work properly for the hardy backport (https://bugs.launchpad.net/hardy-backports/+bug/888627/+attachment/2592842/+files/pdns-recursor_3.3-2~hardy1.debdiff), and thrown a test build in my PPA
[08:07] <ubottu> Launchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]
[08:07] <broder> i probably won't pay any attention to that test build, so that's all up to you :)
[08:07] <Angelo> Hi! I'm new with packaging and I have a problem learning how to start a package
[08:08] <geser> do you know already about the packaging guide?
[08:09] <Angelo> yes, i'm following its instruction geser
[08:09] <Angelo> about kqrcode example
[08:09] <broder> cemc: ok, never mind. just got mail about the build failure. working on attempt 2...
[08:10] <Angelo> but I got this message running dh_make
[08:10] <Angelo> "bzr: ERROR: Either run the command from an existing branch of upstream, or move kqrcode aside and a new branch will be created there."
[08:10] <Angelo> what does it mean?
[08:21] <Angelo> hello?
[08:23] <geser> I don't know what this error message means (and this channel is sometimes quiet, so be a little patient)
[08:23] <broder> man, hardy is old
[08:24] <cemc> broder: :)
[08:24] <broder> also, i have not yet done a PPA upload without having a mini panic attack in the middle that i accidentally uploaded to the archive proper
[08:25] <cemc> broder: you can just send me the diff, and I'll upload to my ppa, I don't have access anywhere else :P
[08:25] <broder> cemc: i uploaded it to mine - https://launchpad.net/~broder/+archive/backports-tests
[08:26] <broder> it should build in a few minutes, assuming that i turned the wayback machine far enough back :)
[08:26] <cemc> :D
[08:27] <cemc> broder: the same has to be done with lucid, mav, natty and oneiric too ?
[08:28] <broder> cemc: i don't think we need to actually modify the package for any of those. i can go ahead and kick off no-change test builds for those. one moment...
[08:28] <cemc> broder: I did that already
[08:29] <cemc> broder: https://launchpad.net/~cemc/+archive/ppa/+packages check them out here
[08:29] <broder> cemc: and you didn't modify the source at all to do the test build, other than adding a new changelog entry?
[08:29] <broder> foiled again! hardy is so old!
[08:30] <cemc> broder: nope, just dch -i and debuild and upload
[08:30] <broder> cemc: ok, perfect. then test those, and i'll figure out how to get this #$%^ hardy build to work :)
[08:31] <broder> at this point i feel a compulsive urge to defeat the old toolchain :)
=== dholbach_ is now known as dholbach
[08:50] <cemc> broder: I'll get right on it. I'll update the bugreport when I'm done testing the packages. thanks a lot
[11:56] <cemc> broder: there's still something wrong with the backported package, see my last comment pls https://bugs.launchpad.net/hardy-backports/+bug/888627
[11:56] <ubottu> Launchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]
[12:00] <Laney> regarding backports, I think respecting NotAutomatic for BDs is the right thing
[13:23] <Angelo> Hi! Someone knows how to overcome this error? "make[2]: *** [kqrcode/CMakeFiles/kqrcode.dir/kqrcodewindow.o] Errore 1 make[1]: *** [kqrcode/CMakeFiles/kqrcode.dir/all] Errore 2"
[13:24] <Angelo> Errore=error (it's in italian)
[13:24] <geser> this is a followup error from a previous error
[13:24] <Angelo> both?
[13:25] <geser> yes, the real error should be short before these lines (usually)
[13:25] <Angelo> ok! :-) thank you
[13:26] <Angelo> yes
=== Quintasan_ is now known as Quintasan
[13:26] <Angelo> this is the first error "error: reference to ‘d’ is ambiguous"
[13:27] <Angelo> but I'm following the tutorial to learn ... it should be correct
[13:28] <geser> that's probably the one you need to fix
[13:28] <Angelo> u know how to do?
[13:28] <geser> can you please put the whole part of this build log into a paste (e.g. http://paste.ubuntu.com/) and put the url here?
[13:29] <Angelo> ok!
[13:29] <Angelo> :-)
[13:32] <Angelo> is this good http://paste.ubuntu.com/735216/ ?
[13:33] <geser> yes, this is good
[13:33] <Angelo> :-D
[13:37] <geser> unfortunately I don't know how to fix it, usually it involves looking at the source code and/or contacting upstream and asking for help
[13:37] <Angelo> I read that installing "kqrcode-dev-0.6.0.tar.gz" package we can solve the problem, and it is true with version 0.6.0. (cuz i've done it), but then I had another problem and so I returned using the tutorial version
[13:38] <Angelo> ok
[13:38] <Angelo> thank you
[13:40] <Angelo> if I could help in something else for me it's ok
[13:45] <ScottK> broder: Could be.
[13:53] <geser> Angelo: check if there are some easy bugs you could fix, it's often easier to start with bug fixes as there is already a working package to start from
[13:56] <Angelo> geser: ok!
[13:56] <Angelo> :-)
[14:19] <Laney> bdrung: uploading haskell-csv to bpo now
[14:19] <bdrung> k
[14:19]  * Laney re-reads the rules
=== bulldog98_ is now known as bulldog98
[14:32] <tumbleweed> right, I think the reverse-depends tool in my backports branch is now at feature parity (the features that matter) with reverse-build-depends
[14:32] <tumbleweed> bugs, suggestions?
[14:34] <tumbleweed> Laney, broder: is the verobose output for that something you'd want in backport request bugs? or just a list of rdepend packages?
[14:35] <Laney> sorry, I haven't been following your development
[14:35] <tumbleweed> my backporst branch = lp:~stefanor/ubuntu-dev-tools/requestbackport
[14:35] <Laney> what is the verbose output?
[14:35] <tumbleweed> run reverse-depensd from that
[14:36] <geser> tumbleweed: can it be used to check for reverse-depends before filing a removal bug? list all reverse-(build-)depends for all binary packages of a source package
[14:37] <tumbleweed> that's a good point, one probably wants to query for source pakcages more than binary packages
[14:39]  * tumbleweed makes the DB schema even more complex
[14:39] <Laney> should it display --help if i run it with no arguments?
[14:39]  * tumbleweed is just using optparse's error-handling there
[14:40] <Laney> ./reverse-depends -b ghc died
[14:40] <Laney>   File "./reverse-depends", line 72, in main
[14:40] <Laney>     fields.append('Reverse-Recommends')
[14:40] <Laney> AttributeError: 'tuple' object has no attribute 'append'
[14:40] <tumbleweed> ta
[14:42] <tumbleweed> Laney: r1208
[14:43] <tumbleweed> probably no point in separating build-depends from build-depends indep, but it doesn't hurt either
[14:46] <tumbleweed> aha, wgrant is also guilty of unusually named changes files https://launchpad.net/ubuntu/feisty/+source/denyhosts/2.6-1ubuntu0.1
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[16:26] <broder> Laney: i think we are all agreeing loudly that backports *should* respect notautomatic, but i got the impression from infinity that that would be a lot of dev work, and we have multiple backports currently blocking on this bug, so we need an interim solution
[16:36] <slangasek> broder: gobject-introspection is not multiarch-friendly in many ways
[17:44] <pmjdebruijn> hi all
[17:44] <pmjdebruijn> https://launchpadlibrarian.net/84926948/buildlog_ubuntu-oneiric-amd64.libgusb_0.1.2-0pmjdebruijn1%7Eoneiric_FAILEDTOBUILD.txt.gz
[17:44] <pmjdebruijn> I have failing self-test that might be USB related
[17:44] <pmjdebruijn> the builds are taking place in Xen virtuals machines
[17:44] <pmjdebruijn> would it be reasonable to think that this is why the usb related test might fail?
[17:54] <geser> pmjdebruijn: does the documentation tell under which conditions the function this assert is checking might fail?
[17:55] <pmjdebruijn> I'm not sure
[17:55] <pmjdebruijn> didn't find it quickly
[17:55] <pmjdebruijn> it builds just fine on my laptop
[18:04] <geser> yes, this most likely is the cause
[18:18] <broder> cemc: i can't reproduce the hardy install failure you reported with a fresh install or with an upgrade from the hardy version
[18:20] <broder> cemc: is it possible you had installed your own backport before hand, where you hadn't changed the rules file?
[18:33] <broder> tumbleweed: i don't think we need anything in the bug as verbose as what reverse-depends spits out now
[18:33] <broder> i'm sort of experimenting at the moment, but it seems like something like http://pastebin.ubuntu.com/735526/ would be useful in the bug description
[18:34] <broder> (though i'm a bit torn on what to sort by first)
[18:35] <broder> tumbleweed: other notes: reverse-depends could stand to throw a nicer error on 404, and it would be nice if i didn't have to specify -a source separately to get r-build-deps
[19:29] <Laney> broder: so what solutions are on the table?
[19:53] <aboudreault> why my quilt push works.... bud debuild fails to apply my patch?
[19:54] <mewerner_arand> aboudreault: Are they by any chance already applied?
[19:54] <aboudreault> can't be.. otherwise my quilt push would'nt work in the same directory
[19:56] <mewerner_arand> Hmm...
[19:57] <aboudreault> can dh_quilt be more explicit?
[19:57] <aboudreault> verbose
[19:58] <jtaylor> no 3.0 package?
[19:58] <aboudreault> if I remove the first patch in the serie file... all other are applied.
[19:59] <aboudreault> but I can do a quilt push, and the patch is applied successfully
[20:00] <jtaylor> if its no 3.0 package is possible that its already applied
[20:00] <aboudreault> and I can't see the .rej
[20:01] <aboudreault> debian/source/format is 3.0
[20:01] <jtaylor> and its using dh_quilt?
[20:01] <jtaylor> thats not good
[20:01] <broder> Laney: infinity outlined them in the bug. they were (a) upgrade the sbuild lp uses, (b) somehow bypass NotAutomatic's effect on apt pinning, (c) hack sbuild to recognize when the resolver didn't install something because it's needed from backports and make it try again
[20:02] <broder> (bug 888665 for reference)
[20:02] <ubottu> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Undecided,Confirmed] https://launchpad.net/bugs/888665
[20:03] <broder> Laney: my opinion is obviously secondary to that of the lp admins, but by my judgement, (a) is the most elegant solution (and therefore good in the long term), (b) is the simplest solution (and therefore good in the short term), and (c) is neither simple nor elegant and therefore probably shouldn't be considered
[20:06] <micahg> and b is not a regression since this was the previous behaviour
[20:07] <broder> but honestly, i wouldn't care if we regressed or not because we currently have multiple backports blocked on this bug
[20:08] <micahg> well, it's problematic with backports on by default in oneiric
[20:09] <broder> huh, do the release/proposed/update pockets build with backports enabled then? i hadn't considered that
[20:10] <broder> i would have assumed that the sources.list for them are more hand-curated
[20:10] <micahg> no, but someone might get more backports than intended
[20:10] <broder> ah, sure
[20:10] <broder> i think that's comparatively minimal risk, though
[20:10] <broder> (since theoretically any backports they pick up should already have been tested against the oldpackages)
[20:10] <micahg> and is the previous behavior of backports
[20:13] <micahg> broder: BTW, we can't do component matching in backports since the components change between releases
[20:13] <micahg> err, what sources are where cahnges
[20:14] <broder> i know that's an issue. i had been led to believe it was possible for an archive admin to manually override component assignments when necessary
[20:14] <broder> alternatively, we could make the lp folks cry and have the component matching change between pre- and post- release
[20:15] <micahg> that would work :)
[20:16] <tumbleweed> broder: (re rev-build-deps) yeah agree about 404, I have uncommitted changes to do that, they'll land when I've finished with something else I'm hacking on
[20:17] <tumbleweed> broder: thanks for the paste, I can work with that
[20:17] <broder> i'm not totally in love with the format, because i think it'll blow up quickly, so if you have ideas for improvements i'm open to them
[20:19] <tumbleweed> broder: sure. Anyway, can't look right now, anyway
[20:19]  * broder nods
[22:47] <tumbleweed> broder: ok, error handling much improved, and can now do reverse-deps for all binaries produced by a source package. Implemented your example in requestbackport too
[22:52] <broder> tumbleweed: awesome. though i think you're using the source release for the backport to find r-deps, instead of the dest release
[22:52] <broder> ./requestbackport libgdata tells me i need to test claws-mail-gdata-plugin, which isn't in oneiric
[22:53] <tumbleweed> oh, true
[22:53] <tumbleweed> I was doing that right, and then thought I wasn't because of an unrelated bug
[22:53] <broder> heh. and i would find it helpful to have blank entries for packages with no r-deps, just so that we can see at a glance that they've been considered
[22:54] <tumbleweed> it's hard thinking about reverse-anything
[22:54] <tumbleweed> easy enough to add
[22:55] <broder> is it considering r-build-deps?
[22:56] <broder> (this looks awesome, though. i think having a standardized format for these things opens up a lot of possibility for speeding up and automating processing)
[22:56] <tumbleweed> should be
[22:56] <broder> doesn't seem to be catching them. reverse-depends src:libgdata doesn't either
[22:57] <broder> also, "The report has not been changed, but you have to explain why the Ubuntu changes can be dropped." i assume that's from cargo-culting requestsync code? :)
[22:58] <tumbleweed> you want reverse-depends -b src:libgdata
[22:58] <tumbleweed> heh, ok, so that needs refactoring :)
[22:59] <broder> ah
[23:01] <broder> tumbleweed: line 122, you iterate over arch in ('any', 'source'), then hardcode 'any'
[23:01] <broder> (also explains why it was listing everything twice :-P)
[23:03] <tumbleweed> ah, that's it
[23:03] <tumbleweed> that's the bug I was going after right now, too
[23:04] <tumbleweed> r1218
[23:06] <broder> awesome. oh, ugh. requestbackport -d natty libgdata seems to barf because the set of binary package names changed
[23:08] <tumbleweed> do you think my web API for the rdepends service is reasonable? It's a good idea to get that kind of thing right before depending on it...
[23:08] <tumbleweed> ah, easily solved with another defaultdict
[23:08] <broder> well, that would build-in a reliance that a given binary is always provided by the same source, wouldn't it?
[23:10] <broder> i think to do this right you might have to get the list of binary packages for the source package you're backporting from, then do a arch=source and arch=any r-deps query for each of those
[23:10] <broder> instead of using the src: query
[23:11] <tumbleweed> no, the problem here is simply a skew in binary names between source and target
[23:12] <tumbleweed> you want to list all binary names, so I was trusting the source to be the same as all the targets
[23:12] <tumbleweed> the src: query does exactly what you are suggesting
[23:13] <broder> are you sure? what happens if the package getting backported contains a binary that used to be provided by a different package (e.g. backporting git to when it was still called git-core)
[23:13] <tumbleweed> I don't see any reasonable way of solving that
[23:13] <tumbleweed> oh, right, sorry I misread your suggestion (1am...)
[23:14] <broder> no worries :)
[23:14] <tumbleweed> yeah, we could do that
[23:14] <tumbleweed> it'd be slower, of course
[23:15] <broder> right, more round trips
[23:15] <tumbleweed> (1am and a fair number of glasses of wine, perfect time for coding :P )
[23:15] <broder> we *could* work around that by making it possible to pass multiple arguments to the rdepends service, though you couldn't use the REST-y scheme you have now to do that
[23:16] <tumbleweed> yeah, I've pushed that scheme about as far as it can go
[23:18] <tumbleweed> would you even cosider a backport that builds a binary package also built by another source package (which is the only place where you'd expect to find reverse-dependencies that match this problem)
[23:21] <broder> i can imagine circumstances where i'd approve it
[23:21] <broder> e.g. a git backport, because gnuit/git didn't have any r-deps at the time
[23:22] <tumbleweed> is it worth the extra round trips?
[23:24] <tumbleweed> anyway, I pushed the defaultdict change
[23:41] <broder> i'd rather make the extra round trips and have the tool be correct. we can optimize for round trips later, but i don't want to have to clean up when we hit those corner cases
[23:54] <tumbleweed> broder: ok, I get the feeling I may want to be clearer about the ignored dependencies (like you were in your example)