[04:09] <eayoungs> disconnect
[06:25] <tumbleweed> bdrung: urgh, sorry, I temporarily broke our PPA. I accidentally jumped from 0.134 to 0.136 and then fixed it. I'll update the daily build to hardcode 0.136 until we've uploaded 0.135
[07:40] <hrw> cjwatson: sorry for mess. will do it better next time
[07:57] <dholbach> good morning
[07:58] <pmjdebruijn> morning
[08:16] <Laney> Subject: haskell-csv_0.1.2-1~bpo60+1_amd64.changes ACCEPTED into squeeze-backports
[08:17] <Laney> bdrung: ^
[08:17] <Laney> also, good morning :-)
[08:19] <nigelb> Morning Laney
[08:21] <cemc> broder: seems to be ok this time, tested the package and I've also updated the bugreport
[09:50] <Rhonda> huch
[09:50] <Rhonda> $> apt-get source qcake  # does fetch me 0.7.2-2build1 instead of what I expected from debian sid :)
[09:53] <Laney> pull-debian-source :-)
[11:56] <dupondje> pbuilder really doesn't show cleanly what depend its missing when I try to build something :(
[11:56] <dupondje> any idea's how I can find out what one is th blocker ?
[12:10] <dupondje> http://pastebin.ubuntu.com/738142/
[12:10] <dupondje> whats missing now :s
[12:22] <geser> that's the reason I use gdebi for build-depends installation as it passes the list of packages to apt instead of a dummy package
[12:22] <cjwatson> suspicious for *all* those to be virtual.  I wonder if it's forgotten about some important Packages files.
[12:22] <cjwatson> if it's etch, well, who knows
[12:24] <geser> dupondje: login into that pbuilder and check if the sources.list looks good
[12:27] <dupondje> deb http://archive.kernel.org/debian-archive/debian-security/ etch/updates main
[12:27] <dupondje> deb http://ftp.de.debian.org/archive/ etch main contrib non-free
[12:27] <dupondje> looks fine :s
[12:28] <cjwatson> apt-get update and see if you can e.g. 'apt-cache show autoconf'
[12:30] <dupondje> works fine
[12:32] <geser> hmm
[12:32] <dupondje> its weird
[12:32] <dupondje> tried to apt-get some packages, and it works just fine in the pbuilder
[12:32] <dupondje> so it can get the packages
[12:35] <dupondje> hmz
[12:35] <dupondje> 646008
[12:36] <dupondje> err
[12:36] <dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646008
[12:52] <dupondje> W: Couldn't stat source package list http://ftp.debian.org etch/main Packages (/var/lib/apt/lists/ftp.debian.org_debian_dists_etch_main_binary-amd64_Packages) - stat (2 No such file or directory)
[12:52] <dupondje> keeps trying to look at those files also for some reason :)
[12:54] <StevenK> dupondje: etch is no longer on ftp.d.o
[12:54] <dupondje> I know, I supplied --mirror archive.de.debian.org .. but still looks for that file somehow
[12:55] <StevenK> archive.de.debian.org == NXDOMAIN
[12:56] <dupondje> errr ftp.de.debian.org
[12:57] <StevenK> Etch isn't on http://ftp.de.debian.org/debian/dists/ either
[12:57] <StevenK> Try --mirror http://ftp.de.debian.org/archive/
[12:59] <dupondje> deb http://ftp.de.debian.org/archive/ etch main contrib non-free
[12:59] <dupondje> have this now in source.list
[12:59] <dupondje> sources.list*
[13:01] <StevenK> That should actually work
[13:02] <StevenK> However, pbuilder does its work in two steps
[13:02] <StevenK> There is the debootstrap phase, which uses --debootstrap-mirror or so, and the second phase, which installs build-essential and so on, which uses --mirror
[13:03] <StevenK> Oh, you have to use --debootstrapopts
[13:04] <StevenK> --debootstrapopts http://ftp.de.debian.org/archive/ --mirror http://ftp.de.debian.org/archive/
[13:05] <dupondje> lets try :)
[13:10] <dupondje> I: running debootstrap
[13:10] <dupondje> /usr/sbin/debootstrap
[13:10] <dupondje> E: No such script: http://ftp.debian.org/debian
[13:10] <dupondje> what ?! :)
[13:11] <dupondje> lets try again
[13:13] <dupondje> nope :(
[13:13] <dupondje> W: Couldn't stat source package list http://ftp.debian.org etch/main Packages (/var/lib/apt/lists/ftp.debian.org_debian_dists_etch_main_binary-amd64_Packages) - stat (2 No such file or directory)
[13:13] <dupondje> still same error :(
[13:15] <Laney> you probably want archive.debian.org
[13:16] <dupondje> lets see if that works
[13:17] <Laney> the dists/ directory is useful to see what a mirror has
[13:17] <dupondje> I: Retrieving Packages
[13:17] <dupondje> and then nothing ... :)
[13:17] <Laney> wait?
[13:18] <Laney> http://archive.debian.org/debian/dists/etch/Release
[13:20] <dupondje> its still showing Retrieving Packages :s
[13:20] <dupondje> weird
[13:28] <dupondje> that doesn't seem to work, still waiting for 'Retrieving Packages' :(
[13:28] <dupondje> pbuilder-dist etch create --mirror http://archive.debian.org/debian/
[13:56] <dupondje> bleh :( unable to fix it :(
[14:15] <dupondje> pfft, whatever I try to do, it wants to use ftp.debian.org
[14:20] <geser> check with --debug-echo if pbuilder-dist does correctly pass your --mirror to the real pbuilder
[14:24] <dupondje> ['sudo', 'HOME=/home/dupondje', 'ARCH=amd64', 'DIST=etch', 'pbuilder', '--build', '--distribution', 'etch', '--buildresult', '/home/dupondje/pbuilder/etch_result/', '--aptcache', '/var/cache/apt/archives/', '--override-config', '--basetgz', '/home/dupondje/pbuilder/etch-base.tgz', '--logfile', '/home/dupondje/pbuilder/etch_result/last_operation.log', '--bindmounts', '/var/cache/archive/', '--mirror', 'http://ftp.debian.org/debian', '--debootstrapo
[14:24] <dupondje> 2 times --mirror it seems :s
[14:28] <geser> try setting MIRRORSITE="http://archive.debian.org/debian/" before calling pbuilder-dist (I hope I read the code correctly)
[14:32] <dupondje> doesn't seem to work neither :(
[14:36] <geser> let's see if bdrung or tumbleweed can help you as they hopefully know better how the mirror selection in pbuilder-dist work
[14:38] <tumbleweed> there is no mirror selection
[14:38] <tumbleweed> but we just fixed that in trunk
[14:41] <dupondje> where exactly ? :)
[14:41] <tumbleweed> dupondje: lp:ubuntu-dev-tools (or just grab a recent build from the ubuntu-dev-tools ppa: https://launchpad.net/~udt-developers/+archive/daily
[14:46] <dupondje> anyway did some mods in the code now, and its working :)
[14:46] <dupondje> finally :)
[14:47] <dupondje> thanks all!
[17:43] <tumbleweed> Laney: how tolerant are we about duplicates in ubuntu_uplaod_history?
[17:43] <Laney> in what way?
[17:44] <tumbleweed> it looks like the mboxes are going to get some duplicates
[17:44] <tumbleweed> same history item imported in a second run
[17:44] <Laney> from your data?
[17:44] <tumbleweed> I'm cleaning them up by hand, but I'm wondering if that's necessar, and wondering if that'll be happening in the future too
[17:44] <tumbleweed> yeah
[17:45] <tumbleweed> finished importing, btw
[17:45] <tumbleweed> just topping up the ends, with uploads since I imported each series, which is why I'm seeing this
[17:47] <tumbleweed> I think getPublishedSources() continues picking up new records that land while you are iterating thorugh it
[17:47] <Laney> nice
[17:48] <Laney> so we should go back to taking the mtime at the end?
[17:48] <Laney> end of the loop
[17:48] <tumbleweed> well, then we risk losing things. Which is why I'm asking how duplicate-sensitive we are
[17:48] <tumbleweed> also, we are trusting the Dates in the changes files, which can be a month or two out of sync with the publication date
[17:49] <tumbleweed> don't know if you'd noticed that
[17:49] <Laney> not as created_since_date?
[17:51] <Laney> i don't see how you lose things if you getPublishedSources behaves as you say and we take the timestamp at the right time
[17:51] <tumbleweed> I mostly noticed it with kernel SRUs, which probably spenda while being tested in a PPA, so that might be correct behavior
[17:52] <tumbleweed> Laney: well, we don't know at what point it stops noticing new things
[17:52] <tumbleweed> but I'm pretty sure it picked up things that appered during a 8 hour run
[17:54] <tumbleweed> oh my per-release changes were probably also completely unhelpful for your normal cronjob use, because it would only look at the devel release. I've just committed a fix for that.
[17:54] <Laney> you could take the latest created date you see as the next starting time
[17:55] <tumbleweed> that sounds correct
[17:55] <Laney> maybe +1 if it is inclusive
[17:55] <tumbleweed> it is according to the docs
[17:56] <Laney> i start seeing python i don't understand
[17:56]  * Laney quivers
[17:58] <tumbleweed> **params ?
[17:58] <Laney> yep
[17:58] <Laney> did lp have correct changesfile links all the way back?
[17:58] <tumbleweed> it's pretty straight-forward :)
[17:59] <tumbleweed> check the log files: http://people.ubuntuwire.org/~stefanor/out/ (I can tar + gz if you want)
[17:59] <tumbleweed> there were a good number of missing changes files in the middle, and the occasional missing changelog everywhere
[18:00] <Laney> if it did then we can forget about merging with the old data
[18:00] <tumbleweed> grep Traceback out/*.log | wc -l
[18:00] <tumbleweed> 14
[18:01] <tumbleweed> $ grep skipping out/*.log | wc -l
[18:01] <tumbleweed> 14
[18:01] <tumbleweed> ah, those went together, nm that
[18:01] <Laney> seems ok
[18:02] <Laney> i had already merged your branch which defaulted to the dev release :(
[18:02] <tumbleweed> ooh, a changes file without a version :)
[18:02] <Laney> so if you can make sure that < precise are current when i take them
[18:03] <tumbleweed> ok, oneiric is still importing
[18:03] <tumbleweed> and I think we can get the samp files to behave correctly before the SRU people accept anything more
[18:04] <tumbleweed> $ grep '404 for \.changes' out/*.log | wc -l
[18:04] <tumbleweed> 567
[18:07] <cjwatson> dear etherpad, stop signing me out every five minutes
[18:08] <ogra_> builtin typing break :)
[18:19] <Laney> just got a text reading "Steak!"
[18:19] <Laney> therefore I am afraid UDD will have to wait :P
[18:20] <tumbleweed> \o/
[18:20] <Resistance> ;p;
[18:20]  * tumbleweed should eat too
[18:20] <Resistance> lol *
[18:20] <Laney> however I discovered timestamp.resolution
[18:20] <Laney> params['created_since_date'] = since + timedelta.resolution or summat
[18:20] <Laney> ttyl
[19:10] <cemc> broder: ping.
[19:10] <broder> cemc: yes?
[19:10] <cemc> broder: what happens now with that pdns-recursor backporting?
[19:11] <cemc> https://bugs.launchpad.net/hardy-backports/+bug/888627
[19:11] <Resistance> hey broder i have a question for ya if you wouldnt mind a /query
[19:12] <broder> cemc: backports require an archive admin to process, so we're waiting for them to do that
[19:12] <broder> Resistance: yes?
[19:13] <Resistance> broder:  you have the message via /query... partly because i dont want to fill the channel and partly because i had already typed /msg broder :P
[19:13] <cemc> broder: right, ok. thanks for the help. or, better yet thanks for doing it ;)
[19:13] <broder> cemc: i'll have to upload the hardy backport by hand since there are source changes, but i want to hold off on doing that until the others have been processed
[19:14] <cemc> broder: got it. let me know if there's anything I can help with
[19:14] <Resistance> broder:  also, how often is packages.ubuntu.com updated with what has been put into the <dist>-backports repos for each distribution/release?
[19:14] <broder> Resistance: i know nothing about how packages.u.c is run
[19:15] <Resistance> broder:  then perhaps you can tell me how i can check the oneiric repos from a natty system?
[19:15]  * Resistance isnt even sure that's possible
[19:15] <broder> https://launchpad.net/ubuntu/+source/<package> will list the versions in all pockets for all current releases
[19:15] <broder> that's source package, not binary package
[19:15] <Resistance> indeed
[19:15] <Resistance> oop nevermind, i got my answer
[19:15] <Resistance> :)
[19:16]  * Resistance found what he was looking for
[19:18] <tumbleweed> Laney: hrm, I'm not convinced we have the right stamp file handling yet. The things that were uploaded during the scraping appared in the right places alphabetically. That means, to me, that we can't know whether we picked up everything that was uploaded during scraping
[19:18] <Laney> let's just ask someone what it is supposed to do
[19:23] <Laney> if it is indeed like that then we'll just have to ignore things uploaded after we made the request
[19:23] <Laney> created
[19:23] <tumbleweed> that's another option
[19:29] <tumbleweed> Resistance: please don't worry about asking questions here. That's what the channel's for. Generally asking thinsg in public is better than private, because more people can help out
[19:30] <Resistance> tumbleweed:  true, but it wasnt a support question  ;P
[19:30] <tumbleweed> Resistance: there's also rmadison (the command)
[19:30] <tumbleweed> this isn't a support channel, it's (amongst other things) a place where people learn their way around ubuntu development
[19:31] <Resistance> indeed
[19:31] <Resistance> next time i'll post here :P
[19:31]  * Resistance goes back to hunting down an elusive bug in a program he coded.
[19:48] <blair> hello, i've prepared a merge to update the rbtools package (https://code.launchpad.net/~blair/ubuntu/precise/rbtools/rbtools-fix-886436/+merge/81388) and it's failing for a reviewer with this bzr merge error: bzr: ERROR: None 0.3.4 was not found in <PristineTarSource ...>.  What am I missing?  It looks like I just need to run bzr merge-upstream?  I already unpacked and dropped the upstream tarball in this branch
[19:56] <blair> does bzr merge-upstream manage everything with dropping a new tarball into an existing checkout?
[20:07] <tumbleweed> blair: no idea. But you should be trying to get that through debian, if possible
[20:08] <blair> tumbleweed, i have a ticket opened, cloned debian's git repository for the package, updated the package and pushed it to github for them to download, but there's been no movement yet
[20:10] <tumbleweed> ah. I see that debian bug, but no mention of your github repo in it
[20:13] <blair> ok, i was privately emailing the debian maintainer, i'll put that into the ticket
[20:14] <tumbleweed> any reply from him?
[20:20] <blair> tumbleweed, no.  also, i just updated the ticket with my work, github location and a few questions
[20:29] <tumbleweed> blair: to answer your questions, git-buildpcakge includes tools to make importing new upstream sources easy
[20:29] <tumbleweed> and yes, it's normal to delete files during build. We delete files that get automatically generated. If we don't delete them, our tools assume we intentionally modified them.
[20:30] <blair> tumbleweed, thanks, i'll remember using git-buildpackage
[21:32] <broder> tumbleweed: hmm...so backportpackage doesn't actually look at the forward deps/build-deps of a package
[21:33] <broder> i know that's obviously tricky because of substvar stuff
[21:37] <tumbleweed> broder: you mean check if it's backportable?
[21:37] <broder> yeah
[21:38] <tumbleweed> yeah, that can't be completely analyzed statically
[21:38] <broder> right
[21:39] <broder> i'm looking at bug #890191. usb-modeswitch-data has a breaks: usb-modeswitch (<< older than natty or so), and i'm trying to figure out if an automated tool should be determining that so i don't have to, and if so which automated tool that should be
[21:39] <broder> (i.e. requestbackport vs. my backport-bug-supervising-bot pony)
[21:39] <CarlFK> james_w:     http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/squid-deb-proxy/oneiric/view/head:/debian/squid-deb-proxy.postinst   Revision ID: james.westby@ubuntu.com-20110630120919-bu7qhz6foun4r58y
[21:40] <CarlFK> james_w:  that's you, right?  (and ping.. no clue if you are around)
[21:40] <james_w> CarlFK, yeah, but it's a bot
[21:40] <tumbleweed> broder: test build it :)
[21:40] <broder> yeah, probably the right answer
[21:40] <CarlFK> james_w: what's a bot?
[21:41] <james_w> CarlFK, a robot, an unattended process
[21:41] <tumbleweed> broder:  a lot of the time, it's tight a debhelper dependency that could be loosened with some rules tweaks, or something like that
[21:42] <CarlFK> um.. never mind the bot confusion.. that postinst - I think it is stepping on the installer's proxy setting:             Bug #889656
[21:42] <tumbleweed> broder: it's certainly possible to highlight potential problems, but there'd be false positives & negatives
[21:43] <broder> yeah. i think i'll plan to put that sort of logic into my bot, since that way i can change it without having to push out patches
[21:43] <CarlFK> wondering if my conclusion is reasonable
[21:49] <james_w> CarlFK, sounds possible
[21:49] <james_w> I don't know any specifics about that package though
[21:50] <CarlFK> james_w: k - I'll add it to the bug.
[22:17] <CarlFK> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/squid-deb-proxy/oneiric/files/head:/debian/
[22:18] <CarlFK> that has both squid-deb-proxy-client and squid-deb-proxy
[22:18] <CarlFK> what scripts get run if I just install squid-deb-proxy-client ?
[22:26] <RAOF> CarlFK: If you just install squid-deb-proxy-client there are no maintainer scripts.
[22:28] <CarlFK> RAOF: k .. where is the list of what gets installed where?
[22:29] <CarlFK> I am guessing this gets put in /etc/apt/apt.conf.d/   http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/squid-deb-proxy/oneiric/view/head:/30autoproxy
[22:29] <RAOF> CarlFK: debian/squid-deb-proxy-client.install
[22:31] <CarlFK> RAOF: forgive my ignorance... what do those 2 lines tell me?
[22:32] <RAOF> Those are the things which are in debian/tmp after the upstream build/install process has finished that will be in the squid-deb-proxy-client package.
[22:33] <broder> CarlFK: you might want to check out the packaging guide if you're trying to understand how a particular package works. http://developer.ubuntu.com/packaging/html/debian-dir-overview.html in particular seems relevant
[22:34] <CarlFK> broder: hoping not to have to go that deep :)
[22:34] <CarlFK> but I just found what I was looking for
[22:34] <broder> i think you already might be that deep
[22:34] <CarlFK> heh
[22:34] <broder> (the page i linked is honestly fairly surface-level and introductory)
[22:44] <CarlFK> woo... I am on my way back up!  broken install fixed with: rm /target/etc/apt/apt.conf.d/30autoproxy
[22:44] <CarlFK> which seems enough detail for the bug report
[22:44] <CarlFK> fixing it is someone elses problem
[22:50] <broder> CarlFK: it sounds like squid-deb-proxy-client just doesn't work inside a chroot
[22:51] <CarlFK> broder: depends on your definition of "work" :)
[22:51] <CarlFK> my install uses d-i mirror/http/proxy string http://chris:8000/
[22:51] <CarlFK> squid-deb-proxy-client seems to clobber that
[22:52] <broder> ...right. that seems like it's by design
[22:52] <CarlFK> yeah, I am not sure what 'right' is
[22:53] <broder> i think there's an issue that /usr/share/squid-deb-proxy-client/apt-avahi-discover will return a bogus result if there's no avahi-advertised proxy available
[22:54] <broder> but squid-deb-proxy-client's design is that you install it and it starts using that proxy
[22:54] <CarlFK> broder: well, the proxy is there and advertising..
[22:54] <broder> advertising over avahi?
[22:54] <CarlFK> yep
[22:55] <broder> ok, then my next guess would be that the debian-installer environment doesn't have avahi setup and working, and the package relies on that
[22:55] <CarlFK> install finished and rebooted.. I need to get back into the installer shell and see if I can run apt-avahi-discover
[22:55] <CarlFK> right
[22:57] <broder> that seems pretty likely, given the constraints on d-i
[22:58] <CarlFK> im actually wondering why it is stepping on the installers settings
[22:59] <CarlFK> my guess is the installer is doing a chroot before things are setup enough
[22:59] <broder> it's stepping on the installer settings because the purpose of the package is to step on settings
[22:59] <broder> if you don't want the package changing the proxy settings, you shouldn't install it
[22:59] <broder> that's how this particular package works
[23:01] <CarlFK> but the installer has it's own settings
[23:01] <CarlFK> kinda like it has its own root user
[23:01] <broder> no, the installer has settings that it injects into the target chroot when it starts
[23:02] <broder> anyway, i argue that the real bug is that apt-avahi-discover prints out something (and even worse, something starting with "http://") when it can't find anything
[23:03] <broder> if it exited without printing anything when it didn't find a result, apt would ignore it and everything would be fine
[23:10] <CarlFK> ~ # chroot /target /usr/share/squid-deb-proxy-client/apt-avahi-discover
[23:10] <CarlFK> Failed to create client object: Daemon not running
[23:11] <CarlFK> but it returns: http://:/
[23:13] <broder> exactly
[23:14] <broder> (the "failed to create client object" bit is probably not problematic, because it's almost certainly printed to stderr and not stdout
[23:14] <broder> )
[23:16] <CarlFK> so my solution is to not install that as part of the install.  I'll let someone else figure out how it should behave
[23:17] <CarlFK> bug 889656
[23:17] <broder> bah. you're going to make me go fix it now
[23:17] <CarlFK> lol
[23:17] <broder> i'm supposed to be working
[23:17] <CarlFK> didn't know you were the someone else
[23:17] <broder> i get irritated when i see simple bugs where i understand the solution unfixed
[23:18] <Resistance> haha lol
[23:18] <broder> it's something of a character flaw
[23:18] <CarlFK> I know the feeling
[23:19] <CarlFK> I pretty much spent all day tracking this down, even though it wasn't causing a real problem
[23:19] <CarlFK> I just had to allow a bit of traffic to not be proxied,and I am just using the proxy for speed
[23:20] <CarlFK> the speed boost will probably never save me 8 hours :)
[23:28] <tumbleweed> bdrung: I think I've come to the end of my current u-d-t TODO list. So I'm ready for an upload whenever you are.
[23:28] <tumbleweed> I haven't moved the EditFile stuff. If you feel strongly about that, please move it.
[23:30] <tumbleweed> there's some biggish changes, I want people to use them and find the bugs I couldn't :)
[23:31] <tumbleweed> actually, not so big
[23:34] <CarlFK> broder: thanks for your help - I am off for today.
[23:35] <bdrung> tumbleweed: C:265:PbuilderDist.get_command: Invalid name "di" (should match [a-z_][a-z0-9_]{2,30}$)
[23:36] <bdrung> in pbuilder-dist
[23:37] <tumbleweed> yeah, I know :) at the time I used that, the line was not easily wrappable
[23:37] <tumbleweed> committed
[23:37] <bdrung> requestbackport -> W: 75:find_rdepends: Unused argument 'package'
[23:38] <tumbleweed> ah, I reworked the substitution
[23:39] <bdrung> W:149:request_backport: Access to a protected member _lpobject of a client class
[23:39] <tumbleweed> not much alternative there
[23:39] <tumbleweed> I suppose one could extend lpapicache further
[23:40] <bdrung> yes, it should have a public function
[23:41] <tumbleweed> fortunatly, that's easy. There are areas of lpapicache that are hard to extend
[23:43] <bdrung> tumbleweed: C:194:EditBugReport.get_report: Invalid name "m" (should match [a-z_][a-z0-9_]{2,30}$)
[23:43] <bdrung> tumbleweed: m -> match
[23:43] <bdrung> in question.py
[23:43]  * tumbleweed finds that silly, m is a common variable when doing regex stuff in python, but sure
[23:44] <bdrung> tumbleweed: m isn't common for me
[23:44] <bdrung> i, j, k, and f are common
[23:45] <bdrung> tumbleweed: besides that, go ahead
[23:51] <tumbleweed> bdrung: ok, uploading