=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
=== slank is now known as slank_away
[01:03] <xnox> xz?
[01:06] <infinity> xnox: *blink*
[01:06] <infinity> xnox: Oh, my webkit question?  No, it really is relinking.
[01:06] <infinity> xnox: Adds about 11h on ARM.  Totally unfun.
[01:06] <xnox> although it has separate -dbg packages.
[01:06] <xnox> infinity: 0_0
[01:07]  * xnox noticed a checky -Zxz in cdbs/gnome.mk
[01:07] <infinity> It's the whole libtool relink-on-install business.
[01:07] <xnox> s/checky/$(whatever proper way to spell it)/
[01:07] <infinity> Cheeky?
[01:07] <xnox> yes.
=== _salem is now known as salem_
[01:11] <micahg> webkit doesn't use cdbs
[01:12] <xnox> micahg: sure. it was a slightly vaguely on-xz-topic references. considering that a few things in desktop seed do use cdbs/gnome.mk.
[01:14] <infinity> xnox: I don't mind if things are sneakily switching.  udebs have been xz for ages.
[01:14] <micahg> switching to xz debs is a good thing for things that are frequently updated
[01:15] <infinity> Over time, I think it's the right answer for almost everything, the only thing I've been pushing back on is us doing it on our own without coordination with Debian.
[01:17] <micahg> so, Debian's main goal right now was to try to get everything that's supposed to be on CD #1 back on CD #1, so that probably explains the GNOME usage
[01:17]  * micahg is telling people what they already know again...
[01:18] <xnox> infinity: micahg: should we switch langpacks from bz2 to xz?
[01:18] <xnox> frequent && !debian-upstream
[01:18] <xnox> =))))
[01:19] <infinity> xnox: Probably, yes.  Anything we're forcing to bz2 right now should probably switch.
[01:19] <infinity> xnox: Need to be careful, though, since that's all autogenerated, and we don't want to accidentally switch, say, lucid langpacks.
[01:19] <xnox> that would be all emacsen & texlive.
[01:20] <xnox> infinity: is lucid still getting langpack updates?!
[01:20] <infinity> Oh, probably not, since we're not doing point releases anymore.
[01:21] <xnox> yeah, that's what i thought - surely it must be past it's point releases.
[01:21] <infinity> But there's always the chance someone may decide that we should.
[01:21] <infinity> *shrug*
[01:21] <micahg> wait till april?
[01:21] <infinity> Anyhow, I wouldn't be against changing langpacks.  It's not really as meaningful as it was when we were trying to stuff them on alternate CDs, mind you.
[01:21] <infinity> Which was why they were bz2.
[01:22] <xnox> infinity: but these days we download them on-demand & the smaller they are the faster we download them.... not sure about the unpack time penalty vs bz2
[01:22] <infinity> It was never about mirror space or download time, just trying to stuff a ton of packages on a CD.
[01:23] <xnox> on-demand = during the install that is.
[01:23] <infinity> Download time versus unpack is hard to benchmark, since we first have to decide what an "average user" has for both bandwidth and CPU/RAM.
[01:24] <micahg> unpack should be faster than bz2
[01:24] <infinity> My gut feeling, though, is that almost any unpack time impact will negate bandwidth concerns almost immediately for all but people on dialup.
[01:24] <micahg> it's compression that might be a tad slower
[01:24] <infinity> micahg: Oh, for bz2, yes.  Which is why I said we should just switch bz2 stuff to xz.
[01:24] <infinity> This sort of turned into a generic xz discussion for me halfway through. :P
[01:25]  * xnox the 21st centure term for dial-up  is 3G or metered/expensive 4G
[01:25] <infinity> In general xz will almost always be a win over bz2.
[01:25] <infinity> But it can often be a loss over gzip.
[01:25] <StevenK> infinity: In terms of CPU time, file size or both?
[01:25] <infinity> StevenK: Both, usually.  bzip2 is pretty awful.
[01:26] <infinity> Which reminds me, I should drag our buildd chroots kicking and screaming into the current century and stop using bz2.
[01:27] <StevenK> Haha
[01:27] <StevenK> Does lp-buildd depend on them being bz2?
[01:27] <infinity> StevenK: Yeah, but that's easily solved.
[01:27] <StevenK> What about dak?
[01:27] <infinity> StevenK: What I need to double-check is that there are no server-side assumptions there.
[01:27] <infinity> StevenK: ...dak?
[01:28] <StevenK> infinity: Yeah, I've been trying to think about the chroot handling in LP, and I'm not sure.
[01:28] <infinity> StevenK: Preeeeetty sure we have no dak instances with a buildd/sbuild setup backed by the librarian's chroot tarballs. :P
[01:28] <StevenK> Heh
[01:28] <xnox> there is always first time for everything =)
[01:28] <infinity> Anyhow, if there are any soyuz assumptions, they'd just be filename assumptions.
[01:29] <infinity> Which isn't actually a big deal.
[01:29] <infinity> Cause I can check file(1) magic when I grab the librarian blob and work with that.  Filenames are meaningless.
[01:30] <infinity> (And given that they're stored as filcache/$HASH on the buildd anyway, filenames are already meaningless)
[01:30] <xnox> infinity: also tar knows how to auto-guess all supported compression formats by default....
[01:30] <StevenK> infinity: Oh, so it just assumes filecache/$HASH is bzip2? Orsum ...
[01:31] <infinity> StevenK: It's a bit weirder than that.  Since the $HASH is the hash of the tar.bz2, but after the first unpack, the contents are actually just the .tar
[01:31] <infinity> (To avoid unzipping over and over)
[01:31] <StevenK> Hah
[01:31] <infinity> Not sure what Daniel was smoking that day.
[01:32] <StevenK> Right, I was wondering if we were paying the bzip2 penalty over and over.
[01:32] <infinity> Nah, the bz2 hit is only on first unpack of a new chroot, so it's not a big deal.
[01:32] <infinity> Which is why I never cared deeply about changing format.
[01:33] <StevenK> infinity: And yet you seem to care a little now? :-)
[01:33] <infinity> I'll stop caring soon.
[01:33] <infinity> But I'm touching lp-buildd for some other fixes over the holidays, some compression magic could accidentally slip in.
=== salem_ is now known as _salem
=== Ursinha is now known as Ursinha-afk
=== chiluk_away is now known as chiluk
=== chiluk is now known as chiluk_away
=== bradm_ is now known as bradm
[07:38] <pitti> Good morning
[07:44] <mlankhorst> could one of the sru admins accept xorg so that I can retire the backports ppa? :-)
[08:00] <dholbach> good morning
=== directhe` is now known as directhex
=== mcclurmc_away is now known as mcclurmc
=== yofel_ is now known as yofel
=== Tonio_aw is now known as Tonio_
=== Pricey_ is now known as Pricey
=== gavin__ is now known as gavinguo
=== mthaddon` is now known as mthaddon
=== henrix_ is now known as henrix
=== stan_ is now known as stan
=== tkamppeter_ is now known as tkamppeter
[09:54] <blami_> what's a ubuntu developer usual workflow? When I decide to patch something should I do my changes to upstream first and then have them propagated to package or fix package first and then contribute to upstream?
[09:56] <persia> For ease of testing, I generally fix the package first, make sure it runs in the current development environment, and then see how the patch could go upstream.
[09:57] <dholbach> blami_, getting fixes as upstream as possible is usually the best idea, but depending on how urgent the fix is, it might make sense to get it into Ubuntu first
[09:57] <persia> That said, it is usually a good idea to check upstream to see if the issue is already solved beforehand (and perhaps cherrypick, if the new upstream version isn't looking likely to land in the current release), which may mean that the first solution is against upstream.
[09:58] <persia> dholbach: In terms of committing the patch, I couldn't agree more, but in terms of initial testing, do you usually pull the upstream source (repackaging if necessary), and patch it for issues?
[09:58] <dholbach> persia, no - I was merely commenting on where to contribute the fix to
[09:59] <persia> Oh, indeed.  Once the patch works, sending upstream is best, and sometimes it's not even worth an Ubuntu upload.
[10:11] <blami_> persia: so you usually do something like bzr branch something or apt-get source something, apply your changes, build the package, test it and then, if it works you decide how to integrate your changes?
[10:15] <persia> blami_: Precisely.  Generally it's apt-get source, edit-patch ${SOMETHING}, debuild -S -us -uc, sbuild -d -A ${PACKAGE}, dpkg -i ${PACKAGE}, test
[10:15]  * xnox with edit-patch hopefully dieing with fire =)
[10:15] <persia> If I'm testing something that only works in a low-performance environment, a headless environment, or an environment with limited flash-only storage, there might be some scps involved.
[10:16] <persia> xnox: Why?
[10:16] <xnox> "just edit in place & dpkg-source --commit" instead
[10:16] <xnox> persia: note "ing" as in process of, not 'dead' as in no longer used =)
[10:17] <persia> Ah, yeah, perhaps we'll reach that point someday.  Since we still have some packages not updated since warty (because they have no known issues that updates would solve), I suspect it will be a long time.
[10:17] <persia> Mind you, someone could teach dpkg-source --commit about the various format:1.0 patch systems :)
[10:23] <blami_> persia: thing is I was asked to evaluate possibility of adding location profiles to NetworkManager. As it seems I will need to integrate a larger body of code for prototype (not one or two line fix), I would appreciate some sort of version control in process of patching.
[10:24] <jtaylor> blami: you can write your patch in a clone of upstreams vcs
[10:24] <persia> If you're doing something complex like that, it's probably better to do the work upstream, wearing a "NetworkManager developer" hat, rather than an "Ubuntu Developer" hat.
[10:24] <jtaylor> most vcs have methods to dump your changes into a single patch for the package
[10:25] <persia> Big changes done downstream tend to be hard to push upstream, as they tend to lag trunk.
[10:25] <xnox> blami_: bzr branch is good for that as well =)
=== mcclurmc is now known as mcclurmc_away
[10:39] <pitti> sbeattie: it seems the last hardy glibc update broke postgresql; I put some analysis to bug 1088393
[10:39] <ubottu> Launchpad bug 1088393 in postgresql-8.3 (Ubuntu Hardy) "New bug fix releases: 9.1.7, 8.4.15, 8.3.22" [Undecided,In progress] https://launchpad.net/bugs/1088393
=== Tonio_ is now known as Tonio_aw
[11:05] <pitti> doko, jelmer: FYI, sent the samba4 patch to https://bugzilla.samba.org/show_bug.cgi?id=9503
[11:05] <ubottu> bugzilla.samba.org bug 9503 in build "waf assumes that pythonX.Y-config is a Python script" [Normal,New]
=== Tonio_aw is now known as Tonio_
[11:20] <seb128> pitti, oh, thanks for that bug reference, I got bitten by that recently in another upload as well
[11:20] <seb128> I wonder how many source will have the issue
=== Guest6605 is now known as iulian
[11:26] <xnox> seb128: interesting. what package was that?
[11:26] <seb128> xnox, py3cairo
[11:27] <seb128> xnox, http://launchpadlibrarian.net/125114732/py3cairo_1.10.0%2Bdfsg-3~exp3_1.10.0%2Bdfsg-3~exp3ubuntu1.diff.gz is the quick diff I didn't when the sync failed to build
[11:28] <seb128> xnox, I was a bit puzzled by why it was working before, but after reading pitti's comment that it's doko who changed the python script by a shell one things start making sense ;-)
[11:28] <xnox> *sigh*
=== mcclurmc_away is now known as mcclurmc
=== _salem is now known as salem_
[11:32] <xnox> seb128: upstream git history doesn't have pre-git history in it. but at least since Sep 2011 waf simply calls the python-config (without prepending interpreter)
[11:32] <xnox> weird.
[11:36] <pitti> seb128: oh, so that does affect more packages then?
[11:36] <seb128> pitti, yes
[11:36] <seb128> pitti, cf the url I just posted
[11:36] <pitti> *nod*
=== cpg is now known as cpg|away
[11:41] <ev> xnox: you were saying last night that the hadoop charm relates to gunicorn multiple times. I can't seem to find this though - could you point me in the right direction?
[11:42] <xnox> ev: ....ehm not to gunicorn. within itself only.
[11:42] <ev> oh
[11:42] <xnox> ev: it has e.g. worker-role, data-node-role or worker-and-data-node-role.
[11:43] <xnox> ev: sorry, i probably missunderstood what you need.
[11:43] <xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles.
[11:44] <xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles".
[11:46] <ev> ahh
[11:46] <ev> that is indeed slightly different
=== Tonio_ is now known as Tonio_aw
[12:07] <xnox> ev: you could write your own subordinate charm/relationship to gunicorn. connect to gunicorn via normal relationship & via subordinate relationship.
[12:08] <xnox> ev: since you can deploy subordinate onto your whoopsie charm.
[12:08] <ev> xnox: Gnuicorn is already a subordinate
[12:08] <ev> gunicorn*
[12:08] <xnox> I see....
[12:08] <xnox> =((((
[12:20] <doko> seb128, does pycairo have it's own copy of waflib?
[12:25] <xnox> doko: thanks to debian ftp-masters all waf packages must be unpacked & ship their own copy of waflib. but it seems like there has been broken piece of code cargo-culted outside of waf upstream.
[12:34] <StevenK> cjwatson_: In terms of that bug, I reported what I saw in terms of the traceback. Sadly, I didn't save a copy.
[12:43] <seb128> doko, yes
=== Ursinha-afk is now known as Ursinha
[12:52] <mdeslaur> pitti: thanks for figuring out the glibc issue, we'll look into it
[12:53] <pitti> mdeslaur: cheers
=== slank_away is now known as slank
=== Quintasan_ is now known as Quintasan
=== chiluk_away is now known as chiluk
=== cjwatson_ is now known as cjwatson
=== henrix_ is now known as henrix
=== Tonio_aw is now known as Tonio_
[14:28] <stgraber> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
[14:28] <stgraber> (missed my shift last Monday)
[14:36]  * dholbach hugs stgraber
=== speakman_ is now known as speakman
[14:43] <pitti> stgraber: FYI, I'm looking at the autopkgtest one
[14:43] <pitti> (sponsor queue item, I mena)
[14:43] <pitti> "mean" -- TGIF!
[14:43] <stgraber> pitti: ok
[14:46] <rbasak> Is there any difference between a source debdiff and a run of diff against two source directories? Can I just attach a suitable diff that can be applied to a debian source tree and claim it's a debdiff, or would that be wrong?
[14:47] <rbasak> (with an implied necessary -p1 the same as debdiff does)
[14:47] <infinity> rbasak: Why claim it's a "debdiff" at all?  Just call it a "patch", which is what it is. :P
[14:47] <pitti> rbasak: a debdiff between two .dsc is more reliable
[14:47] <pitti> rbasak: but in general, no; as long as your diff doesn't have junk in it it should be fine either way
[14:47] <infinity> (And I have no issues with people submitting source patches, and letting the sponsor sort out how best to apply it to the package)
[14:47] <rbasak> LP (or more likely some bots) treats a debdiff slightly differently in some cases
[14:48] <rbasak> infinity: thanks. Because you're getting this one :-)
[14:48] <rbasak> And thank you pitti
[14:48] <rbasak> (this is because I wanted to revert half of a previous commit and I used git to achieve it)
[14:49] <infinity> rbasak: Oh, I am?  Lucky my.  Should I point out that I've been on vacation since yesterday? :)
[14:49] <infinity> (Happy to look at whatever your patch is when I'm bored, though)
[14:50] <ScottK> If you're really bored, you could look at pitti's libc6 regression in Hardy.
[14:50] <infinity> ScottK: Yeah, I have a firefox tab open for that.
[14:50] <pitti> infinity: or enable ddebs :) what better time to enable them than a Friday afternoon before holidays?
[14:50] <pitti> *duck*
[14:51] <infinity> ScottK: I suspect I know which of the sketchy security patches is the problem, but it'll take a rebuild to test.
[14:52] <mdeslaur> ScottK, infinity: I'm currently looking at the libc regression
[14:52] <infinity> mdeslaur: Oh, shiny.  If you find the offending patch but see no way out other than reverting it (which may be the right answer, depending on the severity of the CVE), let me know, and I can help look.
[14:53] <mdeslaur> infinity: ok, cool. thanks.
[14:53] <jodh> Is there a standard idiom for detecting if a library has bumped its ABI from that same libraries maintainer script? Or is it inferred from the changing version number?
[14:53] <infinity> jodh: If the SOVER hasn't changed, the ABI hasn't changed, or that's a grave bug in the packaging.
[14:54] <infinity> jodh: That's what SOVERs are for.
[14:54] <infinity> jodh: Is there context for this, though?  Why is this something a maintainer script should need to know?
[14:55] <rbasak> infinity: so this is in relation to bug 1084106 and bug 1079185. I've explained everything in those bugs. I'd appreciate you looking at it for the obvious reasons, but also that I'd like to get this resolved and landed before the holidays if possible. I think it's bad that we've not managed to land a fix sooner.
[14:55] <infinity> jodh: Generally, this is something you should be detecting (and hard-failing on) during the build, not during install.
[14:55] <ubottu> Launchpad bug 1084106 in The Eilt project "ARM server netboot installers broken" [Undecided,Triaged] https://launchpad.net/bugs/1084106
[14:55] <ubottu> Launchpad bug 1079185 in flash-kernel (Ubuntu Quantal) "Wrong bootarg for disk with label" [High,Fix committed] https://launchpad.net/bugs/1079185
[14:55] <jodh> infinity: Now we have stateful re-exec in Upstart, we can change the maint scripts for the libs it uses to say "restart upstart if our ABI version hasn't changed".
[14:55] <rbasak> infinity: (and I've attached suitable debdiffs^Wpatches)
=== rsalveti_ is now known as rsalveti
=== Ursinha_ is now known as Ursinha
[14:56] <rbasak> infinity: one final question. I noticed that your changelog entry named quantal rather than quantal-proposed. Does that mean that it's not necessary to use quantal-proposed, that we don't care, that it doesn't matter if you're specific where you dput or something else?
[14:56] <infinity> jodh: You're overthinking it.  You can just have it be "telinit u" unconditionally.
[14:57] <infinity> jodh: If upstart depends on libfoo5, it won't be removed because you install a new libfoo6, so the "if my ABI changed" test is meaningless.
[14:57] <infinity> rbasak: The archive auto-rewrites $series to $series-proposed.
[14:57] <infinity> rbasak: Or, rather, the upload processor does.
[14:58] <rbasak> infinity: so should I submit SRU proposals with -proposed or without? Or don't care?
[14:58] <jodh> infinity: right - thanks! ;-)
[14:58] <infinity> rbasak: I think without looks nicer, but it doesn't matter, both are valid.
[14:58] <rbasak> OK, thanks!
[14:58] <infinity> jodh: As a side note, this should be a trigger.
[14:58] <infinity> jodh: Cause restarting init several times on upgrade is silly.
[15:00] <jodh> infinity: agreed. thanks for pointer.
[15:00] <infinity> rbasak: I'm not sure reverting is necessary.  Let me give reproduction a whirl here, I have a pretty good idea how this should blow up.
[15:01] <rbasak> infinity: thank you! I appreciate it, especially on your holidya.
[15:01] <rbasak> FWIW, I've been trying on armadaxp, not panda (as I don't have my pandas set up since I moved my office). I didn't see before how that would matter, but perhaps it does.
[15:03] <infinity> rbasak: Could matter a lot, if the bug only manifests when installing with ubiquity.
[15:03] <infinity> rbasak: Which would be hard to reproduce on anything but omap/omap4. :P
[15:03] <rbasak> Ah. I assumed d-i!
[15:04] <rbasak> And that would explain it
[15:04] <ricotz> infinity, hi :), i hate to bother you again, but do you have any news on the eglibc cherry-pick?
[15:05] <infinity> ricotz: It's in progress.  It's pending fixing an ARM bug at the same time.
[15:06] <soren> infinity: You suck at vacation.
[15:06] <soren> infinity: Just sayin'.
[15:06] <ricotz> infinity, do you mind to put a "preview" packages somewhere? i can build it locally too
[15:06] <jpds> soren: He works until infinity.
[15:06] <infinity> soren: I've noticed.
[15:06] <soren> jpds: And beyond?
[15:06] <soren> jpds: Or would that be overdoing it=
[15:06] <soren> ?
[15:07] <infinity> ricotz: When I'm done the other bits, sure.  The current source isn't buildable. :P
[15:07] <ricotz> infinity, ok, thanks, feel free to ping me
[15:08] <ricotz> this is really an annoying issue here causing lock-ups :\
[15:31] <barry> mvo: so, xapian :)
[15:33] <mvo> barry: eh
[15:34] <barry> mvo: what about whoosh?
[15:34] <mvo> http://whoosh.org/ - Birthplace of the International Association of Xena Studies  ?
[15:35] <barry> http://pypi.python.org/pypi/Whoosh/
[15:35] <barry> mvo: but your link looks like more fun :)
[15:36] <mvo> barry: is it available for py3 ;) the package I have here is py2
[15:36] <mvo> barry: I don't know about it, it looks interessting, I have a look. but it would be nice to know the py3 state
[15:37] <infinity> barry: Pure python doesn't sound like it would be performant.
[15:37] <barry> mvo: upstream claims to support py3, and yeah i see it's only py2 in raring.  shouldn't be too difficult to whip up py3 packaging
[15:37] <barry> infinity: there's fast, and then there's fast enough :)
[15:37] <infinity> barry: If we're replacing xapian, surely we want to replace it with something that doesn't suck on ARM.
[15:37] <mvo> infinity: !python I guess
[15:37] <mvo> (at all!)
[15:37] <infinity> mvo: C/C++ would be nice...
[15:38] <infinity> But you know how I feel about that. :P
[15:38] <mvo> :)
[15:38] <barry> infinity: maybe you'd like to take a crack at http://trac.xapian.org/ticket/346  -- i failed ;)
[15:39] <stgraber> sounds like a good holiday project for infinity ;)
[15:39] <infinity> I saw the word "swig" and was scared away.
[15:40] <barry> infinity: wise
[15:40] <seb128> slangasek, bdmurray, ScottK, infinity, SRU team: I would appreciate if somebody could review the nautilus fix from ritz that I just uploaded to precise quantal (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1090344)
[15:40] <ubottu> Ubuntu bug 1090344 in nautilus (Ubuntu Quantal) "Nautilus creates broken symbolic links to files located on GVFS mounts " [High,In progress]
[15:41] <bdmurray> seb128: oh hey, yesterday I noticed there are two popplers in the quantal queue with different fixes
[15:41] <seb128> slangasek, bdmurray, ScottK, infinity: it's a small patch and some people have been waiting on it to be rolled out for a while (but it got blocked due to organizational issues ... anyway it would be good to get it out before holidays if we can)
[15:42] <infinity> seb128: I'll look at it.
[15:42] <seb128> infinity, thanks
[15:42] <infinity> seb128: On the condition that you talk to bdmurray about the poppler collision. ;)
[15:43] <seb128> bdmurray, shrug, the queues don't make those errors visible ... I've rejected mine, please accept the old one if you can, I will reupload mine after the holidays
[15:43] <seb128> infinity, ^
[15:43] <infinity> seb128: Better if you reupload yours incorporating the other one, IMO.
[15:43] <infinity> seb128: No point dragging it out into two SRU releases.
[15:44] <seb128> infinity, right, I'm not sure I will get to that today though ... but I will try
[15:44]  * infinity nods.
[15:45] <barry> mvo: at the very least, i'll put together a py3 packaging of whoosh, and maybe we can give it a try and see how well/poorly it works?
[15:50] <mvo> barry: yeah, indexing the app-install-data and indexing software-center agents data would be good
[15:51] <infinity> Indexing, and then some sort of mock testsuite to see how well the indexes perform.
[15:51] <infinity> And do it on the slowest device you can find. :P
[15:52]  * stgraber looks at his beagleboard C4
[15:52] <barry> infinity: i have an mx53 :)
[15:52] <infinity> barry: stgraber wins.
[15:52] <barry> fsvo "wins"
[15:53] <infinity> Yeah.  I have a "winning" C4 too.  It's going to learn to fly any day now.
[15:53] <barry> infinity: out the window at high velocity?
[15:53] <infinity> barry: Something like that, yes.
[15:57] <mvo> I have a rapberry pi, where does that stand in the ordering of fast<->slow?
[15:58] <infinity> mvo: Right around the C4.
[15:59] <stgraber> except that the C4 can actually boot Ubuntu )
[15:59] <stgraber> (well, for some definition of boot that doesn't involve anything more complex than a shell)
[15:59] <infinity> Except that, yes.  I believe mvo runs Raspbian on his Pi.
[16:02] <mvo> yeah, its the debian thing running on it with some "crossports" from ubuntu
[16:02] <infinity> seb128: Accepted.
[16:09] <xnox> stgraber: i totally saw a lab of rasbianpis running mythbuntu, does that count as "can actually boot ubuntu" or not?
[16:09] <infinity> xnox: It can't have been mythbuntu.
[16:09] <infinity> xnox: It could have been some mythbuntu stuff recompiled, but not mythbuntu as it exists in our archives.
[16:10] <stgraber> infinity: well, actually, wouldn't quantal armel sort-of vaguely work on the raspberry pi?
[16:11] <stgraber> (at least for the part of main we rebuilt)
[16:11] <infinity> stgraber: Yes, assuming all the packages you wanted were recompiled during the quantal cycle.
[16:11] <infinity> We rebuilt all of main.
[16:11] <infinity> And possibly most of mythbuntu was rebuilt in that timeframe.
[16:12] <infinity> So, I suppose it's concievable that quantal/mtyhbuntu could run on v5/v6 devices.  Maybe.
[16:12]  * xnox saw it running, but didn't have chance to tinker with it much they were display units.
[16:12] <infinity> I wouldn't hold my breath.
=== sil2100_ is now known as sil2100
[16:44] <seb128> infinity, thanks
[16:50] <jono> Sweetshark, are you an ubuntu member?
=== deryck is now known as deryck[lunch]
[17:20] <jamespage> jodh, still around?
[17:20] <jodh> yup
[17:22] <Sweetshark> jono: hmm? no, doesnt seem so.
[17:22] <jono> Sweetshark, you should apply, and then we can get your blog posts on planet
[17:22] <jono> Sweetshark, ping Daniel Holbach, he will help you through the process
[17:23] <Sweetshark> jono: yep.
[17:23] <jamespage> jodh, am I correct in thinking that an upstart configuration that is a task
[17:23] <jamespage> really has no concept of 'stop on'
[17:23] <jamespage> i.e. its not long running....
[17:24] <jodh> yes
[17:24] <jamespage> jodh, great - thats what I though
[17:24] <jono> Sweetshark, cool :-)
[17:26] <Sweetshark> dholbach actually asked me to reapply for upload rights, which IIRC would make me qualify ~automatically, but it fell over the cliff. inbox zero is on the horizon, but its run quickly away from me :/
[17:26] <stgraber> jodh: did you see my pm from earlier today?
[17:29] <jodh> stgraber: ?
[17:31] <stgraber> jodh: I sent you a private message around 14:00 UTC regarding the dbus events branch
[17:31] <jodh> stgraber: too many splits - on sec...
[17:31] <stgraber> ok :)
=== mcclurmc is now known as mcclurmc_away
[18:04] <xnox> slangasek: half of language-pack packages are actually in fact empty.
[18:04] <xnox> (binary that is)
[18:04] <slangasek> huh
[18:04] <slangasek> seems like we should fix things to stop generating those
[18:05] <slangasek> unless they're needed as dependencies of other langpacks that aren't empty?
[18:05] <xnox> slangasek: i guess we need to have ability to generate 'language-pack-none' which provides 'langauge-pack-<countrycode>'
[18:06] <slangasek> I don't think we should need to do that at all if they're empty
[18:06] <xnox> slangasek: otherwise things like ubiquity/presseeeding/languages checks might break. Or do we have locales that don't have language packs?
[18:06] <slangasek> I would expect this to be handled in language-selector
[18:06] <slangasek> I'm pretty sure that from time to time we've had supported locales with no language packs
[18:07] <xnox> slangasek: it's even bigger number of packages that provide <<10% of the template translation.
[18:07] <slangasek> sure
[18:07] <slangasek> we still want to provide those, though
[18:07] <xnox> ok.
[18:07] <slangasek> incomplete translation is better than none if it's the only language you speak :)
[18:08] <xnox> slangasek: some are funny, the only string translated is "continue" - i guess that's all that user will be clicking =)
[18:09] <slangasek> heh
=== chiluk is now known as chiluk_away
[18:10]  * xnox ponders to launch juju spin up hadoop cluster to tell me the most translated string. Will it be "quit" or "continue" ?
=== deryck[lunch] is now known as deryck
[18:21] <stokachu> stgraber: when you get a chance could you review bug 633109?
[18:21] <ubottu> Launchpad bug 633109 in dput (Ubuntu) "No progress bar for sftp uploads" [Wishlist,Fix released] https://launchpad.net/bugs/633109
=== pgraner` is now known as pgraner
[18:26] <stgraber> stokachu: nomination approved, I'll review and upload in a minute
[18:26] <stokachu> stgraber: sweet thanks man
[18:26] <stgraber> np
=== henrix is now known as henrix_
[18:30] <hrw> hi
[18:32] <hrw> I have bug 1085392 which is about adding Samsung Chromebook UCM profiles into alsa-{lib,utils} in order to protect users from frying speakers (if they will try to get sound working on their own). Changes landed in Raring and I made SRU for both quantal and precise. Official procedure requires uploading SRU packages to -proposed but as alsa is in main I am unable to do that. Can someone review patches/packages and upload them for me?
[18:32] <ubottu> Launchpad bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392
[18:32] <hrw> http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/chromebook/SRU/ contains SRU packages
[18:33] <mdeslaur> infinity: it's CVE-2012-3480.patch...still trying to figure out why though
[18:33] <ubottu> Multiple integer overflows in the (1) strtod, (2) strtof, (3) strtold, (4) strtod_l, and other unspecified "related functions" in stdlib in GNU C Library (aka glibc or libc6) 2.16 allow local users to cause a denial of service (application crash) and possibly execute arbitrary code via a long string, which triggers a stack-based buffer overflow. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3480)
[18:34] <mdeslaur> infinity: oh, and only on i386
[18:39] <stgraber> stokachu: ah, oneiric and precise are the exact same release...
[18:39] <stgraber> stokachu: so your version number is wrong as you can't upload the same version to the archive twice
[18:39] <stgraber> stokachu: but I'll fix that for you
[18:39] <stokachu> ah..
[18:39] <stokachu> even for different releases?
[18:39] <stgraber> stokachu: yeah because http://archive.ubuntu.com/ubuntu/pool is shared for all releases
[18:39] <stokachu> ah ok
[18:40] <stokachu> so i needed to mark precise .2 i presume?
[18:40] <xnox> hrw: please update the bug report details. it's currently not in the state fit for SRU.
[18:40] <stgraber> so the first one will be 0.9.6.2ubuntu1.11.10.1 and the other one will be 0.9.6.2ubuntu1.12.04.1
[18:41] <stokachu> stgraber: is the 11.10.1 12.04.1 something I  need to continue to use?
[18:41] <stgraber> stokachu: in such case we usually embed the release in the version, that avoids clashes if another SRU is needed later
[18:41] <stgraber> stokachu: in cases where the exact same version exists in more than one release you're SRUing to, yes
[18:41] <stokachu> ah ok gotcha
[18:42] <stgraber> stokachu: the security team has an handy guide at: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[18:42] <stokachu> sweet /me bookmarks
[18:43] <stokachu> ah i see the version examples have it listed nicely
=== chiluk_away is now known as chiluk
=== Ursinha is now known as Ursinha-afk
[18:53] <stgraber> stokachu: oh, another note, the package is 3.0 (native), so you can't use debian/patches
[18:53] <stgraber> stokachu: I'll just apply the patch inline
=== Sweetshark is now known as UbuntuRocksMOAR
=== UbuntuRocksMOAR is now known as Sweetshark
[18:54] <stokachu> stgraber: ah damn.. ok thanks :D
[18:54] <stokachu> is it not worth doing patches for a package like this then?
[18:54] <stokachu> its pretty small
[18:55] <stgraber> uploaded
[18:56] <stokachu> awesome! :D
[18:56] <stgraber> native packages are usually just patched inline. Using quilt would require some more changes to debian/rules
[18:56] <stokachu> cool, understood
[18:56] <stgraber> (I vaguely wish dput wasn't a native package, but there's no point in divering from Debian for that...)
[18:56] <stgraber> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[18:58] <stokachu> micahg: i was able to get a new package pushed to my ppa for bug 1068399
[18:58] <ubottu> Launchpad bug 1068399 in Precise Backports "Please backport parallel 20120422-1 (universe) from quantal" [Undecided,New] https://launchpad.net/bugs/1068399
[19:00] <hrw> xnox: ok
[19:01] <micahg> stokachu: ok, so, the backport from raring needs to go through quantal, as soon as you can confirm that the new version builds/installs/runs on quantal and precise, I"ll push it for you
[19:01] <stokachu> micahg: cool can i just use the backport tool for quantal and test it myself?
[19:02] <micahg> stokachu: wait, how was the issue I mention addressed?
[19:02] <stokachu> the latest parallel doesn't exhibit the issue filed in the debian bug
[19:03] <stokachu> at least from my testing
[19:03] <micahg> well, unless the two were made cli compatible, it still shares a binary with another package, but doesn't conflict
[19:06] <micahg> though, it's not any worse than the distro version
[19:06] <stokachu> would we want to do a one-off for Ubuntu where it conflicts then?
[19:08] <micahg> well, I'd like someone to talk to the Debian maintainer first about it, there might be an easy solution
[19:08] <stokachu> ok
[19:09] <jtaylor> there is no easy solution ._.
[19:28] <hrw> xnox: I hope that new description will be fine
[19:28] <hrw> s/description/comment/
[19:30] <xnox> hrw: so it's still possible to fry speakers =/ oh well
[19:30] <hrw> xnox: thats kernel stuff which may get fixed later
[19:31] <hrw> xnox: but less users will play with mixer once they get working audio == less fried speakers
[19:31] <xnox> sure.
=== kees_ is now known as kees
=== pcarrier_ is now known as pcarrier
[19:58] <hrw> xnox: thanks for help
[19:59] <xnox> hrw: np.
=== mhall119_ is now known as mhall119
[21:36] <arges> how do I get a package in the upload queue to be dequeued?
[21:36] <marga> dput
[21:36] <marga> dcut
[21:37] <bdmurray> pitti: I've a _usr_lib_indicator-session_indicator-session-service.1000.crash file wihtout a StacktraceAddressSignature with the latest apport in quantal if that is interesting to you
[21:41] <dobey> oh that reminds me
[21:42] <dobey> in raring at least, it seems apport gets launched under python3, even when python2-only apps crash, and it will crash if the apport source.py file for the app tries to import stuff that's only in python2
[21:44] <arges> marga, even if didn't upload it?
=== hggdh_ is now known as hggdh
=== salem_ is now known as _salem
=== cpg|away is now known as cpg
[21:58] <Laney> the ubuntu archive doesn't support dcut
[21:58] <Laney> arges: which queue?
[22:05] <arges> Laney, precise queue, duplicity
[22:05] <arges> Laney, i'm doing a fixed debdiff right now
[22:05] <Laney> arges: so an UNAPPROVED queue. The answer is to ask an archive admin to delete it.
[22:05] <Laney> s/delete/reject/
[22:06] <Laney> if it's not your upload you better also explain why
[22:06] <arges> Laney, ok... who should i ask at this hour on a Friday
[22:06] <arges> Laney, it is my upload
[22:06] <arges> but it was sponsored by somebody else
[22:07] <Laney> https://launchpad.net/~ubuntu-archive/+members#active
[22:07] <Laney> Someone will probably look here soon enough though, I'd imagine.
[22:10] <arges> infinity, hey if you get a chance can you delete an upload for duplicity/precise ?
=== chiluk is now known as chiluk_away
[23:02] <NCommander> Any MIR team members awake? I have a bit of an unusual situation
[23:19] <infinity> arges: You want me to reject duplicity_0.6.18-0ubuntu4 from the precise queue?
[23:36] <arges> infinity, yes I have a fixed debdiff on that bug
[23:36] <arges> bug  1013446 btw
[23:36] <ubottu> Launchpad bug 1013446 in duplicity (Ubuntu Quantal) "Uncached grp and pwd calls make duplicity slow with large group and passwd maps" [Medium,In progress] https://launchpad.net/bugs/1013446
[23:36] <infinity> arges: Rejected.
[23:37] <arges> thanks
=== cpg is now known as cpg|away
=== slank is now known as slank_away