[01:30] <poolie> ubuntu monospace seems to have gone away?
[05:24] <pitti> Good morning
[05:48] <didrocks> good morning
[07:01] <dholbach> good morning
[07:01] <pitti> hey dholbach
[07:03] <dholbach> hey pitti
[07:04] <jamespage> morning
[07:15] <evfool> hey pitti: regarding 829635: glib.markup_escape_text number of params, you've mentioned in the bug that glib has changed to accept only the text, but the gir generated from the typelib still has two params
[07:16] <evfool> what's the thing here I'm missing?
[07:16] <htorque> sladen: hi! will we see an update to the beta fonts anytime soon? the oneiric version 0.71.2-0ubuntu7 supersedes the one in the ppa and now i'm missing that fine mono font. :-)
[07:17] <pitti> evfool: I suppose they fixed the annotation to say that the second is the length of the first
[07:22] <evfool> pitti: so the correct call is as it currently appears in apport, with only one param, the text
[07:23] <pitti> apparently so, yes
[07:44] <sladen> htorque: yeah, I'll add the Arabic beta in that DM sent over
[07:44] <sladen> htorque_: yeah, I'll add the Arabic beta in that DM sent over
[07:45] <htorque_> sladen: thanks :-)
[09:38] <Riddell> sladen: old logo alert https://wiki.ubuntu.com/UbuntuAppDeveloperWeek
[09:45] <sladen> Riddell: https://bugs.launchpad.net/ubuntu-branding/+bug/837531/+affectsmetoo
[10:18] <bdrung> tumbleweed: E:237:SourcePackage.pull_dsc: Instance of 'ParseResult' has no 'scheme' member
[10:43] <tumbleweed> bdrung: aah, I probably only pylinted it on sid. I take it you are happy with the other commits I did directly?
[10:43] <bdrung> tumbleweed: yes
[10:44] <bdrung> tumbleweed: our testcase catches that error posted above.
[10:44] <bdrung> but it appears with 'pylint ubuntutools/archive.py'
[10:44] <tumbleweed> sounsd like a pylint bug, then
[10:44] <tumbleweed> ParseResults have scheme members
[10:45] <bdrung> look at our pylint.conf
[10:46] <bdrung> tumbleweed: do you have some minutes?
[10:51] <bdrung> tumbleweed: pushed. look at http://paste.debian.net/128598/ -> the first message shouldn't be an error in this case!
[10:52] <Laney> shouldn't the second one be Info: too?
[10:53] <bdrung> yes
[10:56] <ogra_> can someone bump the score on https://launchpad.net/ubuntu/+source/vlc/1.1.11-2build2/+build/2763654
[10:56] <cjwatson> ogra_: done
[10:56] <ogra_> thx
[10:56] <ogra_> hopefully it doesnt segfault again
[10:58] <tumbleweed> bdrung: hi, yes I have some time (sorry, just had to deal with a DNS issue)
[10:59] <bdrung> tumbleweed: the first two items in http://paste.debian.net/128598/ should be info level
[11:01] <tumbleweed> bdrung: should we also ignore CURRENT blacklisting when syncing from experimental (when ubuntu > sid, everything will be blacklisted CURRENT)
[11:02] <Laney> you need ffe for that change btw (dh_python2 switch)
[11:02] <bdrung> Laney: i know, i just wanted a test case :)
[11:02] <Laney> k
[11:17] <tumbleweed> bdrung: I disagree about Info. syncpackage hides Info messages by default
[11:18] <bdrung> right
[11:19]  * tumbleweed uses warn
[11:19] <bdrung> then: error -> warn for first message
[11:22] <tumbleweed> ah, normal
[11:24] <bdrung> tumbleweed: btw, pushed again
[11:26] <tumbleweed> bdrung: pushed
[11:29] <bdrung> tumbleweed: "syncpackage: The blacklisting only applies to the current versions in Debian and Ubuntu. --force is required to override the blacklist." is a little bit long
[11:30] <tumbleweed> we're going to have the same problem with comments, because they are append-only. /me adds wrapping
[11:31] <Laney> that could get annoying
[11:31] <bdrung> tumbleweed: pushed
[11:32] <tumbleweed> Laney: any better ideas?
[11:32] <Laney> get launchpad to get rid of old comments
[11:32] <Laney> :(
[11:55] <cjwatson> libdevel-bt-perl is an object lesson in why it's sometimes worth debugging build failures on unsupported architectures
[11:56] <cjwatson> it turns out that the reason powerpc failed is that it's running a new enough kernel to have the yama security extension turned on; if you try to build (or indeed use) libdevel-bt-perl on a current i386 system it fails in the same way
[12:11] <doko> seb128, what to do with seahorse? you did drop the -dev package
[12:12] <seb128> doko, what about seahorse?
[12:12] <seb128> doko, oh, the lib it used to ship is a new source
[12:12] <seb128> somebody needs to package it if we need it for something else
[12:13] <doko> seb128, bug 840611, well, then please don't drop the -dev package in the first place :-(
[12:13] <seb128> doko, how can we keep the binary when the corresponding code has been dropped in the upstream update?
[12:14] <seb128> doko, they moved that code to a new source and tarball
[12:14] <shbk> hello, does anybody know what functions exactly can I use to get info about system(video card, resolution) from man 2 or man 3 . I have to use only c/c++.
[12:14] <bdrung> tumbleweed: what command did you use to test your changes?
[12:14] <seb128> doko, well those 2 binaries can be dropped from oneiric if nobody cares about it
[12:14] <doko> seb128, please state this in the bug report
[12:14] <seb128> doko, ok
[12:14] <pitti> seahorse-plugins seems quite obsolete indeed
[12:15] <pitti> in the past we needed it for gpg, but that's built into g-keyring now
[12:15] <seb128> pitti, it still had gedit integration iirc but it's not worth spending efforts on
[12:15] <shbk> hello, does anybody know what functions exactly can I use to get info about system(video card, resolution) from man 2 or man 3 . I have to use only c/c++.
[12:15] <tumbleweed> bdrung: icedove. I couldn't test the CURRENT blacklisting because i couldn't find a suitable package (and couldn't get it working on dogfood)
[12:16] <bdrung> tumbleweed: xmms2
[12:16] <Hobbsee> shbk: we don't do your homework for you.  Try google.
[12:16] <seb128> shbk, hi, that's probably not the right channel for your question, try #ubuntu, and repeating the question this way will rather be annoying to others than useful to get a reply
[12:18] <jamespage> doko: thanks for doing those syncs yesterday - however maven2-core/maven2 needed to be built/published sequentially so we now need a no-change rebuild on maven2 to pickup the right version of maven2-core (2.2.1-6)
[12:19] <jamespage> once that has published maven-plugin-tools should build OK (FTBFS ATM)
[12:19] <doko> jamespage, sorry, could you do these?
[12:20] <jamespage> doko: I can do a branch for the maven2 rebuild - but I can't upload either package :-)
[12:21] <jamespage> doko: if you are tied up I can prob find someone else to sponsor for me
[12:24] <doko> jamespage, sorry, forgot. will do
[12:24] <jamespage> doko: thankyou
[12:30] <bdrung> tumbleweed: time to release 0.129 or is there something left to do?
[12:31] <tumbleweed> bdrung: I'm happy. I suspect we'll find more issues when more people start using syncpackage, but that's fine
[12:35] <bdrung> tumbleweed: pushed and uploaded
[13:03] <Riddell> sladen: my oneiric install seems to have Ubuntu and Ubuntu Light fonts fixed up http://people.canonical.com/~jriddell/tmp/font-screenshot.png
[13:03]  * ogra_ kicks gtk-3.0 
[13:03] <Riddell> top is Ubuntu, second is ubuntu Light
[13:03] <ogra_> build faster, damned thing
[13:04] <ogra_> ha ! that helped !!
[13:05] <pitti> ogra_: DEB_BUILD_OPTIONS=nocheck,parallel=4 might help? :-)
[13:05] <ogra_> pitti, well, you were the uploader :P
[13:06] <sladen> Riddell: https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/+affectsmetoo  or do you think this is something different again?
[13:06] <ogra_> but i fear that wont help on the uniprocessor armel builders :)
[13:06] <pitti> ogra_: oh, and --extra-paint=go-faster-stripes
[13:06] <pitti> ogra_: ah
[13:06] <pitti> dear linux, please stop sucking so much when even the slightest bit of IO is going on
[13:06] <Riddell> sladen: I suspect it's different.  this isn't qt for one thing
[13:08] <sladen> Riddell: https://bugs.launchpad.net/ubuntu-font-family/+filebug?field.title=Metadata:+Libreoffice+confusion+with+Ubuntu+Light
[13:22] <ogra_> cjwatson, there is some unreleased stuff in the livecd-rootfs tree from you, i assume its fine to upload ?
[13:25] <cjwatson> ogra_: yes
[13:25] <ogra_> thx
[13:25] <cjwatson> I didn't need to upload that since I deployed it by way of RT
[13:26] <ogra_> yeah, i remember
[14:41] <ogra_> siretart, hmm, i see you worked on vlc-cachegen segfaults, any idea why it still fails on armel (seems to build on the other arches now)
[14:46] <dholbach> we have to get sponsorship back on track again
[14:46] <dholbach> the queue is growing, growing and growing
[14:46] <dholbach> and I'm sure there's still loads of good fixes in there
[14:48] <cjwatson> We also have to get the archive stable for release
[14:49] <dholbach> oh, I wasn't trying to say that everybody was twiddling thumbs :/
[14:49] <cjwatson> I'm not saying this as a contradiction, but we have a *lot* of queues that need to be driven to zero
[15:02] <agateau> hi, it seems multiarch support changed quite a lot in oneiric, I need to install 32bit versions of Qt libs in order to test Skype on an amd64 system, do you know how to do that?
[15:03] <pitti> agateau: if you enable partner, sudo apt-get install skype:i386 should get you everything you need
[15:03] <agateau> pitti: oh
[15:03]  * agateau tries
[15:03] <pitti> agateau: the amd64 package hasn't been updated for that yet, that was in the beta-1 release notes
[15:04] <agateau> pitti: you mean for skype or for qt?
[15:04] <pitti> agateau: skype
[15:06] <agateau> pitti: ok, right now the skype binary from skype.com does not start because it is missing 32bit versions of Qt libs and libXss, is there a way for me to install those?
[15:06] <jtaylor> yes, install the missing libs ._.
[15:06] <jtaylor> apt-get insall libxss1:i386 etc
[15:06] <pitti> agateau: yes, you can install any i386 version of a library with e. g. sudo apt-get install libqtgui4:i386
[15:07] <cjwatson> skype:i386 should get you the lot though
[15:07] <agateau> oh, I didn't know about the :i386 syntax, thanks jtaylor and pitti
[15:08] <jtaylor> someone should put that skype thing in the topic, its probably the most frequent question
[15:08] <pitti> it's in the release notes
[15:09] <jtaylor> oh this is not +1
[15:09] <pitti> otherwise, skype isn't in ubuntu :)
[15:09]  * agateau feels like a noob
[15:09] <pitti> agateau: in short, in oneiric final we'll (hopefully) have this fixed so that installing from s-c just works
[15:10] <agateau> pitti: sounds good
[15:10] <agateau> ftr, it seems to work but I had to add foreign-architecture i386 to /etc/dpkg/dpkg.cfg (as mentionned in http://wiki.debian.org/Multiarch/Implementation)
[15:18] <zul> mterry: can you review the MIR for python-stompy please? Bug #835596
[15:18] <cjwatson> agateau: also as mentioned in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html for people who've been upgrading through oneiric; people who upgrade to oneiric directly using update-manager won't need to do that
[15:19] <cjwatson> (if you're running development releases, it's important to follow ubuntu-devel-announce)
[15:19] <mterry> zul, sure
[15:19] <agateau> cjwatson: ok, taking note
[15:20] <zul> mterry: thanks
[15:23] <dholbach> can somebody moderate my mail on u-d-a through?
[15:24] <doko> didrocks, could you upload the new qt4-x11? ARM needs it
[15:25] <pitti> dholbach: looking
[15:25] <didrocks> doko: it's untested on kubuntu (I asked kubuntu-devel people to get some test) and it completely breaks unity-2d and I wait for some to get some initial fixes
[15:25] <cjwatson> dholbach: done
[15:26]  * pitti cancels listadmin then and starts over :)
[15:26] <seb128> hum, no slangasek
[15:26] <seb128> bug #839744 seems a multiarch sort if issue
[15:26] <doko> didrocks, when do you expect this? because else, I'd like to get the fix for  bug 785318
[15:26] <didrocks> doko: Thursday at the latest, hoping tomorrow
[15:26] <dholbach> thanks cjwatson
[15:27] <doko> ok, sounds good
[15:27] <dholbach> and thanks pitti too :)
[15:27] <seb128> seems like the amd64 and i386 binaries conflict on the changelog?
[15:27] <cjwatson> seb128: are the changelogs bitwise-identical between architectures?  (this is required)
[15:28] <seb128> cjwatson, I see no reason they shouldn't be
[15:28] <cjwatson> but are they?
[15:28] <seb128> but I didn't check the debs content
[15:28] <seb128> let me have a look
[15:28] <seb128> "Package: libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz]" on the apport bug
[15:28] <seb128> that's a bit weird
[15:29] <doko> gnome-auto stuff?
[15:29] <seb128> not on the changelog
[15:29] <cjwatson> I don't know how relevant that is - I'd check the actual .debs
[15:29] <seb128> it seems to happen for people upgrading from natty
[15:33] <Laney> won't they be not-bit-identical due to the changelog trimming?
[15:34] <pitti> that would be weird
[15:34] <pitti> changelog trimming is very well defined
[15:34] <pitti> and not arch specific
[15:34] <Laney> I was thinking of the compression
[15:35] <pitti> the full lenght changelogs get compressed as well, though
[15:35] <pitti> (just like manpages, etc.)
[15:35] <pitti> dh_compress ought to call gzip with the "no timestamp" mode to get reproducible files
[15:35] <Laney> true
[15:36] <pitti> that is to say, I'm not at all claiming that changelog trimming isn't to blame here
[15:36] <nigelb> g23
[15:36] <seb128> cjwatson, yeah, the files are the same (same md5sum, from the unpacked debs)
[15:36] <pitti> it's just that we apply it to each and every package, and it doesn't seem to be a general problem
[15:36] <Laney> they're the same here
[15:37] <seb128> cjwatson, it seems only to happen for natty to oneiric updates seeing the duplicate, no bug from oneiric to oneiric
[15:37] <seb128> Laney, pitti: ^
[15:38] <pitti> would that be a problem if you have multiarch enabled in natty, and upgradre the amd64 and i386 package at different times?
[15:38] <pitti> (regardless of the particular package)
[15:43] <cjwatson> pitti: the terminal log here shows that the amd64 package had already been upgraded, so that *shouldn't* be a problem
[15:53] <cjwatson> seb128: posted some analysis to bug 836915; would appreciate your thoughts
[15:53] <seb128> cjwatson, thanks, looking
[15:54] <cjwatson> seb128: ... and added some IRC discussion too
[15:58] <ogra_> hmpf, why does cdimage not respect ARCHES= anymore
[15:58] <cjwatson> it should do
[15:58] <ogra_> yeah
[15:58] <cjwatson> exact command line?
[15:59] <seb128> cjwatson, I'm not sure now why we synced that one, is was a while back, but updating ptlib and ekiga with the experimental seems the easier thing to do there
[15:59] <ogra_> ARCHES=armel+ac100 for-project ubuntu cron.daily-preinstalled
[15:59] <ogra_> i end up with a log for mx5
[15:59] <cjwatson> (although you should not be putting ARCHES= in the crontab any more, as there's a better mechanism)
[15:59] <ogra_> no, thats a manual testbuild
[16:00] <ogra_> i use cdimage's mechanism for auto-builds
[16:01] <cjwatson> seb128: can you do the FFe stuff the?
[16:01] <cjwatson> *then
[16:01] <cjwatson> I'm currently trying to assemble a working build tree; if I can get far enough then I can provide a libav patch if need be
[16:01] <ogra_> funnily i know that the same worked before beta (ac100 was disabled suring milestone freeze)
[16:01] <seb128> cjwatson, ok
[16:08]  * ogra_ tries the build again but removes armel+mx5 from etc/default-arches
[16:09] <ogra_> i'm pretty sure ARCHES is overridden here ... might be that my format for the entry in etc/default-arches wasnt right
[16:09] <ogra_> yup, that way it works
[16:12] <ogra_> cjwatson, is there anything wrong with the old line 2 on http://paste.ubuntu.com/683644/ ? ARCHES isnt respected with the upper line but works fine if i just add ac100 to line 4
[16:13] <ogra_> (or drop mx5 as i did)
[16:13] <ogra_> (thats wrt cdimage/etc/default-arches)
[16:14] <bdmurray> pitti: I'm trying to sort out an issue with the ubiquity apport source package hook and version tagging of bug reports in bug 842130 you can see the tag was added by my bot and not with the source package hook
[16:14] <cjwatson> default-arches shouldn't even be looked at at all if ARCHES is set
[16:14] <cjwatson> I suggest using sh -x to find out what's going on
[16:14] <cjwatson> (DEBUG=1 is useful when doing this too, so that it doesn't try to publish stuff)
[16:14] <ogra_> k
[16:27] <apw> pitti, i have an issue with apport-gtk, where it seems to be consuming 25% of my CPU, killing my battery life
[16:28] <apw> pitti, when i renamed it away i got a popup saying that "program this report refers to is no longer present"
[16:28] <apw> (and my CPU went back to 0)
[16:28] <bdmurray> apw: is there anything recent in /var/crash ?
[16:29] <apw> bdmurray, yep piles of unity exploding
[16:29] <bdmurray> apw: you might try recreating the issue with ubuntu-bug /var/crash/pile_1_of_explodyness
[16:46] <apw> bdmurray, will try once i have done these power tests
[16:47] <maco> there's a patch pilot in the /topic but not in the channel. hrmph.
[16:49] <micahg> maco: fixed :)
[16:49] <maco> heh
[16:50]  * maco scowls at lp. scan branch fasterer!
[17:57] <bryceh> @pilot in
[17:58] <om26er> bryceh, Hi! can you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/unity/unity-fix-761409/+merge/74009 :)
[17:58] <barry> ScottK: re your comment in bug 832864.  are you saying you've approved the ffe for pyside?  if so, i can upload the new version and its dependents
[17:58] <ScottK> Yes.
[17:59] <barry> ScottK: cool, thanks
[18:02] <bryceh> om26er, ok, looking
[18:03] <micahg> bryceh: there's another unity issue waiting for sponsorship from hyperair
[18:03] <hyperair> \o/
[18:03] <om26er> micahg, i have the fix for that as well ;)
[18:03] <hyperair> om26er: you do?
[18:04] <hyperair> om26er: why didn't you include it in your upload? =\
[18:04] <om26er> hyperair, my branch have the fix
[18:04] <om26er> i added your patch
[18:04] <hyperair> ah
[18:04] <hyperair> i didn't see your branch
[18:04] <hyperair> but whatever got uploaded to -proposed didn't have my patch.
[18:05] <om26er> hyperair, I also proposed your fix to lp:unity/3.0
[18:05] <hyperair> afaik my fix was irrelevant/already committed into trunk.
[18:05] <hyperair> so there wasn't really a need to do that, or was there?
[18:06] <om26er> hyperair, it proposed it to stable series trunk
[18:06] <bryceh> om26er, hyperair, ok, ping me again when you have this all sorted out :-)
[18:06] <om26er> bryceh, its sorted already ;)
[18:07] <bryceh> om26er, also, the version number for a natty backport should be ~natty1.n rather than ~natty3
[18:07] <om26er> bryceh, last upload I had it natty1.1 it was rejected
[18:07] <om26er> i was asked to make it natty2
[18:07] <bryceh> om26er, by whom?
[18:07] <micahg> bryceh: natty2 is already in -proposed
[18:07] <om26er> raof I think
[18:07]  * om26er checks
[18:08] <bryceh> hmm
[18:08] <micahg> bryceh: makes sense this this was already a natty backport
[18:08] <micahg> or a natty specific upload
[18:08] <bryceh> oh right
[18:09] <bryceh> weird numbering
[18:09] <om26er> https://bugs.launchpad.net/ubuntu/natty/+source/unity/+bug/769703/comments/46
[18:09] <micahg> om26er: your branch should be against natty-proposed BTW, not natty
[18:10]  * micahg goes back to other things...
[18:13] <hyperair> meh. i can't figure out all this bzr crap.
[18:13] <hyperair> om26er: do you have any other fixes queued in your bzr branch?
[18:14] <hyperair> if not, can bryceh just upload my debdiff as is?
[18:14] <hyperair> it would be much simpler that way.
[18:14] <hyperair> bryceh: also, what's with the natty1.n versioning? i've never seen this kind of versioning before.
[18:15] <om26er> hyperair, it have two bug fixes bug 816632 and 761409
[18:15] <hyperair> oh seriously.
[18:15]  * hyperair sighs
[18:15] <hyperair> how complicated.
[18:15] <hyperair> honestly, i don't really care as long as my patch goes in somehow.
[18:16] <hyperair> the memory leak is annoying.
[18:16] <hyperair> so just do as you like
[18:16] <bryceh> hyperair, shall I wait on sponsoring om26er's branch until you have things sorted out?
[18:17] <hyperair> bryceh: i'm letting om26er sort things out. he's already got my patch queued in his branch.
[18:17] <om26er> (this branch have the fix for the issue hyperair reported) the change in src/IndicatorObjectEntryProxyRemote.cpp is the fix
[18:17] <hyperair> bryceh: honestly, bzr confused the hell out of me, and i'm satisfied with just uploading debdiffs.
[18:18] <hyperair> s/confused/confuses/
[18:26] <maco> bryceh: can you take a look at https://code.launchpad.net/~maco.m/ubuntu/oneiric/system-config-printer/desktop-change/+merge/74273 ?
[18:27] <maco> >< an hour is an awful long time to take to generate a one-line diff
[18:27]  * micahg hugs maco for that fix
[18:27] <beuno> maco, launchpad's diff generation is stalled at the moment
[18:27] <maco> beuno: oh, well that would explain that
[18:27] <maco> micahg: xfce user?
[18:27] <micahg> maco: xubuntu dev :)
[18:27] <maco> oh heh
[18:28] <maco> charlie was making some noise about it in -a11y
[18:30] <bryceh> maco, sure
[18:31] <mdz> smoser, kirkland, we're running into bug 816387 and are going to try Tyler's proposed patch
[18:31] <maco> bryceh: thanks
[18:31] <mdz> is https://wiki.ubuntu.com/KernalTeam/EC2Kernel the best resource for how to build the kernel for EC2?
[18:32] <smoser> mdz, kernel is just -virtual kernel
[18:32] <mdz> smoser, ok, so no special instructions? just build that flavour?
[18:33] <smoser> yes.
[18:33] <smoser> for >= maverick
[18:33] <mdz> is https://help.ubuntu.com/community/Kernel/Compile the right resource then?
[18:33] <smoser> you should ask in ubuntu-kernel to be more sure, smb woudl know. but i think so, yes.
[18:34] <mdz> smoser, ok, thanks
[18:34] <smb> !kernel-compile
[18:35] <smb> smoser, mdz Not sure there was a community one but also some more specific...
[18:35] <smb> The link was the community one
[18:36] <bryceh> om26er, sponsored and uploaded to natty-proposed.
[18:36] <om26er> bryceh, thank you :)
[18:36] <smb> mdz, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[18:40] <tyhicks> mdz: Be sure to check out the kernel.org bug - the proposed patch that was mentioned in the LP bug didn't fix it
[18:41] <tyhicks> mdz: This one seems to fix it: http://git.kernel.org/linus/f61500e000eedc0c7a0201200a7f00ba5529c002
[18:41] <mdz> tyhicks, will do, thanks very much!
[18:44] <bryceh> /tmp/buildd/system-config-printer-1.3.6+20110831/debian/tmp//usr/share/applications/system-config-printer.desktop: error: value "KDE,GNOME;" for key "NotShowIn" in group "Desktop Entry" contains an unregistered value "KDE,GNOME"; values extending the format should start with "X-"
[18:44] <bryceh> Error on file "system-config-printer.desktop": Failed to validate the created desktop file
[18:44] <bryceh> make[3]: *** [install-desktopDATA] Error 1
[18:44] <bryceh> maco, ^^
[18:45] <maco> bah, ok.
[18:46]  * maco goes to re-look-up how lists work
[18:46] <bryceh> should it be =KDE;GNOME maybe?
[18:46] <broder> yeah, i think semicolon is the separator there
[18:46] <seb128> bryceh, it should yes
[18:47] <maco> oops. sorry :(
[18:47] <seb128> bryceh, maco: with a ; at the end of the list as well i.e ="KDE;GNOME;"
[18:47] <maco> i dont have an oneiric here to try to do the testing with
[18:48] <maco> i wonder if "The OnlyShowIn field is a list of strings identifying the environments that should display a given menu item. If an OnlyShowIn field is present, a given environment should only display the menu item if the string identifying that environment is present. The strings are case-sensitive." in the menu spec could be updated to say "semi-colon delineated list"
[18:49] <bryceh> at least the build process includes a validator to catch it
[18:50] <bryceh> so that's nice :-)
[18:50] <maco> making a debdiff for that for oneiric on natty wouldnt work here, so i just kinda hoped the syntax was right :-/
[18:50] <bryceh> maco, I've fixed it up locally and will upload it
[18:51] <maco> bryceh: thanks
[18:51] <hyperair> om26er: thanks for incorporating my patch.
[18:51] <bryceh> maco, chroots and pbuilders are your friends :-)
[18:51] <maco> bryceh: dont i need a source package before i can pbuild it?
[18:52] <maco> (and i have no idea how to do the chroots thing. i can chroot in to rescue a system, but other than that...vmware)
[18:52] <om26er> hyperair, oh no problem :)
[18:52] <hyperair> om26er: :)
[18:53] <seb128> maco, the format didn't change you could probably desktop-file-valide it on any recent ubuntu version
[18:53] <bryceh> maco, no problemo, I'll email you a script I use to make chroots
[18:54] <maco> seb128: i didnt know about that command. i guess if i quilt push -a then i could run it on the desktop.in, maybe?
[18:55] <seb128> maco, yeah, you could take the .desktop, hack it locally and run the validator on it
[19:10] <bryceh> maco, chroot making script sent.
[19:11] <bryceh> maco, branch merged and uploaded for oneiric
[19:14] <maco> thank you
[19:15] <seb128> maco, that changelog entry is quite confusing, it doesn't match the upload
[19:15] <seb128> "to NotShowIn:KDE so it works for Xubuntu, GNOME, etc. (LP: #841817)"
[19:15] <seb128> "NotShowIn=KDE;GNOME;"
[19:18] <maco> cruddddd did i write it before reading your comment on the bug, maybe?
[19:18] <maco> today is a fail day
[19:53] <kirkland> mdz: I'm just getting online for the first time in a few days....responded to your email now, glad to see tyhicks got you looking at the right git commit
[20:15] <smoser> kees, does this look sane to you: http://paste.ubuntu.com/683827/
[20:17] <micahg> smoser: he's off today, but you're missing the piece in debian/control that was dropped
[20:17] <smoser> oh for petes sake.
[20:22] <smoser> micahg, ok http://paste.ubuntu.com/683828/
[20:22] <smoser> that seems right to me (and builds)
[20:23] <micahg> smoser: I think that's fine, but to be sure, you can grab the last ubuntu version and diff
[20:24] <smoser> micahg, last ubuntu version did not need the additional patch
[20:24] <smoser> (the adding of the 'hardening-wrapper' is correct)
[20:25] <smoser> previous source just built with no necessary additional patches
[20:25] <micahg> smoser: right, was referring to the control file, idr exactly what the diff was, ah, if you checked then it should be fine :)
[21:37] <seb128> could somebody set https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 to merged?
[21:50] <jono> Laney, howdy
[21:50] <Laney> greetings
[21:51] <jono> sorry in advance
[21:51] <jono> I am here to nudge you about work items
[21:51] <Laney> hahaha
[21:51] <jono> would you mind having a look into your items on the following:
[21:51] <jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-app-review-board-review-and-assessment
[21:51] <jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-debian-dex
[21:51] <jono> https://blueprints.launchpad.net/ubuntu/+spec/community-o-review-sponsorship-process
[21:51] <Laney> I mailed the ARB yesterday
[21:51] <jono> that's it :-)
[21:51]  * Laney changes that one
[21:51] <jono> if you could update them, that would be great
[21:51] <jono> thanks!
[21:51]  * Laney is not very good at blueprints
[21:52] <ajmitch> Laney: you did?
[21:52] <Laney> yes
[21:52] <Laney> didnt it work?
[21:53] <stgraber> haven't received anything
[21:53] <Laney> is it moderated for non members?
[21:53] <ajmitch> did you do it through the LP contact-a-team, or the ML?
[21:53] <Laney> list
[21:53] <ajmitch> probably, jono can approve
[21:53] <Laney> yah boo
[21:53] <Laney> down with moderation!
[21:54] <ajmitch> yay for less spam though :)
[21:54] <stgraber> Laney: add a WI for jono to let the e-mail through ;)
[21:54] <jono> stgraber, oi!
[21:54] <jono> :-)
[21:55] <ajmitch> jono: or you could possibly add arb people to the mailman listadmin? :)
[21:55] <Laney> it wasn't a very good solution to the work item fyi
[21:55] <Laney> "here are the docs, but they suck"
[21:55] <jono> lol
[21:55] <ajmitch> hah
[21:56] <Laney> maybe the new sexier mentors will let us unify the two finally
[21:56] <jono> ok, I need to get IS to reset the password for the list for me
[21:56] <jono> I have lost it
[21:57] <jono> and then I will see if someone else can be an admin
[21:57] <Laney> haha
[21:57] <Laney> i'll forward it to ajmitch who can then send it to the list :P
[21:57] <ajmitch> heh, ok
[21:57]  * jono is useless
[21:57] <jono> apologies Laney
[21:57] <ajmitch> jono: don't worry, it took me awhile to dig up the password for the ubuntu-nz list :)
[21:58] <jono> :-)
[21:58] <Laney> you don't have it in ~/.listadmin.ini?
[21:58] <Laney> sent
[21:58] <ajmitch> I didn't
[21:59] <jono> thanks Laney
[21:59]  * jono goes back to hassling other people about work itemms
[21:59] <jono> items
[21:59] <Laney> I was thinking about the debdiffs thing the other day
[21:59] <Laney> how would you tell them apart from other diffs?
[21:59]  * micahg has a work item or 2 outstanding, but doesn't remember what they are
[21:59] <Laney> lsdiff them for changes in debian/?
[22:00] <ajmitch> given that any change should include something in debian/changelog, I guess that'd work
[22:01] <Laney> then you have to download them all :(
[22:03] <ajmitch> is there a fulltext search on LP for attachments?
[22:03]  * ajmitch is sure he read something about that awhile ago
[22:05] <ajmitch> https://lists.launchpad.net/launchpad-dev/msg03633.html is the best I can find offhand, saying no
[22:14] <bryceh> @pilot out
[22:23] <ajmitch> Laney: ok, it made it through to the list now
[22:24] <Laney> hoorah
[22:27] <Laney> nighty night
[23:30] <siretart> ogra_: in debian, the cause was a lovely segfault due to global destructors in qt
[23:34] <siretart> ogra_: known in ubuntu as LP: #785318
[23:46] <elmo> is the FFE process for universe really the same as main these days?
[23:47] <infinity> Pretty much.
[23:47] <infinity> Though you may find release folk slightly more tolerant of universe FFEs.
[23:48] <cjwatson> yep, same process, not necessarily same strictness
[23:48] <micahg> elmo: not on an image with no rdepends has a lower burden