[07:53] <zequence> Hi. Could someone help me understand why ubuntustudio-meta has been stuck in -proposed for such a while?
[07:53] <zequence> I tried installing it, and it seemd to work fine
[07:53] <zequence> The Ubuntu Studio ISO is failing to build without our updated meta
[07:58] <zequence> ..ah, libav needs to be promoted first
[07:59] <zequence> or?
[08:02] <zequence> Am I reading this correctly? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntustudio-meta
[08:18] <xnox> zequence: yes, we are still battling with libav migration - see updates on ubuntu-release about the progress on that.
[08:18] <xnox> (mailing list that is)
[08:43] <zequence> xnox: Thanks
[09:35] <cjwatson> zequence: Right, please don't mess with this for the moment :)
[09:35] <cjwatson> zequence: The full gory details are in update_output.txt (update_excuses.html is just the first stage), but can be a bit tricky to read.  See https://wiki.ubuntu.com/ProposedMigration
[11:28] <Saviq> slangasek, hey, when you're around, we'd like to NEW qtmir and qtmir-android from silo 6 please
[12:21] <jibel> infinity, are builds of Precise images disabled? there is no new build since last week (22nd)
[12:27] <mvo_> could someone please reject the update-manager in the precise-proposed queue (.17 ?) I need to do another update
[12:30] <infinity> jibel: Ahh, yeah, they were disabled to avoid contention with trusty.  I'll turn 'em back on this morning.
[12:30] <jibel> infinity, thanks!
[12:33] <infinity> cjwatson: Don't forget a new grub2-signed to match that grub2 in precise.  Doesn't look like that's been consistently happening.
[12:34] <cjwatson> Right, will sort that out today
[12:40] <infinity> cjwatson: How would you feel about switching to the kernel method of versioning there (ie: signed is identical to unsigned, and then can magically build-dep and fail hard when not built against the right version)?
[12:41] <infinity> cjwatson: I know your original intent was to allow iterating signed indepedently, but I suspect the days of fine-tuning the packaging are over.
[12:41] <infinity> cjwatson: And it's way less confusing to see if they match by checking versions instead of build logs or upload dates.
[12:41] <infinity> (or binary versions, I guess, since you encode it there)
[12:42] <cjwatson> I'd be fine with that, but I don't really want to go reorganising it today
[12:42] <cjwatson> (i.e. lack of time)
[12:42] <infinity> Oh, yeah, I didn't mean go do that or I won't accept your upload. ;)
[12:42] <infinity> It was more me volunteering to change it if you didn't object.
[12:42] <cjwatson> If you're feeling enthusiastic then by all means please do
[12:42] <cjwatson> We can always iterate independently by appending something, if we need to
[12:46] <infinity> cjwatson: I can make the version parser stop at a "+", so if we really need to iterate, it would ignore +1
[12:46] <infinity> ... assuming grub2 never has + in its version.
[12:48] <cjwatson> Not very safe
[12:48] <cjwatson> (It has in the past)
[12:48] <cjwatson> But you could make it stop at "+signed"
[12:48] <cjwatson> (say)
[12:49] <mvo_> thanks infinity
[13:26] <stgraber_> slangasek: I delegated testing and release of Edubuntu 14.04.1 to highvoltage so no, I wasn't planning on being around for it (I was actually offline up until about an hour ago)! :)
[13:55] <highvoltage> stgraber: there wasn't any problems with the release, at least
[13:55] <highvoltage> stgraber: you probably should just sync the new image to your server so that I can add it back on the downloads page again
[13:57] <stgraber> highvoltage: oh right, I'll do that later today. Thanks for taking care of everything else!
[14:06] <highvoltage> stgraber: np, we should take some time to discuss 14.10 again when you've caught up and we both have some time
[14:36] <mvo_> could someone please approve xorg-lts-transitional from precise-proposed to precise-updates? not having it breaks lts upgrades from 12.04+hwe-trusty and it just adds a bunch of transitional packages
[14:54] <barry> infinity: looks like zope.security is still not getting promoted :(  i suppose i botched the transition of python-zope.security-untrustedpython, but how can we fix or override that?
[15:09] <infinity> barry: Lemme look.
[15:09] <infinity> barry: Oh, pitti never removed the NBS from -proposed.
[15:10] <barry> infinity: ah
[15:10] <infinity> Fixing.
[15:11] <infinity> barry: Should be okay after a publisher run.
[15:11] <barry> infinity: awesome, thanks
[15:12]  * infinity goes to lie down for an hour, not feeling so hot this morning.
[15:31] <arges> cjwatson: hello. rtg is looking for help getting the linux uploads in the utopic new queue accepted. I don't mind doing it, but just wanted to ask if there was anything specific I need to check before clicking accept.
[15:35] <ScottK> IIRC overrides on kernel uploads are special.
[15:35] <ScottK> infinity would know as well.
[15:36] <xnox> arges: are you archive admin these days as well?
[15:36] <xnox> arges: i thought you were SRU only.
[15:36] <xnox> so you are. =) interesting.
[15:36]  * xnox notes down to bug arges next time =)
[15:37] <arges> xnox: well, its only for limited cases (kernel stuff), not for general use
[15:57] <cjwatson> arges: Use kernel-overrides from u-a-t
[15:57] <cjwatson> Beyond that it's pretty turnkey
[15:57] <arges> cjwatson: ok so the linux* binaries here: https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= . I click accept, then I need to change-override them back to main
[15:58] <arges> ( just reviewing so i don't mess it up
[15:58] <cjwatson> No no no no no no no
[15:58] <cjwatson> Use kernel-overrides first
[16:00] <arges> cjwatson: this is why i asked. Ok so which kernel-overrides options, should i be using. Or are the defaults setup to target new uploads in the development queue?
[16:01] <cjwatson> Right, so for ordinary kernels in utopic you basically just want "kernel-overrides 3.14.0-1" or whatever the new ABI is
[16:02] <cjwatson> It'll print a bunch of dots as it works through the existing overrides and copies them over
[16:02] <cjwatson> Then I'd suggest "queue info linux | less" and make sure everything's in main
[16:02] <cjwatson> Then "queue accept linux"
[16:03] <cjwatson> You need different options to k-o if you're dealing with a source package other than linux, or for other series
[16:03] <arges> cjwatson: makes sense. In this case I think I got it. I'll take care of this one then
[16:03] <arges> Thanks
[16:04] <cjwatson> Cool, thanks
[16:28] <cjwatson> oh yes of *course* now there's a protobuf-c transition as well
[16:28] <cjwatson> it was in danger of being too simple
[16:29] <doko> =)
[16:38] <xnox> cjwatson: i'm doing abiword / libwps+friends
[16:38] <xnox> cause i think that's in the mix now as well.
[16:40] <cjwatson> Isn't that just held back by autopkgtests or similar?
[16:41] <cjwatson> Ah, no, I see
[16:42] <doko> cjwatson, any particular package you want some help?
[16:45] <cjwatson> doko: I don't think there's too much left now ...
[16:46] <cjwatson> Just this libwps/etc. stuff, and I'm fixing criu and crtools
[16:46] <doko> ok, looking at libps
[16:47] <doko> wps even
[16:48] <barry> infinity: \o/ zope.security (4.0.1-1ubuntu2) utopic; urgency=medium
[16:49] <cjwatson> doko: well, xnox said he was doing those ...
[16:49] <doko> oh, fine
[16:49] <xnox> doko: well i'm deep in abiword, you can pick something else. E.g. inkscape, or like libreoffice no change rebuild.
[16:49] <doko> going back to toolchain issues
[16:49] <xnox> =))))
[16:50] <cjwatson> we need a libreoffice build?!  ffs
[16:50] <cjwatson> hate hate
[16:50]  * xnox failed at tricking doko into libreoffice TIL
[16:50] <xnox> ISO C++ forbids declaration of 'parameter' with no type  =>>>> well, can't you just do it anyway please?! =)
[16:51] <slangasek> Saviq: silos bypass the NEW queue (which is a bug), which is why I pre-reviewed the qtmir packages and signed off on them
[16:51] <cjwatson> slangasek: only for binaries
[16:51] <doko> xnox, I'm behind that =)
[16:51] <slangasek> ah
[16:52] <slangasek> Saviq: then what cjwatson said; in which case someone needs to upload it so I can process it in NEW? :)
[16:52] <Saviq> slangasek, yeah, we need it to be in distro before the silo lands anyway, as we need a new ubuntu-touch-meta
[16:52] <cjwatson> haha, good luck with that
[16:52] <cjwatson> that's now blocked on the megatransition of doom
[16:52] <slangasek> mm? "in distro before the silo lands"?
[16:53] <cjwatson> oh wait maybe it isn't
[16:53] <slangasek> what's the megatransition of doom?
[16:53] <cjwatson> just a dependency removal, shouldn't get stuck
[16:53] <cjwatson> libav etc.
[16:53] <Saviq> slangasek, we need a new seed, which can only be built after qtmir{,-gles} is in the archive
[16:53] <xnox> slangasek: gnutls, libav, wps, cdr, libwpg, libvisio, libwps, and so on and so worth
[16:53] <Saviq> slangasek, I was thinking you guys could just bincopy from silo
[16:54] <cjwatson> Saviq: that's what publishing a silo is
[16:54] <slangasek> Saviq: "you guys" - that's exactly what the citrain does, why does the "publish" button not work here for you?
[16:54] <Saviq> slangasek, it does, just didn't want a separate silo, but if that's what we need then we just need a bincopy into a different sil
[16:54] <Saviq> o
[16:54] <Saviq> and land that
[16:54] <cjwatson> why do you need a separate silo?
[16:54] <cjwatson> you can build extra stuff in a silo even after it's published
[16:55] <cjwatson> or if it's just ubuntu-touch-meta, that's usually just uploaded directly anyway
[16:55] <Saviq> cjwatson, but I can't land the silo before I get new ubuntu-touch-meta in there, which I can't generate before qtmir is in archive
[16:55] <cjwatson> well sure you can
[16:55] <slangasek> Saviq: why can't you land the silo?
[16:55] <cjwatson> you can just make the changes by hand
[16:56] <Saviq> cjwatson, right, that I can do
[16:56] <cjwatson> or you can temporarily point update.cfg at a PPA in addition to the archiv
[16:56] <cjwatson> nothing wrong with that
[16:56] <cjwatson> e
[16:56] <Saviq> cjwatson, hmm I was told otherwise
[16:56] <cjwatson> you were told wrong
[16:56] <Saviq> ok then, let's see
[16:56] <cjwatson> just make sure to undo the update.cfg change before building the source package
[16:57] <cjwatson> personally I'd probably just edit the relevant files directly and make sure it all matches, but either way
[16:57] <slangasek> I also still don't see why you need to update the meta package to land the other pieces
[16:58] <slangasek> if landing this breaks the image because some essential component will fall out of the image, then something other than the metapackage should surely have been depending on it
[16:58] <cjwatson> Yeah
[16:59] <cjwatson> I was assuming that you just needed a metapackage addition in order to test the whole thing; but yes, if it's for the reason slangasek suggests, then that would be a bad reason
[17:04] <Saviq> cjwatson, slangasek, so... this whole situation is because of the -android and -desktop packages that are built from qtmir and qtmir-gles (there's a respective problem with qtubuntu as well)
[17:04] <Saviq> cjwatson, slangasek, neither is really a good default, as it depends on where you install
[17:05] <slangasek> ok
[17:05] <slangasek> so the metapackage is used to pick the default
[17:05] <Saviq> slangasek, yes
[17:05] <slangasek> yeah, that's reasonable
[17:05] <cjwatson> xnox: Actually, libwps etc. is a separate transition, amazingly
[17:05] <slangasek> sorry for being slow on the uptake
[17:05] <cjwatson> xnox: IF you don't entangle it by uploading anything else
[17:05] <Saviq> slangasek, no worries, I had to clear my head on that as well
[17:05]  * Saviq prepares a meta
[17:07] <cjwatson> xnox: I think this all has some chance of clearing once criu and crtools are built and once p-m notices the re-run marble autopkgtest
[17:07] <xnox> cjwatson: calligra not in it?
[17:07] <cjwatson> Oh, maybe it is
[17:07] <cjwatson> Of course, calligra is hidden by the marble failure
[17:07] <cjwatson> How depressing
[17:08] <xnox> we really should tackle this mess with full force. cause it's been way too long.
[17:09] <cjwatson> Yeah, we should get this done before a2 freezes otherwise the probability of success diminishes further
[17:09] <cjwatson> I'll see if I can no-change rebuild libreoffice somehow
[17:11] <ScottK> Did librevenge get promoted?
[17:12] <xnox> ScottK: looks like it's in main to me.
[17:13] <cjwatson> Yeah
[17:13] <cjwatson> calligra builds now, it's just stuck on other things
[17:13] <cjwatson> The recent KDE update didn't help
[17:41] <xnox> abiword uploaded, taking inkscape
[17:42] <xnox> doko: did you just DDOS all buildds, thus it's pointless in trying to resolve this migration of doom?! =)
[17:44] <slangasek> DDOS how?
[17:50] <xnox> slangasek: all gcc's got uploaded or something.
[17:50] <ScottK> At least three.
[17:51] <xnox> thus my humble universe uploads are to start never =)
[18:09] <cjwatson> digikam uploaded (for megatransition)
[21:50] <infinity> arges, cjwatson: kernel-overrides is obsolete as of precise (at least for master), all the bianries are in main, all the time.
[21:51] <cjwatson> well it potentially fixes section and priority ...
[21:51] <infinity> Which also means the queue gets it right for Tim's uploads to the archive.
[21:51] <arges> infinity: i was wondering why they were all already in main
[21:51] <infinity> cjwatson: If section and prio are wrong, I make Andy and Tim fix it in the packaging. ;)
[21:51] <cjwatson> there is that
[21:52] <arges> infinity: did running kernel-overrides break anything then? or was it a noop?
[21:52] <infinity> arges: I'm assuming it told you what it was doing.
[21:52] <infinity> I haven't used it literally in years, I don't recall what it does.
[21:53] <cjwatson> no-op at worst.
[21:54] <arges> Yea, it didn't mention much other than the names/versions of the packages and printing some dots on the screen. But checking queue info showed that they were still in main before and afterward
[21:56] <arges> infinity: so I assume that I forgot to accept the linux-signed package, and you just did that?
[21:58] <infinity> arges: Aye.
[21:58] <arges> noted
[22:05] <xnox> britney is useless with all the arch-skew, so hopefully powerpc catches up by tomorrow.
[22:07] <infinity> xnox: Err, really?  Building libreoffice with bundled libs? :(
[22:08] <infinity> xnox: That's not how you transition.
[22:08] <xnox> infinity: just the mini small ones. Sweetshark has rc4 ready which builds those as system shared libs.
[22:08] <xnox> infinity: but it FTBFS at the moment.
[22:08] <xnox> infinity: and we want to transition the doom pile, preferably without fixing new libreoffice upstream FTBFS.
[22:08] <infinity> xnox: I don't want anyone to take this as a cue to start doing that more.
[22:09] <infinity> xnox: Why couldn't libreoffice have just rebuilt against the current versions of those libs?
[22:09] <infinity> xnox: It's an upload either way.
[22:09] <xnox> infinity: because next upstream release was ported and tested against the new versions, 4.2 was not.
[22:10] <infinity> Feh.  Well, that new upstream better come along soon.
[22:12] <xnox> infinity: it was meant to be ready last week, but slipped into this week instead.
[22:12] <xnox> infinity: but colin and I hope to get the transition of doom in before alpha2 freeze =)
[22:12] <xnox> and hence without 4.3 final.
[22:13] <xnox> the longer we keep this mess the more smaller transitions get intertweened into it.
[22:16] <infinity> xnox: I'm going to cancel that LibO PPC build and aim it at sagari later.  Don't panic when you get the fail mail. :P
[22:16] <xnox> infinity: alright, thanks. I'll go back to reading 50 shades of gray
[22:17] <infinity> ...
[22:17] <infinity> Don't.  It's awful.
[22:17] <infinity> Not the content, but the grammar.
[22:17] <cjwatson> xnox: I'd suggested skipping the NBS for now; did you miss that message?
[22:17] <infinity> Well, the content is laughable too.
[22:18] <cjwatson> laughable and abusive.
[22:43] <cjwatson> infinity: are you aiming LibO at sagari now?  I see it on manual
[22:47] <infinity> cjwatson: Yes.
[22:48] <cjwatson> ok, thanks
[23:32] <xnox> infinity: cjwatson: well, I found quotes from the parody funny and even the parody will get the movie (50 sheds of gray) and i'm sure i'll be dragged into watching them all, so i figured i should read them.
[23:32] <xnox> cjwatson: skipping the NBS would help, but it might all migrate by itself tomorrow or just require smaller things to be built.
[23:35] <slangasek> 50 sheds of gray?  Are these bikesheds?
[23:36]  * skellat remembers he was once a librarian and worries over the state of "literature" these days
[23:36] <RAOF> Gah! The version of gnome-do in 14.04 fails to build from source :(
[23:38] <bluesabre> gnome-don't
[23:38] <bluesabre> :)
[23:40] <cjwatson> Hm, autopkgtest execution queue rather backed up
[23:45] <slangasek> so what's the right way to fix the seed interdependencies?
[23:45] <cjwatson> Ideally, this should be detected at runtime rather than relying on fragile alternatives
[23:46] <cjwatson> I'm not sure how this can be fixed at the seed level
[23:46] <slangasek> no way to make touch-core inherit from desktop|touch-android, then :-)
[23:50] <cjwatson> Not so much :)
[23:58] <xnox> slangasek: https://twitter.com/50ShedsofGrey   for quotes.
[23:58] <xnox> RAOF: i did mention that in malta.... =)
[23:59] <RAOF> xnox: I clearly forgot :/


[02:58] <lotuspsychje> good morning
[07:25] <ducasse> good morning
[08:11] <marcoagpinto> morning!
[08:33] <marcoagpinto> one year and two months for 22.04 LTS!
[08:34] <marcoagpinto> I can hardly wait for it
[18:58] <jivan> drakonan: hello!
[19:12] <drakonan> hey thanks
[19:17] <jivan> drakonan: np — also, FWIW, sysadmin jobs pay pretty damn well, lol
[19:18] <lotuspsychje> https://canonical.com/careers/all 110 roles


[04:45] <themill> Does launchpad/loggerhead let you download the entire repo at some revision or do I need to figure out how to talk to bzr? (I'd like to get https://bazaar.launchpad.net/~esys-p-dev/esys-particle/gengeo/files)
[08:52] <xnox> themill:  bzr export gengeo.tar.gz https://bazaar.launchpad.net/~esys-p-dev/esys-particle/gengeo
[08:53] <xnox> sigh, wrong
[08:53] <xnox> bzr export gengeo.tar.gz lp:~esys-p-dev/esys-particle/gengeo
[08:53] <xnox> this one works
[20:13] <hallyn> hey guys - i'm looking for the packaging for the 'skeyer' package which existed in vivid but not since then.  Is that archived somewhere?
[20:13] <hallyn> (behing really lazy - i *could* just recreate it from scratch, i know...)
[20:18] <xnox> hallyn:  http://old-releases.ubuntu.com/ is the archive for archived stuff
[20:28] <hallyn> xnox: thanks.  oddly, not finding skeyer there, but i'll keep looking
[20:44] <xnox> hm, you sure it was in Ubuntu https://launchpad.net/ubuntu/+source/skeyer/+publishinghistory ?
[20:44] <xnox> not a single ppa either https://launchpad.net/ubuntu/+ppas?name_filter=skeyer&show_inactive=on
[20:47] <hallyn> xnox: well it was for ubuntu phone.
[20:47] <hallyn> no i'm not sure
[20:47] <hallyn> as i look at the source, i'm also not sure that this is legal (GPL library used in an LGPL project), so i may just have to do something completely different
[20:48] <hallyn> xnox: oh, yeah, i guess it was in michael.sheldon ppa for vivid only
[20:51] <xnox> hallyn:  there is an external phone fork, they could have it still.
[20:51] <hallyn> you're talking about ubports?
[20:51] <hallyn> they don't have it :(
[20:52] <hallyn> but, thanks :)   \o


[10:24] <brendand> this bug is not present in 11.04 -
[10:24] <brendand> https://bugs.launchpad.net/ubuntu/+source/totem/+bug/792692
[10:24] <ubot4> Launchpad bug 792692 in totem (Ubuntu) "Totem don't play MIDI files a second time (affects: 1) (heat: 8)" [Undecided,Incomplete]
[10:24] <brendand> but there is a different bug with the same functionality
[10:24] <brendand> should i leave it open?
[10:28] <brendand> we can't say the bug has been fixed but nor is it reproducible in the new release
[13:59] <brendand_> i can confirm this guys problem with the video mentioned in the bug
[13:59] <brendand_> https://bugs.launchpad.net/totem/+bug/755461
[13:59] <ubot4> Launchpad bug 755461 in totem (Ubuntu) (and 1 other project) "After "pause" and "play" again , it plays only few seconds, then stops (affects: 2) (heat: 10)" [Undecided,Confirmed]
[14:00] <brendand_> it has an importance of Normal in Gnome Bugzilla, so I reckon an importance of Medium would suit
[14:06] <charlie-tca> brendand_: done
[14:51] <RedSingularity> jibel: How did you figure sunbird to be the issue in bug 790517 ?  The only mention of sunbird in the logs was "Installing sunbird as Depends of sunbird-locale-de"
[14:51] <ubot4> Launchpad bug 790517 in update-manager (Ubuntu) "Upgrade to kubuntu natty failed (affects: 1) (heat: 10)" [Undecided,Invalid] https://launchpad.net/bugs/790517
[14:54] <roadmr> hi folks: bug 780962 and bug 792501 look the same to me, I'd like to dupe them but am unsure if it should go under unity or libreoffice. Also, unable to duplicate, but two people with the same problem looks legit enough to me
[14:55] <ubot4> Launchpad bug 780962 in libreoffice (Ubuntu) "Conflict with unity dock (affects: 1) (heat: 106)" [Undecided,Incomplete] https://launchpad.net/bugs/780962
[14:55] <ubot4> Launchpad bug 792501 in unity (Ubuntu) (and 1 other project) "sidebar launcher apears unexpected when i use libreoffice (affects: 3) (heat: 353)" [Undecided,Incomplete] https://launchpad.net/bugs/792501
[15:05] <jibel> RedSingularity, this is bug 760713, but it's supposed to be fixed. I didn't had time to look at the details to check if it is actually not fixed or something specific to the user setup.
[15:05] <ubot4> Launchpad bug 760713 in nss (Ubuntu) "Upgrade from 10.10 to 11.04 fails: sunbird/karmic holds back libnss3 (affects: 9) (dups: 2) (heat: 84)" [Low,Fix released] https://launchpad.net/bugs/760713
[15:12] <RedSingularity> jibel: yeah thats it.  How did you figure sunbird?  I dont even see it mentioned in those logs.
[17:13] <brendand_> hey pedro_
[17:13] <brendand_> can i ask a quick question?
[17:14] <pedro_> sure
[17:19] <brendand_> pedro_ - if i submit an application for Bug Control membership early next week will it be reviewed in the Thursday meeting?
[17:27] <hggdh> brendand_: not much of a chance... we wait for two reviews, and then we wait for a _week_ before making it official
[17:27] <hggdh> brendand_: the reviews are done via ML
[17:36] <brendand_> hggdh - well, that's ok
[18:30] <elopio> good morning ubunteros :)
[18:31] <elopio> when I try to close a bug with something like
[18:31] <elopio> hugday close 618836
[18:31] <elopio> I get ValueError: One or more bugs can't be found: 618836
[18:31] <elopio> does it work for you?
[18:37] <braiam> elopio: me too!!
[18:41] <elopio> braiam: at least I'm not alone :)
[18:45] <elopio> braiam: I found a conversation here: http://logs.ubuntu-eu.org/free/2010/03/10/%23ubuntu-bugs.html
[18:45] <elopio> it's a problem with the url of the bugs in the wiki.
[18:48] <braiam> elopio: you mean "at least we're not alone" ;)
[18:50] <elopio> ok, I think it should work now :)
[18:56] <elopio> I have a doubt. If we ask somebody to send the issue upstream, should the issue be marked as incomplete?
[19:00] <Ampelbein> elopio: I usually set to confirmed and move to triaged when the upstreaming has been done.
[19:01] <elopio> Ampelbein: that sounds good. And what if after some months nobody has send it?
[19:01] <elopio> I added a reminder coment
[19:01] <elopio> but it should remain confirmed for ever if no one sends it upstream?
[19:02] <Ampelbein> elopio: you can open an empty upstream task and check in a month or so. if noone sends it, I report the issue upstream myself.
[19:03] <elopio> Ampelbein: Ok. Do you send it even if you can't reproduce it?
[19:04] <Ampelbein> elopio: depends. I let my gut decide. ;-)
[19:04] <Ampelbein> elopio: what is the bug in question?
[19:04] <elopio> :)
[19:04] <elopio> thanks for your answers Ampelbein. A hug for you.
[19:05] <elopio> the bug: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/590800
[19:05] <ubot4> Launchpad bug 590800 in totem (Ubuntu) "Pause sets video back (affects: 5) (heat: 21)" [Low,Confirmed]
[19:06] <elopio> brb. I'll feed my gut, so he can make wise choices :D
[19:14] <braiam> elopio: you changed the wiki or what??
[21:44] <jpiche> does anyone from bug control have a minute to look at the "importance" on bug 775950?
[21:44] <ubot4> Launchpad bug 775950 in linux (Ubuntu) "fixing recursive fault but reboot is needed! upon boot (always reproducible on battery only, but sometimes on AC too) (affects: 21) (heat: 110)" [Undecided,Confirmed] https://launchpad.net/bugs/775950
[22:51] <pfefferz> hello?
[22:52] <pfefferz> I'm seeing a weird emacs issue
[22:52] <pfefferz> emacs: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: pango_font_description_get_style
[22:52] <pfefferz> GNU Emacs 23.2.1
[22:52] <pfefferz> I think this happened after my last autoupdate
[23:01] <micahg> sounds like it's missing a dependency
[23:01] <micahg> or needed a rebuild
[23:03] <pfefferz> yeah...


[02:07] <jldupont> for building a package with a different revision # (package revision #), where do we put htis information ?
[02:07] <jldupont> launchpad doesn't let me re-upload under the same version #...
[02:07] <jldupont> I'd rather not bump my version #...
[02:07] <mwhudson> jldupont: the version number is specified in debian/changelog
[02:07] <jldupont> PLEASE help!
[02:08] <maxb> he just did
[02:08] <jldupont> mwhudson: ok, I'll try. thanks
[02:08] <mwhudson> jldupont: if you changed something, you have to change the version number, them's the rules
[02:08] <wgrant> It's not the same version, so it should not have the same version number.
[02:08] <mwhudson> jldupont: if you just changed the packaging info though, you'd usually change the part after the '-' in the version number
[02:08] <jldupont> I just need to re-package because I screwed up something.
[02:08] <jldupont> the codebase is the same.
[02:08] <mwhudson> or add a part after the '-'
[02:08] <jldupont> I just messed up the package... not the source.
[02:09] <mwhudson> right
[02:09] <mwhudson> so make the new package 1.0-1jldupont1 or something
[02:09] <jldupont> mwhudson: I give it a try. thanks
[02:09] <jldupont> great.
[02:09] <mwhudson> wgrant and maxb know far more than me about good taste in version numbers though :-)
[02:10] <jldupont> :-)
[02:10] <wgrant> jldupont: Also, they're not NMUs.
[02:10] <maxb> jldupont: It looks like you are erroneously building 'native' packages
[02:10] <wgrant> And you really do wnat to make them non-nativ.e
[02:10] <jldupont> How do I fix that?
[02:11] <jldupont> tintian was complaining about not seeing NMU
[02:11] <jldupont> so I just stuck NMU
[02:11] <maxb> So you've got your http://erlang-dbus.googlecode.com/files/erlang-dbus-0.3.zip ... now it's slightly more complicated as it's not a tarball
[02:12] <jldupont> maxb: no no
[02:12] <maxb> So first you repack it into erlang-dbus-0.3.tar.gz, since upstream don't give you one of those
[02:12] <jldupont> the stuff on GC is not up to date
[02:12] <jldupont> I am building locally ... no upload to GC
[02:12] <bronger> For manual review of translations, is a waiting time of one week worrying?  The docs say "few days" so it may be okay and I wouldn't pester the admins.
[02:12] <jldupont> I can do the full cycle to Launchpad with no issue
[02:12] <maxb> ....yet you are using the same version number as that
[02:12] <jldupont> yes
[02:12] <jldupont> I mean the codebase is 0.3
[02:13] <maxb> Right
[02:13] <jldupont> just I messed up the packaging part
[02:13] <maxb> So you take your erlang-dbus-0.3.tar.gz
[02:13] <jldupont> yes
[02:13] <maxb> and you rename it to erlang-dbus_0.3.orig.tar.gz, following dpkg conventions for an upstream tarball
[02:13] <jldupont> well, no
[02:14] <jldupont> I needed to change debian/changelog
[02:14] <maxb> and then you set the version number in debian/changelog to 0.3-something
[02:14] <jldupont> I am going thourhg a cycle now... I'll update you guys in a sec
[02:14] <maxb> 0jldupont1 is a good value for something
[02:14] <wgrant> This issue comes up to frequently that I think we need to stick an FAQ somewhere.
[02:15] <maxb> And then, when you build the debian source package, you get a erlang-dbus_0.3-0jldupont1.diff.gz containing the packaging changes relative to the .orig.tar.gz
[02:16] <jldupont> did all that... waiting for accept/reject from Launchpad now...
[02:16] <jldupont> BTW, I am packaging another project... a dependency to erlang-dbus... epapi
[02:16] <jldupont> http://epapi.googlecode.com/
[02:17] <jldupont> "Within Temptation"... those guys ROCK!
[02:21] <jldupont> accepted !! thanks guys!!
[02:23] <maxb> err.... except you've not done what I said at all
[02:23] <maxb> You've just made a native package with a dash in its version
[02:23] <maxb> I wish dpkg didn't allow that
[02:24] <jldupont> maxb: not sure what you mean.
[02:24] <jldupont> newbie here... please explain.
[02:24] <maxb> You haven't done what I said about using an .orig.tar.gz
[02:25] <jldupont> I just execute "debuild -S -sa"
[02:25] <jldupont> like @cyphermox told me
[02:26] <jldupont> I get epapi_0.7-2_source.changes
[02:26] <mwhudson> jldupont: do you know what a 'native package' is?
[02:26] <jldupont> epapi_0.702.tar.gz
[02:26] <jldupont> no I do not know what a "native package" is.
[02:26] <jldupont> newbie here,,, sorry
[02:26] <mwhudson> jldupont: debian packaging is not simple
[02:27] <mwhudson> for better or for worse
[02:27] <jldupont> (and I thought that Python PyPi packaging was tricky)
[02:27] <mwhudson> trying to pretend it is doesn't really work
[02:27] <mwhudson> but it's not that bad either
[02:27] <jldupont> (thank god packaging extension for Google CHrome is much simpler)
[02:28] <mwhudson> jldupont: https://wiki.ubuntu.com/PackagingGuide is probably a good place to start
[02:28] <jldupont> so, what's a native package and why can't I do one?
[02:29] <mwhudson> the idea of debian packaging is to take an upstream release
[02:29] <mwhudson> this is the orig.tar.gz
[02:29] <jldupont> ok
[02:29] <mwhudson> and produce a diff that adds the packagingn information
[02:29] <mwhudson> (the .diff.gz)
[02:29] <jldupont> ... but I am the "upstream"... that's my stuff
[02:30] <mwhudson> if you don't do this, if the packaging is in the upstream tarball, then it's a native packaging
[02:30] <mwhudson> jldupont: it's still the debian way to separate upstream and packaging information
[02:31] <jldupont> hmm... I am closer to understanding... but not quite.
[02:31] <jldupont> the sutff in epapi.googlecode.com
[02:31] <jldupont> is my stuff. I am just trying to package it
[02:31] <jldupont> for easier distribution.
[02:31] <mwhudson> i'm not really an expert
[02:31] <wgrant> It's still cleaner to separate the upstream code and packaging. Plus it makes for better version numbers.
[02:32] <maxb> The point is: either the package is being built for Debian/Ubuntu itself *only* - in which case there is no separation between upstream and distro - and this is a native package - e.g. dpkg itself
[02:32] <maxb> Or it's a piece of software that just happens to be being packaged for Debian/Ubuntu
[02:32] <jldupont> maxb: right.
[02:33] <jldupont> of course I'll consider packaging for Fedora.
[02:33] <maxb> In which case, one upstream version, 0.7, may very well be packaged many times - e.g. for hardy, jaunty, karmic etc.
[02:33] <jldupont> oh
[02:33] <jldupont> I think I understand now.
[02:33] <jldupont> what you are suggesting is that I name my pakacge better:
[02:34] <jldupont> epapi_0.7-2_jaunty
[02:34] <maxb> Hence a dash has a special meaning in a debian version number: it separates the upstream part of the version from the packaging part of the version
[02:34] <jldupont> or something like it?
[02:34] <jldupont> I am strating to grok it
[02:34] <maxb> uhoh, no, an underscore is a separator for other things, you don't want one of those in a version number
[02:35] <jldupont> so, epapi_0.7-2jaunty then?
[02:35] <maxb> Reasonable
[02:35] <jldupont> and when I get to karmic, I do epapi_0.7-2karmic
[02:35] <wgrant> -2 sounds like a lie, however.
[02:35] <jldupont> ??
[02:36] <jldupont> oh
[02:36] <wgrant> It should probably be -0, since -1 would be the first Debian version.
[02:36] <jldupont> don't be too picky... newbie here
[02:36] <maxb> -2 conventionally implies it's derived from an official debian package
[02:36] <jldupont> ah!
[02:36] <wgrant> But with the current proliferation of repositories, sane versioning is becoming harder.
[02:36] <jldupont> there is convention there too... I get it.
[02:36] <jldupont> point me in the right direction.
[02:36] <jldupont> and I am happy to oblige
[02:36] <maxb> Basically, it should start with a zero after the dash unless it's derived from a version in Debian
[02:37] <wgrant> And ideally should be less than -0ubuntu1
[02:37] <jldupont> epapi_0.7-0jldupont-jaunty
[02:37] <wgrant> So that if you get the package into Ubuntu, the official version will supersede the one in your PPA.
[02:37] <jldupont> ok
[02:37] <wgrant> So you could do 0.7-0jldupont1~jaunty1
[02:37] <maxb> Fortunately, 'U' is late in the alphabet
[02:37] <wgrant> I normally do -0ppa1, because 'wgrant' > 'ubuntu' :(
[02:38] <jldupont> I see
[02:38] <jldupont> I get it now... you guys rock!!
[02:38] <maxb> epapi_0.7-0jldupont-jaunty  <-- but dashes are special, so that one would not do what you wanted it to
[02:38] <jldupont> let me resubmit to Launchpad now...
[02:39] <maxb> jldupont: Your next problem is to deal with all the binary build artifacts that are messily included in the upstream tarball, and are not cleaned
[02:39] <jldupont> yeah, I'll do epapi_0.7-0jldupont~jaunty1
[02:39] <jldupont> ? mess in the tarball ?
[02:40] <jldupont> from where are you taking this??? the source tarball is not on GoogleCode...
[02:40] <jldupont> it is only on my machine... at least the tarball I use for packaging to Launchpad that is.
[02:41] <jldupont> the one you may probably see contains the right source code... but that's not the one I am working from to package here.
[02:41] <wgrant> Having multiple tarballs with the same version number but different contents is a very bad idea.
[02:42] <jldupont> granted... I am trying to move away from GC.
[02:42] <jldupont> I'll clean up.
[02:42] <jldupont> I'll point the main page on GC to the one on Launchpad.
[02:42] <maxb> Your hosting provider is irrelevant - there's still the concept of "the upstream tarball" which then gets packaged
[02:43] <jldupont> maxb: yes
[02:46] <jldupont> ok now... changes applied... shipped to launchpad... waiting.
[02:47] <maxb> What exact version did you upload?
[02:48] <jldupont> epapi_0.7-0jldupont1~jaunty1
[02:48] <jldupont> I'll cancel the other one.
[02:48] <maxb> will be rejected because it's a lower version than the current publication
[02:48] <jldupont> !@&#*!(@#&
[02:49] <jldupont> so then, how about epapi_0.7-3jldupont1~jaunty1) ?
[02:50] <maxb> Launchpad should accept epapi_0.7-0jldupont1~jaunty1 if you delete the 0.7-2 first
[02:50] <jldupont> I tried deleting stuff before... it seems there is a lag of many minutes... not fast enough... I want to get to bed at some point!
[02:51] <maxb> There won't be a problem here
[02:51] <maxb> As soon as you've done the deletion in the UI, it'll be happy to accept the new upload
[02:52] <jldupont> maxb: are you working for Launchpad?
[02:52] <maxb> Even if the files don't disappear from disk until some time later
[02:52] <maxb> No. Just a contributor
[02:52] <jldupont> I delete 0.7-2 ... can I dput now?
[02:52] <maxb> yes
[02:52] <jldupont> done
[02:53] <jldupont> ... will it go through now?
[02:55] <mrooney> Is there a delay for ppa dependencies taking effect?
[02:55] <FFEMTcJ> I'm a little confused and I'm hoping someone can help me out.. During UDS it was mentioned about LoCo teams creating and using roadmaps...
[02:55] <maxb> I don't believe so. It should take effect from the next build started after you reconfigure
[02:55] <FFEMTcJ> In order to create a roadmap, am I correct that you need to create a project?
[02:56] <mrooney> I've added some ppa deps to a ppa, uploaded a new package, I see the new package but it says it can't resolve
[02:56] <mrooney> maxb: hm maybe the build started before, I could check
[02:56] <jldupont> maxb: accepted!
[02:56] <mrooney> I'll do anew upload but I'm pretty sure I had the deps before
[02:56] <maxb> mrooney: You can see the actual apt lines used for a particular build in the buildlog
[02:57] <mrooney> I don't need to do anything special with the deps in debian/control right, just the package name I need from whatever archive ends up satisfying it?
[02:57] <maxb> yes
[02:57] <maxb> What's the package?
[02:58] <maxb> FFEMTcJ: 'roadmap'? What's one of those?
[02:59] <FFEMTcJ> https://blueprints.edge.launchpad.net/ubuntu/+spec/encouraging-team-roadmaps-and-planning maxb look at that
[02:59] <mrooney> When the build machine builds, would it pull in an old cache or not?
[02:59] <FFEMTcJ> sorry.. not roadmap.. blueprint
[02:59] <FFEMTcJ> sorry maxb
[02:59] <mrooney> The specific ppa is ppa:elementaryart/elementarydesktop
[03:00] <FFEMTcJ> wrote what i was looking at not what i was thinkin about
[03:00] <maxb> Right... a blueprint is a Launchpad thing, which may point at an arbitrary URL, which might be a roadmap
[03:01] <maxb> And yes, blueprints need to be associated with a project or distro
[03:01] <mrooney> Hm I see the ppas listed in http://launchpadlibrarian.net/35903735/buildlog_ubuntu-karmic-i386.elementary-desktop_0.1-0ubuntu1~ppa4_FULLYBUILT.txt.gz
[03:01] <FFEMTcJ> ok maxb.. thanks
[03:01] <jldupont> maxb: Synaptic complains that my package can't be authenticated... what should I do?
[03:03] <jldupont> maxb: I thought Launchpad was taking care of all the authentication bits.
[03:03] <maxb> mrooney: yes, that's where to look
[03:04] <maxb> jldupont: I guess you haven't trusted your own ppa then
[03:04] <jldupont> where do I get the key file?
[03:05] <jldupont> I mean, this must be made public, no?
[03:06] <jldupont> sorry again for the newbie questions...
[03:07] <jldupont> ok... got it I think: http://keyserver.ubuntu.com:11371/pks/lookup?search=0xEC7AE4B5E4179E846B8AE0CF1A1E287CA6E4A2FB&op=index
[03:07] <jldupont> maxb: am I responsible for displaying this info to the public?
[03:08] <jldupont> or does Launchpad somehow exposes this?
[04:19] <wzssyqa> i have used dput to upload a package,and sucess.then i can't see it on my ppa.why
[04:21] <wgrant> wzssyqa: You'll receive an email of acceptance or rejection within five minutes, as long as you've signed the package with a key attached to your Launchpad account.
[04:23] <wzssyqa> wgrant: o ,i have not attatched my key to launchpad
[04:24] <wgrant> wzssyqa: You'd best do that and upload again.
[04:24] <wzssyqa> wgrant: o ,thx
[04:27] <wzssyqa> wgrant: Launchpad could not import your OpenPGP key   why?
[04:29] <mwhudson> have you uploaded your key to a key server?
[04:29] <wzssyqa> i don't know
[04:30] <mwhudson> wzssyqa: 'gpg --send-key'
[04:30] <wgrant> gpg --keyserver keyserver.ubuntu.com --send-key YOURKEYID
[04:32] <mwhudson> argl
[04:32] <wzssyqa> argl?
[04:32] <wzssyqa> upload sucess
[04:32] <mwhudson> https://help.launchpad.net/Packaging/UploadErrors -> "# The signing key that you used is not known to Launchpad, you need to add it to your account" -> links to https://edge.launchpad.net/+me/+editsshkeys
[04:35] <mwhudson> which is actually wrong in two ways
[04:36] <mwhudson> still, yay for wikis
[05:13] <wzssyqa> mwhudson: if i want to make it for several distro ,how to edit changlog?
[05:13] <mwhudson> wzssyqa: you can't
[05:14] <mwhudson> the usual practice is to upload it to the oldest appropriate distroseries and then copy it to the newer ones
[05:14] <wzssyqa> mwhudson: thx
[05:22] <wzssyqa> mwhudson: Unable to find distroseries: Karmic why?
[05:22] <mwhudson> wzssyqa: maybe it's case sensitive?
[05:22] <mwhudson> karmic
[05:32] <wzssyqa> mwhudson: PPA uploads must be signed by an Ubuntu Code of Conduct signer.  omg
[05:32] <mwhudson> yep
[05:32] <mwhudson> only nice people pls
[05:33] <wzssyqa> mwhudson: i can't understand
[05:34] <mwhudson> sorry
[05:34] <mwhudson> you have to sign the ubuntu code of conduct before you can use a ppa
[05:34] <mwhudson> the ubuntu code of conduct very roughly says "don't be a nasty person"
[05:35] <mwhudson> wzssyqa: https://edge.launchpad.net/codeofconduct
[05:55] <[BIOS]dnivra> i tried opening launchpad.net and i keep getting server is down
[05:55] <[BIOS]dnivra> i tried doing this again after 5 minutes and same problem
[05:55] <[BIOS]dnivra> is the server down or something else is wrong?
[05:55] <[BIOS]dnivra> the page asked me to inform on this channel
[05:56] <[BIOS]dnivra> is the server down?
[05:56] <raziel420> it seems down
[05:56] <wgrant> spm: ^^
[05:56] <raziel420> getting 503 errors on ubuntu one login even
[05:56] <[BIOS]dnivra> does this happen often?
[05:57] <wgrant> [BIOS]dnivra: No. I haven't seen it broken like this in a very long time.
[05:57] <raziel420> woulden't know, i just got back on linux yesterday after being away for almost a year
[05:57] <[BIOS]dnivra> ok
[05:57] <[BIOS]dnivra> raziel420: :O
[05:58] <[BIOS]dnivra> hey I am able to ping the server, doesn't it mean the server is still up
[05:58] <raziel420> i'm surprised myself, it took a year for xp to finnaly die on this machine, either i'm getting better at anti-internet or the other people who use my computer are finnnaly listening, plus tiny xp was actually the best xp i've ever used
[05:59] <raziel420> i don't think your actually pinging the server, i think your pinging a backup server, which seems to only have the offline message
[06:00] <raziel420> and yes the ip is probably the same, but the mac addy is probably different
[06:01] <[BIOS]dnivra> hmmm ok
[06:01] <Tanoshii> i couldn't get launchpad to work either, i gave up for now
[06:01] <dailystruggle> Is it maintenance?
[06:02] <[BIOS]dnivra> it's up again
[06:02] <raziel420> [BIOS]dnivra: i'm not completely certain, but a load balancing cluster is likely for launchpad
[06:03] <wgrant> There are a lot of machines behind the scenes, yes.
[06:03] <Tanoshii> it's back
[06:03] <[BIOS]dnivra> true
[06:03] <[BIOS]dnivra> lot of machines drive these servers
[06:04] <Tanoshii> i was trying the PPA Search works ok now
[06:05] <raziel420> of course sadly, it's also likely that someone tripped over a power cord, and they all managed to go down at once, except the dns and backup "offline" page
[06:05] <[BIOS]dnivra> raziel420: he he he
[06:06] <raziel420> i know i'd have those either at a completely different location, or at least with a ups and a seperate plug
[06:07] <[BIOS]dnivra> i think a completely different location should be the ideal one: no chance of it going down unless someone went with that intention
[06:07] <raziel420> but it was probably maintnance, since it was just a few minutes
[06:08] <raziel420> the problem with a different location is response time for the balancing dns
[06:09] <raziel420> well i'm out
[06:31] <wzssyqa> mwhudson: if have change my file ,how to re-upload?
[09:10] <bronger> For manual review of translations, is a waiting time of one week worrying?  The docs say "few days" so it may be okay and I wouldn't pester the admins.
[09:15] <qense> This week was the UDS, so a substantial amount of the devs were in Dallas discussing, rather than developing.
[09:15] <qense> That could explain your delay.
[17:24] <fcuk112> i just added my ssh key to launchpad, however when i try to get some source i get the following: http://www.pastie.org/708981
[18:29] <mrooney> Hey, anyone around familiar with PPA dependencies on other PPAs? I added some last night, did two rebuilds, and this morning I still have unsatisfiable deps
[18:29] <mrooney> which go away if I add the PPA deps myself to my machine
[18:30] <mrooney> I'm not sure what I'm doing wrong
[18:40] <qense> mrooney: I don't know much, but maybe you have to add the -dev packages as well? Maybe you already did that, just the only thing I can come up with.
[18:41] <mrooney> hm, I don't think, it builds fine on LP
[18:45] <mrooney> are those only the deps for building the package? does the user manually have to add the required PPAs?
[18:46] <mrooney> I think that might be how it works
[18:53] <mrooney> anyway if someone reads this and knows, please ping to me to confirm or deny
[19:00] <geser> mrooney: if your PPA need packages from other PPAs, the user needs to have both enabled on his system
[19:05] <mrooney> geser: ah okay, I was really confused, I thought PPA dependencies handled that, it took me two days banging my head against this to realize that only works for launchpad builds
[19:07] <magcius> Does Launchpad have Code Review?
[19:07] <magcius> That's based around patches and not Code Hosting?
[19:08] <magcius> Because some of us actually like to use Git or Mercurial.
[19:08] <jldupont> is it possible to publish the same package for more than 1 distribution? (provided it works of course)  e.g. Package X for jaunty & Karmic
[19:12] <jldupont> anyone??
[19:18] <geser> jldupont: you can copy a package between series
[19:20] <jldupont> I guess I need to change debian/changelog and go through all the cycle with Launchpad anyhow, right?
[19:27] <geser> only if you want to do a proper upload
[19:27] <geser> for copying packages between series you can use the webinterface
[19:28] <jldupont> geser: thanks.
[19:54] <jldupont> Do I need a separate PPA per serie? i.e. PPA X1 for Jaunty, PPA X2 for Karmic?
[19:54] <tsimpson> no
[19:54] <jldupont> @tsimpson: I guess debian/changelog suffice to Launchpad then./
[19:54] <jldupont> right?
[19:54] <tsimpson> yeah
[19:55] <jldupont> tsimpson: cool. thanks.
[19:55] <tsimpson> you can also upload to a specific series
[19:55] <jldupont> hmmm... checking dput options...
[19:56] <tsimpson> you use "incoming = ~<lp_name>/ppa/ubuntu/<a ubuntu suite>"
[19:56] <tsimpson> you can call it something like [my-ppa-<release>]
[19:56] <tsimpson> then just: dput my-ppa-jaunty file.changes
[19:56] <jldupont> in dput.conf I guess
[19:57] <jldupont> right?
[19:57] <tsimpson> yeah
[19:57] <jldupont> ok, thanks for bearing with me... newbie to PPA here.
[19:57] <tsimpson> but the changelog way is probably better anyway, as you can't upload the same version of a package to different releases
[19:58] <jldupont> got it.
[19:58] <jldupont> right now, in my dput.cf, I've got "www.wampserver.com/en/"
[19:58] <jldupont> sorry...
[19:59] <jldupont> incoming = ~jldupont/jldupont/ubuntu/
[19:59] <jldupont> is this even remotely correct??
[19:59] <jldupont> I think I have just cut&pasted from a tutorial ....
[19:59] <tsimpson> it's ~<lp ID>/<ppa name>/ubuntu/
[20:00] <jldupont> ok, check.
[20:00] <jldupont> ... and the series is specified in debian/changelog
[20:00] <jldupont> I get it now.
[20:00] <tsimpson> yes
[20:00] <jldupont> Now, let's say I want to pbuild for different series,
[20:01] <tsimpson> but if you upload to "~jldupont/jldupont/ubuntu/karmic/" that will override what's in the changelog
[20:01] <jldupont> ok, got it.
[20:01] <jldupont> then I am not forced to go through a full build cycle...
[20:02] <jldupont> except I have to a package name more generic...
[20:02] <jldupont> i.e. not with the series in the filename...
[20:02] <jldupont> right?
[20:02] <jldupont> right now, I've got "epapi_0.7-0jldupont1~jaunty2
[20:03] <jldupont> wait, I thought the "series" parameter needs to appear in debian/changelog...
[20:04] <tsimpson> it does, you're just changing the version of the package so the binaries (.debs) don't conflict with each other
[20:04] <tsimpson> you'll have to build for each series you want unfortunately, so you'd need to change the version to "epapi_0.7-0jldupont1~karmic1" for example, then debuild -S and dput the changes
[20:04] <jldupont> ... but once I fiddle with debian/changelog, I have to go through the full pbuilder cycle, no??
[20:05] <tsimpson> you don't pbuild anything
[20:05] <tsimpson> launchpad does the building
[20:05] <tsimpson> you just upload the source (the .orig.tar.gz, .dsc, .diff.gz and .changes)
[20:05] <jldupont> I know pbuild isn't stricly required... I just want to make sure it builds on my side
[20:05] <jldupont> before waiting many hours for Launchpad...
[20:05] <jldupont> I guess if I am confident enough, I skip the pbuild step...
[20:06] <tsimpson> unless you want to test build on every release, let LP do it for you :)
[20:06] <jldupont> right.
[20:07] <jldupont> I just need to be patient I guess.
[20:07] <jldupont> for pbuilder, I need to use a separate VM per series I guess... right?
[20:07] <tsimpson> a separate chroot, yeah
[20:08] <jldupont> separate chroot... hmmm... how do I do that...?
[20:08] <jldupont> I followed https://wiki.ubuntu.com/PbuilderHowto
[20:09] <tsimpson> you need to create each one with something like "pbuilder --create [--basetgz karmic-base.tgz --distribution karmic"
[20:09] <jldupont> oh yes... sorry... makes sense.
[20:09] <jldupont> cool... thanks again.
[20:09] <tsimpson> :)
[20:10] <jldupont> and when I do "pbuilder build",
[20:10] <jldupont> pbuilder will switch to the appropriate chroot environment?
[20:10] <tsimpson> no, you have to do that manually ;)
[20:10] <jldupont> based on what is in the .dsc file?
[20:11] <tsimpson> pbuilder --build --basetgz karmic-base.tgz --distribution karmic <file.dsc>
[20:11] <tsimpson> it's a pain
[20:11] <jldupont> that's my line in my makefile: @cd "/tmp/$(PRJ)/" && sudo pbuilder build *.dsc
[20:11] <jldupont> I don't see a reference to a series...
[20:13] <jldupont> tsimpson: are you sure you need the "--distribution" switch?
[20:13] <tsimpson> this is my ~/.pbuilderrc: http://paste.ubuntu.com/324756/
[20:14] <tsimpson> you may not, but I tend to use it for the above
[20:14] <tsimpson> then I don't need to worry about the --basetgz part
[20:14] <tsimpson> or I can just do "sudo pbuilder --build ../<file>.dsc" and it'll figure out the distribution for me
[20:14] <tsimpson> (from inside the source dir)
[20:16] <jldupont> that means that when I do "pbuilder create", I have to specify a $DIST-base.tgz, right?
[20:17] <tsimpson> with that .pbuilderrc you should just have to do "sudo pbuilder --create --distribution <dist>" and it'll do the rest
[20:17] <tsimpson> the name of the basetgz is figured out from the distribution
[20:17] <jldupont> yes right... unlike what they say in the tutorial then....
[20:17] <jldupont> sudo pbuilder create --debootstrapopts --variant=buildd
[20:18] <tsimpson> yeah, if you don't specify a distribution, it'll use your current one (the output from "lsb_release --short --codename")
[20:18] <jldupont> right.
[20:19] <tsimpson> it just makes my life that little bit easier :)
[20:19] <jldupont> cool.
[20:19] <jldupont> I want that too ;-)
[20:22] <jldupont> oopppsss... just doing "sudo pbuilder --create --distribution karmic" on my jaunty machine doesn't work...
[20:22] <jldupont> help !
[20:23] <jldupont> E: No such script: /usr/share/debootstrap/scripts/karmic
[20:24] <jldupont> help!
[20:25] <tsimpson> install debootstrap from -backports
[20:25] <tsimpson> or just add a symlink manually
[20:25] <tsimpson> they all point to /usr/share/debootstrap/scripts/gutsy
[20:25] <jldupont> nice to know !
[20:25] <jldupont> is that what you do, just symlink?
[20:26] <tsimpson> ls -l /usr/share/debootstrap/scripts/karmic
[20:26] <tsimpson> lrwxrwxrwx 1 root root 5 2009-10-30 02:42 /usr/share/debootstrap/scripts/karmic -> gutsy
[20:26] <tsimpson> so just "sudo -i" then "cd  /usr/share/debootstrap/scripts/; ln -s gutsy karmic"
[20:26] <tsimpson> done
[20:27] <jldupont> done... cool!
[20:31] <Gandalfar> when creating own PPA, I don't see a button to "activate" it? Do I have to wait for the first build? Is there a way to see a status of the build?
[20:31] <jldupont> it activates itself when it is built correctly.
[20:32] <Gandalfar> can I see any progress on the build or ETA until build starts?
[20:32] <jldupont> tsimpson: don't you have a typo in your .pbuilderrc?  DISTROBUTION ?
[20:32] <jldupont> @Gandalfar: there is a link through your PPA homepage somewhere.
[20:32] <tsimpson> jldupont: ohh, thanks
[20:32] <Gandalfar> ah
[20:32] <Gandalfar> it showed up now!
[20:33] <Gandalfar> excited :)
[20:33] <Gandalfar> >>  Pending (2505) , what does the number mean?
[20:34] <jldupont> it is a "score"... there is a man page somewhere on LP.
[20:34] <jldupont> i.e. package pending build.
[20:34] <Gandalfar> ah
[20:34] <tsimpson> https://help.launchpad.net/Packaging/BuildScores
[20:34] <Gandalfar> I thought it's ETA :)
[20:34] <jldupont> funny!
[20:34] <tsimpson> the higher the score, the earlier it'll build
[20:35] <Gandalfar> maybe I should just do a binary upload
[20:36] <jldupont> you can't
[20:37] <Gandalfar> ahh, found the ETA :)
[20:37] <jldupont> is there a robot for the common questions?
[20:44] <Lostinspace_46> I am setting up a PPA.  All has gone well until launchpad sends me the code of conduct I have to sign and send back.  If I sign it and send it back I get a message that says the text is not the same as the code of conduct.  If I send it unsigned I get a message that says contains no data.  How might I fix this?
[20:44] <jldupont> seems like a cut&paste error...
[20:46] <Lostinspace_46> I have checked the text word for word in the pasted area before I submit
[20:46] <Gandalfar> Lostinspace_46, did you paste the signature part also?
[20:47] <Lostinspace_46> Gandalfar,  Yes I did, that's when I get the "text is not the same" message
[20:48] <Gandalfar> hmm, I wgeted the code .txt file and then ran the signature, cat-ed the result and copy/pasted using firefox
[20:48] <Gandalfar> s/signature/gpg signing
[20:49] <tsimpson> have you imported your gpg signature?
[20:50] <tsimpson> and make sure you download from: https://launchpad.net/codeofconduct/1.0.1/+download
[20:50] <tsimpson> rather than copy + paste
[20:51] <Lostinspace_46> Gandalfar, I did notice there is a begin and an end for the signature but only a begin for begin signed message.  also the acs file won't open with "verify sigmature"
[20:51] <Lostinspace_46> Yes i imported the sig
[20:51] <Gandalfar> it looks there is a problem with your signature process
[20:51] <Gandalfar> like you're missing last line or something
[20:53] <Gandalfar> fun, my build failed
[20:53] <Lostinspace_46> I used the email that was sent, I will try the download. thanks and I will be back in a few.  Also the missing line crossed my mind.
[20:54] <jldupont> Gandalfar: ... time to setup a "pbuilder" environement ;-)
[20:54] <Gandalfar> jay
[20:54] <Gandalfar> do you have doc handy? :)
[20:54] <jldupont> https://wiki.ubuntu.com/PbuilderHowto
[20:54] <Gandalfar> thanks :)
[20:54] <jldupont> I am documenting on my end as I go along.
[20:56] <Lostinspace_46> Understand that most of this is a bit beyond me.  But I know a working openoffice 3.1.1 is available at launchpad.  That is the reason I am doing this.
[20:56] <Lostinspace_46> I assume I need a PPA to access a PPA
[20:56] <Gandalfar> Lostinspace_46, you don't need PPA
[20:57] <Gandalfar> Lostinspace_46, you can grab PPA as anonymous user
[20:57] <Gandalfar> you need PPA env only if you want to make your own PPA repository, as in .. you're a developer
[20:57] <Lostinspace_46> Gandalfar,  AARRRGGHHH!!  I spent hours trying to get this to work
[20:58] <Gandalfar> well, the good news is .. you can stop now :)
[20:58] <Gandalfar> Lostinspace_46, https://help.launchpad.net/Packaging/PPA/InstallingSoftware
[20:59] <Gandalfar> even though, this guide looks a bit unfriendly
[20:59] <Lostinspace_46> Gandalfar,  Thanks I am checking that now. Back in a few, and thanks
[21:11] <Gandalfar> hmm, I guess I created a bad pbuilder repository
[21:13] <Gandalfar> The following packages have unmet dependencies:
[21:13] <Gandalfar>   pbuilder-satisfydepends-dummy: Depends: libplot-dev which is a virtual package.
[21:13] <Gandalfar> The following actions will resolve these dependencies:
[21:13] <jldupont> where is "libplot-dev" located?
[21:13] <jldupont> maybe you need OTHERMIRROR ?
[21:13] <Gandalfar> universe
[21:14] <jldupont> then, .pbuilderrc COMPONENTS is missing.
[21:14] <Gandalfar> I see
[21:14] <Gandalfar> found it in the faq now :)
[21:14] <jldupont> cyphermox: is there a robot sitting around here?
[21:14] <jldupont> for common queries etc.
[21:16] <Lostinspace_46> Copy the first line from the apt sources.list entries section of the PPA overview page.  I can't find that page :(  No laughing at the noob, now..lol
[21:16] <Gandalfar> Lostinspace_46, which ppa are you trying to install?
[21:17] <Lostinspace_46> Openoffice 3.1.1
[21:17] <Gandalfar> url?
[21:17] <Lostinspace_46> Gandalfar,  LOL..I think that is what I am trying to find
[21:18] <Gandalfar> PPA repositories are very specific
[21:18] <Gandalfar> you need to get a link to one first
[21:18] <Gandalfar> go to the source of your ifnormation about this OOo 3.1.1 and they should have it
[21:19] <Lostinspace_46> Gandalfar,  OK let me see what I can do.
[21:34] <jldupont> To whoever cares: http://docs.google.com/View?id=dgstxrxv_443fx3845cr
[21:34] <jldupont> I'll be documenting the LP process (to some extent)
[21:38] <Gandalfar> jldupont, turn around first part
[21:38] <jldupont> ?
[21:38] <Gandalfar> jldupont, introduce correct .builderrc first and then sudo command
[21:38] <jldupont> oh , ic
[21:39] <jldupont> better?
[21:42] <Gandalfar> yep :)
[21:57] <Gandalfar> can I kill a build?
[21:59] <wgrant> No.
[22:00] <Gandalfar> I hope it doesn't recurse but just dies
[22:00] <Gandalfar> err, fails
[22:00] <Gandalfar> wgrant, who can kill it?
[22:00] <Gandalfar> it's this one - https://launchpad.net/~gandalf/+archive/pspp/+build/1358375
[22:02] <wgrant> Gandalfar: Only a sysadmin, none of whom are likely to be around at the moment.
[22:03] <Gandalfar> will the system autokill it after a while?
[22:03] <wgrant> If it stops producing output for a couple of hours, yes.
[22:03] <wgrant> Otherwise somebody will notice it has been going for ages and kill it manually.
[22:03] <Gandalfar> it's recursing in the ./configure part
[22:04] <Gandalfar> so the output will keep going
[22:04] <wgrant> Ah.
[22:05] <Gandalfar> maybe there is an admin channel or something where it's possible to raise this before it kills buildd for a couple of hours
[22:26] <mwhudson> unlikely to get a response on a sunday
[22:26] <Gandalfar> :(
[22:27] <Gandalfar> at least I learned how to test my builds prior to upload in pbuilder
[22:27] <mwhudson> i mentioned it in the company sysadmin channel anyway in case someone with permissions happens to see it
[22:28] <Gandalfar> k, thanks :)
[22:28] <wgrant> I really should fix the abort feature.
[22:28] <wgrant> I know why the backend of it is broken now.
[22:36] <Gandalfar> wgrant, would uploading a newer version kill the current job?
[22:37] <wgrant> Gandalfar: No.
[22:37] <wgrant> Gandalfar: It probably should, but that hasn't been implemented.
[22:38] <wgrant> Gandalfar: The queue will clear in a couple of hours, at which point a single builder out of action will not matter much.
[22:38] <Gandalfar> ok :)
[22:51] <fta> this build seems stuck since yesterday: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1354329
[23:09] <wgrant> bohrium again.
[23:09] <wgrant> It likes doing that.


[01:57] <stgraber> LaserJock: I'll at least do the testing part for edubuntu
[01:58] <LaserJock> stgraber: thanks, hopefully more people will step up as well for that
[01:58] <LaserJock> I'd hate for Jaunty to not get release just on account of that
[04:00] <stgraber> LaserJock: nah, it'll get released :) I'll just nag slangasek enough to get it released.
[04:06] <LaserJock> stgraber: heh, yeah
[04:06] <LaserJock> stgraber: how's LTSP lookin'?
[04:15] <stgraber> LaserJock: very good, a few glitches with local devices to fix, will do that next week at work
[04:15] <stgraber> LaserJock: I got a new background for ldm from ubuntu-art, really looks great
[04:15] <LaserJock> great
[04:16] <stgraber> http://www.stgraber.org/download/ldm_16-9.jpg
[05:36] <LaserJock> stgraber: that's awesome!
[17:40]  * anom2 is singing a horrible off-key tune.
[19:58] <zeronimo> This colombian LAWYER firm stole edubuntu's logo
[19:58] <zeronimo> http://www.forumabogadosyconsultores.com/home.htm
[20:07] <LaserJock> zeronimo: sure looks like
[20:07] <LaserJock> it
[20:20] <HedgeMage> :o