[00:08] <directhex> MenZa, sod it. http://retro.apebox.org/grub-ubuntu3.tar.bz2. shove it in /boot/grub/themes/. the grub.cfg is just an example - the vital parts to extract from it are the gfxmode 1024x768 (the theme is hard-coded, apparently grub bzr supports percentage-based numbers tho), the insmod png, the insmod gfxmenu, and the menuviewer= and theme= lines.
[00:09] <directhex> theme.txt is my work entirely and under WTFPL 2.0. background image is canonical's and i think it's CC-BY-SA 3.0 or somesuch. other images are based on your work, so licensing is yours to dictate.
[00:15] <MenZa> directhex: good choice of licence
[00:15]  * MenZa approves
[00:21] <directhex> MenZa, forgot to mention, there's an out-by-one error in my boot_menu. i didn't get around to working out which value to tweak to make it fit just right. there are a few out-by-one errors really. oh, and i didn't do your scrollbar (the theme format supports it though, so good news there) as i kinda only had 6 items on my list ^_^
[00:21] <MenZa> :D
[00:24] <directhex> i didn't want to break a real pc by messing with real grub ¬_¬
[00:24] <MenZa> of course not
[00:24] <directhex> and kvm reboots like lightning
[00:24] <MenZa> that would be silly
[00:27] <MenZa> directhex: alright, I added a README and a license text to the txt file
[00:27] <MenZa> directhex: now uploading
[00:29] <MenZa> directhex: sent to ayatana@lists.lp
[00:31] <MenZa> most of the README file is just copy/paste from irssi :D
[01:27] <TheMuso> c
[01:45] <joshua___> Well I decided equivs was just too painful for blocking packages (I did it wrong 3 times) that I made a dpkg-block that does it easily.
[01:46] <ion> Huh? Creating a dummy package with equivs is trivial.
[01:46] <joshua___> making it replace the existing one so apt-get won't install it is not
[01:47] <ion> Just use a greater version number, e.g. 42:1dummy or whatever.
[01:47] <joshua___> oh I see
[01:47] <joshua___> I ended up making a single package that both Provides and Conflicts all packages by name
[01:54] <chrisccoulson> superm1 - i've just pushed a gnome-system-tools update to bzr which fixes bug 484559 and bug 497441
[01:55] <superm1> chrisccoulson, great thanks.
[01:55] <chrisccoulson> i can't upload g-s-t though, so feel free to sponosr it if you get the chance :)
[01:55] <chrisccoulson> s/sponosr/sponsor
[01:56] <superm1> chrisccoulson, sure i can sponsor later tonight probably.  just need to throw a lucid pbuilder together to test build her
[01:56] <chrisccoulson> superm1 - thanks
[01:57] <chrisccoulson> superm1 - the update is here: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-system-tools/ubuntu/revision/21
[04:02] <joshua___> ugh now I really feel glad I made that tool
[04:03] <joshua___> I just upgraded my chroot jail to karmic and it installed a bunch of junk (kernel images etc) that needs to be gone
[04:12] <joshua___> ping
[06:27] <pitti> Good morning! Happy new year everyone
[06:29] <Hobbsee> hey pitti!
[06:29] <ScottK> pitti: Happy New Year.
[07:12] <dholbach> good morning and happy new year! :-)
[07:12] <RAOF> dholbach: Good morning!  Hope Christmas & New Years has treated you well :)
[07:13] <dholbach> hey RAOF - it did! :-)
[07:13] <dholbach> RAOF: how about you? how's life?
[07:13] <RAOF> Sweet!
[07:13] <RAOF> Pretty cool.  It's fun being married :)
[07:13] <dholbach> oh nice... when did it happen?
[07:14] <RAOF> October.
[07:14] <RAOF> But it's still fun :)
[07:14] <dholbach> cool :-)
[07:15] <RAOF> There are some photos on facebook, actually.  I should put some of the new ones up, too.
[07:15] <RAOF> It was awesome :).
[07:15] <pitti> hey dholbach, gesundes Neues! *hug*
[07:16] <dholbach> RAOF: nice - I'll have a look in a bit!
[07:16] <dholbach> hey pitti! and the same to you! :-)
[07:18] <RAOF> Hugs all around!
[07:49] <dholbach> SPONSORING! Have a look at http://overbenny.wordpress.com/2010/01/04/empty-ubuntu-universe-sponsors-queue/
[08:15]  * nixternal crosses finger on distributed development merge
[08:43] <dholbach> hey seb128
[08:43] <seb128> hey dholbach
[08:43] <seb128> happy new year!
[08:43] <seb128> how are you?
[08:43] <dholbach> and the same to you :)
[08:43] <dholbach> good good - how 'bout you?
[08:44] <seb128> good too thanks
[08:44] <seb128> I had relaxing holidays and didn't touch the computer much during those
[08:44] <dholbach> nice :)
[08:44] <seb128> how was Istanbul?
[08:44] <dholbach> İstanbul was fantastic - I had a great time :)
[08:45] <seb128> great ;-)
[08:46]  * RAOF is unable to see the name “Istanbul" without hearing the They Might Be Giants song :)
[08:47] <ion> Relaxing time; not touching computer? That’s contradictory.
[08:49] <tseliot> pitti: what's your take on this thread? We need the opinion of the udev guys (and I seem to remember that you're one of them): http://lists.x.org/archives/xorg-devel/2010-January/004497.html
[08:51] <pitti> hey tseliot, happy new year! looking
[08:51] <tseliot> pitti: thanks, happy new year to you :-)
[08:51] <pitti> I have noticed that "the ability to set the Xorg driver, or arbitrary driver
[08:51] <pitti> options, directly through udev has been removed".
[08:51] <pitti> tseliot: ^ oh?
[08:51] <tseliot> yep
[08:52] <pitti> tseliot: was the udev backend accepted upstream now?
[08:52] <tseliot> yes
[08:52] <tseliot> but only xkb options can be passed
[08:52] <tseliot> pitti: which is why I proposed that new feature
[08:53] <tseliot> pitti: if you have never heard of xorg.conf.d: http://who-t.blogspot.com/2010/01/new-configuration-world-order.html
[08:54] <pitti> tseliot: I heard about it, but no details yet; ok, let me digest the thread and the blog post
[08:54] <tseliot> ok, thanks
[08:57] <pitti> ah, so http://cgit.freedesktop.org/xorg/xserver/commit/?id=435f27667f84269768efecde34de4af2b2d43376 was the upstream commit
[08:57] <dpm> good morning and a happy new year to everyone!
[08:57] <pitti> tseliot: do you know how this can set the driver in the first place?
[08:57] <pitti> hey dpm, good morning and happy new year!
[08:59] <tseliot> pitti: the udev backend (see config/udev.c) in the xserver already passes options and flags to X: http://cgit.freedesktop.org/xorg/xserver/commit/?id=435f27667f84269768efecde34de4af2b2d43376
[09:00] <pitti> tseliot: so drivers get assigned in xorg.conf.d/driver.conf as well now?
[09:00] <tseliot> pitti: yes, but /etc/xorg.conf has the highest priority
[09:01] <tseliot> in general we can put quirks and other stuff in xorg.conf.d so as to make things work better out of the box without touching the main xorg.conf
[09:01] <tseliot> (or even without having one)
[09:02] <pitti> MatchIsTouchpad "on"
[09:02] <pitti> ah, clever
[09:02] <tseliot> yep
[09:02] <pitti> so that will replace the udev rules like ENV{ID_INPUT_TOUCHPAD}=="1", ENV{x11_driver}="synaptics"
[09:03] <tseliot> pitti: yes, exactly
[09:03] <tseliot> pitti: that and the other options that we currently use for touchpads
[09:04] <pitti> tseliot, bryce_: do you think we can get this xserver into lucid, so that we avoid asking people to migrate their fdis to udev rules, just to migrate them again to xorg.conf.d in lucid+1?
[09:04] <tseliot> pitti: I think we can just backport the patch from the new X
[09:05] <pitti> tseliot: the udev backend yes, but we also need the xorg.conf.d support
[09:05] <tseliot> tjaalton was already planning on pulling the patches for both things
[09:05] <pitti> and the new Match* stuff and InputClass
[09:05] <pitti> ok, cool
[09:05] <tseliot> pitti: yes, of course
[09:05] <pitti> once that's in, I'll make sure to update the docs and migration guide
[09:06] <tseliot> pitti: so this is an example of how my new feature should work: http://lists.x.org/archives/xorg-devel/2010-January/004534.html
[09:06] <tseliot> (the quoted text contains an explanation about the design)
[09:09] <pitti> tseliot: http://lists.x.org/archives/xorg-devel/2010-January/004534.html sounds good to me
[09:09] <pitti> i. e. adding tags
[09:09] <pitti> tseliot: I'd just ask you to not name it ENV{TAG}
[09:09] <pitti> perhaps ID_INPUT_TAG ?
[09:09] <tseliot> pitti: yes, that was just an example ;)
[09:09] <tseliot> pitti: sounds good to me
[09:10] <pitti> other than that, it's not really udev related, udev is just the database here
[09:10] <pitti> but your example with ID_INPUT_TAG sounds perfect to me
[09:10] <tseliot> pitti: here Peter wanted to hear from you guys about namespacing the tags: http://lists.x.org/archives/xorg-devel/2010-January/004545.html
[09:11] <tseliot> shall I forward the email to you so that you can reply?
[09:11] <pitti> tseliot: I can't post to xorg-devel@
[09:11] <hyperair> crimsun: codec#0 and codec#1 respectively, re powerdown powersave changes for hda-intel:
[09:11] <hyperair> http://pastebin.com/f4257e508
[09:11] <hyperair> http://pastebin.com/f5f922cb8
[09:12] <pitti> tseliot: what do you mean with namespacing? ID_INPUT_XORG.TAGS ?
[09:12] <tseliot> pitti: it's a free mailing list
[09:12] <pitti> it doesn't really matter much
[09:12] <pitti> tseliot: oh, nice; could you bounce the mail then?
[09:12] <pitti> (not forward, that'd lose the msgid)
[09:12] <tseliot> pitti: in the sense that subscription is free and the list is not moderated
[09:12] <tseliot> pitti: sure
[09:13] <pitti> tseliot: right, but you need to be subscribed to post, I figure?
[09:13] <tseliot> note: I don't know exactly what Peter meant by "namespacing"
[09:13] <tseliot> pitti: yep
[09:13] <tseliot> but you can reply directly to Peter if you prefer
[09:13] <pitti> right, and keep my ML post in the moderation queue
[09:15] <tseliot> pitti: ok, sent
[09:23] <tjaalton> pitti, tseliot: seems that debian will not pull the xorg.conf.d stuff unless the display driver fallbacks are fixed to work (when there is an xorg.conf)
[09:26] <tseliot> tjaalton: what happens exactly with the driver fallbacks?
[09:27] <geser> what's the current process regarding bzr based merges? is opening a merge proposal enough or should a merge bug be opened too?
[09:27] <tjaalton> tseliot: the server builds an internal copy of xorg.conf where there are multiple driver sections ($foo, vesa, fbdev)
[09:27] <tjaalton> and then tries them one at a time
[09:27] <tjaalton> the one that works will be used
[09:28] <tseliot> right
[09:28] <tjaalton> so if the native driver doesn't support the id, the init will fail and the next one is tried
[09:28] <tjaalton> but if there is an xorg.conf (even just an empty one) it'll only use the first one
[09:29] <tjaalton> because it's a completely different code path
[09:30] <tseliot> tjaalton: and this happens also when no xorg.conf is there but there's something in xorg.conf.d/, right?
[09:31] <tjaalton> tseliot: pretty sure
[09:31] <tseliot> tjaalton: is there a bug report about this on freedesktop? I think I can work on it
[09:32] <tjaalton> not that I know of
[09:32] <tseliot> ok
[09:32] <tjaalton> best to throw the idea on the upstream list and discuss it there too
[09:32] <tjaalton> dan or someone else might have ideas
[09:33] <tseliot> sure, I don't want to waste my time on something that won't be accepted or that someone else has already fixed
[09:34] <tjaalton> jcristau already said to me that "every time i looked at that i ended up running away screaming" :)
[09:34] <tseliot> hehe
[09:36] <tjaalton> don't know how hard it would be to use the udev backend for output as well..
[09:36] <tjaalton> not that it would directly solve this problem though
[09:37]  * tseliot nods
[09:38] <pitti> tseliot: sorry, lost your replies after "pitti | tseliot: does your mail client support bounce?"
[09:38] <pitti> tseliot: anyway, I replied to your forwarded mail
[09:38] <tseliot> pitti: perfect, thanks
[10:21] <tseliot> cjwatson: I can't log in (in gdm/kdm) when using Lucid livecd on amd64. I can't even see my username listed (same problem if I use startx and install the system). Is it a known issue?
[10:21] <cjwatson> tseliot: you know as much as I
[10:21] <tseliot> oh
[10:22] <tseliot> i386 works fine
[10:23] <joaopinto> tseliot, I experience the same problem with a desktop install, but it only fails to start ramdomly
[10:23] <alkisg> tseliot: I've been seeing that (in i386) for a week now, both on the ubuntu live and the edubuntu live
[10:24] <alkisg> I had to create a new user to login & install
[10:24] <joaopinto> a manual service gdm start works
[10:24] <tseliot> oh, so it doesn't affect only amd64
[10:24] <alkisg> joaopinto: but gdm starts; just autologon doesn't work for the ubuntu user....
[10:24] <tseliot> joaopinto: restarting gdm didn't help here as gdm didn't show my username in the list and didn't accept my username either
[10:25] <tseliot> joaopinto: I think you're experiencing a different problem (X.org failure?)
[10:25] <joaopinto> hum, I am using autologin
[10:25] <joaopinto> tseliot, X.org failing to start randomly from upstart only ?
[10:26] <alkisg> joaopinto: we're talking about the *live* cd...
[10:26] <pitti> I filed bug 502838 this morning, but for me it happens on the installed system, not live cd
[10:26] <alkisg> Autologin there is only for the premade `ubuntu` user
[10:26] <joaopinto> ok, so I have a different issue, sorry
[10:26] <tseliot> ok
[10:27] <tseliot> joaopinto: that must be the problem you mentioned ^^
[10:28] <joaopinto> yup
[10:30] <joaopinto> pitti where you able to use the "low graphics dialog" at all ?
[10:30] <pitti> joaopinto: no, it just keeps reappearing
[10:30] <joaopinto> I did also get it randomly, but on the second step (which I don't remember right now), it did nothing
[10:30] <joaopinto> something like "Create new config"
[10:33]  * alkisg had to use xforcevesa for the live cd to boot at all...
[10:34] <pitti> right, today's amd64 live login is busted here, too (kvm)
[10:37] <cjwatson> I've been getting livefs build failure mails for a while, whining about initramfs-tools versioning; I didn't look into them since I was on holiday, but maybe that's it
[10:37] <alkisg> cjwatson: sorry, an unrelated question: in gfxboot, "Try edubuntu without any change to your computer" is untranslated in *all* languages, while it is translated in launchpad. Any clues?
[10:37] <pitti> gdm-simple-slave and xorg just segfault, that's it
[10:38] <cjwatson> alkisg: I need to import the translations semi-manually
[10:38] <alkisg> cjwatson: ok, thank you :)
[10:38] <cjwatson> anyway, it's "Try Edubuntu without installing" in lucid
[10:39] <cjwatson> but before that change there were definitely some translations in gfxboot-theme-ubuntu
[10:39]  * alkisg is using the 23-12 daily build of edubuntu
[10:39] <cjwatson> alkisg: are you talking about karmic or lucid or what?
[10:39] <alkisg> 2009-12-23
[10:39] <cjwatson> alkisg: have a look at the gfxboot-theme-ubuntu 0.9.0 changelog then
[10:40] <cjwatson> you shouldn't be seeing the string "Try Edubuntu without any change to your computer" at all, in any language ...
[10:40] <cjwatson> oh, blast, I need to change debian-cd too
[10:40] <alkisg> Hmmm I'll try with a more current version
[10:40] <cjwatson> nah
[10:40] <cjwatson> it's a bug, I'll fix it now, thanks. but the translations still need to be imported anyway
[10:40] <alkisg> Thank you :)
[10:41] <pitti> cjwatson: happy new year! enjoyed the holidays?
[10:41] <cjwatson> pitti: not bad, thanks
[10:53] <geser> what's the current process regarding bzr based merges? is opening a merge proposal enough or should a merge bug be opened too?
[10:54] <sebner> geser: I just wanted to merge pbuilder and what do I see? Actual debian branch on LP is the same version as lucid :P
[10:56] <sebner> pitti: happy new year migthy pitti :)
[10:56] <pitti> hey sebner, gesundes Neues!
[10:58] <ogra> pitti, frohes neues ! :)
[10:58] <pitti> ogra: thanks, you too! *hug*
[10:58] <ogra> :)
[10:58] <sebner> pitti: :), aber du hast versagt. Ich und der geser waren hardcore auf in der Nacht um packaging work zu tun :P
[10:59] <pitti> I tried not to do too much work during the holidays :) (just some apport hacking and lots of postgresql-common bug fixing, the Debian type of stuff)
[11:01] <DktrKranz> sebner: ... and for sud sud-tirolers like me, what's that all about? :)
[11:01] <sebner> DktrKranz: you too of course! :P
[11:02]  * DktrKranz has to understand that statement first
[11:02] <ev1> pitti: it's because of the 15autologin change.  I've been looking into it, but sed's handling of variables with embedded newlines is creating some difficulty for me."
[11:03]  * DktrKranz is not good in sebnerish
[11:03] <pitti> ah, that
[11:03] <ev1> pitti: this is what I have so far, but the sed a command breaks: http://pastebin.ubuntu.com/351186/
[11:05] <pitti> ev: perhaps this should be radically simplified by just writing the file from scratch if it doesn't exist yet (normal live system), and not touching it at all if it does exist?
[11:07] <sebner> DktrKranz: as sud sud-tiroler you should understand :P
[11:07] <ev> pitti: that works for me, provided it doesn't break any use case you're aware of.  I'm not sufficiently familiar with the bug that spurred this change in the first place.
[11:08] <pitti> ev: it was introduced only recently; before we just always wrote the file from scratch
[11:08] <pitti> I'm not aware of an use case with a preexisting file and no configured autologin where it's desirable to enable autologin again
[11:09] <pitti> that could only happen if you explicitly disable it from the live system and use persistency
[11:09] <pitti> in which case I think it makes sense to respect this
[11:10] <geser> sebner: I've already prepared a merge for pbuilder (bug #502135). it just awaits sponsoring.
[11:14] <ev> pitti: okay, so does this look okay to you: http://pastebin.ubuntu.com/351189/ (revert to previous method and make sure custom.conf doesn't exist)
[11:15] <pitti> ev: looks fine to me; and much easier to maintain/understand than the multiline seddery IMHO
[11:15] <ev> lovely, I'll commit and upload that
[11:15] <ev> thanks
[11:17] <pitti> thanks to you!
[11:23] <sebner> geser: uhh, great. thanks
[11:23] <sebner> geser: but the oldstyle way I suppose? without bzr
[11:32] <verb_> Progress with Fribidi: Daniel asks for a .diff.gz
[11:32] <verb_> https://bugs.launchpad.net/ubuntu/+source/fribidi/+bug/191241
[12:08] <Rovanion> What package am I missing when I get a compiler error about 'snd_session'? Here is the full compiler log: http://pastebin.org/70981
[12:31] <amikrop> Places->Connect to server->Secure WebDAV does not work. it says Could not open location, not a WebDAV enabled share, but it is (I can connect from other computers)
[12:46] <amik> mvo: hi there! are you the maintainer of software-properties?
[12:46] <mvo> amik: yes
[12:47] <amichair> mvo: I've been working on it from the kde side, closed all kde related bugs and some backend ones
[12:48] <amichair> do you intend on fixing things up in gtk/backend for this LTS?
[12:49] <mvo> amichair: I noticed that you work on the kde side, many thanks for that! I'm very short on time unfortunately, but if you have specific suggestions I will try to get them in - if you want to work on the gtk side too, that is more than welcome too of course :)
[12:50] <amichair> mvo: I've got limited time as well, so I try to help out in the kubuntu regions for now (that's what I use)
[12:50] <amichair> mvo: another thing, regarding add-apt-repository
[12:50] <amichair> it looks like a bit of a quick hack, just a few lines of code
[12:50] <amichair> but once out there, people expect it to be more
[12:51] <mvo> amichair: right, well. it was meant as a quick command-line version of the "add" button. what in particular do you think is missing?
[12:51] <amichair> there are a bunch of bugs/wishlist items open on it, going as far as 'make a software-properties-text frontend', for which a-a-r is a start, I guess. On the other hand, it doesn't seem like anyone has time (or intention?) to support it that far...
[12:52] <mvo> yeah, it seems like time is the big problem, I'm would be happy to merge a newt based frontend, just like we have one for update-manager
[12:53] <mvo> but  it requires someone with a bit of time to work on it (should not be very hard)
[12:53] <amichair> so the vision is indeed to go in that direction?
[12:54] <mvo> well, ideally the frontend code is abstract enough to make that easy, but that will only work if someone devotes time on it
[12:55] <mvo> its currently not quite there IIRC, the seperation is not that great, but it could be a good time to do cleanup there too
[12:55] <mvo> so in summary, I would not call it "vision", but I will not oppose it
[12:55] <amichair> that's the problem with introducing quick new features - you become responsible for everything you *didn't* do, which is the other 99% of the work :-)
[12:56] <mvo> lol
[12:56] <mvo> indeed :)
[12:56] <mvo> the old 80/20 rule
[12:57] <mvo> amichair: I will try to do some cleanup this week on the buglist and see what I can squeeze in for lucid
[12:57] <amichair> btw does ubuntu have some policy regarding closing bugs for an LTS, or is it just 'when we get to it' as usual?
[12:58] <mvo> amichair: no policy, but if you have specific (anoying) bugs in it please let me know about them
[13:02] <amichair> mvo: no, nothing in particular. I was just hoping you'd be able to take the opportunity (15-20 recently squashed bugs) to clean the slate on 'your' side, or at least dust it off a bit :-)
[13:03] <mvo> amichair: ok, thanks for that! I check it out :)
[13:03] <amichair> mvo: cool, great :-)
[13:04] <amichair> mvo: wish I had more free time as well...
[13:06]  * mvo agrees so much
[13:38] <cjwatson> kees: I synced hardening-wrapper from unstable in order to be able to merge new openssh
[13:39] <cjwatson> kees: P.S. if you're changing openssh in future please note that it's in bzr now; I merged your change in there
[13:44] <JamieBennett> lool: MIR for embryo https://wiki.ubuntu.com/MainInclusionReportEmbryo and concerns over "another virtual machine" - https://wiki.ubuntu.com/MainInclusionReportEmbryo
[13:45] <lool> JamieBennett: I'm not surprized
[13:45] <lool> JamieBennett: I actually noted that down in my concerns since I started reviewing it  ;-)
[13:45] <pitti> I thought it was obsolete now?
[13:45] <lool> pitti: Currently, edje build-deps on it
[13:46] <lool> JamieBennett: So I guess you should talk to upstream or the Debian maintainer and ask whether we really need embryo?
[13:46] <pitti> we already discussed that some weeks ago, and I wasn't happy about it; JamieBennett(?) told me that newer builds wouldn't need embryo any more?
[13:46] <lool> Gustavo Barbieri might be able to comment too
[13:46] <JamieBennett> pitti: I was mistaken
[13:47] <lool> JamieBennett: So is it a strict requirement according to upstream?
[13:47] <JamieBennett> lool: I'll check with upstream for the details of exactly why its needed.
[13:48] <lool> pitti: I personally reviewed the package quickly, it seems it's ok (no build time warning / error on this one!); perhaps we could ask kees for a security review?
[13:48] <lool> my notes http://paste.ubuntu.com/351252/
[13:49] <lool> Ah there's a bug too
[13:49] <pitti> lool: my concern is that it is the n+1st and obscure VM, while we already have well-known and well-supported ones (like lua)
[13:49] <lool> pitti: Just reading the bug now, didn't understand it had been discussed already
[13:49] <pitti> lool: and my biggest concern is the total lack of a test suite
[13:49] <lool> Ack, saw that in the bug
[13:51] <lool> Commented in the bug
[13:52] <cjwatson> ttx: I've uploaded openssh 1:5.2p1-1ubuntu1, including conversion to upstart; you can start relying on that in eucalyptus if you like, though you probably ought to have a versioned dependency on openssh-server if you do
[13:55] <ttx> cjwatson: sure thing, thanks. Haven't had time to test it as requested, sorry about that
[13:55] <james_w> dear archive admins: You may like to look at https://code.edge.launchpad.net/~james-w/ubuntu-archive-tools/improved-sync-helper/+merge/16779 for improved CLI driven processing of the sync queue. Feedback welcome.
[13:55] <cjwatson> that's ok, just means it blows up for more lucid users ;-)
[13:56] <lool> pitti: There even was a CVE against embryo!
[13:58] <lool> actually might be another software
[14:02] <JamieBennett> just talking to raster about embryo, it seems its absolutely essential but isn't designed for anything other than edje really
[14:03] <lool> JamieBennett: do they intend to provide a testsuite?
[14:03] <mpt> How can I list the packages that are marked as "Enhances:" for a particular package X? I've muddled my way as far as 'apt-cache dumpavail | grep "Enhances: X"', but obviously the output doesn't include any package names. (mvo?)
[14:03] <lool> mpt: grep-dctrl might help you
[14:03] <lool> or aptitude, not sure it lists enhances though
[14:04] <ion> Yeah, grep-dctrl indeed.
[14:04] <mpt> Ah, wonderful, thanks lool
[14:05] <lool> mpt: Actually aptitude allows that, so you can browse to the package in aptitude and look at the reverse deps from the ncurses gui
[14:05] <mpt> whoa, aptitude has a gui
[14:05] <ion> grep-aptavail -sPackage -FEnhances -r '\<screen\>'
[14:05] <lool> It has an experimental gtk+ gui too
[14:05] <mvo> mpt: debian/unstable has a gtk gui too
[14:05] <JamieBennett> lool: no testsuite plans
[14:06] <JamieBennett> raster took the lib from compuphase and assumes that all testing was done there
[14:06] <lool> JamieBennett: I'll let pitti comment as he did most of the review and had the strongest opinion; I personally would be fine running it through kees
[14:06] <mpt> brillian
[14:06] <mpt> t
[14:06] <lool> I'm not overall happy that we end up with another toolkit and vm in main, but then if it's maintained by
[14:06] <lool> mobile team + Debian, it should be ok
[14:07] <mpt> thanks ion!
[14:07] <lool> JamieBennett: Oh it's a fork?
[14:07] <JamieBennett> pitti: the consensus from upstream is that embryo should be rolled into edje but at the moment its just separate, i.e. we should treat them as the same package
[14:07] <ion> mpt: If you only want the value from a single field (say, Package), you might also want -n
[14:08] <mvo> mpt: please note that enhances are curerntly not well supported in apt/python-apt, we need to do some ground work first. if you want them in s-c I will have to add some support code first to the lower levels
[14:08] <JamieBennett> lool: Not that I'm aware of, raster took the lib, streamlined it and released it as embryo
[14:09] <JamieBennett> lool: but it was based on something else historically
[14:09]  * tedg wants 'enhances' support :)
[14:10]  * ogra wonders why everybody talks about VM here, i thought its a toolkit lib
[14:10] <mpt> mvo, this is for <https://wiki.ubuntu.com/SoftwareCenter#add-ons>, which is in the "Yet-to-be-specified features" section, not scheduled for 2.0 :-)
[14:10] <pitti> embryo is a VM, similar to lua
[14:10] <ogra> bah
[14:11] <mvo> mpt: ok, I have a look anyway at the code, it should be trivial to add (just some leg-work) :)
[14:14]  * mpt looks for a package that has an interesting set of Enhances but that isn't Firefox
[14:41] <davidw> given the latest comment here: https://bugs.launchpad.net/ubuntu/+source/barry/+bug/426716 - would it be ok if I changed the status of this bug?  I'm not really sure what standard practice is in these cases.
[14:44]  * barry unpings; nice project name :/
[14:46]  * jussi01 hugs barry
[14:47]  * barry feels better, thanks jussi01! :)
[14:48] <davidw> barry, ahahaa :-)
[14:57] <beuno> mpt, hi. Do you have moderating powers on ayatana?
[14:58] <beuno> mpt, I think there's a few messages stuck in the queue
[15:08] <zul> doko: ping
[15:13] <mpt_> beuno, no, I didn't know ayatana@ existed until a couple of months ago :-)
[15:13] <beuno> mpt_, ha!
[15:16] <smoser> Keybuk, http://paste.ubuntu.com/351288/ shows me failing boot on my ec2-images, is there something I need to do to get plymouth? or is that just red-herring error?
[15:16] <smoser> any clues?
[15:17] <LaserJock> pitti: quick question on your MIR proposal: will there still be some template for people to know what information should go into a report? For people who don't do it often it is a helpful guide to what they need to think about
[15:18] <pitti> LaserJock: the UbuntuMainInclusionRequirements page provides the whole checklist
[15:18] <LaserJock> so that will remain
[15:18] <pitti> (part of the reason why I want an explicit "I checked the UbuntuMainInclusionRequirements and all was okay)
[15:18] <pitti> LaserJock: right, that's the essential part of it now
[15:19] <LaserJock> I was unsure if what you were saying was "you don't need to look at the wiki at all anymore" or if it was just that you don't  have to fill out the wiki form
[15:19] <Keybuk> smoser: it's just a warning
[15:19] <pitti> the latter rather
[15:19] <LaserJock> so that answers my question :-)
[15:19] <Keybuk> smoser: the SEGV is far more like a bug :p
[15:19] <LaserJock> pitti: sounds good, thanks for working on that
[15:19] <pitti> you're welcome
[15:19] <pitti> seems an unanimous "agree" so far, so I'll move it over soon and write to u-d-a@
[15:20] <smoser> Keybuk, you want me to open a bug ?
[15:20] <Keybuk> smoser: only if you have a core dump
[15:21] <smoser> well, no, but i can likely trace it back and see a set of package changes that cause it.
[15:22] <Keybuk> smoser: that won't help
[15:22] <Keybuk> since it doesn't do it to me, or anyone else
[15:22] <Keybuk> really need core dump
[15:22] <Keybuk> init=/bin/sh
[15:22] <Keybuk> mount a tmpfs over /var/crash
[15:22] <Keybuk> start apport
[15:22] <Keybuk> exec /sbin/init
[15:22] <Keybuk> then when it crashes, apport should still have worked
[15:24] <pitti> with the current lucid kernel that also requires an "ulimit -c unlimited", I believe
[15:25] <pitti> (bug 498525)
[15:25] <Keybuk> ah right
[15:25] <Keybuk> yes, and do that before init, and it gets passed down to everything ;)
[15:25] <pitti> Keybuk: happy new year
[15:25] <ebroder> udev/lvm2 question: Hardy's LVM has a udev rule that does vgchange -a y when new volume groups are found, but there's no such rule in Karmic. Hardy also has an initramfs script that activates the root VG, and Karmic doesn't. What brings up VGs on Karmic?
[15:25] <Keybuk> pitti: happy new year to you too
[15:26] <Keybuk> ebroder: your second statement is incorrect
[15:27] <ebroder> Keybuk: Wait, really? All I see is an init-premount script that does a vgscan in mountroot_fail, at which point presumably it's too late to recover, right?
[15:28] <Keybuk> ebroder: your second statement being that "there's no such rule in Karmic"
[15:28]  * ebroder looks
[15:28] <barry> i'm using virt-manager with bridged networking to do development on a lucid vm, however every time i reboot the karmic host, the bridged network doesn't come up until i /etc/init.d/networking restart.  any ideas why that is?
[15:29] <ebroder> ...huh. Oh right - it's Debian that doesn't have that rule
[15:29] <Keybuk> ebroder: important difference ;-)
[15:29] <ebroder> Keybuk: Sorry, I forgot that my Karmic VM isn't using LVM :)
[15:29] <Keybuk> ebroder: yeah, LVM doesn't work if you're not using LVM
[15:30] <ebroder> Keybuk: I'll keep that in mind :-P - let me try again, though. Why does /Debian/ not need something to activate volumes?
[15:30] <Keybuk> ebroder: because Debian has all sorts of initramfs and init scripts to try and activate volumes over and over again
[15:32] <ebroder> Keybuk: Makes sense. Thanks. (I spent a while last night trying to get a Hardy machine to boot using Debian's LVM package, and it didn't work until I copied over the original Hardy udev rule)
[15:32] <Keybuk> why didn't you use Ubuntu's LVM package?
[15:32] <ebroder> Too old
[15:32] <ebroder> I actually was using Debian's packaging against a 2.0.56 upstream tarball, because I wanted some of the very recent updates to clvm
[15:33] <Keybuk> anything at that level isn't going to work
[15:33] <Keybuk> we have fundamentally different core pieces of our boot and plumbing
[15:33] <ebroder> Well, I eventually got it to work - it just took a very big hammer :)
[15:33] <Keybuk> Ubuntu's plumbing layer is closer to Fedora or SuSE than Debian
[15:33] <Keybuk> you could probably wedge Fedora's lvm RPM in and have more chance of it working
[15:33] <Keybuk> (quite seriously)
[15:37] <ebroder> Really, it wasn't that bad. Since I was backporting to Hardy, I had to deal with the {/etc => /lib}/udev/rules.d change, I had to drop in Ubuntu's lvm2 udev rule, and I had to correct for copy_exec requiring two arguments in initramfs hooks (which I think was also a backporting issue). Once I did that, the package worked
[15:39] <ebroder> Of course, it doesn't really seem to have fixed the fact that corosync and openais and pacemaker and clvm and really the whole Linux clustering stack are a steaming pile of worthless, undocumented crap...but that's not a Debian vs. Ubuntu problem :-P
[15:50] <ebroder> distributed development question - if somebody's done a package merge by proposing a bzr merge, I can't just approve the bzr merge, right? I still dput the resulting package as well?
[15:51] <jelmer> ebroder: yes, at the moment you still need to manually dput
[15:51] <ebroder> jelmer: Ok - what if I want to make a modification? Should I approve the merge and then dput something different? Reject and dput?
[15:52] <james_w`> ebroder: if you grab the lp:ubuntu/<package> branch, do a bzr merge-package of their proposed branch, then modify and commit
[15:53] <james_w`> you can push the result to lp:ubuntu/<package> and dput what "bzr bd -S" spits out
[15:53]  * ebroder nods. Let's see if I can wrap my head around making this all work...
[15:56] <ebroder> Does bzr bd automatically choose the right gpg key to use?
[15:56] <cjwatson> I normally branch to a temporary location, merge, commit further changes, and then merge *that* into the trunk
[15:56] <cjwatson> seems to fit my mental model of what's going on better - "don't merge to trunk until I'm happy"
[15:59] <ogra> colins code arboretum ? :)
[16:02] <james_w`> ebroder: it's just running dpkg-buildpackage, so that's what decides what to use
[16:04] <ebroder> james_w`: Hmm...but it's using my key even when the changelog entry lists somebody else..that's unusual
[16:05] <james_w`> do you have a ~/.devscripts ?
[16:06] <ebroder> Huh - apparently I do. I had forgotten about that
[16:11] <DktrKranz> james_w`: some package branches are not up-to-date, even if they're not listed in those which failed to update. Is there a workaround for that?
[16:12] <james_w`> DktrKranz: we have some operational problems that I am trying to fix
[16:12] <james_w`> you could run it locally, but that might be a bit more than you want to try
[16:12] <james_w`> are you on the ubuntu-distributed-devel list? there were some pointers on there
[16:14] <DktrKranz> no, I can see archives though
[16:15] <ttx> pitti, cjwatson: could one of you trigger a server CD respin please ?
[16:15] <pitti> ttx, cjwatson: will do
[16:16] <pitti> running
[16:16] <pitti> ETA 10 mins
[16:16] <ttx> pitti: thx
[16:16] <sbalneav> mvo: ping on bug #501559 , I beleive you're the maintainer for gksu?
[16:21] <mvo> sbalneav: let me have a look, I'm not the maintainer as such, but often work on it
[16:21] <sbalneav> mvo: It just needs another config option
[16:22] <sbalneav> it used to do the forkpty by default, but then it got extrapolated out into a set of #ifdef's
[16:22] <sbalneav> with a corresponding config option.
[16:23] <mvo> sbalneav: thanks, I assgined it to me
[16:23] <DktrKranz> jelmer: any plans to have latest bzr-builddeb in Lucid to experimental too?
[16:24] <DktrKranz> I find it very useful
[16:24] <dholbach> kirkland: did I already ask you about giving a session about kvm stuff at UDW? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep has a slot open for you :)
[16:24] <jelmer> DktrKranz: yes, it's great
[16:25] <dholbach> DktrKranz: could you imagine giving the same python packaging session twice? :)
[16:25] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep would have a slot for you :)
[16:25] <jelmer> DktrKranz: or perhaps even sid, I think the version in Lucid works better than the one in unstable
[16:25] <jelmer> james_w`: ^
[16:26] <kirkland> dholbach: hmm, maybe you did?  :-)
[16:26] <dholbach> kirkland: I forgot what you said so I thought I'd ask again :)
[16:26] <james_w`> jelmer, DktrKranz: yeah, it should go to sid
[16:26] <kirkland> dholbach: i'll do it, but it will have to be Thursday or Friday, as I'm traveling back from LCA that week
[16:26] <james_w`> I've just been lax in getting it packaged up
[16:26] <james_w`> any help welcome
[16:27] <james_w`> I need to upload to lucid and pursue an SRU as well
[16:27] <DktrKranz> jelmer: even better
[16:29] <DktrKranz> dholbach: having the same session just a week later?
[16:29] <dholbach> DktrKranz: yeah :)
[16:29] <dholbach> kirkland: I'll see with whom you could maybe swap :)
[16:30] <dholbach> jelmer: do you think you could run your session also on wednesday at 19 UTC? if not, I'll ask somebody else :)
[16:31] <DktrKranz> dholbach: I've no problem, perhaps RainCT is interested too
[16:31] <dholbach> DktrKranz: that'd be very fantastic
[16:31]  * RainCT reads the log
[16:31] <kirkland> dholbach: let's shoot for Thursday, if possible
[16:31] <jelmer> dholbach: I think we should be able to get some people on IRC around that time, I'll be at a bzr sprint during the open week :-)
[16:32] <kirkland> dholbach: can i swap with you and jcastro ?
[16:32] <DktrKranz> dholbach: keep the one at 20 UTC, because I'm not home before
[16:32] <dholbach> jelmer: oh... so you can't give that session?
[16:32] <dholbach> DktrKranz: wednesday 20 utc?
[16:32] <RainCT> DktrKranz: sure, I have plenty of time after the 18th January
[16:32] <dholbach> kirkland: swap which slot with that one?
[16:32] <DktrKranz> dholbach: isn't 27th?
[16:33] <dholbach> DktrKranz: yep
[16:33] <DktrKranz> I've one on 21st, fine on 27th too
[16:33] <dholbach> ROCK
[16:33] <DktrKranz> I'll try to differentiate it a bit
[16:33] <dholbach> DktrKranz: let me know if you find somebody else to give the session with you and I'll update the page and everything
[16:33]  * dholbach hugs DktrKranz
[16:34] <highvoltage> *hugs* #ubuntu-devel
[16:34] <DktrKranz> just not to bore people with boring simple testing packages I prepared :)
[16:34] <ScottK> dholbach: Did someone volunteer to do a session on merging with bzr?
[16:34] <highvoltage> (man I need bigger arms)
[16:34] <jelmer> dholbach: No, it's not a problem. I should be around, and I'll try to bring some other bzr devs as well.
[16:34] <dholbach> ScottK: there's a session about merging and one about bazaar
[16:34] <dholbach> jelmer: that's awesome!
[16:34] <ScottK> dholbach: Is the merging one using bzr to do it?
[16:34] <dholbach> thanks a bunch jelmer!
[16:34] <dholbach> ScottK: I don't know
[16:35] <dholbach> I'm not giving the session
[16:35] <ScottK> dholbach: OK.  I think a lot of people could use one like that (me included)
[16:36]  * sebner proves ScottK right
[16:36] <DktrKranz> mvo: some days ago, I submitted a gdebi merge proposal with some candidate fixes, did you have time to look at that?
[16:38] <mvo> DktrKranz: not yet, I was on holiday, I have a look now. I wonder why I have not goten a mail from LP about it :/
[16:38] <dholbach> kirkland: swap which session with jcastro and me? if you mean wed 19 utc, I have to decline I'll be at a french course at the time :)
[16:39] <DktrKranz> thanks
[16:39] <mvo> thank you!
[16:44] <ebroder> Ugh...I should get a lintian backport so that Karmic stops yelling at me about putting lucid in changelogs
[16:45] <kees> cjwatson: cool; I just read your changelog and noted the bzr location.
[16:45] <jdong> yes jdong, smart move, let's just restart openssh over ssh, that'll work.
[16:46] <Keybuk> it should work
[16:46] <jdong> not on FreeBSD
[16:46] <jdong> if Linux is smarter than that, then A+ :)
[16:47] <jdong> right now I'm just staring at the stopping sshd message that taunts me
[16:47] <cwillu_at_work> jdong, well, it'll still restart your session, but it shouldn't crap out preventing it from starting back up
[16:47] <kees> cjwatson: btw, what do you think of debian bug 562048 as a solution to the stack of bugs that are merged to debian bug 139505 ?
[16:47] <ebroder> Restarting ssh over ssh has worked for as long as I've been using Linux, modulo other issues
[16:47] <geser> kees: Hi, if you want to get exim4 off your merge list: bug #501657
[16:48] <ebroder> Including not breaking your current ssh session - the old sshd sticks around for as long as it has sessions open
[16:48] <kees> geser: go for it!  :)
[16:48] <jdong> hmm shockingly it is accepting new SSH requests
[16:48] <jdong> ooh :)
[16:48] <geser> kees: I need a sponsor for it
[16:48] <cwillu_at_work> jdong, "shockingly" as in "somebody sane wrote this"?
[16:48] <jdong> but somehow my existing session died
[16:48] <jdong> cwillu_at_work: something like that :)
[16:48] <jdong> I did change the binding address for the daemon
[16:48] <cwillu_at_work> jdong, it killed sshd and restarted, what did you expect would happen? :p
[16:48] <cjwatson> kees: TBH I hadn't got round to thinking about it yet - 5.2p1 and the bzr import was a *huge* pile of stuff to swallow at once, and all I really did was polish off a bunch of easy/non-controversial stuff on top of that
[16:49] <jdong> cwillu_at_work: I expected SIGHUP on the lost controlling terminal to cause the rc script to stop executing
[16:49] <cjwatson> sshd forks when you open a new session, and the child sshds are the ones that keep the sessions going
[16:49] <cjwatson> they don't need the parent to still be alive
[16:49] <kees> cjwatson: ok, sure.  I'm only asking after it because it's one of the workitems for the security team.  ;)
[16:50] <cjwatson> kees: the main thing that stood out at first glance was that I wondered if the configuration option name should be explicitly Debian-specific
[16:50] <cjwatson> i.e. prefixed with the string "Debian"
[16:51] <kees> cjwatson: right, we'd talked about it a bit at some UDS or sprint a while back and you'd mentioned something similar.  I figured I'd go for generic first, and work the patch from there.
[16:51] <kees> I don't care what it's called.  :)
[16:51] <kees> DebianVersion off    or something
[16:51] <kees> geser: I'd be happy to sponsor
[16:54] <mathiaz> cjwatson: hi!
[16:54] <cjwatson> kees: ok, at any rate it's near the top of my list for openssh
[16:54] <mathiaz> cjwatson: re  lilo in main
[16:54] <mathiaz> cjwatson: you suggested to drop it from the -server iso
[16:54] <mathiaz> cjwatson: I see that lilo is also in ship
[16:55] <mathiaz> cjwatson: should it be dropped from there as well (and then seeded somewhere else to keep it in main)?
[16:55] <kees> cjwatson: cool; no real rush from me -- I was just fishing for a relative ETA.  thanks for taking the hardening-includes changes, btw.  what did you think of that approach?
[16:55] <cjwatson> mathiaz: yeah
[16:55] <cjwatson> kees: it seemed ok, although I imagine backporters will hate me
[16:56] <kees> hah
[16:56] <mathiaz> cjwatson: the comment in ship say: # MattZimmerman wants this for server admins; needed for LVM installs
[16:56] <mathiaz> cjwatson: I guess that LVM installs don't require lilo anymore?
[16:58] <cjwatson> mathiaz: correct
[16:59] <mathiaz> cjwatson: ok - so I'll move lilo to the supported seed
[17:00] <cjwatson> mathiaz: I think maybe supported-installer-common
[17:00] <mathiaz> cjwatson: ok
[17:04]  * soren calls it a day
[17:10] <free> mvo: hi, and happy new year :)
[17:11] <mvo> hey free! happy new year
[17:11] <free> mvo: hey!
[17:11] <free> mvo: quick question
[17:11] <free> mvo: is there a way to run the do-release-upgrade script and have third-party-repos kept and not commented out?
[17:12] <mvo> free: yes, give me a sec
[17:12] <free> mvo: I think the RELEASE_UPRADER_ALLOW_THIRD_PARTY env var didn't work with do-release-upgrade, but I might have overlooked something
[17:12] <free> mvo: thanks
[17:12] <ebroder> free, mvo: Ooh, ooh - I know this one. Drop a .conf into /etc/update-manager/release-upgrades.d with "[Sources]\nAllowThirdParty=yes"
[17:13] <free> ebroder: sounds awesome, mvo you confirm? ^^^
[17:13] <mvo> free: yeah, that will work
[17:13] <free> mvo, ebroder: cool, thanks!
[17:13] <mvo> free: the env var should work too, but sudo will clean it
[17:14] <mvo> free: sudo cleans every env var it does not know about and has in its whitelist
[17:14] <free> mvo: yeah
[17:15] <mvo> free: I need to leave for dinner now, but I will read scrollback
[17:15] <free> mvo: it's fine, have a nice one!
[17:15]  * mvo waves
[17:16] <mvo> thanks ebroder btw :)
[17:39] <free> mvo: it looks that even the config doesn't work as well, so probably it's because I'm trying it on intrepid, it looks that the allow-third-party feature is newer
[17:39] <ebroder> free: No, that feature worked for Intrepid -> Jaunty upgrades
[17:39] <free> ebroder: weird
[17:41] <ebroder> free: Are you sure you dropped in a file with a .conf extension?
[17:41] <ebroder> Oh! Sorry - it's a .cfg extension
[17:41] <free> ebroder: oh
[17:42] <ebroder> (I'm not entirely sure if that actually matters, but it is what my configuration has)
[17:42] <free> ebroder: I just checked the source of update-manager, and the feature is present from jaunty onwards, so I guess intrepid->jaunty should work, because the tool from jaunty gets downloaded
[17:45] <free> ebroder: .cfg made the trick :) thanks!
[17:45] <free> ebroder: I wonder if there is way to achiave the same on dapper and hardy
[17:46] <ebroder> free: I don't have any way. Although I bet it'll work for Hardy -> Lucid upgrades
[17:46] <free> ebroder: yeah, that would do it
 can anyone tell me how to find out whether LaserJock has upload permission to qcad?
 I know he doesn't have either component upload rights or package upload rights for it
 I'm not sure how to determine package set rights
[18:38] <pitti> mvo: I noticed a work item "create static shell package" -- what's wrong with bash-static?
[18:38] <pitti> (I'm just curious)
[18:43] <cjwatson> james_w`: lp:ubuntu-archive-tools, ./edit_acl.py -p <launchpad id> query
[18:43] <james_w`> thanks cjwatson
[18:52] <cr3> is there a quick way to determine when any packages have last been installed? I don't need to know for specific packages, just any package, so perhaps there's a file timestamp I could look at
[18:52] <cjwatson> cr3: /var/log/dpkg.log
[18:52] <cr3> cjwatson: thanks!
[18:55] <ebroder> Ugh. I was hoping to finish clearing out the u-u-s queue, but this last package is horrendously abandoned by upstream
[18:55] <cjwatson> ArneGoetje: are you aware of the problem at the end of (e.g.) http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/edubuntu-dvd/20100104/livecd-20100104-i386.out? looks like language-support-zh-han[st] are outdated
[18:59] <geser> james_w`: do you know if opening a merge proposal is enough to get something sponsored or should a matching bug be opened too? (I don't know if the sponsor teams also look at their pending reviews)
[19:00] <james_w`> geser: the LP API isn't complete enough yet for us to put the merge proposals on dholbach's overview page, so it's easy to
[19:00] <james_w`> miss them. Opening a bug could be good in that case.
[19:01] <NCommander> cjwatson, ping, if you have a moment, can you help me look at the crontab on antimony? ports/daily doesn't seem to be properly run (and the log http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/ports_daily-20100104.log doesn't have anything useful in it)
[19:02] <geser> james_w`: thanks, will open matching bugs and update my merge proposals (so they don't get lost and other don't repeat the work as they didn't look at open merge proposals just only bugs)
[19:04] <danage> fta: you're maintainer of the ubuntu songbird ppa - can i kindly request your intervention? the svn hasn't built for four weeks. or maybe you could put the 1.4.2 final?
[19:07] <cjwatson> NCommander: debugging
[19:07] <kees> what does "(delayed)" mean in the emails to -changes ?
[19:07] <kees> e.g. https://lists.ubuntu.com/archives/hardy-changes/2010-January/012360.html
[19:12] <cjwatson> NCommander: fixed and rebuilding; it was trying to build lpia and getting confused that it wasn't there any more, and the error handling sucked
[19:12] <fta> danage, i gave up on maintaining it, not enough upstream cooperation, and almost no luck to get it into the archives.
[19:14] <fta> danage, i passed the hand to micahg, but he's been busy with other stuff, and the package is unbuildable since upstream landed a patch that needs a private copy of sqlite
[19:15] <fta> danage, it's fixable with some work, but i'm busy myself with work/life/other projects :P
[19:15] <micahg> danage: I plan on looking at that after I finish with TB3
[19:17] <NCommander> cjwatson, thanks
[19:28] <ebroder> Can I configure dput such that `dput ppa:foo/bar` works, but `dput ppa` defaults to my PPA?
[19:29] <danage> fta: micahg: thanks for your answers. i keep wondering why the songbird people don't maintain their own repository for ubuntu, like a lot of other projects do (ex. pidgin, virtualbox). it's almost as if they don't _want_ to get their product out of the door...
[19:37] <ebroder> Ugh. Somebody just uploaded openoffice or something to their PPA, didn't they. *sigh*
[19:43] <ebroder> Whoo! u-u-s queue is empty!
[19:48] <kitallis> does ubuntu plan on partcipating for GSoC'10?
[19:48] <ebroder> Is there anybody that should know that doesn't know that one of the powerpc buildds is hilariously unhappy? <https://launchpad.net/ubuntu/+source/mypasswordsafe/0.0.20061216-0ubuntu1/+build/1427243>
[19:49] <kitallis> that's because iirc, that backed out last time.
[19:49] <kitallis> s/that/they
[19:51] <mvo> pitti: nothing, its probably the one that is going to be used :)
[19:51] <mvo> pitti: the item is just misleading
[20:07] <kitallis> does notify-osd depend on libnotify?
[20:33] <deviad> May I ask for help in here about jackd and qjacktcl. Someone wrote a guide in the official ubunt wiki website but I can't get it to work. The author even forgot to say that a real time kernel was needed.
[20:33] <ScottK> deviad: You''re probably better off to ask in #ubuntu-studio
[20:34] <deviad> OK, thx
[20:39] <deviad> ScottK, I'm getting no answer in ubuntustudio. :\
[20:40] <deviad> it's kind of a quiet channel
[20:41] <ScottK> That's where the experts would mostly likely be found and user support is off topic here.
[20:46] <bdrung> james_w`: a fakesync are done by replacing only the source file or should it be stated somewhere?
[20:51] <james_w`> bdrung: grab the debian package, dch -i and state that you are doing a fake-sync, replace the .orig.tar.gz with the Ubuntu one and then upload the built source package
[22:01] <highvoltage> fp
[22:14] <james_w> "not ubuntu: debian"
[22:15] <james_w> thanks, that's a very cutting error message