[00:14] evand === sjoerd_ is now known as sjoerd [02:38] seagate took their firmware fix offline to fix it [02:38] seagate doesn't inspire confidence with not even being able to make their fix work, segfaults on trying to flash [03:40] So when in the development cycle do we make update-manager's -d flag work? [03:41] Should be working now; that's how I updated, pre alpha-1. [03:42] raof: Well, when I updated pre-alpha 1, I went the update sources.list dist-upgrade approach. Now, I just did a fresh install of intrepid the other day. But update-manager -d doesn't show anything [03:43] nhandler: it's sudo update-manager -c -d [03:43] -c tells it to check for a distro upgrade, -d tells it to use a development one [03:43] You could try adding a -p, to update using the update-manager from -proposed. I'm not sure if there's one there yet. [03:43] yeah, I always try to remember to do sudo update-manager -c -d -p [03:43] usually forget the -p though :P [03:46] No luck bluesmoke. It still says I am up-to-date [03:47] This is interesting. In the terminal, it says "current dist not found in meta-release file [04:36] * calc understands a bit about this pulseaudio/mixer mess esp after reading all Realtek codecs are considered "buggy" :-\ [04:37] calc: where did you read about the realtek stuff? [04:40] the Gnome 2.26 module inclusion discussion heats up thread on desktop-devel-list@gnome.org [04:40] ah ok [04:40] there is a link to a list of drivers that are broken wrt PA support [04:40] hrm interesting. [04:40] and on that list is all snd-hda-intel realtek codecs [04:40] so not every realtek codec but most of the modern ones anyway [04:40] interesting, since realtek is one of the most popular., [04:41] and if i read the page right all intel ac97 is broken as well [04:41] * TheMuso wonders whether they are broken in a hardware sense or software sense. [04:41] driver sense afaict [04:41] Oh great. [04:41] it seems they might need things like jack sensing support added (?)' [04:41] apparently thats a new feature in alsa [04:41] * calc has no idea about that stuff [04:42] Yeah it is a new feature, jaunty won't likely have it. [04:42] stuff was mentioned like the fact there are separate mixers for headphones vs speakers on laptops [04:42] yeah I've seen that. [04:42] the thread is pretty long but there was some interesting stuff in it, seems to be all about PA [04:43] not on my own hardware, but I have heard of it [04:43] mine has that [04:43] * TheMuso needs to read it. [04:43] apparently the new PA stuff in 2.25 doesn't work well with it [04:43] i'm still on 8.10 on my laptop [04:43] * TheMuso gets the thread URL [04:43] i'm not surprised it probably has issues the new mixer app is so dumbed down i was surprised it could work at all [04:43] http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00251.html [04:44] yeah i have it [04:44] that isn't the beginning of it, just where i am in the thread currently [04:44] oh ok. [04:44] it sounds cool in theory but i don't know that they can dumb down alsa well enough to have it 'just work' [04:45] if they can do it sanely i will be impressed [04:46] And not forgetting different drivers for USB/other PCI cards also have different mixers. [04:46] but then gnome seems to shoot for an 80% solution and leave the other 20% to use KDE ;-) [04:46] TheMuso: I have jack sensing already [04:46] TheMuso: yea thats how i noticed it works weird with my usb headset [04:46] If I plug in headphones the speakers turn off but I can turn them back on with alsamixer [04:47] bluesmoke: Jack sensing is more than just that. [04:47] bluesmoke: It can detect what type of device is ocnnected, i.e speakers, headphones, microphone, etc. [04:47] ah [04:47] i might try upgrading to jaunty on my laptop and just deal with the breakage :) [04:47] so it would turn on digital out automatically [04:48] jaunty's kernel doesn't have that work, though [04:48] yes that is useful but not letting the user turn it off isn't particularly great [04:48] Hm. Where's bugzilla for the new volume applet? I'd like to check if some features already have bugs or not. [04:48] eg if you have your system hooked up via hdmi to a tv does it always play out that interface since its hooked up? [04:48] having good defaults with no way to override them... isn't good [04:49] and having to go into the terminal isn't a real solution [04:49] * calc should be arguing this with the PA upstream not with poor Ubuntu maintainer ;-) [04:49] calc: PA itself has no UI, its other utilities that sit on top of PA that give the UI. [04:51] TheMuso: ah well gnome-volume-control (or whatever the tray thing is) [04:51] calc: gnome-volume-manager, yeah thats GNOME stuff. [04:51] ah ok [04:51] gnome-volume-manager is utopia stuff, not sound [04:51] raof: http://tinyurl.com/g-m-bugs [04:52] sorry gnome-volume-control is what I meant [04:52] Urgh. They're thinking of removing the applet entirely, leaving us with the crazy notification icon. [04:52] * raof thinks that's 100% pure UI crack. [04:52] raof: yep and converting the old version to a notification icon as well [04:53] raof: so they act the same for fallback [04:53] * raof presumes he's not the only one who's wierded out by a volume control icon that only turns up after something has started playing. [04:54] heh [04:54] thats stupid I agree [04:54] * calc bbl [04:54] No other OS does that. [04:58] TheMuso: It's innovation then. [04:58] ScottK: if you could call it that. I'll bet KDE has more sane plans. :) [04:58] That's my impression. [04:59] although I hear 4.2 has gained a PA backend for Phonon? [04:59] well gnome is full of crack recently it seems, they broke gnome-session and didn't seem to care too much [05:00] dtchen: I don't think we're using it though. [05:01] ScottK: Riddell has talked to me about possibly enabling it at least. [05:01] ScottK: I can't remember the exact conversation, and I'd have to ask him again what he was thinking as I don't entirely remember myself. [05:01] I didn't think PA was a possible backend for Phonon. Isn't phonon a GStreamer abstraction? [05:02] I think it's meant to be more generic than that. [05:02] But you say "play me this mp3 file", right? [05:02] TheMuso: Providing it as an option is much different than here's the new default. [05:02] I mean, I know it's more than a gstreamer abstraction, but it's a *media* abstraction, not a soundserver abstraction? [05:02] ScottK: I know [05:03] * raof has tried to understand, but *still* doesn't get what phonon buys KDE. [05:03] * ScottK thought it was sound, but has tried to avoid knowing much about it. [05:04] calc: I think full on crack, that's why I'm using KDE presently after years of Gnome usage [05:07] Fun new volume control bug: have two audio devices, one set to full volume, the other one (which is actually playing audio) set to a much lower, comfortable value. [05:08] Click the "Choose output device" radio button for the 100% volume device. This results in the other, active device having its volume changed to 100%. This is awkward when said other device is my USB speakers, which are painfully loud at that volume. [05:08] * TheMuso would try KDE if there was sufficient accessibility. [05:09] raof: well, it's rather very WIP; stream migration isn't quite present [05:09] TheMuso: Feedback on what's missing would be appreciated. [05:10] dtchen: For values of "quite" equal to "at all", yes. [05:10] ScottK: Its got to do with frameworks etc. QT is not yet hooked up to the at-spi framework, and won't be till at-spi is on dbus. It will be a while yet. [05:10] ScottK: In simple terms, I can't even use a screen reader with KDE. KDE/Troltek know about this afaik but nothing can be done till other bits that will eventually e shared between gnome and KDE are done. [05:11] I see. [05:12] You would think someone would be paying for this work to happen if they really care about it [05:13] bluesmoke: What work? [05:13] porting at-spi to dbus [05:13] If Qt Software is stalled on that happening they could speed it up [05:13] bluesmoke: Its being done currently, but will take time. [05:13] bluesmoke: and accessibility is a minority thing, so there are not that many people who do care about it. [05:14] bluesmoke: And I am happy to wait. GNOME is serving me ok for now. === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair [06:13] So is there a script somewhere that's responsible for building the ubuntu release ISOs? [06:13] good morning [06:14] I've seen plenty of "customize ubuntu's live CD for your needs", but no "this is how ubuntu builds their release installers." [06:14] including the mini installers. === hyperair1 is now known as hyperair [06:15] jharr: that's debian-cd and ubuntu-cdimage [06:15] LaserJock: thx. [06:18] is ubuntu-cdimage a package somewhere? [06:18] I don't think so [06:18] jharr: look at the Launchpad projects of the same name [06:18] and look at the bzr branches they have [06:19] LaserJock: cool, thx [06:26] * lamont tries to remember how to get X to spill a config === RAOF is now known as raof === tkamppeter_ is now known as tkamppeter [07:42] Good morning [07:42] uh oh, time for bed [07:43] hi pitti [08:15] pitti, I got an answer on bug 318818, telling that an SRU consisting of a replacement of the released version by a newer upstream version needs TB approval and on the Wiki page https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is written that the package build needs integrated regression tests (like CUPS has). [08:15] Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [Medium,In progress] https://launchpad.net/bugs/318818 [08:15] tkamppeter: I just replied to that [08:31] pitt, thanks, I also replied to your comment now. [08:44] pitti: around ? [08:44] emgent: hi [08:45] hello pitti [09:12] * pitti watches the jaunty retracers behave well -- finally [09:13] * seb128 hugs pitti [09:13] pitti: how did you fix the apt error thing? [09:14] seb128: it was a bug in my "update apt cache for every retrace" commit [09:14] seb128: after apt.Cache.update() you must call apt.Cache.open() [09:14] * pitti hugs mvo [09:15] seb128: since the archive doesn't change that much for intrepid, we only saw it for jaunty [09:15] ah ok [09:18] tkamppeter: btw, the idea of pet-bug is to be bugs which are very old already and you always wanted to work on, but didn't have time for in earlier releases (due to focus on feature development); they shouldn't be used for recent bugs [09:19] tkamppeter: btw, is the cups SRU in the queue still valid, given that you recently proposed another pdftops fix in the bug? [09:32] Can somebody accept the arm binaries from the last kernel build: https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-4.11/+build/840124 [09:34] pitti: ^ [09:37] hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me [09:45] hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me [09:45] ferrariii: this is not the right chanel for such questions, please ask in #ubuntu === tkamppeter_ is now known as tkamppeter [10:26] amitk: I'm not sure to which components I should put them; had there ever been any kernel armel debs in jaunty? [10:30] pitti: not yet [10:31] cjwatson requested it [10:31] amitk: ok, I'll put them all into main then, and see what falls out later [10:31] pitti: thanks [10:32] pitti: I misread that. There were no udebs before [10:33] pitti: the debs existed as far back as -2.2 https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-2.2/+build/802941 [10:33] amitk: hm, I don't seem them on http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ [10:34] oh, ports [10:34] zul: Hey, I think you uploaded the latest squid merge? squid is uninstallable (and unupgradable) on all arches because squid-common was never rebuilt as the i386 build failed; did you have a look into this? [10:35] directhex: Not sure whether you saw my ping yesterday: I heard you're working on the C# transition which affects f-spot, beagle, tomboy in the default install; it's been some days that these prevent upgrades; is there a bug for whatever blocks progress right now? [10:36] amitk: done [10:37] lool, i don't know if there's an open bug for it. AFAIK the problem(s?) are related to the gnome# library getting changes in debian experimental which require an abi bump & rebuild [10:39] ok, bug #197762 seems to be a frequent user complain, somebody wants to look at that for jaunty? [10:39] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/197762/+text) [10:39] not sure if that's linux to blame or who should be assigned to the bug [10:39] bug #197762 [10:39] Launchpad bug 197762 in linux "file transfers on USB disk are very slow" [Undecided,Confirmed] https://launchpad.net/bugs/197762 [10:39] lool, the one who knows most about it is slomo. if i get a chance today i'll try to investigate myself since he's rarely about [10:40] the bug mostly gets frustrated users comments right now [10:40] directhex: which bug? [10:42] slomo, something surrounding your gtk# or gnome# updates (which were merged around alpha2 time) causes issues. i think it might just need a resync, build-dep change, and rebuild. but i've not had time to investigate myself [10:42] i thyink sebner was investigating, but iirc he's off to do military service [10:43] the only problem i'm aware of (that shouldn't disappear by merging the latest versions of gnome#/gtk# and uploading gnome-desktop# from NEW) is, that many packages need to be transitioned for the gnome# API change [10:43] API, not just ABI? balls [10:44] directhex: thanks [10:44] yes, there was quite some API cleanup... for example the panel applet stuff (which is not in gnome-platform but -desktop) was moved to gnome-desktop# [10:44] oh and the gnomeprint stuff too [10:45] blarg [10:45] lool, i don't know how much chance i'll get today though [10:45] slomo: So the libs were pushed, but tomboy/f-spot/banshee aren't in a shape to use them?! [10:46] lool: no idea who had the great idea to sync/merge it to ubuntu :) tomboy only needs a build-dep change but iirc f-spot/banshee need some code/build system changes [10:46] slomo: Lovely :-/ [10:46] * slangasek raises his hand [10:47] slomo: Is upstream working on porting? [10:48] getting rid of mono 1.0 is going to be a significant savings on our CDs; unfortunately I didn't learn until after merging gnome-sharp2 from experimental that the pieces weren't all there yet [10:48] lool: no idea about f-spot but for banshee i have this on my todo list ;) [10:48] to be fair to slangasek, he was only trying to help, and i don't think anyone realised what a bad idea using gnome# from experimental was (whilst we were busily recommending everything ELSE mono related from experimental was great) [10:48] i guess i should've been a bit more explicit in the changelog :) [10:49] realistic question: does this warrant an epoch? [10:49] * slangasek whimper [10:50] i don't know how much trouble the API change will cause [10:50] I'd rather not epoch in Ubuntu and not in Debian [10:50] lool, i know, but slomo's in charge of gnome# in both [10:52] well, it should be fairly easy to port all packages... it just needs someone to do it ;) [10:52] slomo: Actually banshee is installable [10:52] So it's only tomboy and f-spot for me, and tomboy is said to be trivial [10:54] yes, tomboy is just a b-d change... i'm surprised that banshee works though. libgconf2.0-cil became libgconf2.24-cil [10:54] same for libgnome2.0-cil [10:54] pitti, did you get my answers on your last messages here? Or did you reply something? I had a network interruption shorttly after that? [10:54] so i guess the old binary packages are still there or something [10:54] tkamppeter: I didn't get answers from you [10:55] So I will repost them: [10:55] I would rather try to update f-spot if upstream didn't yet than use an epoch [10:55] sorry, I thought these are the bugs I thought to be most important or put the most effort into. [10:55] slomo: I don't know whether it works, it's just installable [10:55] pitti, the fix in the pdftopdf filter which is the proposed SRU fixes a regression against Hardy and so makes the behavior of the filter workflow in the cases mentioned by the bug at least equal Hardy. The proposed fixes on pdftops and pstopdf in the last 5 or so postings are to really fix the problem of mixed-page-size documents and printing with the paper size given by the document. [10:55] lool: ok :) [10:55] well, i've to get some food now... bbl [10:56] tkamppeter: if there wasn't an explicit "LSB compat" fix, but LSB compat only broke due to the other regressions, that's fine [10:56] tkamppeter: okay, so the current upload in intrepid-proposed is not obsolete then? [10:56] pitti. yes. === azeem_ is now known as azeem [11:23] seb128: did you ever see a double-pkgstriptranslations build as in http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ? [11:24] pitti: no, just the one which got mentionned on #soyuz yesterday [11:24] I tried to replicate it locally, without success, and had a long hard stare at the code [11:24] I have NFC where it would fork [11:24] pitti: how would you notice it out of a publisher crash? [11:25] hm, good question [11:25] I don't look at build logs so closely when the build success usually [11:26] lool, directhex: for porting just keep in mind that platform stuff is now in gnome-desktop# (i.e. panel applet, gnomeprint), that all pkg-config files have a different version number now and that every removed method will have a better alternative (iirc some deprecated/obsoleted methods were removed) [11:26] seb128: well, if that was the reason for the publisher crash, then I guess it didn't happen before [11:28] * pitti spots "InterpreterPath: /target/usr/bin/perl" in a crash report and sighs -- aufs FTW [11:33] pitti: there's someone in #ubuntu-bugs with a report of a regression in Intrepid. metacity is now segfaulting on login. [11:33] pitti: so far it is hinting towards libc6 in -proposed or cups in -security [11:33] james_w: uh, we didn't update that for a while [11:34] pitti: I'm asking them to narrow it down as we speak [11:34] james_w: libc6 was updated 11 days ago for some fortify regression fixes [11:34] james_w: so he runs -proposed? [11:34] http://pastebin.com/m711f0ba5 <- stacktrace http://pastebin.com/d7369120b <- which-pkg-broke [11:34] yeah, -proposed enabled [11:34] and those two packages updated today as you can see [11:36] so downgrading libc6 or libcups2 should telll [11:37] they're currently downgrading libc6 [11:37] perhaps I should have started with cups actually [11:39] james_w: the cups security update only affected the scheduler, not the library [11:39] pitti: interesting, thanks [11:39] I'll let you know how things go, but I wanted to mention it early [11:40] james_w: thanks a heap! === hyperair1 is now known as hyperair [11:44] james_w: where is which-pkg-broke? apt-cache search doesn't catch that [11:44] pitti: debian-goodies [11:44] awesome [11:44] really useful tool [11:46] pitti: will a downgrade of libc6 require a restart for metacity to start using the new one? [11:47] james_w: yes, but I thought it previously crashed on startup? [11:47] all running programs need to be restarted for using the new libc6 [11:47] k [11:47] they have rebooted since the upgrade [11:47] but not since the downgrade [11:47] and it crashes when metacity starts, they are using an alternative WM at the moment [11:47] then it should work immediately [11:48] james_w: of course, theoretically, it could also be libcups2 now misbuilding due to new glibc, or something similarly hairy [11:48] urgh [11:48] so downgrading that too is still worthwhile testing [11:49] yup [11:50] the cause of the bug seems to be an empty gconf setting though, but that is a bit odd === hyperair1 is now known as hyperair [12:32] seb128: FYI, all bugs are retraced now, and retracer is fully on auto [12:41] pitti: excellent! === davmor2 is now known as davmor2-lunch [13:18] superm1, hey you about? [13:20] pitti: panic off it seems. Corrupted gconf defaults were the cause. Why that happened is not clear, but I can't see a link to the updates. [13:21] shameless plug: http://ubuntuforums.org/showthread.php?p=6584115 [13:26] directhex: no repository for jaunty? [13:27] tseliot1, no. do you want one? it's the same source package for any dist with cairo >= 1.8 [13:27] directhex: sorry, I had missed the line about Jaunty in your post [13:28] tseliot1, it's not in jaunty yet due to NEW slowness (when it's in exp i'll requestsync) [13:28] tseliot1, but if you like, i can just quickly upload a jaunty version to my ppa [13:28] directhex: please do it :-) [13:29] uploaded. waiting for build. [13:29] directhex: thanks a lot [13:31] build started [13:33] great [13:35] james_w: we get some bugs every now and then where the gconf settings are not correctly set for some softwares, there is a bug open about this bug gconf doesn't log enough to give a real clue about when and how that's happening, and usually doing a new schemas registration works correctly [13:35] it's a 9 minute build. [13:35] seb128: sounds about right [13:43] if I suspect a license problem with a package in Ubuntu, what should I do? [13:45] that is, is reporting it as a public bug the right way to do it? [13:46] tseliot1, build, pending the usual LP delays creating Packages.gz [13:46] s/build/built/ [13:47] directhex: thanks again [13:47] tseliot1, no problem - i'm pleased as anything to avoid a disappointing miss for moon as happened with the olympics === LucidFox_ is now known as LucidFox [13:52] Hi [13:52] Hi, I'm testing beta of bibble5. Bibble5 is not compiled for 64bits, so I'v installed ia32 and bibble5 is ok. In the last beta libuuid1 is needed, but libuuid1 installed is for x86-64 architecture. [13:52] I can not find an elegant way to install the 32bit version of this lib [13:53] I'v manually downloaded and manually extracted lib in /lib32 but it's dirty [13:53] is there a way to simplify this ? [13:53] No, there is no elegant way to install 32bit libs if they are not specifically packaged [13:54] maxb, is there a possibility to use a 64lib in a 32bit emulation ? [13:54] no [13:54] wow that's problematic [13:54] dholbach: does your nag script take into account bugs that were tagged for sponsoring, but for which the tag was removed and the sponsor subscribed themselves to chase for more information? :p [13:54] maxb, thanks [13:59] Keybuk: it counts uploads and bug traffic on the sponsoring mailing lists [14:00] Keybuk: which tag are you using there? === davmor2-lunch is now known as davmor2 [14:47] I remember "deb-make" could make a debian package out of a normal source. What replaced it? [14:47] I want to build a package for the newest git sources [14:48] there's no way to create a package without doing some actual packaging work which doesn't suck hard [14:48] you MIGHT be thinking of dh_make (which creates a skeleton packaging setup) [14:48] you might be thinking of checkinstall (which takes some source & jumps all over your /usr [14:49] dh_make yeah [14:53] pitti: hi! regarding my ufw SRU. A bug just came in today that I would like to fix in that SRU. would you mind if I revved the version with the fix and updated the bug, or would it be better to hold off and do another SRU later? [14:53] jdstrand: is it a bug in the changes you made to that SRU, or an independent one? [14:54] jdstrand: usually it's better to shove through one SRU completely, then start with the next round [14:54] and in the mean time, stash changes into bzr [14:54] pitti: it is a completely new, unique bug [14:54] pitti: independent of that SRU [14:55] jdstrand: second, the new bug should match the SRU criteria (some in the previous one really were borderline, like the removal of rc0.d symlink) [14:55] pitti: oh, I thought we discussed that one on IRC... [14:56] pitti: but I don't think you'll have a problem with me fixing this new one [14:56] :) [14:56] jdstrand: yes, and I approved it :) but as I said, I think it's borderline [14:56] bug #319226 [14:56] Launchpad bug 319226 in ufw "ufw fails if /etc under subversion revision control" [Undecided,In progress] https://launchpad.net/bugs/319226 [14:57] pitti: cool. btw, on a totally unrelated note-- while I always had procmail recipes for my ubuntu email, your talk in UDS on how you have your four classes of email *totally* helped me out [14:57] jdstrand: depends on how it fails, I guess [14:57] jdstrand: glad to hear it :) [14:58] pitti: I'm actually able to see things as they come in and not be completely buried [14:58] pitti: thanks! :) [14:58] jdstrand: my feeling as well, it allows me to keep up with the important bits without getting swamped [14:59] pitti: re bug> it exits with error about finding a hidden file in the ufw directory. It is a superfluous check, cause I don't read in any hidden files anyway... [15:00] pitti: but I'll just do another SRU, as you suggested [15:00] jdstrand: it doesn't sound very urgent, so I'd recommend waiting until this one is in -updates [15:00] pitti: np. thanks for your feedback :) [15:00] jdstrand: (people will either have noticed by now and found a workaround, or are using a completely different solution by now) [15:02] * jdstrand nods [15:16] tseliot1, does that package work for you? i posted a link to a SL game which should be an adequate test [15:17] directhex: it didn't but I'm running firefox 3.1. I had to install the firefox extension manually [15:18] tseliot1, it ought to work on 3.1, the deps were fiddled especially [15:18] directhex: I doubt it's specific to your package though. The same happened to me with some other plugins before [15:19] tseliot1, is this ff3.1 from the mozillateam ppa? [15:19] directhex: no, I extracted the tarball from mozilla's website [15:19] tseliot1, aha. do you want to get the package working, or do you prefer to use the .xpi? [15:20] oooh, cjwatson is back :) [15:20] tseliot1, symlink /usr/lib/moon/plugin/libmoonloader.so in your tarball firerfox's plugins folder. it doesn't check /usr/lib/xulrunner-addons, which is an ubuntuism [15:20] * ogra gently points cjwatson to the ubuntu-devel ML discussion about debootstrap [15:21] directhex: ah, ok thanks [15:21] tseliot1, applies generally for plugin packages [15:21] yes, I picked that up [15:24] ogra: ok [15:24] ha! i knew i'd get Keybuk intrested in the thread if i mention upstart somewhere ... that magically summons him *g* [15:26] ogra: err, you mentioned Upstart? [15:26] indeed i did [15:26] I didn't notice that [15:26] I jumped into the thread because cjwatson and I were just talking about debootstrap and making devices the other day [15:26] ah [15:27] ogra: actually, the only thing I wanted to say has already been said [15:27] Keybuk, init does if it cant write to /dev/console, so indeed i mentioned upstart :) [15:27] ogra: i.e. it's already in backports (and pitti also said that SRUs for stable releases would be fine, which I agree with) [15:28] cjwatson, backports ? [15:28] yes, backports [15:28] i'm talking about jaunty there [15:28] ogra: init does what? [15:28] * ogra should probabaly have mentioned that [15:28] well, I said that *backports* are fine, and that I'd rather not stuff it into SRUs [15:28] ogra: are we looking at different threads? I'm looking at Subject: piuparts, debootstrap and newer releases [15:28] cjwatson, "missing /dev/console in debootstrap --foreign, a bug or not ?" [15:29] pitti: err, right, sorry, I oversimplified. (You did say that it would be bearable but you'd rather not.) [15:29] ogra: oh, I haven't pulled down all my mail yet. I'll get to it [15:29] ogra: looking at debootstrap's code, I can't see why /dev/console would be missing [15:29] well, either way; if we need them for something, let's do them [15:29] pitti: as people said, they're already in backports [15:29] Keybuk, "attempting to kill init" involves upstart (in some remote way :) ) [15:29] oh, wait, yes I can [15:29] ogra: sure, you can't start any init if you don't have at least /dev/console or /dev/null [15:29] I've been sticking debootstrap into backports myself for years anyway, since I know the backport is trivial :) [15:29] that's not Upstart specific [15:30] Keybuk, thats what my mail said :) [15:30] cjwatson: so it turns out that "console" is not made by MAKEDEV std [15:30] Keybuk: so add consoleonly to that? [15:30] Keybuk, it also said that you could (indeed thats very ugly) make init call mknod first :) [15:30] consoleonly makes other things too [15:31] ogra: no I can't, the filesystem is read-only [15:31] consoleonly makes one other device, namely tty0 [15:31] pitti: you uploaded calibre? it includes code under the four clause BSD which would be incompatible with the GPLed code [15:31] oh, right [15:31] cjwatson: oh, sorry, was reading console) [15:31] which doesn't seem like too much of an imposition [15:31] . o O { man, makedev doesn't do anywhere near anything similar to udev } [15:31] Riddell: oh argh, forgot about that [15:32] Keybuk: btw, mind if I upload udev? I fixed its udeb earlier today [15:32] cjwatson: how did you fix it? [15:32] added lib/udev/devices/{net,pts,shm} to udev-udeb.dirs [15:32] udev.installer-startup got kind of upset when cp /lib/udev/devices/* failed [15:32] Riddell: it's used in a plugin in calibre-bin (msdes.so) [15:33] heh, sure [15:33] Riddell: what was that problem again, the advertising clause/ [15:33] ? [15:34] pitti: yes (well potential problem still looking at it) [15:34] cjwatson: I haven't thought about the groups issue yet [15:34] Keybuk: that's OK, it's cosmetic rather than important [15:35] we may end up just growing udevd --no-groups or something [15:35] aye, that's the kind of thing I was thinking about [15:36] I couldn't imagine you wanting to tweezer apart all the rules again just for the udeb [15:37] Hmm. All this talk about Wine is interesting. I wonder if we're every going to get it to integrate so it acts like eral windows with regards to having per-machine stuff. [15:38] Keybuk: so what do I need to do with bzr-builddeb to make this build properly? [15:38] cjwatson: you can't ;) [15:38] pitti: so it's a GPL 3 python app loading and using an incompatible licence plugin [15:38] I don't think I remember the conclusion of your discussion with James [15:38] Keybuk: ah. what's the magic dpkg-buildpackage argument then? :-) [15:39] cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.git-ignore|test) [15:39] iirc [15:39] Riddell: merely shipping the source is okay, right? so if I just disabled building and shipping the plugin it should be okay, until we sort this out with upstream? [15:39] pitti: yes that's fine [15:39] err [15:39] cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.gitignore|test) [15:40] pitti: I'll reject for now then [15:40] Riddell: okay [15:40] Keybuk: yeah, that does the right thing, thanks [15:41] http://www.pennergame.de/change_please/6086543/ [15:43] Ubuntu Developer Week - Day 2 just about to start in 17m in #ubuntu-classroom :) [15:43] * pitti is still creating his talk... [15:43] yay :) [15:44] it was a really nice start yesterday [15:44] pitti: you luckily still have a bit of time left :) [15:44] Jarlen: yeah, it was fantastic :) [15:45] well, depends on how you define fantastic [15:45] in my view it was FANTASTIC :) [15:45] if you rule out that I didn't make 50% of my homework because I was reading Ubuntu developer stuff, then yah, it was fantastic :P [15:45] * dholbach hugs Jarlen === asac_ is now known as asac [15:46] from an ubuntu point of view, I really enjoyed it! [15:47] is there ever any events like this from a community point of view, instead of the developer POV? [15:47] Jarlen: there's an Ubuntu Open Week two times a year too [15:47] other sessions are less regular [15:48] pitti: do you know what's to be done with the language packs waiting in hardy-proposed New? === dholbach changed the topic of #ubuntu-devel to: Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | this week: https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:48] dholbach: ah, yeah, the open week looks a bit more diverse [15:48] Riddell: they should just be rejected IMHO, we haven't introduced new langauges into stables so far [15:48] Jarlen: less focussed on development [15:49]