[00:00] <cyphermox> broder: go right ahead.
[06:03] <pitti> Good morning
[06:05] <vibhav> pitti: Hi
[06:24] <pitti> hello vibhav
[06:24] <pitti> dupondje: NB that the cryptdisks package split patch is missing some things, working on it
[06:55] <Daviey> #launchpad-redsquad
[06:55] <Daviey> oops
[06:58] <dupondje> pitti:  what did I misss?
[06:58] <pitti> dupondje: just sent updated patch to the bug, and uploaded
[06:58] <pitti> dupondje: thanks!
[06:59] <vibhav> DO I need to report a bug for attaching a typo fix patch?
[07:00] <pitti> vibhav: depends on what package, but usually that's better for coordination, yes
[07:02] <dupondje> pitti: I see, just tought to keep cryptformat in the cryptsetup package, as this would not be used by people that just want to mount their crypted dev
[07:03] <pitti> dupondje: with the GUIs available it's indeed largely obsolete these days
[07:03] <pitti> but still nice on a server
[07:03] <pitti> dupondje: but yes, the location of that is certainly debatable
[07:03] <pitti> dupondje: but the cryptsetup manpages were in "cryptsetup" and should be in the same package as the binary, i. e. -bin
[07:05] <dupondje> you mean ./usr/share/man/man8/cryptsetup.8.gz
[07:05] <dupondje> ?
[07:05] <pitti> yes
[07:05] <dupondje> weird, I builded it yesterday, and that one was in the bin package .. :)
[07:08] <dupondje> You mean luksformat.8 maby?
[07:30] <dupondje> pitti: anyway thx for the upload. I'm the first happy user of the -bin package :D
[07:30] <pitti> dupondje: hah, so I'm the second :)
[07:31] <pitti> I have it installed now, and tested successfully with palimpsest
[07:32] <dupondje> thats great. Having laptop here where I sometimes open an external drive that is crypted. No need for the whole cryptsetup package now to just open it :)
[07:33] <dupondje> anyay bbl
[07:58] <mealstrom> hi, can you tell me how .ICEauthority is created and management? Ive got a lot of problems with it using nfs server to store home directories.?
[07:58] <mealstrom> or how system checks that file? when saying "Could not update ICEauthority"
[08:02] <dholbach> good morning
[08:02] <vibhav> hi
[08:26] <brendand> mealstrom, that often tends to mean that the home directory cannot be accessed in some way
[08:27] <brendand> mealstrom, i've had it in the past when i've used encrypted home and there've been bugs in ecryptfs
[08:45] <pitti> jibel: bonjour
[08:45] <pitti> jibel: I believe you still have a workaround in the dist-upgrader for iodbc?
[08:46] <pitti> jibel: could you please drop this, so that we can check that the fix works now? (it was uploaded yesterday)
[08:46] <jibel> pitti, guten morgen
[08:47] <jibel> pitti, yes, I've seen your upload yesterday, I'll reinstall the package
[08:50] <pitti> jibel: thanks
[09:14] <jussi01> mvo: We are having a conversation about different meta packages on the kubuntu-devel list, and we want to get several meta packages added to app install data. WHat do you need from me apart from a list of packages?
[09:14] <jussi01> Riddell: ^^
[09:14] <jussi01> ;)
[09:46] <henrix> pitti: hi! me again... i still can't see the latestest version of the oneiric kernel when i run "rmadison --arch=source linux"
[09:47] <henrix> pitti: i guess there's something wrong with the upload to -proposed
[09:47] <pitti> henrix: indeed, seems the copy-proposed-kernel command failed somehow
[09:47] <pitti> re-running
[09:47] <henrix> pitti: thanks
[09:48] <pitti> https://launchpad.net/ubuntu/+source/linux/+publishinghistory
[09:48] <pitti> seems someone deleted it from -proposed
[09:49] <pitti> henrix: it's pending again, I copied it back
[09:49]  * pitti fixes overrides
[09:49] <henrix> pitti: that's odd. anyway, thanks again
[09:54] <henrix> pitti: are you still looking at this? i just refreshed https://launchpad.net/ubuntu/+source/linux/+publishinghistory and see 'deleted' again
[09:54] <pitti> not any more, the change-override is done
[09:55] <pitti> and now that page times out
[09:55] <henrix> cool
[09:55] <pitti> well, not cool
[09:55] <pitti> WTF does it get deleted?
[09:56] <henrix> i can't imagine
[10:14] <pitti> henrix: should be ok now, and published in ~ 45 mins
[10:15] <henrix> pitti: great, thanks
[11:23] <apw> pitti, that script that copies it to -proposed seems to say its copying to -updates
[11:23] <pitti> apw: err?
[11:24] <pitti> apw: you mean in the warning? that seems to be correct
[11:24] <pitti> Failure to do so may result in uninstallability when it is ultimately copied to
[11:24] <pitti> -updates/-security.
[11:25] <apw> ahh ... odd
[12:13] <tseliot> cjwatson: do you remember how to reproduce bug 929384 inside of an i386 chroot without having to use the nvidia driver?
[12:13] <AzaToth> tkamppeter: have you thought of doing a backport of cups to debian squeeze? I was trying to do one, but gave up when I was down trying to build cairo :(
[12:14] <cjwatson> tseliot: well, I never actually bothered reproducing it myself IIRC, I just did theoretical work
[12:15] <tseliot> cjwatson: ah, ok, maybe it was slangasek who did something like that
[12:15] <cjwatson> tseliot: it was a linker bug on libGL.so though, so just fiddling with the diversions ought to be enough
[12:15] <tseliot> cjwatson: ok, thanks for the tip
[12:15] <cjwatson> tseliot: one moment though, there was something in some other BTS
[12:16] <tseliot> oh
[12:16] <cjwatson> tseliot: ah yes, IIRC if you get the right libGL in place and do something like 'LD_DEBUG=version glxgears' then it shows symbol lookup errors
[12:17] <tseliot> cjwatson: excellent, thanks!
[12:42] <cjwatson> didrocks: your unity upload is never going to come out of dep-wait state - you added a build-dependency on libxfixes rather than libxfixes-dev
[12:43] <didrocks> cjwatson: oupsss, yeah, sorry
[12:43] <didrocks> fixing
[12:45] <didrocks> cjwatson: uploaded, thanks for the notice
[13:22] <apw> cjwatson, linux-base (synced from debian) is bringing /usr/bin/perf which collides with linux-tools-common in ubuntu.  whats the right annotation to avoid them both being installed
[13:23] <cjwatson> Conflicts, but really that's the wrong answer, you should make them play nicely together instead
[13:24] <apw> cjwatson, as in add our different algorithm to linux-based ?
[13:24] <cjwatson> or else we should have only one of them in the archive, though I'd prefer us to be gravitating towards Debian's layout since linux-base was supposed to be used by other packages too
[13:26] <cjwatson> (linux-base ships a Perl module which was intended to help other packages do things like sorting kernel versions)
[13:26] <apw> the perf binary there assumes that perf is version independant, which it actually is not necessarily ... hmm
[13:27] <apw> cjwatson, ok will have a think about it
[13:30] <apw> cjwatson, do you happen to have a debian system you can get a uname -r off of?
[13:31] <cjwatson> not saying it's perfect as it is
[13:31] <cjwatson> not a current one; my stable system says 2.6.32-5-686
[13:31] <apw> yeah as i suspected, they look exactly like ours ...
[13:34] <mvo> @pilot in
[13:37] <seb128> mvo, \o/
[13:37] <apw> cjwatson, as they are indistinguisable, is it reasonable to carry a delta to linux-base ... with a view to extracting the core there into a function for use in other links
[13:38] <cjwatson> apw: sure, if you're happy with that
[13:39] <cjwatson> I'd actually been avoiding syncing linux-base on the grounds that it would require coordination with the kernel team; not sure how it got synced, but there you go
[13:39] <apw> cjwatson, yeah indeed ... well if it is needed going forward its probabally time for us to take ownership of it and fix it up
[13:55] <pitti> oh, someone binNEWed libical after all -- it's FTBFS on arm* and ppc
[13:56] <pitti> I was going to wait for fixing that
[14:01] <cjwatson> pitti: oh, that was me, sorry
[14:01] <cjwatson> seemed no particular reason not to
[14:01] <pitti> cjwatson: I initially thought it was a soname bump, but seems it isn't
[14:01] <pitti> so not much harm
[14:01] <cjwatson> it was just an added -dbg package
[14:01] <pitti> I just prefer to wait for all builds for soname bumps
[14:02] <pitti> right; sorry for the noise
[14:02] <pitti>  /query mbiebl
[14:03] <pitti> erk
[14:06] <mvo> doko: hi, around? I'm piloting today and came accross #953171 - do you have a upload pending or should I got ahead?
[14:13]  * dholbach hugs mvo
[14:14] <scott-work> cjwatson: if i have questions about the ubiquity background/text bug (952462), would it be more appropriate to ask them here or in the bug report?
[14:15] <scott-work> cjwatson: also, did you see my question about line #17 from the pastebin yesterday and the single parenthesis?
[14:15] <cjwatson> scott-work: #ubuntu-installer, probably
[14:15] <scott-work> cjwatson: thank you
[14:15] <cjwatson> scott-work: I did, but you'd left by the time I was ready to respond.  It was correct as it was - shell syntax is like that.  (Actually the opening parenthesis is optional, but conventionally omitted.)
[14:15] <scott-work> ah, thank you yet again :)
[14:16] <cjwatson> There were other bugs in my paste though - I committed a working version this morning
[14:37] <awe> rickspencer3, fyi that chromium menu bug I entered is actually not-specific to chromium...
[14:56] <Pjotr> Hello
[14:56] <Pjotr> cjwatson: I have reported a Ubiquity bug that you might want to take a look at: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/953959
[15:07] <cjwatson> Pjotr: thanks
[15:15] <Pjotr> cjwatson: thank you for wanting to look at it. :-)
[15:15] <Pjotr> bye
[15:17] <rickspencer3> awe, can you give me the bug # then?
[15:31] <awe> rickspencer3, yea... one sec.  just got out of a meeting
[15:33] <awe> rickspencer3, 948059
[15:34] <rickspencer3> bug #948059
[15:47] <doko> bug 953171
[15:47] <doko> mvo: no, didn't plan another upload
[15:54] <infinity> Riddell: What's with calligra's weird version number? :P
[15:56] <Riddell> infinity: uh oh, did I miss off a 1 from the end?
[15:57] <infinity> Riddell: You might have. ;)
[15:58] <infinity> Riddell:Given the number of times it's been uploaded this cycle, I assume this won't be the last, so it'll self-solve, I guess. :P
[17:18] <pitti> calligra still needs at least two RC fixes (missing transitional pacakges and ttf-lyx recommends), so it can't be the last :)
[17:22] <mhall119> m_3: ping
[17:24] <m_3> mhall119: yo
[17:25] <m_3> mhall119: got the hosting account info for linuxplumbers
[17:26] <mhall119> m_3: cool, I'm working on an apache config file for it
[17:26] <m_3> hey... awesome
[17:26] <mhall119> m_3: but I need to know where it's being installed
[17:26] <mhall119> /srv/summit/?
[17:26] <m_3> /srv/$service_name/project/ atm... but I can turn any vhost you can give me into a template
[17:27] <mhall119> ok
[17:27] <m_3> mhall119: I got the menu and admin account created from the charm
[17:27] <m_3> so really the apache vhost was next
[17:27] <m_3> in meetings for another hour or so, so that'd be really helpful man
[17:27] <mhall119> m_3: can you /join #ubuntu-website?
[17:27] <m_3> sure
[17:59] <jussi> mvo: ping?
[17:59] <jussi> mvo: did you see my message earlier?
[18:06] <jono> where do I file bugs against the music lens?
[18:08] <dholbach> jono, "ubuntu-bug unity-lens-music"?
[18:08] <jono> dholbach, doesnt wortk
[18:08] <jono> oh it does
[18:08] <jono> thanks dholbach
[18:08] <dholbach> :-)
[18:08] <jono> I was doing ubntu-music-lens
[18:08] <jono> thanks!
[19:04] <arges> SpamapS, hello.
[19:04] <SpamapS> arges: *hello*
[19:05] <arges> SpamapS, was looking at pad.lv/578536  ... was wondering what is needed to get this accepted into natty-proposed as well
[19:05] <arges> if you need a debdiff, or bzr branch
[19:06] <SpamapS> arges: either will be fine
[19:06] <arges> ok I'll post that then, anything else I need to do to flag it then?
[19:06] <SpamapS> arges: though it looks like the fixes have sat in maverick/lucid proposed since August... are you certain this one will be verified if its fixed in natty?
[19:07] <arges> SpamapS, i'll talk to the reporter and make sure it gets verified
[19:07] <SpamapS> arges: create the debdiff and subscribe ubuntu-sponsors, or do a merge proposal.
[19:07] <arges> cool
[19:20] <m_3> mhall119: hey, ok.... so done with hangout meetings for the day
[19:20] <m_3> mhall119: do you just wanna send me a rough vhost?
[19:21] <mhall119> m_3: http://paste.ubuntu.com/882217/ is a working apache.conf almost identical to production
[19:21] <m_3> mhall119: awesome... thanks!
[19:22] <ha1dfo> hi all. I don't know if this is the right channel, i'll ask anyways. I'm building a .deb for myself. I have a config/template pair, and it works fine when I dpkg-reconfigure my pkg, but won't get configured when i'm installing it. Do you have any idea what am i missing?
[19:24] <mvo> jussi: no, sorry, I did not
[19:24] <mvo> jussi: could you paste/msg it to me?
[19:24] <jussi> [11:14:36] <jussi01> mvo: We are having a conversation about different meta packages on the kubuntu-devel list, and we want to get several meta packages added to app install data. WHat do you need from me apart from a list of packages?
[19:25] <cjwatson> ha1dfo: you're probably missing a postinst that sources the debconf confmodule - see debconf-devel(7), especially the HACKS section
[19:25] <ha1dfo> cjwatson, Thanks, now I see it.
[19:26] <jussi> mvo: background: https://lists.ubuntu.com/archives/kubuntu-devel/2012-March/005919.html and https://lists.ubuntu.com/archives/kubuntu-devel/2012-March/005920.html
[19:27] <cjwatson> it doesn't have to do anything else - so   #! /bin/sh \n set -e \n . /usr/share/debconf/confmodule \n exit 0   is fine (with " \n " replaced by real newlines)
[19:30] <mvo> jussi: easiest is to add something app-install-data-ubuntu in menu-data-additional
[19:30] <mvo> @pilot out
[19:31] <jussi> mvo: right, so I havent done anything for ubuntu in a while, whats required/involved?
[19:32] <jussi> mvo: need to run (baby needs attention). leave me a message
[19:32] <mvo> jussi: you could just apt-get source app-install-data-ubuntu and look at the examples in menu-data-additional and create a bunch of desktop files with icons for the stuff you have in mind
[19:32] <mvo> jussi: sure, see you
[19:36] <cody-somerville> How do I close a bug in Debian BTS as invalid?
[19:44] <Laney> with a mail to nnn-done@bugs.debian.org
[19:45] <cody-somerville> Laney, But is there anything special to mark it invalid?
[19:45] <Laney> no, just your text
[19:45] <cody-somerville> Okay.
[19:45]  * cody-somerville was sort of expecting there to be an 'invalid' tag or something.
[19:45] <Laney> you can also tag 'wontfix', but there is not much point
[19:58] <bryceh> slangasek, -openchrome sru fix is in the hopper
[19:59] <slangasek> bryceh: cheers :)
[20:12] <michael-vb> Evening.
[20:14] <michael-vb> slangasek: someone suggested that I draw your attention to <https://bugs.launchpad.net/ubuntu/+source/libxt/+bug/953860>, regarding -dev packages for X11 and multiarch.  It would be lovely if that could be made to work in 12.04, as I use it a lot for developing the VirtualBox Guest Additions.
[20:14] <michael-vb> ubottu: right :)
[20:34] <slangasek> michael-vb: multiarch -dev packages are not realistically going to be of help right now for building i386 packages on amd64; the recommended method for that is still an i386 chroot.
[20:35] <michael-vb> slangasek: right, that is my fallback of course (well, I tend to go for VMs for obvious reasons!)
[20:35] <michael-vb> Shame, it would have been nice to get just the few I needed.  I see e.g. libx11-dev is multiarch.
[20:35] <slangasek> yes, we'd certainly like to have these all coinstallable
[20:36] <tumbleweed> chroots are much easier (pbuilder / sbuilder make it trivial)
[20:36] <slangasek> fwiw, you can cross-install the ones that aren't marked M-A: same, you just can't have both the amd64 and i386 ones installed at the same time
[20:36] <michael-vb> I need the amd64 ones though.
[20:37] <slangasek> right; that's not solved for 12.04
[20:37] <michael-vb> Obviously if there is something I can do to help get this done let me know, though I will quite understand if you are too busy.
[20:38] <slangasek> michael-vb: well, I just dropped a comment on the bug about what needs to happen - either the html docs need to be split out of the -dev package, or the html generation needs to be made reproducible
[20:39] <michael-vb> I didn't look to see exactly how they differed, as I was rather busy at the time myself.  I think I will though, I am curious why the docs should differ and the rest not.
[20:40] <michael-vb> Thanks anyway.
[20:47] <slangasek> michael-vb: no prob - sorry there's not a better answer here yet
[20:47] <michael-vb> I'm sure you're hard at work on that.
[20:50] <michael-vb> Getting a bit late over here - good night all.
[20:53] <slangasek> pitti, dupondje: it doesn't appear that the latest cryptsetup upload has been committed to the bzr branch - do either of you have that staged somewhere, or should I take care of it?
[21:36] <SpamapS> Oh ye packaging and archive wise sages.. in 11.10, we shipped the 'ensemble' package in the juju source package to help with the rename to juju. If 12.04, if we remove that, and make sure that juju Breaks: and Replaces: ensemble (<< ${binary:Version} ) .. that should mean that it will be removed on upgrade to 12.04 and never come back, right?
[21:40] <ScottK> Except you need to have ensemble depend on juju so upgraders get the new package.
[21:40] <SpamapS> ScottK: it did as of 11.10's release
[21:41] <SpamapS> ScottK: so they should already have had juju pulled in if they had ensemble early in 11.10's development
[21:41] <ScottK> OK.
[21:41] <ScottK> Instead of binary version just make it unversioned then and drop the transitional package.
[21:41] <SpamapS> ScottK: so in theory, I shouldn't even need the Breaks/Replaces..
[21:42] <SpamapS> Right, that sounds better actually
[21:42] <ScottK> You need them to make the old package go away, if that's what you want to do.
[21:42] <ScottK> That or you could just ask mvo to make the upgrader do it.
[21:42] <broder> won't the upgrader automatically remove packages that aren't in the archive anymore?
[21:43] <SpamapS> I don't mind being explicit
[21:45] <Laney> only Conflicts ensures that it actually gets removed
[21:45] <Laney> I am not sure you should worry about making it get removed though
[21:45] <Laney> it has implications if the archive wants to grow another package called ensemble
[21:47] <SpamapS> Laney: we'd need that new package to have a new epoch (or at least a new version) no matter what, anyway, right?
[21:48] <Laney> I don't think so if it was removed
[21:48] <SpamapS> well in theory, 11.10 users may have had it installed...
[21:49] <SpamapS> It would have depended on juju.. so on upgrade to 12.04 .. we can use clues in juju to signal removal of ensemble
[21:49] <SpamapS> I was under the impression that Breaks/Replaces was that signal.
[21:50] <SpamapS> Since nothing ever reverse depended on ensemble.. can we make it a Conflicts, and that would be the end of ensemble?
[21:50] <SpamapS> Laney: ?^^
[21:50] <Laney> I am just saying that it might not matter so much if users have an empty package installed. But if you want to do it then you should use Conflicts IIUC
[21:51] <SpamapS> Laney: I actually want to clean up the namespace.
[21:51] <Laney> possibly with <= the-last-version-of-the-ensemble-package
[21:54] <broder> uh, isn't conflicts with <= almost always incorrect?
[21:54] <Laney> explain
[21:55] <broder> last paragraph of http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[21:55] <broder> i've never been good at keeping all of that straight in my head, so my takeaway has traditionally been "don't use conflicts with < or <="
[21:55] <broder> but i recognize that i'm oversimplifying the rules and could be wrong :)
[21:56] <RAOF> IIRC lintian (or some other tool) will throw a warning at you if you're using conflicts with <=
[21:57] <Laney> maybe Breaks is OK, but I understand that it doesn't guarantee removal (although apt may implement it as such)
[21:57] <lifeless> its not meant to guarantee removal
[21:58] <lifeless> it permits concurrent unpacking, but requires all deps to be ok before configuring
[21:58] <broder> hmm, ok. point taken. i guess the cases you get screwed with conflicts and <= is if you're actually upgrading the package that's conflicted on
[21:59] <SpamapS> in this case, I want to put out a death warrant on the 'ensemble' binary package
[21:59] <lifeless> right, classic case of conflict issues is one source two binaries that mutually dpeend on each other
[21:59] <lifeless> and some lock-step internal change so you need to ensure lock-step upgrades
[21:59] <slangasek> that sounds like the classic case of Conflicts misuse to me :)
[22:00] <lifeless> conflicts won't *let* that happen, because you have a symettrical constraint, breaks does, because you can unpack them both then configure
[22:00] <lifeless> slangasek: exactly
[22:00] <lifeless> SpamapS: there is no 'kill kill kill' for the package; the best you can do is breaks or conflicts (depending on whether unpacking will work - and consider replaces too) with it and get it removed from the archive
[22:01] <broder> right. ok, i withdraw my objection to conflicts :)
[22:01] <lifeless> conflicts+replaces is the stock answer for package renames isn't it ?
[22:01] <Laney> afaict it is already removed, he just wants to ensure that users don't have the transitional package any more
[22:02] <slangasek> lifeless: indeed
[22:03] <SpamapS> Its still being built today, but the next upload of juju will not build the 'ensemble' binary package... and make it NBS ..
[22:04] <SpamapS> It sounds like Breaks+Replaces on 'ensemble' without a version is the clearest way to inform package managers that this package should be removed.. and if they choose to ignore that, then they'll be left with an annoyed user who will likely remove it.
[22:05] <lifeless> SpamapS: how will they be annoyed? just get archive admin to remove the NBS package once juju has built
[22:05] <SpamapS> lifeless: user would be annoyed because on installing 'juju' the package manager would refuse to configure *juju* ;)
[22:05] <lifeless> SpamapS: htf?
[22:05] <slangasek> no, it wouldn't
[22:06] <slangasek> ensemble would be deconfigured, juju would be configured
[22:06] <SpamapS> exactly, it wouldn't..
[22:06] <SpamapS> I'm going through the scenarios in my head where a package manager would sanely not remove ensemble at that point.
[22:07] <SpamapS> One question, why not also include a ( << ${binary:Version} ) to ensure that the namespace is protected if some future package wants to be 'ensemble' and doesn't actually break because it has nothing to do with juju
[22:07] <SpamapS> (assuming I forget to remove the breaks/replaces in 12.10)
[22:12]  * SpamapS goes through his daily "delete all the haskell change emails from precise-changes mailing list" routine
[22:12] <Laney> SpamapS: there is no need for it to be a variable
[22:12] <Laney> HOW DARE YOU!
[22:12]  * Laney uploads some more for punishment
[22:18] <SpamapS> Laney: indeed, I can make it static so its just up to the current version
[22:40] <dupondje> Now this is odd, updating my precise system, and getting: 'dpkg: error: parsing file '/var/lib/dpkg/available' near line 14'
[22:58] <bkerensa> micahg: On my merge proposal for the xchat bug you suggested we request Upstream to ship a higher-res icon but is this really a good idea considering we would be asking upstream to accommodate Ubuntu when this problem does not exist elsewhere?
[23:00] <ajmitch> there'd be nothing stopping other systems from using a high-res icon, would there?
[23:12] <bryceh> slangasek, bug #953953 looks sort of like that gz bug you mentioned, except all the referenced versions in the log were built today.  We've had two reports today of this error, both amd64 with the i386 libxfixes installed presumably for wine
[23:13] <slangasek> bryceh: looking
[23:19] <slangasek> bryceh: bug #953955 (which is marked as the master) is definitely not related to gzip; the upgrade error is from trying to configure the package when the amd64 and i386 packages aren't installed at the same version
[23:20] <slangasek> bryceh: the reference to a modified changelog in the title is probably just that the bug is being reported against the amd64 package, and the currently unpacked changelog is from the i386 package; since they're at different versions, of course the changelogs don't match
[23:21] <bryceh> slangasek, ah, weird
[23:22] <slangasek> bryceh: I've checked the libxfixes3 in the archive, and the changelog files match
[23:23] <jalcine> Is it me or is Launchpad just failing to build anything?
[23:24] <slangasek> jalcine: example?
[23:25] <jalcine> https://launchpadlibrarian.net/96701937/buildlog.txt.gz
[23:25] <jalcine> I think it's #915505
[23:25] <jalcine> https://launchpad.net/bugs/915505
[23:25]  * jalcine looks for ubottu
[23:25] <slangasek> ah, that looks like a recipe build?
[23:25] <slangasek> I think you'd want to ask #launchpad
[23:25] <jalcine> Yup.
[23:26] <jalcine> Thanks.
[23:27] <bryceh> slangasek, ok, so just chalk it up to a transitory failure?
[23:28] <slangasek> bryceh: well, it could be a bug in whatever package management frontend they were using, or it could be user foot-shooting
[23:28] <slangasek> it's not the sort of thing that we should be seeing as a matter of course
[23:32] <bryceh> hmm