=== ampharmex is now known as perdent
=== perdent is now known as carlesma
[02:01] <psusi> I have noticed some udev attributes like this: ID_MODEL_FROM_DATABASE=P8P67 Deluxe Motherboard.  Where does this come from?  Is there a database somewhere one could record that it is known on such and such model motherboard that ata port X is in fact, esata?
[02:58] <cjwatson> xnox: Could you please merge qutecom for the libav transition?
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk
[05:32] <pitti> Good morning
=== BruceMa is now known as BruceMa-afk
[06:31] <dholbach> good morning
[08:13] <xnox> cjwatson: ack.
[08:50] <LocutusOfBorg1> Hi ubuntu developers
[08:51] <LocutusOfBorg1> do you think flex should be demoted on universe?
[08:51] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/flex
[08:51] <LocutusOfBorg1> the last -8 upload needs cm-super, available on universe
[08:52] <LocutusOfBorg1> so there is a FTBFS because of the missing dependency on i386 (B-D-I)
[08:55] <xnox> LocutusOfBorg1: no, we can't demote flex. Because then a good chunk of main will not be able to build anymore.
[08:56] <seb128> LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/flex/flex
[08:56] <xnox> LocutusOfBorg1: we'd typically promote cm-super-minimal into main, or modify documentation building process to not require it.
[08:57] <Laney> https://bugs.launchpad.net/ubuntu/+source/cm-super/+bug/1328509
[08:57] <ubottu> Ubuntu bug 1328509 in pfb2t1c2pfb (Ubuntu) "[MIR] cm-super, build dependency of gdb-doc" [Undecided,Incomplete]
[08:59] <xnox> slangasek: bmurray: can you please subscribe foundations to pfb2t1c2pfb ?
[08:59] <xnox> (ps. not a typo)
[08:59] <Laney> bless you
[08:59] <xnox> should unblock above MIR ^
[09:07] <LocutusOfBorg1> :) yes a MIR is indeed better :)
[09:27] <pitti> xnox: pronounce that 5 times in succession?
[09:28] <xnox> pitti: "that p package's name i have written on the post-it note" http://xkcd.com/1105/
[09:28] <Laney> it's a silly name for a package which contains two conversion tools: pfb2t1c and t1c2pfb
[09:29] <pitti> haha
=== vrruiz_ is now known as rvr
=== iulian_ is now known as iulian
[09:51] <cjwatson> Riddell: Hm, why the weird merged version for opencv?
[09:53] <menace> Hi, i wanted to testbuild libreoffice on ubuntu. i did apt-get build-dep libreoffice ; apt-get source libreoffice ; i only updated the changelog of the libreoffice file and tried to rebuild it with dpkg-buildpackage -uc -us. But it breaks on trusty with an compilation error (http://pastebin.com/zBd2Fj7p). Since packages should be able to be rebuilt, why does that fail? Any Idea?
[09:57] <infinity> menace: This is fixed in trusty, and will be fixed in utopic in the next upload.
[09:58] <infinity> menace: This diff will fix it for you: http://launchpadlibrarian.net/177856415/libreoffice_1%3A4.2.4-0ubuntu1_1%3A4.2.4-0ubuntu2.diff.gz
[09:59] <Riddell> cjwatson: oh yes, my mistake, do you know I should upload again with the right version number?
[09:59] <cjwatson> Riddell: Not urgent, if you like, was just wondering
=== roadmr is now known as roadmr_afk
[10:41] <TheMuso`> Does anybody know if we are likely to move to kmod version 17 this cycle?
[10:42] <pitti> TheMuso`: we should certainly merge it, particularly if it's blocking you or anyone else
[10:49] <TheMuso`> pitti: Its not blocking me as such, but alsa bits in Debian are starting to depend on it, and keeping in sync would be easier if we were in lock step with kmod.
=== TheMuso` is now known as TheMuso
=== MacSlow is now known as MacSlow|lunch
[11:24] <menace> infinity: thanks, I try that
[11:26] <menace> aeh, wait a minute, infinity. i use trusty with updates and it does not work for me... but i'll try your diff.gz anyway :)
[11:27] <menace> though i have libreoffice 4.2.3~rc3
[11:28] <bluesabre> sponsors, sru team, can we upload these items to -proposed to begin verification?
[11:28] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
[11:28] <ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
[11:28] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[11:28] <ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
=== roadmr_afk is now known as roadmr
[11:34] <infinity> TheMuso: I can merge it.
=== ara is now known as Guest7746
=== MacSlow|lunch is now known as MacSlow
[12:20] <infinity> xnox: What was wrong with the xbmc upload 10 hours ago? :P
[12:42] <mlankhorst> does anyone want to sponsor https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff for me? debdiff is against the debian version
[12:43] <mlankhorst> oh woops
=== _salem is now known as salem_
=== salem_ is now known as _salem
[12:49] <xnox> infinity: lack of coffeine in my body? =)
[12:51] <cjwatson> brendand,mvo: sorry, I'm going to have to miss this call this week - I left a brief report in the calendar invite
[12:51] <brendand> cjwatson, np - thanks
[12:52] <mvo> cjwatson: no problem (from my side), thanks for the note
[12:52] <mvo> s
[12:58] <pitti> cjwatson: \o/ congrats for landing the image builds on buildds, really nice!
[13:11] <mlankhorst> oh fixed the build issue, https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff
[13:15] <infinity> mlankhorst: Looking.
[13:18] <GunnarHj> Anybody in the SRU team who can take a look at bug 1308771? What makes it special is that the fix consists of two new binaries.
[13:18] <ubottu> bug 1308771 in openoffice.org-hyphenation (Ubuntu Trusty) "Update Swedish spellcheck and hyphenation dictionaries" [Low,Triaged] https://launchpad.net/bugs/1308771
[13:20] <tseliot> bdmurray: hey, can you approve nvidia-prime in precise-proposed, please? It fits the same use cases of ubuntu-drivers-common
[13:25] <tseliot> bdmurray: actually, let's hold off, I might as well check a few oem details first while I'm at it
[13:26] <infinity> mlankhorst: You shouldn't have dropped the delta on patches/lldb-link-atomic.diff
=== _salem is now known as salem_
[13:27] <mlankhorst> why's that?
[13:27] <mlankhorst> (it was conflicting, so i figured the debian one was more up to date)
[13:27] <infinity> mlankhorst: Did you look at the delta?  We just drop the conditional.
[13:28] <infinity> mlankhorst: The Debian one is still wrong, just slightly less wrong than it used to be.  Adjusting for the fuzz would have been the right thing.
[13:28] <mlankhorst> ok
[13:28] <mlankhorst> want me to redo it or?
[13:28] <infinity> Nah, I'll fix it.
[13:28] <mlankhorst> ok thanks
[13:29] <infinity> Just going through the rest of the review before I sponsor.
[13:34] <GunnarHj> bdmurray: ping?
[13:35] <ChrisTownsend> I'm prepping the next Unity SRU for Trusty and we would like to include a fix that has a new string.  What is the policy for handling this regarding localization/documentation/etc?
[13:35] <seb128> ChrisTownsend, "don't do that" would be the default response there ... what's the string/where is it going to be displayed?
[13:36] <ChrisTownsend> seb128: It's  a string in the lcokscreen telling the user the Caps lock is on.  Give me a sec and I'll give you the exact string.
[13:37] <seb128> ChrisTownsend, do you have a bug report about that/a screenshot?
[13:37] <infinity> ChrisTownsend: Like a hover text over the /!\ icon?
[13:38] <ChrisTownsend> seb128: I'll get that to you in a sec.  Trying to find the bug in my sea of open tabs.
[13:38] <ChrisTownsend> infinity: Yes
[13:38] <infinity> seb128: You can see it on utopic.  Ctrl-Alt-L, hit caps lock, hover over icon.
[13:39] <infinity> ChrisTownsend: Generally, the answer to new strings is "just don't", but since it's not visible except on hover, maybe the added functionality is worth the lack of translation.
[13:39] <infinity> ChrisTownsend: Though, if you could get some translations in too, that would be much better.
[13:39] <seb128> ChrisTownsend, what infinity said
[13:39] <seb128> having translations is doable
[13:39] <seb128> upload a new template to launchpad, which includes the string
[13:40] <seb128> wait for translators to work on it, and for a langpack export
=== shadeslayer_ is now known as shadeslayer
[13:40] <seb128> then include the code change
[13:40] <infinity> Well, we'll spin new langpacks for 14.04.1 in a couple of weeks, probably.
[13:40] <seb128> we did it for the logout-when-other-users-are-connected dialog
[13:40] <infinity> So, if one can get it well-translated by then, that would be great.
[13:40] <seb128> right
[13:40] <seb128> launchpad shares strings between series I think
[13:41] <infinity> But, being a mouseover hover, I'm also not hugely put out by it being untranslated at first.
[13:41] <seb128> so it might already be translated in utopic and trusty should get those once the template is updated
[13:41] <seb128> yeah, same here
[13:41] <ChrisTownsend> infinity: So it's ok to go ahead and include the fix in our next SRU and let the translations catch up?
[13:41] <infinity> ChrisTownsend: Yeah, I think that's fine.
[13:41] <ChrisTownsend> infinity: Cool, thanks.
[13:42] <ChrisTownsend> seb128: Thanks to you too:)
[13:42] <seb128> ChrisTownsend, just make sure the string is included in the translation template
[13:42] <infinity> ChrisTownsend: But if you guys can follow up on the state of the string in LP and see what it'll look like for 14.04.1, that would be nice.
[13:42] <seb128> yw!
[13:42] <ChrisTownsend> seb128: Will do
[13:42] <ChrisTownsend> infinity: Ok
[13:42] <zyga> sergiusens: rsync works :)
[13:42] <zyga> sergiusens: I got a way to use rsync that works with the likes of phablet-shell
[13:42] <zyga> sergiusens: and it's x10 faster from what I see
[13:43] <zyga> sergiusens: I can show you the patches if you want to see
[13:43] <sergiusens> zyga: sure; sounds good
[13:43] <seb128> could somebody from the SRU team review libdbusmenu in the trusty queue? it's a simple diff and it has been there for a while, locking a landing silo
[13:44] <infinity> seb128: Ahh, yeah, now that the KDE stuff is all cleared out, I can read the queue again!
[13:44] <seb128> infinity, ;-)
[13:47] <infinity> mlankhorst: Uploading.
[13:47] <mlankhorst> ty
[13:50] <infinity> seb128: Accepted.
[13:50] <seb128> infinity, thanks
=== salem_ is now known as _salem
=== timrc-afk is now known as timrc
[14:06] <cjwatson> mvo: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/lastBuild/? \o/
=== pete-woods1 is now known as pete-woods
[14:10] <mvo> cjwatson: yeah!
[14:11] <mvo> cjwatson: that looks great! I was wondering if something like https://code.launchpad.net/~mvo/cupstream2distro-config/click-tests-against-devel-branch/+merge/224140 would help us too, i.e. run the jenkins-bot on all MPs against lp:click/devel (it seems to be defaulting to lp:click currently)
[14:14] <menace> how can i recognize if a package is a virtual package? is there any way to see this in the control/apt-cache show part?
[14:15] <infinity> menace: If it's a virtual package, it doesn't exist.  That's sort of the point.
[14:16] <infinity> (base)adconrad@cthulhu:~$ apt-cache show mail-transport-agent
[14:16] <infinity> N: Can't select versions from package 'mail-transport-agent' as it is purely virtual
[14:16] <infinity> menace: ^-- As an example.
[14:16] <cjwatson> mvo: Ah, that sounds like it'd make sense
=== _salem is now known as salem_
[14:17] <OdyX> tkamppeter: sorry, my cups-filters 1.0.54-2 upload had my local-non-committed-failing autopkgtests in it. I will upload an updated cups with the running script installed and then upload a new cups-filters with the filters activated or the tests removed.
[14:17] <infinity> mlankhorst: I'm cancelling your PPA builds of llvm to reclaim buildd resources, since that seems somewhat redundant with the distro upload.
[14:18] <menace> hrm, i'm updating packages in our distribution (based on ubuntu) in dak. and i already missed with the kernel-package and the ssh-package the concrete packages, because i just imported the virtual packages *headscratch*
[14:18] <mlankhorst> sure
[14:19] <xnox> menace: "imported the virtual packages" not sure that would be possible..... you possibly imported some package that is a provider of it. What are you trying to achieve, how & why? Maybe there is a better way to do it....
[14:19] <mlankhorst> oh the llvm-toolchain ftbfs for ppc64el seems to not be a new one
[14:19] <mlankhorst> goodie
[14:20] <infinity> mlankhorst: Yeah, it's been like that for a while.  We'll get it sorted at some point.
[14:22] <cjwatson> Riddell: For the opencv/arm64 failure, I think disabling precompiled headers on arm64 is the right fix for now - I've had to do that in a few other places
[14:22] <infinity> cjwatson: Do we know if that's fixed in gcc-4.9?
[14:22] <cjwatson> Not for sure
[14:22] <infinity> (And why it seems to have broken only in utopic...?)
[14:23] <infinity> Actually, hrm, I wonder if this spells doom for the gcc-4.8 microrelease SRU too.
[14:23] <menace> well, i want to update packages from precise to OurCodeName via dak. and it happened a few times, when i updated the linux meta-package, the the dependent packages would not be updated. and as far as i saw, this was because the meta-package is virtual or has a new name
[14:24] <infinity> menace: That doesn't sound like it has anything to do with virtual packages, just that you need to import both the "linux-meta" and "linux" source packages.
[14:24] <menace> something similar seemed to happen with the ssh package as well. i'm not very sure, how to work with dak correct with that issue..
[14:24] <menace> hrm
[14:25] <menace> i'll come back when i better understand my problems :)
[14:34] <bdmurray> GunnarHj: hello
[14:38] <Riddell> thanks cjwatson
[14:45] <xnox> menace: neither linux-meta nor linux are virtual. Simply each abi bump changes the binaries package names on the linux package, and the deps change name on linux-meta. If you import one without the other, your archive is inconsistent (you have packages depending on other packages, which are not present)
[14:45] <xnox> menace: apt has no idea if that's intended or a mistake, and it tells you that it doesn't know about it - maybe it's virtual?! (and no providers where found for it)
[14:47] <xnox> menace: but it cannot know, that the dak archive you created simply isn't in a consistent state and e.g. missing a matching copy of the linux package & binaries.
=== salem_ is now known as _salem
[14:53] <psusi> cjwatson: I hate to bother you with this but I can find zero documentation anywhere on it ( I'll have to write some once I figure it out ).. I am guessing that the grub-xen package is supposed to serve as the proper pv aware boot loader for xen domUs, but it doesn't seem to have a main binary anywhere that you can configure xen to load as the boot loader; it just installs the modules
[14:56] <cjwatson> psusi: It's a partial implementation that needs to be completed; https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00184.html and thread has background
[14:56]  * infinity still uses this on precise, and wonders if he needs to learn new tricks for trusty: bootloader = '/usr/lib/xen-4.1/bin/pygrub'
[14:56] <smb> psusi, Using pygrub as bootloader should work for PV guests. It comes with the xen-utils. For trusty you may need to modify apparmor frofiles (libvirt)
[14:56] <cjwatson> psusi: The next stage at this point is to write up a boot protocol document that can be included in the Xen tree; I asked smb if he could help with this
[14:57] <smb> Or are we talking about efi variants?
[14:57] <cjwatson> psusi: It is *possible* to make grub-xen work, but it's not all assembled yet so documenting it would not be an appropriate next step
[14:57] <cjwatson> smb: pygrub2
[14:57] <cjwatson> smb: remember our conversation in Malta?
[14:57] <smb> cjwatson, We had one?
[14:57] <cjwatson> Yes
[14:57] <cjwatson> Anyway, the thread above has the background :)
[14:58] <smb> cjwatson, (you really had, with that guy that could not stand straight which was me?) Anyway ok
[14:58] <psusi> afaics, pygrub was a hack that externally parses the grub.cfg from outside the domU and figures out how to translate that into xen commands to launch the domU with the right kernel.. and this new grub-xen is supposed to be an actual build of grub that can run inside the domU and use the pv disk io etc to do everything grub normally does
[14:58] <cjwatson> smb: Hm, I guess maybe it was apw
[14:59] <cjwatson> All you kernel folks are indistinguishable after all
[14:59] <smb> psusi, Ah ok. There also is pvgrub buried in the xen source which works once one goes through the horrible setup path (involving downloading a lot of tar'ed libraries)
[15:00] <cjwatson> pvgrub is what grub-xen will replace once it's finished
[15:00] <cjwatson> a.k.a. PV-GRUB2
[15:00] <smb> cjwatson, Usually people confuse the Ste(ph|f)ane?'s :)
[15:00] <apw> cjwatson, erm, maybe, /me reads
[15:00] <infinity> smb: Big Steffie and Little Steffie, you mean.
[15:01] <smb> infinity, nope. really not
[15:01] <infinity> :)
[15:01]  * xnox wistles 2 1/2 man theme tune
[15:01] <smb> I may have cup size a but not feeling very feminine :-P
[15:01] <xnox> *whistles?!
[15:02] <smb> cjwatson, Ok, yeah. I guess I have to grab apw at some point
[15:02] <psusi> oh wait... grub-install maybe did make something... core.elf?
[15:03] <apw> cjwatson, oh yeah that might have been me :)
[15:04] <cjwatson> psusi: Don't expect any of this to work yet
[15:06] <menace> 3
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:16] <caribou> is there a preferred way to build unit tests for bash scripts ?
[15:17] <pitti> caribou: I think shunit2 (package|program) is the de-facto standard, although many scripts just use some ad-hoc stuff like [ $a = "expected ]
[15:21] <caribou> pitti: ok I'll look into it, thanks
[15:22] <caribou> pitti: was looking at what I did in another live, was using PERL for testing bash..
[15:23] <caribou> pitti: matter of fact, those tests wil go to Debian forst
[15:23] <caribou> s/forst/first
=== _salem is now known as salem_
[15:37] <slangasek> xnox: pfb2t1c2pfb? are you having a stroke?
[15:39] <xnox> slangasek: mostly hayfever.
[15:43]  * mdeslaur didn't know pfb2t1c2pfb was russian for 'Atchoo'
[15:44] <ogra_> bless you
[15:46] <slangasek> xnox: subscribed; but I wonder if I should put a moratorium on Foundations-owned MIRs to force the issue of archive reorg ;)
[15:49] <pitti> sil2100: FYI, libunity-scopes2 now fails to install in -proposed due to "GError: Can not find a single database provider in /etc/click/databases"; this fails the tests for ubuntu-system-settings-online-accounts and unity-scope-click and thus holds back stuff
[15:49] <pitti> ubuntu-system-settings-online-accounts and unity8 in particular
[15:49] <pitti> robru: ^ maybe you are interested as well
[15:51] <sil2100> pitti: oh...
[15:51] <seb128> sil2100, moved that to -touch
[15:51] <xnox> slangasek: https://launchpad.net/ubuntu/+source/moratorium does not exist.
[15:51] <seb128> since we don't have mhr3 here
[15:51] <pitti> sil2100: I'm not sure, are you interested in notifications like this, or is that just noise for you?
[15:53] <sil2100> pitti: I would appreciate info like this, especially that I'm slowly moving to +1 maintenance work :)
[15:53] <pitti> sil2100: ok
=== salem_ is now known as _salem
[16:00] <seb128> pitti, thanks for pointing the issue!
[16:00] <pitti> seb128: de rien
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== _salem is now known as salem_
=== salem_ is now known as _salem
[16:22] <shadeslayer> ev: how long does it take between someone applying for e.u.c access and them being added to the group?
=== _salem is now known as salem_
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
[17:24] <hallyn> stgraber: I don't know why i can't keep this straight...  Suggests does *not* get installed by default?  It's ok for something in main to Suggest something in multiverse?
[17:24] <hallyn> or it does and it's not?
[17:24] <cjwatson> Correct on both counts
[17:25] <hallyn> uh.  the first pair, not the second? :)
[17:26] <stgraber> hallyn: the first
[17:26] <hallyn> cool, thanks, then qemu can Suggest ovmf, dropping one bit of delta from debian - thx
[17:26] <stgraber> yep
[17:38] <ev> shadeslayer: as long as it takes for me to review it. Is there a specific user you're waiting on?
[17:38] <shadeslayer> ev: yeah, Marco Martin
[17:38] <ev> do be aware they have to provide an address and project information
[17:38]  * ev looks
[17:38] <ev> yeah, Marco hasn't provided an address
[17:38] <ev> he'll need to submit the form again with that part filled out
[17:39] <ev> frustratingly there doesn't appear to be a way to make those fields required, though I'd still have the problem of people writing N/A in them.
[17:40] <shadeslayer> heh
[17:41] <shadeslayer> ev: I've passed on the info to him, he's upstream KDE, useful to have them access to the tracker, instead of me copy pasting backtraces on pastebin :P
[17:41]  * ev nods
[17:41] <ev> happy to add him as soon as he gets the form completed
[17:41] <shadeslayer> cheers, and thx :)
[17:41] <ev> sounds like he'd be a great addition to the team :)
[17:41] <shadeslayer> *nod*
[17:43] <shadeslayer> ev: David Edmundson too :)
[17:48] <psusi> well once I remembered this old server I'm importing into a xen domU on new hardware was in fact 32 bit, and I used the 32 bit grub core.elf, it seems to work quite nicely... aside from the fact that the xen console does not seem to notify the domU about the terminal dimentions
[18:09] <hallyn> mvo: hi, would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4-2/netcf_0.2.4-2.dsc and sponsoring into debian-experimental?  (debian/libnetcf1.symbols fixes suggested by xnox)
[18:41] <dobey> /usr/include/accounts-qt5/Accounts/service.h:38:24: fatal error: QDomDocument: No such file or directory #include <QDomDocument>
[18:41] <dobey> whee, so i guess qt5.3 broke libaccounts-qt5?
=== salem_ is now known as _salem
[19:31] <mdeslaur> what's going on with https://errors.ubuntu.com/ ?
[19:36] <sbeattie> bdmurray: ^
[19:38] <bdmurray> its not accepting core dumps at the moment, I'm actively working on it
[19:38] <mdeslaur> bdmurray: darn, I was kind of hoping we had fixed every single bug :(
[19:38] <mdeslaur> ;)
[19:40] <bdmurray> yeah, that'd be neat
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
[20:17] <ChrisTownsend> infinity: Hey, you're the SRU guy today, right?
[20:35] <ari-tczew> can someone finally to sponsor one sync? bug 1327934
[20:35] <ubottu> bug 1327934 in python3-stdlib-extensions (Ubuntu) "Sync python3-stdlib-extensions 3.4.1-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1327934
[20:36] <Unit193> Just one sync?  What about others' uploads? :(
[20:38] <ari-tczew> dunno
[20:39] <Unit193> ari-tczew: Just pulling your leg. ;)
=== timrc is now known as timrc-afk
[21:15] <ari-tczew> Unit193: tomorrow as patch pilot is xnox, looks good :P
[21:23] <Unit193> Heh. :)
[21:30] <brendand> lifeless, hi - i have something working for testtools, but i'm just worried i'll break something. unit tests still pass, but can you have a quick look at it?
[21:32] <brendand> lifeless, http://paste.ubuntu.com/7692320/
=== timrc-afk is now known as timrc
[23:14] <sarnold> is there an easy way to pull the build logs for all 'released' versions of a package from launchpad?
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc