[00:05] slangasek: BTW alsa-plugins/libasound2-plugins also needs to be pulled from hardy-proposed, as when users install plugins, things will break as it needs 1.0.16 or later of alsa-lib. === asac_ is now known as asac [00:08] weird, I don't think the uncommented pci id patch would actually do what it looks like it wants to do [00:09] + awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/100B/' > nsc.ids [00:09] + awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/1078/' >> nsc.ids [00:09] ohhh I get it [00:11] TheMuso: oh, I didn't realize that we had an alsa-plugins upload in there... I'll yank it out === Amaranth_ is now known as Amaranth [00:12] slangasek: ok new ubuntu0.1 uploaded with just that line uncommented [00:13] (I finally fully understand how the patch works) [00:14] ok :) === pwnguin is now known as jldugger === jldugger is now known as pwnguin === Amaranth_ is now known as Amaranth [00:46] calc: ok libx11 time [01:00] calc, ok I've emailed ben [01:16] bryce: in your latest upload, doesn't 02_fix_geode_pciid.patch need to be refreshed to reflect your changes to 01_gen_pci_ids.diff? [01:17] bryce: it looks to me like the Makefile.am and Makefile.in are out of sync, with the Makefile.in being incorrect [01:17] (i.e., still commenting out the cyrix line) [01:22] slangasek: hrm, ok I'll take a look [01:36] ahh, no one hooked up the patch system in -nsc. [01:36] *boggle* ok [01:37] ah, maybe that's part of what the massive xsfbs patch that got pulled in was about? [01:37] surprisingly no; despite all that, debian didn't set up the patch system either [01:38] which is why I didn't catch it when reviewing the debdiffs... didn't even think to look [01:38] heh [01:38] but it became obvious when I went looking for why none of my prior uploads had failed to build [01:39] ahhhh and it explains why the sync had gone through when that patch clearly couldn't apply. === jeff__ is now known as SEJeff_home [03:16] calc: My apologies for not taking care of it earlier: I'm reading the platform minutes, and discover that you were assigning taking a look at openoffice.org-en-au: it's a sync, and I've filed the sync request. [03:38] someone can stop Michael Garrido planet.u.c climbing ? [03:39] emgent: ? [03:39] bryce: I wasn't actually at the platform meeting. My 'shot' at selinux packages will be to file sync requests. [03:40] n8k99: [03:40] nxvl: Him update the date of his post to stay in the first news planet.uc pathetic. [03:41] my feedrss reader see it ... [03:42] emgent: mm i don't think he did, it must be a random error [03:43] emgent? [03:43] nxvl: impossible.. him use *.wordpress.com and more other planet user use it. but only him have this "problem" [03:44] n8k99: sorry, wrong tab :) [03:44] oh haha [03:44] emgent: i have noticed it this time, but just once [03:44] or have you noticed it many times? [03:45] many times. [03:45] mmm [03:45] strange [03:45] i have just noted on his last post [03:45] i will talk to him [03:45] ok thanks [03:46] emgent: you can talk to him, he's connected [03:46] liferea dont log all, update the date hour post, argh. [03:46] emgent: xander21c in freenode [03:47] ok nxvl i will do. Thanks [03:49] emgent: i have just talked to him [03:49] dont reply to me now :\ [03:49] emgent: he said he's going to check the settings @ wordpres [03:49] ok cool. [03:49] maybe he's not registred [03:50] ? [03:50] on freenode you can't reply to private messages if you are not registred and loged in [03:50] oh ok [04:06] nxvl: I think new services removed that limitation, actually. [04:07] 'SET UNFILTERED has been removed and the global block on messages from users that have not identified to NickServ has been removed.' [04:07] wgrant: are you sure? [04:07] http://blog.freenode.net/?p=80 [04:09] \o/ [04:43] wow! my wifi has a light now! [04:43] any music sounds like someone's torturing a cat, though [04:44] haha [04:44] * Hobbsee wonders why the light keeps flashing every once in a while [04:44] * ajmitch calls the SPCA around to Hobbsee's place [04:44] ajmitch: Yours isn't royal? [04:45] Hobbsee: Is there meant to be a 2.6.26 LUM? [04:45] it may be officially, but it's usually called the SPCA [04:45] My audio sounds awful as well, and headphones don't mute speakers. [04:45] Hobbsee: The music people heard about your myspace page and thought you'd like it. [04:45] We have the RSPCA here. [04:45] ScottK: That's gone now :( [04:45] wgrant: apparently not? [04:46] But the legend lives on. [04:46] ScottK: hahhahahahha [04:46] ScottK: i don't suppose you know if facebook will let you embed html in it, to change the background? :P [04:46] * StevenK gets that flashy swirly thing happening to his retinas again [04:47] it's a *lovely* background. [04:53] * ajmitch twitches [04:53] don't make me run for the medication again [05:00] i would have thought you'd learned by now to keep it with you. [05:02] argh. what's the pcspkr module called now, in 2.6.26? [05:02] Hobbsee: snd_pcsp [05:02] I encountered the same problem. [05:03] wgrant: and how do i force it not to be in use? [05:04] Hobbsee: By blacklisting and rebooting, or removing the whole stack of audio modules, I guess. [05:04] Hobbsee: You can rmmod it, blacklist it, or pass module arguments to cause it to load later in the sequence. [05:04] I gave up on 2.6.26 because I presumed that my audio depended on LUM. [05:05] Which seems to no longer be around. [05:05] persia: rmmod gives the same thing. [05:05] * Hobbsee updates the blacklist though, for the next reboot [05:05] was hoping to fix it without a reboot [05:05] Hobbsee: WOrk out what depends on it. [05:05] lsmod should help. [05:06] Hobbsee: You can't rmmod it? Please pastebin your lsmod [05:06] sarah@saturn:~% lsmod | grep pcsp 2:06PM [05:06] snd_pcsp 17312 1 [05:06] Hobbsee: Also, check /proc/asound/cards to make sure you have another working device present. [05:07] snd_pcm 82180 3 snd_pcsp,snd_hda_intel,snd_pcm_oss [05:07] snd 61988 16 snd_pcsp,snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device [05:07] yeah, i do. [05:07] wgrant: thanks, that's the command i wanted, but had forgotten. [05:07] persia: is that enough, or do you want the entire thing? [05:08] That says nothing depends on snd_pcsp. You get am error from rmmod? [05:08] s/am/an/ [05:08] sarah@saturn:~% sudo rmmod snd_pcsp 2:08PM [05:08] ERROR: Module snd_pcsp is in use [05:08] yup [05:08] * ajmitch blames userspace [05:09] Hobbsee: OK. lsof | grep /dev/snd to find the offending process. [05:09] Convince that process to use a different device. [05:09] rmmod it. [05:09] persia: no offending process. go figure. [05:09] * ajmitch wonders if it'll be pulseaudio hogging it [05:10] Likely. [05:11] * Hobbsee puts it down to intrepid weirdness. [05:11] Hobbsee: Have you run the ALSA set-default macro since you changed kernels? [05:14] persia: no? [05:14] * Hobbsee has no idea what that even is - never needed it before [05:14] those sound applets that live in panels are good candidates for killing if you cant rmmod [05:14] Hobbsee: That would do it. You likely altered the indecies for your cards as a result of the PC speaking getting ALSA support and loading first. [05:15] superm1: don't have one of them, but good idea. [05:15] persia: ah, right. which is why the sound sounds strange. [05:16] Hobbsee: Check your card names in /proc/asound/cards, then run `asoundconf set-default-card $(NAME)` [05:17] Actually, `asoundconf list` might give you a better list of names than /proc/asound/cards [05:18] persia: that's fixed it, thanks. although i still can't rmmod the other, for some reason. [05:18] With that done, you oughtn't need to worry about rmmod or blacklisting. [05:18] * Hobbsee had forgotten just how crap the default speakers sound. [05:19] OOps! [05:26] Hrm grub seems to fail on the intrepid alternate i386 daily. [06:01] TheMuso: fail how? [06:23] good morning [06:24] too [06:25] slangasek: Something to do with the package not being able to be installed... [06:25] ok [06:25] slangasek: "The package 'grub' cannot be installed into /target or some such. [06:27] slangasek: did you get chance to check Bug #225005? [06:27] Launchpad bug 225005 in gnupg "Please merge gnupg 1.4.6-2.1 from debian sid" [Undecided,Confirmed] https://launchpad.net/bugs/225005 [06:28] morning dholbach [06:28] nxvl: no, sorry; that will have to be tomorrow for me [06:28] hi Hobbsee [06:28] slangasek: ok, because i merged it before intrepid were open and we are 1 day away from DIF [06:29] slangasek: but, no problem, take a look when you have some time :D [06:29] TheMuso: mm, is there any more specific error in the log? [06:29] I see there are new versions of grub in intrepid that aren't in the bzr repo, doh [06:42] TheMuso: I don't see anything wrong with the latest grub diff in intrepid; an exact error message from the log would be helpful === dholbach_ is now known as dholbach [06:44] slangasek: Ok I'll see what I can dig up. [06:45] slangasek: Ok not much there that says why, I may have to run again with the verbocity cranked up somewhat. [06:46] I think that any maintainer script errors should be registered in the log, somewhere? [06:46] but I'm off to bed now, so not much help I'm afraid [06:46] slangasek: no problem, will keep digging. [07:06] Good mornin [07:13] pitti: hello! [07:32] Is there a list somewhere of the packages installed by default in the various *buntu? [07:32] I've been going by the popularity contest, but that's not broken down by variant. [07:35] yes, there is [07:35] i just don;t remember where [07:36] andrew_sayers: It's a close match to the dependencies of the various -meta packages. [07:36] (and the recursive dependencies thereof) [07:38] persia: you mean there's a xubuntu-meta package out there? [07:39] persia: never mind, I get it :) [07:39] andrew_sayers: Yep. xubuntu-desktop is likely the one that would provide the interesting list. [07:39] I see - so basically xubuntu == xubuntu-desktop + dependencies? [07:42] andrew_sayers: and + ubuntu-base [07:43] Thanks, that's all I need to know :) [07:43] s/base/minimal [07:45] nxvl: Is it? I thought when seeds had dependencies those were expressed in the resulting metapackages. === thekorn_ is now known as thekorn === RAOF_ is now known as RAOF === Amaranth_ is now known as Amaranth [08:37] Hello === halex_ is now known as halex [08:45] slangasek: were we missing anything to get bryce's updated -nsc package in? I wanted to test this, but it doesn't show up in Sources either, yet. === tkamppeter_ is now known as tkamppeter [09:04] mvo: hey [09:05] mvo: do you plan to reply to this mailing thread about main packages having recommends in universe? [09:06] seb128: can do, I'm (even more) behind my mail than usually because I finally switched to a new provider and that is causing a bit of transition pain [09:07] mvo: alright, I was just wondering because you probably know how the packaging tools handle the situation and what are the plan for that [09:07] dunno if that has been discussed before though [09:08] I need to read the thread but I see no problems with recommending on universe. people with universe enabled get the packages, people without don't [09:08] my understanding is that CD are already at the limit so we will not have changes there [09:08] and then recommends will be installed in functions of the sources available [09:08] mvo: right, the thread is "should we promote all recommends to main or not" basically [09:09] * mvo nods [09:09] I guess its a matter of policy, but I don't see a reason why we should [09:09] we should check them out and decide on a case-by-case basis and maybe demote some to suggests [09:10] I think it will cause QA confusion to have different sets of packages installed for people who install off the livecd (with package copy) and the alternate CD (with possible network access). [09:10] did someone do a analysis on this? i.e. how many packages have those and what recommends those are? [09:10] persia: oh, I agree on this of course, we should make sure this is consistent [09:10] I don't think a full analysis has been done, and certainly not widely published. [09:11] * mvo was thinking about the general case [09:11] mvo: In general case, I think you7re right. I'm mostly worried about the impact on the installation case. [09:11] persia: ok, I will put it on my todo for today and check the scope on this [09:12] mvo: Thanks :) [09:15] mvo: btw [09:15] mvo: I have to say I think different behaviour depending on apt configuration will be very confusing. I had been planning to make germinate treat Recommends like Depends so that we get flagged to promote things from universe that are Recommended. [09:15] mvo: sudo apt-get install --fix-policy --install-recommends [09:15] mvo: which doesn't of course mean promoting everything en masse, it means a case-by-case review [09:15] 17 upgraded, 173 newly installed, 3 to remove and 99 not upgraded. [09:15] Need to get 237MB of archives. [09:15] After this operation, 515MB of additional disk space will be used. [09:15] mvo: that's on my intrepid machine and I've no many universe things installed [09:16] seb128: I suspect that that's due to a handful of actual Recommends arcs that then pull it lots of further dependencies [09:16] urg [09:16] Installing mailx as dep of logrotate [09:16] Installing bsd-mailx as dep of mailx [09:16] Installing exim4 as dep of bsd-mailx [09:17] I think what I'll do is add it to germinate with a --no-recommends command-line option, so you can still do a comparison [09:17] * cjwatson runs the (I suppose) last autosync [09:18] cjwatson: sounds good to me as well, the confusion a valid point [09:18] seb128: yeah, especially the "recommends mail-transport-agent" need to be demoted [09:19] that is currently quite anyoing [09:23] mvo: It brings exim into a basic debootstrap, I note. [09:40] I am trying to compile a Qt/KDE application (KDE4) and "cmake" produces the following errors: [09:40] CMake Error at CMakeLists.txt:5 (find_package): [09:40] find_package could not find module FindPoppler.cmake or a configuration [09:40] file for package Poppler. [09:40] [...] [09:40] CMake Error at CMakeLists.txt:6 (PKGCONFIG): [09:40] Unknown CMake command "PKGCONFIG". [09:40] Which packages do I have to install on Intrepid [09:43] what are you trying to build? [09:44] seb128: The Common Printing Dialog. The GSoC student has started on it with a KDE4 interface. Riddell is mentoring him. Riddell, are you here? [09:45] tkamppeter, I would guess you're missing libpoppler-dev and/or pkg-config perhaps? [09:47] MacSlow, these two are in place. I have even installed libpoppler-qt4-dev [09:53] tkamppeter, the I don't know. [09:55] hi njpatel, MagnusR [09:55] morning MacSlow [10:19] Riddell, ping [10:53] err, stupid question, but how do i tell gpg to use a specific key to --clearsign? [10:53] asac: -k [10:54] hmm [10:54] --default-key worked now [10:54] tkamppeter: hi [10:55] persia: -k doesnt work here [10:55] "conflicting command" :) [10:55] --default-key was it [10:56] Riddell, I am trying to build Alex' Common Printing Dialog on Intrepid. Which packages do I need to installl? [10:57] Riddell, or should I better do it on Hardy? [10:57] tkamppeter: what's the bzr command to check it out? I'll try it in intrepid [10:58] bzr branch http://bzr.openprinting.org/devel/common-printing-dialog [10:59] On Intrepid I get [11:00] CMake Error at CMakeLists.txt:5 (find_package): [11:00] find_package could not find module FindPoppler.cmake or a configuration [11:00] file for package Poppler. [11:00] [...] [11:00] CMake Error at CMakeLists.txt:6 (PKGCONFIG): [11:00] Unknown CMake command "PKGCONFIG". [11:01] On Hardy cmake complains about missing kde4-config and I have no idea in which package kde4-config is. [11:09] -- Performing Test HAVE_POPPLER_0_6 - Success [11:10] tkamppeter: works for me in intrepid after installing libpoppler-qt4-dev and libpoppler-dev [11:11] tkamppeter: also kdelibs5-dev [11:18] tkamppeter: but with you cmake isn't finding FindPoppler.cmake [11:19] tkamppeter: what cmake command are you running and where are you running it? [11:19] The packages you mention are all installed. [11:20] In the source dir I do [11:20] mkdir build [11:20] cd build [11:21] cmake .. [11:21] to not mix the built files with the source files ... [11:22] tkamppeter: and presumably you have this in the top level CMakeLists.txt? "set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")" [11:23] Riddell, yes I have. [11:23] hmm, no that's wrong. it's kde4-dialog/CMakeLists.txt "set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")" which is important [11:24] and also cmake/modules/FindPoppler.cmake [11:24] Yes, I am in kde4-dialog/build and the file is kde4-dialog/CMakeLists.txt [11:25] tkamppeter: ah, you are building from the wrong directory [11:25] tkamppeter: start your build a directory up [11:25] in common-printing-dialog mkdir build; cd build; cmake .. [11:27] Riddell, thank you very much. Now I got the Makefile. [11:31] Riddell, now I could compile it and start it in the background ... [11:31] yay [11:33] ... but I do not get it visible. [11:33] Ridell I am starting kde4-dialog/cups-dialog.shell and nothing happens. [11:35] tkamppeter: same here [11:35] pitti: are you planning to merge belocs-locales-bin? [11:36] Riddell, do you know by the way in which package kde4-config is on Hardy? [11:37] tkamppeter: kde4libs-bin but it is in a non-standard prefix so you will need to use -DCMAKE_INSTALL_PREFIX=/usr/lib/kde4 with cmake [11:38] tkamppeter: looking at the code I don't see anything which shows any widgets [11:38] Riddell, which code? cups-dialog or cups-dialog.shell? [11:39] the code that makes cups-dialog, dialog-test.cpp and printdialogmanager.cpp [11:40] Riddell, you have already shown me a start of Alex' dialog on your laptop. Which code did you use for that? [11:41] tkamppeter: that was cups-dialog [11:42] ls [11:43] tkamppeter: but that version had a dlg->show() line, this version does not [11:43] a KCPDialog gets made (in printdialogmanager.cpp) but doesn't actually get shown [11:44] Riddell, so we have a non-working interim version here? [11:44] I expect it just needs a show() somewhere [11:46] Riddell, I can build it also on Hardy, following your instructions. [11:47] Riddell, as you are more a KDE/Qt expert, can you tell me where to insert the show() or post a patch? Thanks. [11:53] * ogra wonders if his evo got wonky or if others get "Could someone repackage git-core with curl dependency ?" resent about once a week on ubuntu-devel-discuss [11:56] tkamppeter: looks like the intention is for the dialog to be run through dbus [11:56] cjwatson: I'm forking the mobile seeds and metas to their own source package (mobile-meta) and bzr branches; I plan to upload mobile-meta, then remove the mobile metas from ubuntu-meta when it comes out of NEW, then removing mobile seeds from the main bzr branch; anything else I should do inbetween? [12:01] Riddell, I think so, too. The changelog tells that the DBUS interface was introduced. [12:01] Therefore I have also tried to run cups-dialog in the background and then cups-dialog.shell, but this way nothing happens, too. [12:02] tkamppeter: got it http://muse.19inch.net/~jr/tmp/printing-dialogue.png [12:03] tkamppeter: 1) in cpd_preview.cpp change QString filename = to a PDF file you actually have === ogra_ is now known as ogra [12:03] tkamppeter: 2) in printdialogmanager.cpp add "dialog->show();" in PrintDialogManager::CreatePrintDialog() above the "return" line [12:04] tkamppeter: 3) compile and run cups-dialog.shell [12:04] lool: does anything of yours rely on Task fields in the Packages files in the archive? [12:04] cjwatson: Not that I know of right now [12:04] 4) in qdbusviewer (or whatever the gnome equivalent is) run CreatePrintDialog as in that screenshot [12:05] or ever came across until now [12:05] lool: then I think you should be OK; what is the access control on the new mobile seed branches? [12:05] cjwatson: ~ubuntu-mobile [12:05] and it inherits from the platform seeds? [12:06] I'd be happy to have a look over the seed branch for you when you have it done [12:06] platform.intrepid has been forked as well because germinate was pulling it from the same base [12:06] urgh! [12:06] no please don't do that [12:06] you can pass germinate multiple seed sources [12:06] cjwatson: I didn't think too much about it as it was done like this for hardy and you validated this with StevenK [12:06] platform.intrepid wasn't forked for hardy [12:06] err, platform.hardy wasn't :-) [12:07] at least if it was I didn't validate that bit [12:07] isn't the whole point of the layered seeds precisely so you don't *have* to fork them? :-) [12:07] cjwatson: lp:~ubuntu-mobile/ubuntu-seeds/platform.hardy exists [12:07] exactly [12:07] indeed, doing so could get you into a very fine mess [12:07] lool: that's a bug [12:07] I'm happy to fix this [12:08] lool: please use -S http://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/,http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ [12:08] Alternatively, I could move the seeds back to ~ubuntu-core-dev [12:08] superm1: you too, please stop having a forked version of the platform seeds, it's bad [12:08] After all StevenK, persia and myself all are [12:08] lool: no, there should be no need to do that [12:09] It might actually be safer [12:09] I'd rather that there be separate access control, even if it isn't mobile-dev [12:09] Seeds might be pulled from other places than the meta packages builds [12:09] but it's up to you; however, whatever you do, don't do it because of this non-problem [12:10] for update.cfg, use: [12:10] So they might directly impact a random cron jobs and I'm not sure I want to give access to everybody in ~ubuntu-mobile to that [12:10] seed_base: bzr+ssh://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/ bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ [12:10] or similar [12:10] err s/mobile-dev/whatever/g [12:10] cjwatson: I understand I could add it to seed_base [12:10] It's just that it made me realize that perhaps using ubuntu-core-dev made the most sense [12:11] But right, I could use ~mobile-dev [12:11] lool: generally, I'm pushing to have separate products have separate development teams, even if they include ubuntu-core-dev [12:11] Ok; I think this is a good idea too [12:11] I'm not necessarily saying ~ubuntu-mobile as it stands now is right [12:11] but I think you're going to want to add new people without necessarily having time to get them through the ubuntu-core-dev process [12:12] One problem I'll immediately face with a new team is admitting that not everybody in ~ubuntu-mobile belongs there [12:12] mm, that might be a political problem I agree [12:12] ubuntu-mobile-dev ;) [12:12] well, up to you, you at least have a fix to stop you needing platform.* forkage [12:12] It's the same problem :) [12:13] I was going to make a joke about having the same problem with ubuntu-core-dev, but decided that would be very very mean ;) [12:13] I think I'll opt for the easy core-dev solution for now and use the opportunity to not renew some ubuntu-mobile memberships when the times comes [12:14] Keybuk: haha [12:14] Keybuk: Nice way to still make the joke and avoid being mean :) [12:14] Perhaps at some point ubuntu-mobile will reflect a more conservative set of people [12:15] (I didn't mind while the packages were QA-ed before upload, the seeds are different though) [12:15] you can rename teams [12:15] lool: as seeds become more important to archive management, we probably want to change the team membership, as it has a different meaning. I suspect most current members won't complain if there remains an appropriate place for them to push things. [12:15] I don't see that it'd be politically that difficult to introduce a dev team for people who need upload rights [12:15] and only put those people who are also core-dev into it at first [12:15] since the archive reorg will require everyone to do that, and be careful about their -dev team membership [12:16] since irresponsibility with -dev team membership will make the TB very very angry [12:18] Keybuk: Must it be restricted to core-dev? There's at least one member of ubuntu-mobile who is not core-dev, but who is likely to modify seeds or otherwise work "critical" ubuntu-mobile packages. [12:18] soren: I have some trouble here with loadvm/savevm in kvm in intrepid, is this known? [12:19] mvo: With qcow images? [12:20] I belive it broke some time during the hardy cycle due to a security fix.. I patched it in Debian a month ago or so, so we should have the fix in Ubuntu now, too. [12:20] I can check, though. [12:20] persia: no, it need not be, but I'd suggest that the exceptions be carefully considered, since those people would gain upload privileges in the near future [12:20] Keybuk: Very much expected, and understood. Thanks for the clarification. [12:21] yeah, lets rather see that we quickly get this person into core-dev :) [12:23] ogra: See, that defeats the point of archive-reorg. One oughtn't need to be core-dev to work on most things, only if one needs to work on true core applications, shared by many flavours. [12:23] well, depends how you define "most things" [12:24] i'D consider seeds for example not to be a common "thing" :) [12:25] ogra: Perhaps, although there are currently several sets of seeds managed in some cases by people who are not ubuntu-dev. It all depends on what the seeds are expected to grow. [12:25] ineed [12:25] and indeed its all bzr, you can maintain your own seed branch and have a privileged person merging it for example [12:26] thats what xubuntu does atm afaik [12:26] seeds shouldn't need to be a common super-core kind of thing [12:26] and the xubuntu situation is a hassle and is being fixed === devfil_ is now known as devfil [12:27] s/a common/an uncommon/ [12:27] no, but there are easy ways to maintain them even without everyone having commit access [12:27] but it's even easier if they do [12:27] indeed [12:27] w.r.t. getting people into core-dev, yes, that is a useful goal, but we have seen a lot of problems in practice due to assuming that this is feasible in all cases [12:28] cjwatson: see my activity report; it's essentially a no-op, so I'd do it only for the sake of getting it off MoM [12:28] in practice what this does is block a lot of people from contributing effectively when they have relatively narrow interests [12:28] pitti: ok, well, I wouldn't object to getting another one off MoM, but I realise you have a lot to do [12:29] oh, I'm on the top of the list now [12:29] cjwatson: ah, I do it right now for the sake of a clean record; it's a two-minute job, after all [12:33] mvo: Are you suggesting that it used to work, but now doesn't? === ara is now known as ara_lunch [12:37] soren: I'm not sure if it ever worked, but it would be nice if it did :) [12:37] soren: do you have any information about this, i.e. should it work or is it known that it does not work etc? [12:38] mvo: Are you using qcow{,2} images? [12:38] soren: yes [12:39] mvo: Ok, due to a security patch we applied at some point in the hardy cycle, savevm with resizing images fails quite horribly. [12:39] Resizing images are qcow, qcow2 and vmdk, AFAIR. [12:39] hm, ok [12:39] Let me check if my patch from Debian got applied here, too. [12:39] what can be done about this? switching the imageformat as a workaound? [12:40] mvo: Well, I wrote a patch that fixes it, so we should be fine. [12:40] * soren is still checking if it's applied in intrepid. [12:41] mvo: At least the changelog claims I did. :) [12:41] mvo: What exactly fails for you? [12:41] soren: aha, I'm just testing the hardy kvm and loadvm seems to be much happier there [12:42] soren: no keyboard in the guest anymore, segfaults in the guest and sometimes "could not load vm, error -22 or error -1" (intrepid/amd64) [12:44] * mvo does some further testing [12:44] cjwatson: thx for importing Tuxguitar [12:45] Riddell, thank you. It works now. [12:47] rzr: no problem [12:48] hi [12:48] lamont: around? [12:49] mvo: Really? Would expect hardy's kvm's load/savevm to be rather broken, actually. [12:50] soren: well, it survived three loadvm, I give it a bit more testing now === rzr is now known as ZrZ === thekorn_ is now known as thekorn [13:02] carlos: yeah [13:02] lamont: hi. I just send you an email [13:02] ok [13:10] Keybuk: While working on the initramfs-tools merge, I've noticed that Debian is using /lib/udev/firmware.agent, whereas Ubuntu has /lib/udev/firmware_helper. Are they functionally the same? [13:11] we use firmware_helper [13:11] soren: hm, hardy/i386 seems to be pretty happy with savevm/restorevm, it survied a bunch of those now (~20?) without trouble, might be a i386<->amd64 problem of course too [13:12] Keybuk: I know. But are they both functionally the same? [13:12] TheMuso: why are you asking? [13:13] Keybuk: Because Debian's initramfs-tools copies firmware.agent into the initramfs. [13:13] we should copy firmware_helper [13:14] Ok I'll check up on that tomorrow. Thanks. [13:16] TheMuso: but initramfs-tools should not do that [13:16]