[00:05] <TheMuso> 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.
[00:08] <bryce> weird, I don't think the uncommented pci id patch would actually do what it looks like it wants to do
[00:09] <bryce> +       awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/100B/' > nsc.ids
[00:09] <bryce> +       awk '/^#define.*PCI_CHIP/ {print $$3}' ${srcdir}/nsc_driver.c | sort -u | grep -v 0030 | sed -e 's/0x/1078/' >> nsc.ids
[00:09] <bryce> ohhh I get it
[00:11] <slangasek> TheMuso: oh, I didn't realize that we had an alsa-plugins upload in there... I'll yank it out
[00:12] <bryce> slangasek: ok new ubuntu0.1 uploaded with just that line uncommented
[00:13] <bryce> (I finally fully understand how the patch works)
[00:14] <slangasek> ok :)
[00:46] <bryce> calc: ok libx11 time
[01:00] <bryce> calc, ok I've emailed ben
[01:16] <slangasek> 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] <slangasek> bryce: it looks to me like the Makefile.am and Makefile.in are out of sync, with the Makefile.in being incorrect
[01:17] <slangasek> (i.e., still commenting out the cyrix line)
[01:22] <bryce> slangasek: hrm, ok I'll take a look
[01:36] <bryce> ahh, no one hooked up the patch system in -nsc.
[01:36] <bryce> *boggle* ok
[01:37] <slangasek> ah, maybe that's part of what the massive xsfbs patch that got pulled in was about?
[01:37] <bryce> surprisingly no; despite all that, debian didn't set up the patch system either
[01:38] <bryce> which is why I didn't catch it when reviewing the debdiffs...  didn't even think to look
[01:38] <slangasek> heh
[01:38] <bryce> but it became obvious when I went looking for why none of my prior uploads had failed to build
[01:39] <bryce> ahhhh and it explains why the sync had gone through when that patch clearly couldn't apply.
[03:16] <persia> 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] <emgent> someone can stop Michael Garrido planet.u.c climbing ?
[03:39] <nxvl> emgent: ?
[03:39] <ScottK> bryce: I wasn't actually at the platform meeting.  My 'shot' at selinux packages will be to file sync requests.
[03:40] <emgent> n8k99:
[03:40] <emgent> nxvl: Him update the date of his post to stay in the first news planet.uc pathetic.
[03:41] <emgent> my feedrss reader see it ...
[03:42] <nxvl> emgent: mm i don't think he did, it must be a random error
[03:43] <n8k99> emgent?
[03:43] <emgent> nxvl: impossible.. him use *.wordpress.com and more other planet user use it. but only him have this "problem"
[03:44] <emgent> n8k99: sorry, wrong tab :)
[03:44] <n8k99> oh haha
[03:44] <nxvl> emgent: i have noticed it this time, but just once
[03:44] <nxvl> or have you noticed it many times?
[03:45] <emgent> many times.
[03:45] <nxvl> mmm
[03:45] <nxvl> strange
[03:45] <nxvl> i have just noted on his last post
[03:45] <nxvl> i will talk to him
[03:45] <emgent> ok thanks
[03:46] <nxvl> emgent: you can talk to him, he's connected
[03:46] <emgent> liferea dont log all, update the date hour post, argh.
[03:46] <nxvl> emgent: xander21c in freenode
[03:47] <emgent> ok nxvl i will do. Thanks
[03:49] <nxvl> emgent: i have just talked to him
[03:49] <emgent> dont reply to me now :\
[03:49] <nxvl> emgent: he said he's going to check the settings @ wordpres
[03:49] <emgent> ok cool.
[03:49] <nxvl> maybe he's not registred
[03:50] <emgent> ?
[03:50] <nxvl> on freenode you can't reply to private messages if you are not registred and loged in
[03:50] <emgent> oh ok
[04:06] <wgrant> nxvl: I think new services removed that limitation, actually.
[04:07] <wgrant> 'SET UNFILTERED has been removed and the global block on messages from users that have not identified to NickServ has been removed.'
[04:07] <nxvl> wgrant: are you sure?
[04:07] <wgrant> http://blog.freenode.net/?p=80
[04:09] <nxvl> \o/
[04:43] <Hobbsee> wow!  my wifi has a light now!
[04:43] <Hobbsee> any music sounds like someone's torturing a cat, though
[04:44] <ajmitch> 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] <wgrant> ajmitch: Yours isn't royal?
[04:45] <wgrant> Hobbsee: Is there meant to be a 2.6.26 LUM?
[04:45] <ajmitch> it may be officially, but it's usually called the SPCA
[04:45] <wgrant> My audio sounds awful as well, and headphones don't mute speakers.
[04:45] <ScottK> Hobbsee: The music people heard about your myspace page and thought you'd like it.
[04:45] <wgrant> We have the RSPCA here.
[04:45] <wgrant> ScottK: That's gone now :(
[04:45] <Hobbsee> wgrant: apparently not?
[04:46] <ScottK> But the legend lives on.
[04:46] <Hobbsee> ScottK: hahhahahahha
[04:46] <Hobbsee> 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] <Hobbsee> it's a *lovely* background.
[04:53]  * ajmitch twitches
[04:53] <ajmitch> don't make me run for the medication again
[05:00] <Hobbsee> i would have thought you'd learned by now to keep it with you.
[05:02] <Hobbsee> argh.  what's the pcspkr module called now, in 2.6.26?
[05:02] <wgrant> Hobbsee: snd_pcsp
[05:02] <wgrant> I encountered the same problem.
[05:03] <Hobbsee> wgrant: and how do i force it not to be in use?
[05:04] <wgrant> Hobbsee: By blacklisting and rebooting, or removing the whole stack of audio modules, I guess.
[05:04] <persia> Hobbsee: You can rmmod it, blacklist it, or pass module arguments to cause it to load later in the sequence.
[05:04] <wgrant> I gave up on 2.6.26 because I presumed that my audio depended on LUM.
[05:05] <wgrant> Which seems to no longer be around.
[05:05] <Hobbsee> persia: rmmod gives the same thing.
[05:05]  * Hobbsee updates the blacklist though, for the next reboot
[05:05] <Hobbsee> was hoping to fix it without a reboot
[05:05] <wgrant> Hobbsee: WOrk out what depends on it.
[05:05] <wgrant> lsmod should help.
[05:06] <persia> Hobbsee: You can't rmmod it?  Please pastebin your lsmod
[05:06] <Hobbsee> sarah@saturn:~% lsmod  | grep pcsp                                       2:06PM
[05:06] <Hobbsee> snd_pcsp               17312  1
[05:06] <persia> Hobbsee: Also, check /proc/asound/cards to make sure you have another working device present.
[05:07] <Hobbsee> snd_pcm                82180  3 snd_pcsp,snd_hda_intel,snd_pcm_oss
[05:07] <Hobbsee> 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] <Hobbsee> yeah, i do.
[05:07] <Hobbsee> wgrant: thanks, that's the command i wanted, but had forgotten.
[05:07] <Hobbsee> persia: is that enough, or do you want the entire thing?
[05:08] <persia> That says nothing depends on snd_pcsp.  You get am error from rmmod?
[05:08] <persia> s/am/an/
[05:08] <Hobbsee> sarah@saturn:~% sudo rmmod snd_pcsp                                      2:08PM
[05:08] <Hobbsee> ERROR: Module snd_pcsp is in use
[05:08] <Hobbsee> yup
[05:08]  * ajmitch blames userspace 
[05:09] <persia> Hobbsee: OK.  lsof | grep /dev/snd to find the offending process.
[05:09] <persia> Convince that process to use a different device.
[05:09] <persia> rmmod it.
[05:09] <Hobbsee> persia: no offending process.  go figure.
[05:09]  * ajmitch wonders if it'll be pulseaudio hogging it
[05:10] <persia> Likely.
[05:11]  * Hobbsee puts it down to intrepid weirdness.
[05:11] <persia> Hobbsee: Have you run the ALSA set-default macro since you changed kernels?
[05:14] <Hobbsee> persia: no?
[05:14]  * Hobbsee has no idea what that even is - never needed it before
[05:14] <superm1> those sound applets that live in panels are good candidates for killing if you cant rmmod
[05:14] <persia> 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] <Hobbsee> superm1: don't have one of them, but good idea.
[05:15] <Hobbsee> persia: ah, right.  which is why the sound sounds strange.
[05:16] <persia> Hobbsee: Check your card names in /proc/asound/cards, then run `asoundconf set-default-card $(NAME)`
[05:17] <persia> Actually, `asoundconf list` might give you a better list of names than /proc/asound/cards
[05:18] <Hobbsee> persia: that's fixed it, thanks.  although i still can't rmmod the other, for some reason.
[05:18] <persia> 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] <persia> OOps!
[05:26] <TheMuso> Hrm grub seems to fail on the intrepid alternate i386 daily.
[06:01] <slangasek> TheMuso: fail how?
[06:23] <dholbach> good morning
[06:24] <vozniakBR> too
[06:25] <TheMuso> slangasek: Something to do with the package not being able to be installed...
[06:25] <slangasek> ok
[06:25] <TheMuso> slangasek: "The package 'grub' cannot be installed into /target or some such.
[06:27] <nxvl> slangasek: did you get chance to check Bug #225005?
[06:28] <Hobbsee> morning dholbach
[06:28] <slangasek> nxvl: no, sorry; that will have to be tomorrow for me
[06:28] <dholbach> hi Hobbsee
[06:28] <nxvl> slangasek: ok, because i merged it before intrepid were open and we are 1 day away from DIF
[06:29] <nxvl> slangasek: but, no problem, take a look when you have some time :D
[06:29] <slangasek> TheMuso: mm, is there any more specific error in the log?
[06:29] <slangasek> I see there are new versions of grub in intrepid that aren't in the bzr repo, doh
[06:42] <slangasek> TheMuso: I don't see anything wrong with the latest grub diff in intrepid; an exact error message from the log would be helpful
[06:44] <TheMuso> slangasek: Ok I'll see what I can dig up.
[06:45] <TheMuso> slangasek: Ok not much there that says why, I may have to run again with the verbocity cranked up somewhat.
[06:46] <slangasek> I think that any maintainer script errors should be registered in the log, somewhere?
[06:46] <slangasek> but I'm off to bed now, so not much help I'm afraid
[06:46] <TheMuso> slangasek: no problem, will keep digging.
[07:06] <pitti> Good mornin
[07:13] <nxvl> pitti: hello!
[07:32] <andrew_sayers> Is there a list somewhere of the packages installed by default in the various *buntu?
[07:32] <andrew_sayers> I've been going by the popularity contest, but that's not broken down by variant.
[07:35] <nxvl> yes, there is
[07:35] <nxvl> i just don;t remember where
[07:36] <persia> andrew_sayers: It's a close match to the dependencies of the various -meta packages.
[07:36] <persia> (and the recursive dependencies thereof)
[07:38] <andrew_sayers> persia: you mean there's a xubuntu-meta package out there?
[07:39] <andrew_sayers> persia: never mind, I get it :)
[07:39] <persia> andrew_sayers: Yep.  xubuntu-desktop is likely the one that would provide the interesting list.
[07:39] <andrew_sayers> I see - so basically xubuntu == xubuntu-desktop + dependencies?
[07:42] <nxvl> andrew_sayers: and + ubuntu-base
[07:43] <andrew_sayers> Thanks, that's all I need to know :)
[07:43] <nxvl> s/base/minimal
[07:45] <persia> nxvl: Is it?  I thought when seeds had dependencies those were expressed in the resulting metapackages.
[08:37] <kahrytan> Hello
[08:45] <Q-FUNK> 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.
[09:04] <seb128> mvo: hey
[09:05] <seb128> mvo: do you plan to reply to this mailing thread about main packages having recommends in universe?
[09:06] <mvo> 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] <seb128> 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] <seb128> dunno if that has been discussed before though
[09:08] <mvo> 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] <seb128> my understanding is that CD are already at the limit so we will not have changes there
[09:08] <seb128> and then recommends will be installed in functions of the sources available
[09:08] <seb128> mvo: right, the thread is "should we promote all recommends to main or not" basically
[09:09]  * mvo nods
[09:09] <mvo> I guess its a matter of policy, but I don't see a reason why we should
[09:09] <mvo> we should check them out and decide on a case-by-case basis and maybe demote some to suggests
[09:10] <persia> 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] <mvo> did someone do a analysis on this? i.e. how many packages have those and what recommends those are?
[09:10] <mvo> persia: oh, I agree on this of course, we should make sure this is consistent
[09:10] <persia> 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] <persia> mvo: In general case, I think you7re right.  I'm mostly worried about the impact on the installation case.
[09:11] <mvo> persia: ok, I will put it on my todo for today and check the scope on this
[09:12] <persia> mvo: Thanks :)
[09:15] <seb128> mvo: btw
[09:15] <cjwatson> 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] <seb128> mvo: sudo apt-get install --fix-policy --install-recommends
[09:15] <cjwatson> mvo: which doesn't of course mean promoting everything en masse, it means a case-by-case review
[09:15] <seb128> 17 upgraded, 173 newly installed, 3 to remove and 99 not upgraded.
[09:15] <seb128> Need to get 237MB of archives.
[09:15] <seb128> After this operation, 515MB of additional disk space will be used.
[09:15] <seb128> mvo: that's on my intrepid machine and I've no many universe things installed
[09:16] <cjwatson> seb128: I suspect that that's due to a handful of actual Recommends arcs that then pull it lots of further dependencies
[09:16] <seb128> urg
[09:16] <seb128> Installing mailx as dep of logrotate
[09:16] <seb128> Installing bsd-mailx as dep of mailx
[09:16] <seb128> Installing exim4 as dep of bsd-mailx
[09:17] <cjwatson> 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] <mvo> cjwatson: sounds good to me as well, the confusion a valid point
[09:18] <mvo> seb128: yeah, especially the "recommends mail-transport-agent" need to be demoted
[09:19] <mvo> that is currently quite anyoing
[09:23] <wgrant> mvo: It brings exim into a basic debootstrap, I note.
[09:40] <tkamppeter> I am trying to compile a Qt/KDE application (KDE4) and "cmake" produces the following errors:
[09:40] <tkamppeter> CMake Error at CMakeLists.txt:5 (find_package):
[09:40] <tkamppeter>   find_package could not find module FindPoppler.cmake or a configuration
[09:40] <tkamppeter>   file for package Poppler.
[09:40] <tkamppeter> [...]
[09:40] <tkamppeter> CMake Error at CMakeLists.txt:6 (PKGCONFIG):
[09:40] <tkamppeter>   Unknown CMake command "PKGCONFIG".
[09:40] <tkamppeter> Which packages do I have to install on Intrepid
[09:43] <seb128> what are you trying to build?
[09:44] <tkamppeter> 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] <MacSlow> tkamppeter, I would guess you're missing libpoppler-dev and/or pkg-config perhaps?
[09:47] <tkamppeter> MacSlow, these two are in place. I have even installed  libpoppler-qt4-dev
[09:53] <MacSlow> tkamppeter, the I don't know.
[09:55] <MacSlow> hi njpatel, MagnusR
[09:55] <njpatel> morning MacSlow
[10:19] <tkamppeter> Riddell, ping
[10:53] <asac> err, stupid question, but how do i tell gpg  to use a specific key to --clearsign?
[10:53] <persia> asac: -k
[10:54] <asac> hmm
[10:54] <asac> --default-key worked now
[10:54] <Riddell> tkamppeter: hi
[10:55] <asac> persia: -k doesnt work here
[10:55] <asac> "conflicting command" :)
[10:55] <asac> --default-key was it
[10:56] <tkamppeter> Riddell, I am trying to build Alex' Common Printing Dialog on Intrepid. Which packages do I need to installl?
[10:57] <tkamppeter> Riddell, or should I better do it on Hardy?
[10:57] <Riddell> tkamppeter: what's the bzr command to check it out?  I'll try it in intrepid
[10:58] <tkamppeter> bzr branch http://bzr.openprinting.org/devel/common-printing-dialog
[10:59] <tkamppeter> On Intrepid I get
[11:00] <tkamppeter> CMake Error at CMakeLists.txt:5 (find_package):
[11:00] <tkamppeter>   find_package could not find module FindPoppler.cmake or a configuration
[11:00] <tkamppeter>   file for package Poppler.
[11:00] <tkamppeter> [...]
[11:00] <tkamppeter> CMake Error at CMakeLists.txt:6 (PKGCONFIG):
[11:00] <tkamppeter>   Unknown CMake command "PKGCONFIG".
[11:01] <tkamppeter> On Hardy cmake complains about missing kde4-config and I have no idea in which package kde4-config is.
[11:09] <Riddell> -- Performing Test HAVE_POPPLER_0_6 - Success
[11:10] <Riddell> tkamppeter: works for me in intrepid after installing libpoppler-qt4-dev and libpoppler-dev
[11:11] <Riddell> tkamppeter: also kdelibs5-dev
[11:18] <Riddell> tkamppeter: but with you cmake isn't finding FindPoppler.cmake
[11:19] <Riddell> tkamppeter: what cmake command are you running and where are you running it?
[11:19] <tkamppeter> The packages you mention are all installed.
[11:20] <tkamppeter> In the source dir I do
[11:20] <tkamppeter> mkdir build
[11:20] <tkamppeter> cd build
[11:21] <tkamppeter> cmake ..
[11:21] <tkamppeter> to not mix the built files with the source files ...
[11:22] <Riddell> tkamppeter: and presumably you have this in the top level CMakeLists.txt?  "set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")"
[11:23] <tkamppeter> Riddell, yes I have.
[11:23] <Riddell> 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] <Riddell> and also cmake/modules/FindPoppler.cmake
[11:24] <tkamppeter> Yes, I am in kde4-dialog/build and the file is kde4-dialog/CMakeLists.txt
[11:25] <Riddell> tkamppeter: ah, you are building from the wrong directory
[11:25] <Riddell> tkamppeter: start your build a directory up
[11:25] <Riddell> in common-printing-dialog   mkdir build; cd build; cmake ..
[11:27] <tkamppeter> Riddell, thank you very much. Now I got the Makefile.
[11:31] <tkamppeter> Riddell, now I could compile it and start it in the background ...
[11:31] <Riddell> yay
[11:33] <tkamppeter> ... but I do not get it visible.
[11:33] <tkamppeter> Ridell I am starting kde4-dialog/cups-dialog.shell and nothing happens.
[11:35] <Riddell> tkamppeter: same here
[11:35] <cjwatson> pitti: are you planning to merge belocs-locales-bin?
[11:36] <tkamppeter> Riddell, do you know by the way in which package kde4-config is on Hardy?
[11:37] <Riddell> 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] <Riddell> tkamppeter: looking at the code I don't see anything which shows any widgets
[11:38] <tkamppeter> Riddell, which code? cups-dialog or cups-dialog.shell?
[11:39] <Riddell> the code that makes cups-dialog, dialog-test.cpp and printdialogmanager.cpp
[11:40] <tkamppeter> Riddell, you have already shown me a start of Alex' dialog on your laptop. Which code did you use for that?
[11:41] <Riddell> tkamppeter: that was cups-dialog
[11:42] <tkamppeter> ls
[11:43] <Riddell> tkamppeter: but that version had a dlg->show() line, this version does not
[11:43] <Riddell> a KCPDialog gets made (in printdialogmanager.cpp) but doesn't actually get shown
[11:44] <tkamppeter> Riddell, so we have a non-working interim version here?
[11:44] <Riddell> I expect it just needs a show() somewhere
[11:46] <tkamppeter> Riddell, I can build it also on Hardy, following your instructions.
[11:47] <tkamppeter> 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] <Riddell> tkamppeter: looks like the intention is for the dialog to be run through dbus
[11:56] <lool> 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] <tkamppeter> Riddell, I think so, too. The changelog tells that the DBUS interface was introduced.
[12:01] <tkamppeter> 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] <Riddell> tkamppeter: got it http://muse.19inch.net/~jr/tmp/printing-dialogue.png
[12:03] <Riddell> tkamppeter: 1) in cpd_preview.cpp change QString filename = to a PDF file you actually have
[12:03] <Riddell> tkamppeter: 2) in printdialogmanager.cpp add "dialog->show();" in PrintDialogManager::CreatePrintDialog() above the "return" line
[12:04] <Riddell> tkamppeter: 3) compile and run cups-dialog.shell
[12:04] <cjwatson> lool: does anything of yours rely on Task fields in the Packages files in the archive?
[12:04] <lool> cjwatson: Not that I know of right now
[12:04] <Riddell> 4) in qdbusviewer (or whatever the gnome equivalent is) run CreatePrintDialog as in that screenshot
[12:05] <lool> or ever came across until now
[12:05] <cjwatson> lool: then I think you should be OK; what is the access control on the new mobile seed branches?
[12:05] <lool> cjwatson: ~ubuntu-mobile
[12:05] <cjwatson> and it inherits from the platform seeds?
[12:06] <cjwatson> I'd be happy to have a look over the seed branch for you when you have it done
[12:06] <lool> platform.intrepid has been forked as well because germinate was pulling it from the same base
[12:06] <cjwatson> urgh!
[12:06] <cjwatson> no please don't do that
[12:06] <cjwatson> you can pass germinate multiple seed sources
[12:06] <lool> 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] <cjwatson> platform.intrepid wasn't forked for hardy
[12:06] <cjwatson> err, platform.hardy wasn't :-)
[12:07] <cjwatson> at least if it was I didn't validate that bit
[12:07] <Keybuk> isn't the whole point of the layered seeds precisely so you don't *have* to fork them? :-)
[12:07] <lool> cjwatson: lp:~ubuntu-mobile/ubuntu-seeds/platform.hardy exists
[12:07] <cjwatson> exactly
[12:07] <Keybuk> indeed, doing so could get you into a very fine mess
[12:07] <cjwatson> lool: that's a bug
[12:07] <lool> I'm happy to fix this
[12:08] <cjwatson> lool: please use -S http://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/,http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/
[12:08] <lool> Alternatively, I could move the seeds back to ~ubuntu-core-dev
[12:08] <cjwatson> superm1: you too, please stop having a forked version of the platform seeds, it's bad
[12:08] <lool> After all StevenK, persia and myself all are
[12:08] <cjwatson> lool: no, there should be no need to do that
[12:09] <lool> It might actually be safer
[12:09] <cjwatson> I'd rather that there be separate access control, even if it isn't mobile-dev
[12:09] <lool> Seeds might be pulled from other places than the meta packages builds
[12:09] <cjwatson> but it's up to you; however, whatever you do, don't do it because of this non-problem
[12:10] <cjwatson> for update.cfg, use:
[12:10] <lool> 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] <cjwatson> seed_base: bzr+ssh://bazaar.launchpad.net/~mobile-dev/ubuntu-seeds/ bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/
[12:10] <cjwatson> or similar
[12:10] <cjwatson> err s/mobile-dev/whatever/g
[12:10] <lool> cjwatson: I understand I could add it to seed_base
[12:10] <lool> It's just that it made me realize that perhaps using ubuntu-core-dev made the most sense
[12:11] <lool> But right, I could use ~mobile-dev
[12:11] <cjwatson> lool: generally, I'm pushing to have separate products have separate development teams, even if they include ubuntu-core-dev
[12:11] <lool> Ok; I think this is a good idea too
[12:11] <cjwatson> I'm not necessarily saying ~ubuntu-mobile as it stands now is right
[12:11] <cjwatson> 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] <lool> One problem I'll immediately face with a new team is admitting that not everybody in ~ubuntu-mobile belongs there
[12:12] <cjwatson> mm, that might be a political problem I agree
[12:12] <Keybuk> ubuntu-mobile-dev ;)
[12:12] <cjwatson> well, up to you, you at least have a fix to stop you needing platform.* forkage
[12:12] <lool> It's the same problem :)
[12:13] <Keybuk> 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] <lool> 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] <lool> Keybuk: haha
[12:14] <lool> Keybuk: Nice way to still make the joke and avoid being mean :)
[12:14] <lool> Perhaps at some point ubuntu-mobile will reflect a more conservative set of people
[12:15] <lool> (I didn't mind while the packages were QA-ed before upload, the seeds are different though)
[12:15] <Keybuk> you can rename teams
[12:15] <persia> 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] <Keybuk> I don't see that it'd be politically that difficult to introduce a dev team for people who need upload rights
[12:15] <Keybuk> and only put those people who are also core-dev into it at first
[12:15] <Keybuk> since the archive reorg will require everyone to do that, and be careful about their -dev team membership
[12:16] <Keybuk> since irresponsibility with -dev team membership will make the TB very very angry
[12:18] <persia> 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] <mvo> soren: I have some trouble here with loadvm/savevm in kvm in intrepid, is this known?
[12:19] <soren> mvo: With qcow images?
[12:20] <soren> 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] <soren> I can check, though.
[12:20] <Keybuk> 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] <persia> Keybuk: Very much expected, and understood.  Thanks for the clarification.
[12:21] <ogra> yeah, lets rather see that we quickly get this person into core-dev :)
[12:23] <persia> 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] <ogra> well, depends how you define "most things"
[12:24] <ogra> i'D consider seeds for example not to be a common "thing" :)
[12:25] <persia> 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] <ogra> ineed
[12:25] <ogra> and indeed its all bzr, you can maintain your own seed branch and have a privileged person merging it for example
[12:26] <ogra> thats what xubuntu does atm afaik
[12:26] <cjwatson> seeds shouldn't need to be a common super-core kind of thing
[12:26] <cjwatson> and the xubuntu situation is a hassle and is being fixed
[12:27] <cjwatson> s/a common/an uncommon/
[12:27] <ogra> no, but there are easy ways to maintain them even without everyone having commit access
[12:27] <cjwatson> but it's even easier if they do
[12:27] <ogra> indeed
[12:27] <cjwatson> 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] <pitti> 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] <cjwatson> in practice what this does is block a lot of people from contributing effectively when they have relatively narrow interests
[12:28] <cjwatson> pitti: ok, well, I wouldn't object to getting another one off MoM, but I realise you have a lot to do
[12:29] <pitti> oh, I'm on the top of the list now
[12:29] <pitti> cjwatson: ah, I do it right now for the sake of a clean record; it's a two-minute job, after all
[12:33] <soren> mvo: Are you suggesting that it used to work, but now doesn't?
[12:37] <mvo> soren: I'm not sure if it ever worked, but it would be nice if it did :)
[12:37] <mvo> 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] <soren> mvo: Are you using qcow{,2} images?
[12:38] <mvo> soren: yes
[12:39] <soren> 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] <soren> Resizing images are qcow, qcow2 and vmdk, AFAIR.
[12:39] <mvo> hm, ok
[12:39] <soren> Let me check if my patch from Debian got applied here, too.
[12:39] <mvo> what can be done about this? switching the imageformat as a workaound?
[12:40] <soren> 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] <soren> mvo: At least the changelog claims I did. :)
[12:41] <soren> mvo: What exactly fails for you?
[12:41] <mvo> soren: aha, I'm just testing the hardy kvm and loadvm seems to be much happier there
[12:42] <mvo> 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] <rzr> cjwatson: thx for importing Tuxguitar
[12:45] <tkamppeter> Riddell, thank you. It works now.
[12:47] <cjwatson> rzr: no problem
[12:48] <carlos> hi
[12:48] <carlos> lamont: around?
[12:49] <soren> mvo: Really? Would expect hardy's kvm's load/savevm to be rather broken, actually.
[12:50] <mvo> soren: well, it survived three loadvm, I give it a bit more testing now
[13:02] <lamont> carlos: yeah
[13:02] <carlos> lamont: hi. I just send you an email
[13:02] <lamont> ok
[13:10] <TheMuso> 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] <Keybuk> we use firmware_helper
[13:11] <mvo> 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] <TheMuso> Keybuk: I know. But are they both functionally the same?
[13:12] <Keybuk> TheMuso: why are you asking?
[13:13] <TheMuso> Keybuk: Because Debian's initramfs-tools copies firmware.agent into the initramfs.
[13:13] <Keybuk> we should copy firmware_helper
[13:14] <TheMuso> Ok I'll check up on that tomorrow. Thanks.
[13:16] <Keybuk> TheMuso: but initramfs-tools should not do that
[13:16] <Keybuk> (udev's initramfs hook does that)
[13:17] <TheMuso> Keybuk: Right, I didn't think so.
[13:17] <Keybuk> in fact, initramfs-tools should have no references to anything shipped by udev
[13:22] <soren> mvo: It's possible, but I wouldn't have thought so at all.
[13:22] <soren> mvo: It problem is that the security fix was written to prevent malicious guests to write outside the boundaries of the disk..
[13:22] <mvo> soren: I keep you updated, I'm exploring this new and interessting kvm feature right now :)
[13:23] <soren> mvo: But the way savevm works is that it writes the state in the end of the disk image (so outside the emulated block device boundaries).
[13:24] <soren> For some reason, this error is never caught, so it's just ignored. You don't notice the breakage until you try to loadvm again at which point it blows up.
[13:24] <mvo> soren: can a savevm be triggered from inside a guest?
[13:24] <soren> The fix I wrote just circumvents the boundary check when we're doing savevm (sort of).
[13:24] <mvo> soren: or how has this become a security issue?
[13:24] <soren> No, the guest can't trigger a savevm.
[13:25] <soren> Oh, the security problem is that if you just told the ide controller to write outside the boundary of the disk, qemu didn't prevent it.
[13:26] <soren> ..which is bad.
[13:26] <mvo> heh :) now I see
[13:42] <bimberi> cjwatson: Thanks again for pointing me to 'dpkg --compare-versions' the other day.  It's been ex-sede-ingly useful ;)
[13:46] <lool> cjwatson: (BTW, fixed platform.{hardy,intrepid} forks)
[13:50] <cjwatson> lool: great, thanks
[13:50] <cjwatson> bimberi: you're welcome
[14:20] <robertknight2> Is there someone here who can look at the possible fix for bug #203016?
[14:21] <mvo> soren: http://paste.ubuntu.com/23088 is what I get when I try a "loadvm" in kvm after I created a snapshot, exited kvm and started it again. as long as keep being in the kvm instance start the snapshot was created with, loadvm seems to work
[14:23] <robertknight2> network-manager is consumes a hefty amount of memory after a few days uptime.  The patch is trivial so I'm wondering if it could be included in an SRU?
[14:25] <james_w> robertknight: asac is the person to speak to
[14:34] <cr3> ogra: to follow up on yesterday, komputes says that he tested the nsc driver upon request from q-funk and it works!
[14:34] <ogra> yay
[14:34] <Q-FUNK> cr3: where did he find it and in which version?
[14:34] <ogra> can he comment on the bug ?
[14:34] <ogra> Bug 219630
[14:35] <ogra> thats the SRU
[14:35] <cr3> Q-FUNK: not sure, I'll have him provide this information in the bug report
[14:41] <mouz> (sorry if wrong channel: no answer in #ubuntu-testing) Is it OK if tests 2.3 through 2.9 on https://wiki.ubuntu.com/Testing/Cases/ServerInstall are combined (combining the software selection steps)? It would make ISO server testing faster.
[14:42] <stgraber> mouz: those testcases were written by the server team, it might be better to ask in #ubuntu-server
[14:42] <mouz> :) ok stgraber thanks
[14:43] <stgraber> mouz: I often do that kind of combined tests myself for Ubuntu alternates but that's more to get more bugs by creating package conflicts than to do less testing time :)
[14:45] <soren> mvo: Oh, that might very well have an impact, yes.
[14:46] <soren> mvo: I always assumed that the procedure was start->do stuff->savevm->quit->other stuff->start again with the snapshot.
[14:46] <mouz> stgraber: that implies it is better to not combine
[14:46] <mvo> soren: kvm -loadvm snapshot gives me the same message
[14:46] <mouz> stgraber: (for me, doing iso testing)
[14:47] <mvo> soren: or is there a different command to use?
[14:48] <alex-weej> why is mlocate raping my notebook disk when i'm on battery?
[14:48] <soren> mvo: No, that's the right one.
[14:48] <alex-weej> in fact, why do we even have it on the Desktop installation at all?
[14:48] <alex-weej> if i open a bug for removing it, will i be laughed at?
[14:48] <soren> Good question.
[14:48] <soren> Both of them :)
[14:48] <alex-weej> :P
[14:48] <wgrant> alex-weej: We only just got rid of slocate.
[14:49] <wgrant> mlocate was a compromise, IIRC.
[14:49] <alex-weej> what's the difference?
[14:49] <soren> One could make the argument that now that there's a server-install seed, it makes sense to remove it from standard.
[14:49] <wgrant> mlocate doesn't reread the whole disk each time.
[14:50] <alex-weej> right, timestamps
[14:50] <alex-weej> i will open a bug against ubuntu-standard
[14:50] <wgrant> You probably want to reread the discussions from Hardy.
[14:55] <cjwatson> alex-weej: are you sure it's mlocate? do you have dlocate installed?
[14:56] <cjwatson> alex-weej: because dlocate can't yet work with mlocate and needs findutils installed, so that set of cron jobs will still run
[14:57] <cjwatson> alex-weej: I would resist removing mlocate; it's a lot better and it's worthwhile, even if you personally don't use it. Also, it's only a Recommends so you can remove it without removing ubuntu-standard if you choose. We can always make it better-behaved on battery
[14:59] <alex-weej> cjwatson: i'm just worrying about energy efficiency
[14:59] <alex-weej> and unnecessary disk thrashing
[14:59] <alex-weej> granted, it IS a lot better
[14:59] <alex-weej> but it's still useless for the vast, vast majority
[15:00] <alex-weej> If anyone has any business in a) using CLI tools, b) looking outside their home folder, c) looking at raw file system hierarchy and d) requiring to find a file based on filename alone, they are definitely in an extreme minority
[15:00] <cjwatson> I have difficulty believing that it is in fact significant unless something is going wrong
[15:00] <alex-weej> yes, it is causing climate change.
[15:00] <cjwatson> sigh. /ignore time I guess
[15:01] <cjwatson> sorry, I'm not having a conversation on these terms
[15:01] <alex-weej> oh... CC denier... :P
[15:01] <cjwatson> using a computer causes climate change
[15:01] <cjwatson> so I expect this channel to vacate immediately
[15:01] <alex-weej> lighten up
[15:02] <cjwatson> personally, I prefer to be able to use my computer efficiently when I need it, and spending a little time on mlocate every so often is much more efficient than having to run whole-filesystem find tools when looking for something
[15:02] <alex-weej> cjwatson: but dpkg -S already searches package installed files
[15:02] <cjwatson> and I don't buy arguments based on most users being naive and never looking outside /home, myself
[15:02] <alex-weej> and we already have Tracker
[15:03] <alex-weej> anywhere outside /home isn't even writeable for default users...
[15:03] <cjwatson> you're claiming that tracker is more efficient than mlocate? :-) We turned it off for a reason!
[15:03] <cjwatson> most users in fact do name their files something vaguely meaningful
[15:04] <alex-weej> like DSC419535.jpg ?
[15:04] <cjwatson> now, I think we should make the locate database easier to get at from the desktop
[15:04] <cjwatson> not throw it out
[15:04] <ogra> ++
[15:04] <ScottK> alex-weej: We've had this arguement like at least 5 times and where we are now is a reasonable compromise.
[15:04] <Ng> +9999999
[15:05] <alex-weej> ScottK: fair enough. we should at least make it obvious that you can remove it if you want to know why your disk is going tickticktickticktick when you're on battery
[15:05] <cjwatson> it shouldn't run while on battery, as I said above
[15:05] <cjwatson> that's a bug
[15:05] <alex-weej> or even at all... FDO notification icon
[15:09] <alex-weej> i can just about deal with stuff installed on the default seed that is used by a small portion of users that does nothing but take up disk space when not in use (HPLIP, Palm OS stuff, etc.)
[15:12] <seb128> alex-weej: or drivers for the hardware you don't have, etc too
[15:12] <seb128> alex-weej: or rhythmbox support for ipods
[15:13] <ogra> pitti, i.e. i find the comments and ideas of the pardus guys on the hal list scary but still they might have something etc ...
[15:13] <pitti> ogra: pardus is pretty new, isn't it? I haven't seen it yet
[15:13] <ogra> pitti, the thing is that we seem to not even look around anymore (i'm including me here) due to time constraints
[15:14] <ogra> which probably makes us lose good opportunities
[15:14] <alex-weej> seb128: none of that code runs once a day to make a stale filesystem database slightly less stale
[15:14] <pitti> ogra: *nod*
[15:14] <seb128> alex-weej: neither does hplip, palm os, etc
[15:14] <alex-weej> exactly! that's why i can accept it! :P
[15:14] <seb128> oh, I misread your comment
[15:15] <cjwatson> mlocate (0.20-2ubuntu1) intrepid; urgency=low
[15:15] <cjwatson>   * Skip cron job if on battery power.
[15:15] <cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Thu, 26 Jun 2008 15:19:06 +0100
[15:15] <alex-weej> show off
[15:15] <seb128> alex-weej: anyway you might want to read the ubuntu-devel archives for the discussion about the locate tools
[15:15] <seb128> there is some users using those a lot
[15:15] <alex-weej> seb128: nothing could be less exciting tbh, i just got angry and caught up in the moment
[15:15] <persia> cjwatson: Is that a raw skip, or will it retry if later on mains power?
[15:15] <cjwatson> persia: raw skip. it'll catch up the next day
[15:15] <seb128> and the gnome search tools dialog do too for example, etc
[15:16] <cjwatson> I was applying KISS
[15:16] <wgrant> cjwatson: Is your clock really fast?
[15:16] <persia> cjwatson: Makes sense.  I was asking in hopes of seeing the magic required to catch up on mains power,
[15:16] <cjwatson> wgrant: it is a few minutes fast, yeah
[15:16]  * persia anticipates devices that are never both powered on and on mains
[15:17] <cjwatson> persia: afraid I don't know such magic offhand ...
[15:18] <cjwatson> you could possibly cobble it together with anacron
[15:18] <persia> cjwatson: That seems to be a common state :)
[15:18] <ogra> well, you could surely add a switch to it
[15:18] <cjwatson> I could have done, but like I say, KISS
[15:18] <ogra> if you know you are on such a device you cn change behavior
[15:19] <persia> ogra: Some sort of trigger that caught the appropriate ACPI signals, and caught up on missing actions at that time?
[15:19] <alex-weej> can you not defer the job and use acpi.d to ask it to catch up?
[15:19] <alex-weej> like make it so the job does not get marked off as complete
[15:19] <alex-weej> can you do that with anacron?
[15:19] <cjwatson> patches welcome; I had five minutes and did a five-minute hack
[15:20] <ogra> persia, well something like a config option you can set on devices that never are on mains for exmple (or rarely being swithced on in this situation)
[15:21] <cjwatson> in fact, /etc/acpi/ac.d/85-anacron.sh already starts anacron when power is plugged back in
[15:21] <cjwatson> so I expect that either this already works out of the box or can easily be made to
[15:22] <alex-weej> cunning
[15:22] <cjwatson> at most, it might need to rerun jobs that exited non-zero, or something like that
[15:22] <persia> cjwatson: It's "can easily be made to": we'd need to wrap stuff.  It's just a matter of appropriate use case construction.
[15:23] <cjwatson> although admittedly anacron runs cron.daily not individual jobs so that's a little harder
[15:23] <persia> Well, anacron could be convinced to act differently, but that impacts cron, etc.
[15:27] <asac> robertknight2: looking at it now
[15:30] <mvo> evand: this python-apt crash you mentioned, is there a bugreport about that yet?
[15:30] <superm1> cjwatson, yeah i know :( didnt expect the breakage during hardy and couldnt sort it out quickly so it was a hack to make things get out the door
[15:30] <cjwatson> superm1: I filed a bug with a patch attached
[15:30] <superm1> cjwatson, oh wonderful.  thanks
[15:33] <evand> mvo: https://bugs.edge.launchpad.net/wubi/+bug/243105
[15:34] <MacSlow> seb128, regarding order of task... first I'll goffice/gnumeric... once I've that nailed down gdm?
[15:35] <seb128> MacSlow: alright
[15:35] <asac> robertknight2: fix committed. for now
[15:35] <asac> to intrepid
[15:35] <MacSlow> seb128, any hints for goffice you can give me right away off the top of your head?
[15:35] <mvo> evand: thanks! does the diff of cjwatson fixes the problem?
[15:36] <laga> cjwatson: thanks for the fixed branch.
[15:36] <kirkland> why does Synaptic sometimes report "The list of changes is not available yet." ?
[15:36] <evand> mvo: not in my first try, but I'm going to give it another go just to be sure.
[15:37] <seb128> MacSlow: I need to look at it, will do that in a minute
[15:37] <MacSlow> seb128, cool thanks
[15:37] <mvo> kirkland: it gets it from a cron job that is run only every 4h
[15:37] <mvo> evand: ok
[15:38] <kirkland> mvo: "it" being my client worstation, or "it" being something on the ubuntu server side?
[15:39] <kirkland> mvo: why would it not just pull that down, too, when it decides that changes are available?
[15:41] <mvo> kirkland: the ubuntu server side. we have "changelogs.ubuntu.com" that has static copies of the changelog files
[15:41] <mvo> kirkland: those get updated every 4h as it has to crawl over all of the (new) deb packages
[15:43] <cjwatson> evand: it was just a guess, of course
[15:43] <kirkland> mvo: hmm, could it pull it from Launchpad?  This seems to be updated almost immediately: https://edge.launchpad.net/ubuntu/hardy/+source/openssl/0.9.8g-4ubuntu3.3
[15:43] <kirkland> mvo: or at least print a link to that in Synaptic, if it hasn't been cached yet
[15:43] <mvo> kirkland: there are potentially a lot of requests, not sure how well launchpad would cope
[15:44] <mvo> kirkland: having a fallback link is a very good idea
[15:44] <evand> cjwatson: understood, I just want to be sure that I didn't make a mistake in applying the patch before moving on to the next idea.
[15:44] <mvo> kirkland: the whole extraction code is currently not very clever, it could certainly be much faster, but it is not currently
[15:44] <mvo> kirkland: (the extraction code on the server)
[15:45] <kirkland> mvo: gotcha
[15:45] <kirkland> mvo: i'm just bothered sometimes when Synaptic knows that an update is available, but can't tell me what it's going to (try to) fix
[15:45] <mvo> kirkland: I think I will add the fallback link right away (easy)
[15:45] <kirkland> mvo: cool!  thanks
[15:46] <mvo> kirkland: a LP export to a static file or a much faster extractor is probably the right answer, I should really look into that code again
[15:47] <kirkland> mvo: yeah, totally
[15:48] <kirkland> mvo: all the headers and LP fluff is totally extraneous
[15:50] <cjwatson> evand: a giant strace dump is probably the next requirement
[15:51] <evand> ok
[15:55] <cjwatson> o gst-plugins-ugly0.10: gstreamer0.10-plugins-ugly-dbg gstreamer0.10-plugins-ugly-doc
[15:55] <cjwatson>    [Reverse-Depends: Rescued from gst-plugins-ugly0.10]
[15:55] <cjwatson> thanks, component-mismatches, that's really helpful. WHY?
[15:56] <cjwatson> ah, <- gstreamer-dbus-media-service <- moblin-media
[16:11] <cjwatson> mvo: can you help me with bug 242815? I can't see anything to do with base-passwd in the detailed log
[16:14] <mvo> cjwatson: hm, the attached log looks corrupted?
[16:14] <cjwatson> mvo: I'm not sure what it's supposed to be like, I must confess
[16:15] <mvo> cjwatson: it should be a log of the dpkg terminal output to make pinpointing the problem a bit easier
[16:15] <mvo> cjwatson: I added a needinfo and asked for the /var/log/apt/term.log file
[16:17] <cjwatson> thanks
[16:28] <james_w> mvo: we ask for that and ../dist-upgrade/... a lot, is there any way they could be included automatically?
[16:29] <mvo> james_w: the current version in hardy-updates should add it automatically, there was a bug in stock hardy that prevented this for a  lot of cases
[16:29] <james_w> mvo: great, thanks!
[16:33] <geser> pitti: thanks for the apache2-mpm-itk upload
[16:37] <cjwatson> superm1: also, I think you may need to actually *remove* the old platform.intrepid branch if possible (or else switch the order of base URLs in seed_base) in order for that change to be effective
[16:44] <mvo> kirkland: the fallback link is now in bzr, thanks for the idea
[16:44] <kirkland> mvo: no problem!
[16:45] <superm1> cjwatson, i reordered it in that update.cfg and removed the branch afterward
[16:45] <superm1> thanks
[16:45] <cjwatson> ok, cool
[16:45] <kirkland> mvo: the "complaint" came from timrc in another channel, and I kinda said, "Yeah, that annoys me too..."  :-)
[16:49] <mathiaz> james_w: I'm trying to figure out how to use bzr looms to handle the patches between debian and ubuntu for the openldap package.
[16:49] <mathiaz> james_w: how would you recommend to handle the changelog ?
[16:50] <james_w> these are patches in debian/patches/ or directly to the source, or just debian/ changes?
[16:50] <james_w> or all three?
[16:50] <mathiaz> james_w: there is a whole bunch of patches related to adding apparmor support which I plan to track in one thread
[16:50] <mathiaz> james_w: only in debian/
[16:51] <mathiaz> james_w: to give you more background, all of openldap upstream code is in the debian svn repository
[16:51] <mathiaz> james_w: http://svn.debian.org/viewsvn/pkg-openldap/openldap/trunk/
[16:52] <james_w> yeah, changelog is not easy to handle this way
[16:52] <mathiaz> james_w: so I've branch the debian svn repository from the last debian upload
[16:52] <james_w> perhaps the best is just to have a "changelog" thread at the top and only modify the changelog in that.
[16:53] <mathiaz> james_w: right - that's what I thought doing
[16:53] <mathiaz> james_w: maintaining relevant changelog bits in each thread seems to complicated
[16:54] <james_w> yeah, it kind of makes sense to have them there, so you can tweak them as you make changes, but you will get conflicts galore.
[16:55] <james_w> and the threads will live across versions, so that maybe makes it not such a great idea.
[16:55] <cjwatson> RAOF: is it OK to sync gnome-do-plugins from Debian? it replaces your do-plugins package
[16:55] <mathiaz> james_w: right - I'll use a unique thread for the changelog then
[16:55] <mathiaz> james_w: may be one day dch will support loom threads and change to the changelog automatically :)
[16:55] <james_w> mathiaz: cool, let me know how it goes, I'm interested to see how it works.
[16:56] <james_w> mathiaz: heh, one day :-)
[16:58] <cjwatson> RAOF: I guess it probably is since you're in Uploaders on the Debian side too - but one obvious problem is that the new gnome-do-plugins needs to declare Replaces on gnome-do-plugin-amarok and gnome-do-plugin-rhythmbox, surely?
[17:00] <pitti> Riddell: ISTR that someone asked me to stop using guidance-backends in Jockey (currently discussing this with tseliot); is it obsolete? dead upstream? what's the replacement in KDE?
[17:01] <Riddell> pitti: it's pretty obsolete, xorg.conf has changed a lot and it makes lots of assumptions which are no longer true
[17:01] <Riddell> pitti: the replacement is just to use xrandr
[17:01] <pitti> Riddell: ah, so it entirely stops changing xorg.conf and thus the parser/writer won't be shipped at all any more?
[17:02] <pitti> Riddell: tseliot currently creates a library and some backends for doing xorg.conf changes, such as configuring the virtual screen resolution (necessary for configuring dual-head)
[17:02] <Riddell> pitti: guidance displayconfig is going away, replaced by a new xrandr tool
[17:02] <pitti> Riddell: ok, thanks for the heads-up
[17:02] <pitti> I'll see to replace it in Jockey then
[17:09] <pitti> asac: oh, still working on NM 0.6? I thought we'd switch to 0.7 in intrepid?
[17:09] <asac> pitti: we will. but since i received a patch which might be suitable for hardy SRU, i thought I'd let it bake in intrepid while 0.7 is not yet there :)
[17:10] <asac> pitti: probably the last upload of 0.6 to intrepid
[17:10] <asac> ;)
[17:10] <pitti> ah, good to know
[17:10] <asac> i just wanted to close an opened changelog ;)
[17:26] <soren> So... Does anyone feel like merging initramfs-tools?
[17:37] <Tm_T> hi sladen :)
[17:41] <calc> anyone know if nvidia resumes better from sleep than nv driver?
[17:41] <calc> i put my system to sleep last night and the video won't come back i think it is using the nv driver
[17:41] <calc> yea it was using 'NV"
[17:46] <mathiaz> james_w: hm - I'm lost now with bzr looms. I've created an apparmor thread and put all the the bits related to apparmor in it. After that I realized that the other patches I wanted to applied needed to be in threads below the apparmor thread. So I created threads below and add the relevant patches to them.
[17:47] <mathiaz> james_w: now I've realized that there is one missing bit in the apparmor thread - I go up to the apparmor thread to add it. But now I see all the previous merges in the apparmor thread.
[17:47] <mathiaz> james_w: ie merges == threads that I created below.
[17:47] <mathiaz> james_w: what should I do now ?
[17:48] <james_w> I'm not sure I understand.
[17:48] <mathiaz> james_w: http://paste.ubuntu.com/23156/
[17:48] <james_w> you have just done "up-thread" to the apparmor thread, and now you see merges in "bzr log" of each of the threads that you added underneath?
[17:49] <mathiaz> james_w: I see pending merges in the apparmor thread.
[17:49] <mathiaz> james_w: and all the merges are related to the threads below.
[17:50] <james_w> yeah, when you do "up-thread" it does a merge to make sure that everything will still fit together.
[17:50] <mathiaz> james_w: so now I have to commit the merge in the apparmor thread
[17:51] <mathiaz> james_w: this is like "refresh patches for new upstream version"
[17:53] <james_w> yeah, it's like when using quilt. If you change a patch in the middle of a quilt stack you should refresh that patch, and then push all the way to the top, fixing up conflicts and refreshing where needed.
[17:53] <james_w> what loom does is analogous to this, but it uses merges to make sure that there are no conflicts.
[17:53] <mathiaz> james_w: cool - thanks :)
[17:53] <james_w> no problem.
[17:55] <pitti> calc: on my desktop, nv resumes from disk nicely (for ages, since hoary or so); nvidia never *ever* worked
[17:59] <cjwatson> soren: TheMuso is working on it
[18:04] <calc> pitti: ah ok
[18:07]  * calc thinks his machine just won't resume in that case :-\
[18:07] <calc> it is amd64 instead of i386, so maybe its not uncommon for that not to work
[18:13] <soren> cjwatson: Excellent, thanks!
[18:16] <zul> slangasek: ping, whats up with the samba changes due to the gvfs stuff?
[18:22] <mouz> TheMuso: grub fails to install with the server iso also. I just saw you encountered it with the alternate ISO.
[18:22] <cjwatson> yeah, I'm debugging it now
[18:22] <cjwatson> it's an apt-setup bug
[18:26] <cjwatson> little bit of a slow process because I have to get through base-installer before it goes wrong
[18:40] <cjwatson> wow! that's such a cool bug
[18:41] <cjwatson> it breaks because it uses a local variable 'file' but doesn't initialise it; file=/cdrom/preseed/ubuntu.seed is passed on the kernel command line and this gets exported to an environment variable 'file' along the way
[18:46] <ScottK> pitti: I'm reading http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/122-Migrating-Emdebian-changes-into-Debian,-not-Ubuntu.html and thinking the package should be removed/blacklisted.  What do you think?
[18:46] <bryce> calc: you're right that Benjamin Drung is a good tester
[18:47] <bryce> calc: so he's finding that yes, disabling xcb makes the problem go away, however as a side effect, it also prevents compiz from working.
[18:48] <bryce> calc, so given that, I won't be pushing the noxcb change, and we'll need to identify a different way to fix this bug.
[18:48] <bryce> (although I should doublecheck Ben's conclusion that compiz depends on libx11 w/ xcb)
[18:51] <slangasek> zul: the samba changes due to the gvfs stuff are sitting in -proposed, waiting to be copied over to -updates
[18:52] <zul> ok any other regressions (just curious)
[19:04] <calc> bryce: can compiz be rebuilt against the new libs and not need xcb?
[19:04] <calc> bryce: it might have just been an overly aggressive linking
[19:05] <bryce> calc: I had assumed so, but Ben investigated that and found compiz doesn't provide a way to easily disable its xcb dependency.
[19:06] <calc> bryce: oh
[19:07] <calc> so how did we get by before x11 linked to xcb?
[19:07] <bryce> calc: and even if we could fix that, it makes me apprehensive at what other things might now be depending on xcb...   which would make SRU'ing this to hardy quite hard
[19:07] <calc> wasn't that just added ~ 2 months ago?
[19:07] <bryce> calc: thus my surprise
[19:08] <bryce> calc: http://pastebin.osuosl.org/8778
[19:09] <calc> bryce: i don't know how this works in detail, but couldn't compiz just rebuild against libxcb1-dev also?
[19:10]  * calc will download the source and take a look at it
[19:10] <bryce> calc, well looking at Ben's crash error, compiz seems to be directly linking to XGetXCBConnection
[19:11] <bryce> perhaps there is a non-xcb version of that routine, or perhaps the call can be ifdef'd out
[19:11] <bryce> I'm curious about ben's suggestions on fixing the bug in openoffice.org-gtk or openoffice.org-core
[19:12] <calc> well xcb existed before x11-xcb patches in ~ april of this year, right?
[19:12] <calc> iirc it has existed for ~ 4-5 years
[19:12] <calc> well if we could even determine what is causing the crash in ooo-gtk then maybe it could be fixed
[19:12] <bryce> yeah it's been around for quite some time, but I don't think many distros have shipped it, at least not until recently
[19:12] <calc> but it isn't reproducible so it would be hard to verify if it was fixed as well
[19:13] <bryce> agreed - given the non-triviality of fixing it in compiz, and the chance that other apps may surprise us with sudden new xcb dependencies, if we can work around it in OOo, that'd probably make the easiest SRU to justify
[19:14] <bryce> in any case, the fact that it is definitely due to something in xcb gives us a strong hint
[19:15] <calc> well that is the thing i have no idea how to fix it in OOo as I can't even get the problem to occur
[19:15] <calc> i have been trying for a week or various systems and archs
[19:15] <calc> even the users who have the problem create a new account and it is fixed for them as well
[19:15] <calc> but deleting their openoffice.org config files doesn't help
[19:16] <calc> so its outside of the ooo settings that is causing the problem (i guess?)
[19:16] <bryce> calc, have backtraces been collected?
[19:16] <calc> maybe, i'll have to see if i can find a good backtrace out of the dupes
[19:16] <calc> hmm x11-xcb didn't exist in gutsy, so i guess compiz added requirement for it since then
[19:18]  * bryce nods
[19:18] <calc> bryce: maybe we need to get him to submit a full apport crash bug
[19:18] <bryce> mvo could probably give us some background there if we need it
[19:18] <bryce> yeah
[19:18] <calc> the ones i have seen have backtrace but with just hex addresses
[19:20] <bryce> calc, ben sent me a strace of it, let me forward to you...  calc@ubuntu.com?
[19:20] <calc> ccheney@ubuntu.com
[19:22] <mathiaz> james_w: \o/ - I've finished imported ubuntu openldap version in a loom based bzr repository. Looks like this now: http://paste.ubuntu.com/23178/
[19:23] <mathiaz> james_w: I've used bzr record to record the last upload to intrepid - 2.4.9-1ubuntu3.
[19:23] <mathiaz> james_w: is there a way to see the list of records ?
[19:25] <calc> bryce: i wonder if this bug is related to another Xrandr bug i found that causes crashes
[19:26] <calc> bryce: apparently Xrandr sometimes is getting mapped in twice
[19:26] <bryce> hmm
[19:26] <calc> i can update the build to current ooo-build and have him test it and see if it fixes his problems :)
[19:27] <calc> it definitely looks like the updates fix some of the non xcb backtrace crashes i have seen reported recently
[19:27] <calc> not certain if it fixes those as well though
[19:27] <bryce> possibly, but I don't think there's a huge overlap between xrandr and xcb.  They probably do interact at some level, but xrandr issues I'd expect to look differently than this
[19:27] <calc> it might end up that users that have -gtk installed see xcb crashes and users with -kde see the other crashes i am getting
[19:28] <bryce> oh that'd be interesting
[19:28] <calc> might be a different bug entirely though
[19:28] <calc> but it would be good to get the one that affects -kde users in any case
[19:28] <bryce> calc: do you have a changelog entry in the latest updates that mentions anything that might be related to this issue?
[19:28] <calc> and if it fixes the -gtk issue as well then great ;-)
[19:28] <calc> https://bugzilla.novell.com/show_bug.cgi?id=398244
[19:28] <bryce> (maybe we could dig in and see if we could extract a patch)
[19:29] <calc> this is the bug report that i found a report of in ooo-build
[19:29] <bryce> ok
[19:29] <calc> and it specifically references an upstream bug report about crashing on 64bit
[19:29] <calc> which most (all?) the users with this bug seem to be 64bit users (iirc)
[19:30] <bryce> mmm, bad file descriptor
[19:30] <bryce> xcb locking issues can produce "bad fd" errors
[19:32] <bryce> calc, did you see this?  https://bugzilla.novell.com/show_bug.cgi?id=398244#c17
[19:33] <bryce> calc, it's interesting that in ben's strace it shows a crash in libvclplug_gtk680lx.so
[19:33] <calc> bryce: yea very similar to the gtk one
[19:34] <bryce> so I think you're maybe right that this bug report is related
[19:34] <calc> which was why i was thinking it might just look different between the two libs
[19:34] <calc> they both crash in the vclplug but with different backtraces :)
[19:34]  * bryce nods
[19:34] <calc> i'll try to get a build going here within a few hours to have him test tomorrow (takes around 4hr or so to build)
[19:35] <bryce> are these managed in a public VCS somewhere?  might be useful to look at their changelogs
[19:35] <calc> if you want to email him back let him know i am creating new test ooo debs to see if it resolves the issue
[19:35] <calc> yea
[19:35] <calc> svn.gnome.org ooo-build
[19:35]  * calc finds the full url
[19:35] <calc> svn+ssh://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-4-1
[19:37]  * calc hopes the ooo-build diff is small
[19:37] <bryce> ah, re: the multiple-xrandr mapping issue I see in comment #23 it mentions this; however you can see they fixed that issue in #24, and then a user says in #25 the issue still exists.  So sounds unrelated
[19:37] <bryce> #25 has a nice backtrace with symbols
[19:38] <calc> it sounds like even thought it was fixed it wasn't in the official build the user was using at the time yet
[19:38] <bryce> looks like the crash is occuring within destructors - does that make sense with your understanding of the problem?  that it occurs when shutting things down?
[19:38] <calc> on the kde crashes that sounds right, not sure about the gtk side
[19:39] <calc> users have mentioned it crashes on exit under kde
[19:39] <bryce> ahh, you're right - #31 that user confirms it's fixed
[19:39] <bryce> so maybe it *is* xrandr being double mapped into the app
[19:39] <calc> 11KB of patches since our last upload
[19:39] <calc> so not too bad
[19:40] <bryce> mm, I can imagine that such a thing could potentially result in xcb requested to do two locks, thus resulting in a locking error
[19:40] <calc> i probably can get slangasek to approve that if it fixes the issue :)
[19:40] <bryce> awesome
[19:40] <bryce> ok, I'll email ben this info
[19:40] <slangasek> bryce: bah ... -nsc accepted, but you left out the LP bug # in the changelog. :)
[19:41] <calc> i also have two meetings tomorrow to prepare for so i will do my best to get this ready for him to test
[19:41] <bryce> doh
[19:46] <calc> it shouldn't take more than an hour to setup
[19:46] <calc> i'm creating a new chroot for it at the moment
[19:49] <bryce> mail away (cc'd you too)
[19:58] <slangasek> bryce: also, did Q-FUNK mention anything to you about fixing up -geode wrt https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-nsc/+bug/219630/comments/50?  I guess I was expecting some feedback from him about whether this would happen; I'll push the currently-available upload through if necessary due to the severity of the issue and the timing, but would really like to see those buglets fixed
[19:59] <bryce> slangasek: indeed yes, we were discussing that last night.  I asked if he needed my help on that too, but it sounded like he felt he had it under control, let me dig up the exact discussion...
[20:00] <mkrufky> mario_limonciell: ping
[20:00] <mkrufky> oops
 Q-FUNK: ok.  you may want to update the state for the -geode/hardy task
 geode/hrady is still to be done
[20:01] <bryce>  I'd need to clena up the chnagelog as steve suggested
[20:01] <bryce>  geode/intrepid is what's done (transition in -all, plus latest upstream package via debian)
[20:01] <bryce> * bryce nods
[20:04] <bryce> earlier in the discussion, "I think that -geode was the only one where he'd rather have me finetune the changelog, before we'd move ahead."
[20:19] <slangasek> bryce: well, he doesn't seem to be around, so I'm not thinking it's under control given that I had asked for that upload to happen last night
[20:19] <bryce> slangasek: I can take care of it right now, if you point me at what needs fixed
[20:20] <slangasek> bryce: let me extract this upload and dump it to chinstrap
[20:22] <slangasek> er, I mean rookery :)
[20:22] <slangasek> bryce: http://people.ubuntu.com/~vorlon/xserver-xorg-video-geode_2.9.0-1ubuntu2.2.dsc , just needs the two fixes I mentioned in that bug log
[20:24] <bryce> great, on it.
[20:25] <mitsarionas> hi all... does anyone know when intrepid alpha 1 is gonna be released?
[20:25] <calc> mitsarionas: sometime this year :)
[20:26] <mitsarionas> lol good to know :)
[20:26] <calc> mitsarionas: i think the hope was for friday(?)
[20:26]  * calc points to slangasek
[20:27] <mitsarionas> i'm getting bored without those dozens of daily updates
[20:28] <slangasek> the hope was "today", but the time machine that normally lets us release images before we fix the installation problems is on the fritz
[20:28] <zul> slangasek: is there 8.04.1 for ubuntu-server cdimages?
[20:28] <calc> lol :)
[20:28] <slangasek> zul: posted at http://iso.qa.ubuntu.com/qatracker/build/all/all
[20:29] <mitsarionas> lol :) glad it's getting out these day though
[20:30] <zul> slangasek: thanks
[20:47] <Gadi> Hi, all.  I have an interesting trident video driver issue, perhaps someone has run into?
[20:47] <Gadi> trident driver + Xorg 1.3.  Everything works fine, except after a period of time, the USB controller dies completely and the USB mouse stops working
[20:47] <Gadi>  its as if the driver is writing over the USB controller's memory space
[20:48] <Gadi> I only ask the question here, because I am not sure where to go upstream with this
[20:48] <Gadi> and I was hoping maybe an Ubuntu Xorg guru may have seen this or know a workaround to limit the memory space the server will use
[20:48] <bryce> Gadi: how are you determining it's a video driver issue?  If it's a USB controller failing, my first guess would be it's a kernel issue...?
[20:49] <Gadi> because it affects only trident driver hardware and the same hardware is unaffected if it uses vesa driver
[20:49] <Gadi> also, it happens after extended use of the xserver (over a period of days)
[20:50] <slangasek> hrrrm, looks like we have some packages now being auto-synced that build-dep on a newer debhelper than what we have in intrepid
[20:50] <Gadi> it is very repeatable on the same trident-driver hw platform
[20:50] <Gadi> (VIA EPIA-5000 mini-itx mobo)
[20:54] <bryce> Gadi, it's not something I've seen, but trident is not a very common driver
[20:55] <bryce> Gadi: usually it's better to make bug reports like these to Launchpad than here on IRC
[20:55] <Gadi> fair enuff
[20:55] <Gadi> thanks
[20:55] <bryce> also, just because it works with -vesa does not necessarily mean it's not a kernel issue, but that's a good data point
[20:56] <ogra> Gadi, is that any disklessworkstation machine ?
[20:56] <ogra> i could probably verify
[20:56] <Gadi> i dont know if they have one that uses that mobo
[20:56] <Gadi> I can ask Jim
[20:57] <ogra> well, you said scott has it too
[20:57] <Gadi> thx, ogra
[20:57] <Gadi> yeah
[20:57] <bryce> I think you'd want more evidence that it was definitely an X issue before going upstream to freedesktop... perhaps take a look at the debugging handbook at wiki.ubuntu.com/X as a start
[20:57] <ogra> he only has DW i think
[21:01] <slangasek> kirkland: -server images published now that have the right apt-setup; I'll post them to the ISO tracker shortly, but you can grab them already from current
[21:01] <kirkland> slangasek: thanks, downloading...
[21:03] <bryce> slangasek: does this description look right now?  https://bugs.launchpad.net/ubuntu/+bug/219630/comments/65
[21:04] <slangasek> bryce: I would s/static xorg.conf's/your configuration/
[21:04] <bryce> ok
[21:04] <slangasek> to avoid the nastiness of trying to pluralize a filename :)
[21:05] <bryce> yeah that reads better
[21:10] <bryce> slangasek: ok uploaded
[21:11] <slangasek> bryce: thanks, wll watch for it in the queue
[21:12] <bryce> slangasek: I'm not sure I fully grok how this is going to affect people using "amd" in their xorg.conf's, but I'll trust you and martin here; I'm probably just not correctly understanding it
[21:13] <slangasek> bryce: well, previously there was an 'amd' symlink, which has gone away for $obscure_ltsp_reason; now it's not there, so anyone whose xorg.conf references amd will definitely find themselves without a driver
[21:13] <slangasek> so the xserver-xorg-video-amd transitional package is solely for dependency purposes, at this point; it doesn't provide backwards-compat for xorg.conf
[21:14] <mitsarionas> when it says that the kubuntu intrepid isos are rebuilding, does it mean like right now?
[21:16] <bryce> slangasek: ok, that's sort of how I interpreted it...  I guess I'm not understanding how this won't anger users who now have to modify xorg.conf?
[21:16] <slangasek> bryce: I'm not sure that it won't.  Do you have time today to implement a better fix, perhaps one that updates xorg.conf?
[21:17] <slangasek> bryce: or do you want me to sit on this upload (in -proposed, perhaps) until you can talk to Q-FUNK about why this is needed?
[21:18] <bryce> hmm
[21:18] <bryce> ogra: do you have any insights/opinions here?
[21:19] <bryce> slangasek: well, I'm curious what exactly breaks in LTSP when the symlink is present, and if we could allow that to remain and perhaps just handle it better
[21:20] <bryce> slangasek: however I know we're pressed to get 8.04.1 done and q-funk really wants this change included.
[21:20] <slangasek> bryce: yes, I share that concern.  pitti did question that change in the bug log, and in the end approved it, I wasn't intending to second-guess him on that
[21:20] <bryce> if I understand this changeset correctly, the symlink change is separate from the pci id change
[21:20] <slangasek> it is, yes
[21:23] <slangasek> hrm, why does xserver-xorg-video-amd Conflicts/Replaces xserver-xorg-video-geode?  that's... backwards
[21:23] <slangasek> I didn't notice this in the previous upload, hrm
[21:25] <slangasek> right, sure enough, it was there
[21:28] <ScottK> pitti: I am hoping you have some time for MIR processing on your archive day tomorrow.  I added a bunch onto the stack.
[21:35] <kirkland> slangasek: cjwatson: nice, that one installed!
[21:35] <slangasek> \o/
[21:38] <slangasek> pitti: do you mind if I do an updated debhelper merge?  there are some packages coming in with a versioned build-dep on the newest debhelper
[21:41] <james_w> mathiaz: no idea if you can get the list of records easily. I'm sure there's a way with python, but I couldn't tell you it.
[21:41] <james_w> mathiaz: you might want to file a bug on bzr-loom.
[21:41] <bryce> slangasek: yeah I think this upload needs a bit more thought.  unfortunately I think this may require more packaging-fu than I have at hand
[21:42] <slangasek> bryce: hmm, ok
[21:42] <mathiaz> james_w: IIUC, record is the way to say "this is 3ubuntu2."
[21:43] <mathiaz> james_w: right ?
[21:44] <james_w> record is a way to make loom do it's thing so that someone else can branch/pull/merge the loom sensibly I think
[21:44] <james_w> I don't know if it's also used for recording interesting points
[21:44] <james_w> I've never fully grabbed it.
[21:44] <james_w> s/grabbed/grasped/
[21:45] <slangasek> bryce: if I can find time to work up some maintainer script magic for this in the next day or so, I will; but no guarantees on that front
[21:46] <bryce> slangasek: ok; I'm going to spend the next couple hours studying it myself
[21:47] <bryce> slangasek: I also want to compare with what was done in the -i810/-intel transition, since that seems very analogous to this
[21:47] <slangasek> ok
[21:47] <bryce> I'd also like to look into what that ltsp issue was
[21:50] <slangasek> kirkland: are you also going to be testing server amd64, or does someone else have that task?
[21:51] <kirkland> slangasek: i'm doing it now ;-)
[21:51] <slangasek> ok
[21:52] <liw> so what's the status of alpha1 ISO image testing?
[21:53] <kirkland> slangasek: which just succeeded ;-)
[21:53] <liw> really nobody has tested the alternate images?
[21:53] <slangasek> liw: apt-setup was found broken yesterday so we had to get an updated package in and respin ISOs; I don't have any results reported yet for ubuntu alternate yet
[21:53] <slangasek> since those images just became available in the past 2h
[21:54] <liw> ah, ok, I'll update and test, then (assuming qemu is still OK)
[21:54] <slangasek> yes, definitely
[21:54] <liw> I found the apt-setup problem also
[21:54] <kirkland> slangasek: i'll do the LVM & encrypted LVM now
[21:54] <mitsarionas> any idea when the new kubuntu isos will be available?
[21:54] <slangasek> kirkland: not required for alpha 1 (i.e., any failures you find there won't prompt me to respin), but feel free
[21:55] <kirkland> slangasek: oh, well then :-)
[21:55] <kirkland> slangasek: i've plenty else to do!
[21:55] <mathiaz> slangasek: which tests are required for alpha1 ?
[21:55] <slangasek> mitsarionas: kubuntu has some metapackage issues that the kubuntu team haven't sorted out yet; as such, kubuntu will probably miss out on alpha1
[21:55] <slangasek> mathiaz: "it installs, ship it!"
[21:56] <mitsarionas> :((((
[21:56] <Better_than_you> Will Kubuntu 8.10 LTS ship KDE3 or 4?
[21:56] <liw> slangasek, what test coverage are you interested in? all test cases for the alternate images? any one? should I aim to do all of one arch and then start on the other?
[21:56] <slangasek> Better_than_you: a) 8.10 will not be an LTS release; b) 4
[21:56] <liw> slangasek, given that I can do two or three at a time
[21:57] <slangasek> liw: one good install for each image is all we require at this stage
[21:57] <Better_than_you> I thought Kubuntu 8.10 was LTS since they delayed it for 8.04
[21:57] <slangasek> liw: if you have spare resources, a test of edubuntu would also be good
[21:57] <liw> slangasek, my main restriction is my brain
[21:58] <liw> 20080626 is the version to concentrate on?
[21:58] <slangasek> liw: the versions posted at http://iso.qa.ubuntu.com/qatracker/build/all/all
[21:58] <slangasek> mm, except edubuntu was respun but the version number not updated there, sec
[21:59]  * liw starts on alternate i386 and amd64
[21:59] <slangasek> there, that's better
[22:00] <pwnguin> bryce: isn't syncronization and IPC fun?
[22:00] <bryce> pwnguin: :-)
[22:01]  * liw remembers that it's not a good idea to share the same qemu image file between different instances
[22:01] <cjwatson> kirkland: woo
[22:01]  * liw introduces head and desk
[22:01] <pwnguin> this probably is why locking should let processes who own locks through :(
[22:02] <lifeless> liw: you 'testing' again ? :)
[22:02] <liw> lifeless, ISO images for intrepid alpha1, yes
[22:04] <lifeless> well I was referring to dual-mounting disk images :)
[22:04] <lifeless> that would count as cluster fs testing surely :)
[22:04] <liw> that was just a mistake :)
[22:05] <liw> lifeless, I did, however, have the pleasure of import .git into bzr yesterday :)
[22:05] <lifeless> lol
[22:05] <liw> lifeless, I was looking at packages to merge from Debian, and using bzr to keep track of what I do to them, and one of the packages had a .git directory
[22:06] <liw> (which _I_ think should be cause for rejecting an upload into Debian, but hey...)
[22:06] <lifeless> hmm
[22:06] <lifeless> bzr should default-ignore that perhaps
[22:11] <liw> lifeless, since it works, I'm fine with bzr doing that; if .git gets default-ignored, then so should the others: .svn, .hg, CVS, *,v, RCS, {arch}, and whatnot
[22:11] <lifeless> liw: we do default ignore some :)
[22:12] <kirkland> slangasek: okay, i completely lied......
[22:12] <liw> lifeless, incidentally, my life would sometimes be easier if I could do "bzr add --ignore-nothing"
[22:12] <kirkland> slangasek: I did end up testing amd64 server + LVM/encryption, and it works fine ;-)
[22:12] <kirkland> Keybuk: there's some errors about not being able to find /sbin/udevsettle, FWIW
[22:13] <kirkland> Keybuk: but the boot happens okay
[22:13] <lifeless> liw: cat << EOF >> ~/.bazaar/ignore
[22:13] <lifeless> liw: or python
[22:13] <lifeless> liw: and then you could make it into a plugin
[22:13] <cjwatson> lifeless: ('>~/.bazaar/ignore')
[22:13] <liw> lifeless, that's more than one line of code, and less suitable for a temporary operation
[22:14] <lifeless> cjwatson: ECAFFEINE
[22:14] <kirkland> Keybuk: looks to me like there's a call to /sbin/udevsettle BEFORE the encrypted-lvm-mount has succeeded
[22:14] <lifeless> kirkland: we do need to bring up enough devices to find the luks partition :O
[22:15] <liw> cvs has -I options to allow ignores to happen for one invocation only, which is sort of what I want, I guess
[22:15] <liw> lifeless, however, since my most common need for that option is for my unpack-debian-sources script, and I've already written that, I don't think I'll bother even filing a wishlist bug
[22:16] <beDrung> hi
[22:16] <lifeless> liw: fair enough
[22:18] <beDrung> hi bryce
[22:23] <beDrung> calc: how far are you with the oo.org patch?
[22:24] <kirkland> lifeless: hmm, should i open a bug on that one?
[22:28] <lifeless> kirkland: uhm, only file bugs you see/create :)
[22:28] <lifeless> kirkland: luks stuf works fine for me modulo not-using-uuids and having to unlock it twice
[22:32] <bryce> beDrung: heya
[22:32] <beDrung> bryce: irc is faster than mail
[22:33] <bryce> beDrung: indeed :-)
[22:34] <beDrung> bryce: is there a patch i can test?
[22:34] <bryce> beDrung: calc got the patch and is building deb's - it'll take hiim a few more hours
[22:34] <bryce> I've not seen the patch myself, but if calc is abouts maybe he can give a pointer to it
[22:35] <bryce> here's the bug report https://bugzilla.novell.com/show_bug.cgi?id=398244
[22:36] <bryce> ubottu: shush
[22:37] <calc> beDrung: priming ccache right now
[22:37] <calc> beDrung: then will build it with the new patches
[22:37] <calc> beDrung: depending on how fast a machine you have it can take upwards of 16hr for a single build
[22:37] <calc> i'm just going to be pulling ooo-build-2-4-1 to do the build
[22:38] <beDrung> calc: my desktop pc ( http://www.sysprofile.de/id33138 ) is fast (Core2Duo E6750).
[22:39] <liw> slangasek, oops, coreutils fails to build :(
[22:39] <beDrung> calc: here in germany it's 23:39. so time is running.
[22:39] <calc> beDrung: sounds slightly slower than what i build on, you could build it, but make sure you use DEB_BUILD_OPTIONS=nogsi or it will take you at least 6hr or more (i would imagine)
[22:40] <slangasek> liw: aw man, we have to make it *build*, too?
[22:40] <calc> beDrung: you just need to get current ooo-build-2-4-1 from svn.gnome.org and replace the version in ooo source with it then run the autotools stuff on it and then build
[22:41] <calc> beDrung: it definitely will take longer than you are awake tonight to finish though
[22:41] <liw> slangasek, hm, I tested it before asking for the upload, but it turns out that I did that in a hardy pbuilder, not an intrepid one (and my hardy debootstrap doesn't know about intrepid, so I can't even create an intrepid pbuilder tgz)
[22:42] <slangasek> liw: you can create an intrepid chroot by telling debootstrap to use the hardy script
[22:42] <calc> even a ccache primed build on my machine takes over 100m to build
[22:42] <cjwatson> liw: there's also a version of debootstrap that knows about intrepid in hardy-backports
[22:42] <slangasek> liw: i.e., debootstrap intrepid /chroots/intrepid http://mylocalmirror/ubuntu hardy
[22:43] <liw> cjwatson, I'll get that one
[22:43] <beDrung> calc: does the build use more than one core?
[22:43] <calc> beDrung: yes
[22:43] <liw> slangasek, yeah, I'd have to get pbuilder do that for me, but there's an option for it
[22:43]  * calc wishes intel would release a 8core desktop chip
[22:43] <liw> oops, my mirror doesn't do hardy-backports
[22:44] <calc> beDrung: some of the more time intensive stuff can't be easily parallelized like the dh_shlibdeps stuff
[22:44] <calc> that part alone takes over 20m iirc
[22:45]  * beDrung wishes intel or amd would release a 16core desktop chip with a maximum tdp of 65W for my passic cooled tower.
[22:46] <calc> heh
[22:47] <liw> 65W is about 64 too many :)
[22:47] <calc> even poor little atom uses more than 1w
[22:50] <beDrung> 1w would be cool. but 140W maximum for my whole pc is ok and my tower ( http://www.zalman.co.kr/ENG/product/Product_Read.asp?idx=186 ) has no problem to cool this.
[22:53] <calc> my system under load is ~ 150W at the wall
[22:53] <calc> under load
[22:53] <calc> er i already said that, doh
[22:54] <beDrung> what graphic card do you use?
[22:55] <liw> slangasek, ok, I reproduce this under an intrepid pbuilder, I'll see if I can fix it
[22:55] <calc> beDrung: nvidia 7600GT
[22:55] <slangasek> liw: cheers
[22:55] <calc> got it before amd bought out ati
[22:55] <calc> doesn't have a fan :)
[22:55] <liw> slangasek, even if it uses an unspeakable build system
[22:56] <beDrung> 30 - 40 W
[22:56] <calc> my next system will probably just have a intel igp
[22:56] <calc> that will save a lot of power
[22:57] <calc> also if my cpu wasn't o/c it wouldn't use nearly as much power
[22:57] <beDrung> i have upgraded to a radeon hd3650, but i think it is too early. ati and radeonhd driver currently do not support xv and fglrx has some problems.
[22:57] <calc> oh
[22:58] <calc> well its probably better than using nvidia (gag)
[22:58] <ion_> ”some” :-D
[22:58] <calc> i can't even resume from suspend
[22:59]  * calc will eat a hat when nvidia finally writes an open source driver and releases full docs for all their hardware like AMD/ATI
[22:59] <calc> i only got the nvidia card because it was the better of the two crappy non-oss friendly brands at the time :-\
[22:59] <alex-weej> nvidia is still way better than ati
[23:00] <alex-weej> my nvidia in my macbook pro is a treat
[23:00] <bryce> calc, during these builds have you checked that your CPU's are all averaging at 100%?
[23:00] <alex-weej> i get redirected 3D acceleration
[23:00] <beDrung> while watching movies some stripes run through the picture (may be a sync problem) and compiz + video in window is flickering, so i deactivated compiz.
[23:00] <calc> bryce: yea, i think it is running 4 threads
[23:01] <beDrung> but: suspend with fglrx works.
[23:01] <calc> bryce: its 100% most of the time anyway, until it gets into debian stuff that isn't parallelized (i am assuming)
[23:01]  * bryce nods
[23:01] <slangasek> liw: that seems like a rather strange build failure
[23:02] <bryce> calc: have you tried seeing if ccache helps?
[23:02] <calc> bryce: afaict things like dpkg-shlibdeps are REALLY resource intensive and don't work parallelized
[23:02] <calc> bryce: already do that to get it down to only ~ 2h build
[23:02] <slangasek> liw: strange in that it didn't also fail in Debian, I mean
[23:02] <bryce> calc: *nod*
[23:02] <calc> bryce: eg ia64 buildd takes > 16h to build
[23:02] <calc> also turn off all the language export stuff as well
[23:02] <liw> slangasek, interestingly, if I run the build on hardy from an unpacked source tree, it succeeds
[23:03] <beDrung> calc: on which platform do you compile it?
[23:03] <slangasek> liw: getopt changes?
[23:03] <calc> beDrung: amd64
[23:03] <liw> slangasek, I don't know, the build just finished
[23:03] <calc> beDrung: takes about the same amount of time on i386 as well
[23:03] <calc> beDrung: at least on the same system
[23:03] <beDrung> yes, but i only need amd64 to test it. ;)
[23:04] <slangasek> liw: I'm guessing it's a change in the glibc getopt behavior
[23:04] <bryce> calc, I'd experimented with optimizing xorg builds via ccache and putting everything on a ramdisk, using a local cache for pulling deps, etc.  ccache made the biggest difference, the rest was just nickels and dimes
[23:04] <slangasek> and therefore fixing it is a one-way trap, @yay
[23:04]  * liw sees this in coreutils code: /* FIXME: comment */
[23:05]  * liw wonders why factor is in coreutils in the first place
[23:06] <bryce> calc: I found that the way xserver is packaged, it wasn't using all the cpu's (-j flag couldn't be set).  So the next step was to look at fixing the packaging, but I don't build xserver all that frequently, and with it down to below 15 min that's not too bad
[23:06] <beDrung> calc: what is the checkout http address?
[23:07] <calc> http://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-4-1
[23:07] <calc> i think that will work
[23:07] <calc> i use it with svn+ssh://
[23:08] <beDrung> why is oo.org on gnome.org?
[23:09] <beDrung> calc: checkout works
[23:11] <sbeattie> asac: ping
[23:12] <calc> beDrung: because someone put it there :)
[23:12] <calc> beDrung: its go-oo not openoffice.org
[23:12] <calc> beDrung: novell (go-oo) and sun (openoffice.org) don't get along especially well
[23:13] <calc> so that is why it isn't hosted somewhere on openoffice.org
[23:14] <beDrung> where is the difference between those two?
[23:15] <calc> go-oo is a large set of patches on top of openoffice.org
[23:15] <slangasek> is the maintenance team for go-oo called the "go-oo power rangers"?
[23:15] <liw> slangasek, yeah, indeed: it's a difference in the output of getopt(3), the hardy version of libc6 uses %c and the intrepid version uses '%c'
[23:16] <slangasek> liw: right; so we can patch the testsuite, or complain to doko about the behavior change in libc6?
[23:17] <liw> slangasek, I'd say the behavior change is for the better, so I'd rather patch the test suite
[23:17] <liw> there's a bunch of other such changes in getopt... `%s' changed to '%s' for example
[23:19]  * slangasek stares at top.  No, I don't think that process was actually using 935% of my processor...
[23:19] <liw> slangasek, what's the correct procedure for fixing this? should we revert the sync request and do a merge instead or what?
[23:20] <mathiaz> slangasek: what's the point of supporting hdb and bdb in the slapd package ?
[23:20] <slangasek> liw: the sync is already done; the next stage is to file a bug in LP about the build problem, provide a patch (debdiff), and subscribe ubuntu-main-sponsors
[23:20] <mathiaz> slangasek: why not just setup hdb ?
[23:20] <slangasek> mathiaz: "both are good", vaguely
[23:20] <liw> slangasek, I'll do that then
[23:21] <slangasek> mathiaz: bearing in mind that the package has had somewhat irregular maintenance, and hdb has only become a preferred backend relatively recently
[23:21] <mathiaz> slangasek: right - but that was preferred over ldbm
[23:21] <slangasek> liw: also, subscribing me directly in this case since I'm well-poised under the circumstances to sponsor with a minimum of extra hassle
[23:21] <mathiaz> slangasek: or bdb was the default before hdb ?
[23:22] <slangasek> mathiaz: bdb was the default before hdb, I believe
[23:22] <slangasek> hdb was considered "new and untested" at the time we made bdb the default
[23:23] <LaserJock> bryce: around?
[23:24] <bryce> LaserJock: heya
[23:24] <mathiaz> slangasek: ok.
[23:25] <slangasek> mathiaz: how important is it to change the default for this cycle?
[23:25] <LaserJock> bryce: got a question on the xcb/x11 issue
[23:25] <slangasek> I think we would have some migration code for the ldbm->bdb switch that we should resurrect, if we're going to change
[23:25] <bryce> LaserJock: shoot
[23:25] <slangasek> and we should definitely discuss whether bdb should be considered obsolete wrt the packaging, or if there are still cases where it should be preferred
[23:26] <LaserJock> bryce: I've got a guy who's trying to install a Java app on hardy, but it crashes with something about locking and spits out a backtrace with libxcb and libx11
[23:26] <bryce> LaserJock: *nod*
[23:26] <LaserJock> bryce: I'm wondering if you have any pointers on how to debug it
[23:26] <mathiaz> slangasek: I've started to look into cn=config migration
[23:26] <slangasek> mathiaz: does that rely on hdb as the backend?
[23:27] <bryce> LaserJock: sure
[23:27] <LaserJock> I have another colleague who's also running hardy and he doesn't seem to have the issue. I'm having them compare notes on installed updates (I didn't know if you'd done anything yet)
[23:27] <mathiaz> slangasek: and when creating a database configuration from an ldiff file, you need to set an objectclass to olcBdbConfig or olcHdbConfig depending on the backend you want to use
[23:27] <bryce> LaserJock: java and xcb haven't had a history of getting along, although afaik the issues had been worked out
[23:27] <mathiaz> slangasek: currently this is done by substitution of @BACKEND@, which is either bdb or hdb
[23:27] <bryce> LaserJock: no we haven't made any changes which would affect java one way or the other
[23:28] <LaserJock> bryce: well, I'm not sure if we're using Ubuntu's Java
[23:28] <LaserJock> would that make a difference?
[23:28] <mathiaz> slangasek: properly generating the ldif entry for the db config means more logic to set the olc{BH}dbConfig
[23:28] <mathiaz> slangasek: the config backend doesn't rely on bdb
[23:28] <mathiaz> slangasek: it's stored as a bunch of ldif files in /etc/ldap/slapd.d/
[23:29] <bryce> LaserJock: however in the cases we've troubleshot so far, the issue is very, very irregular - often dependent on timing issues and such.  So reproducing the issues can be quite tricky, even if you have roughly similar systems
[23:29] <mathiaz> slangasek: my question has more to do with simplifying the code to get read of the backend support - and just provide hdb by default in the debian scripts.
[23:29] <bryce> LaserJock: 86103 may be of interest
[23:30] <slangasek> mathiaz: ok.  I would suggest checking with Howard about whether there are any cases where we *need* to continue supporting bdb, or if we should go ahead and migrate everything over at the same time; though, I'm not entirely certain that the migration code is going to be simpler in the short term than supporting both backends
[23:30] <bryce> LaserJock: esp. if you're using a non-Ubuntu java
[23:30] <LaserJock> ok
[23:30] <slangasek> mathiaz: also, even if the package only supported automatically setting up one of hdb or bdb, does not mean that users wouldn't set up additional databases on their own using backends of their choice
[23:30] <bryce> LaserJock: for troubleshooting, getting backtraces are useful to identify what code paths are involved.  And then look for irregularities
[23:31] <bryce> in both the two cases we have so far, the issue was double-running code that should only be run once
[23:31] <slangasek> mathiaz: i.e., consider that there are things like the sql backend, which while never configured for the user in the package, are certainly expected to work if set up manually...
[23:31] <mathiaz> slangasek: sure - I don't think wich drop bdb as backend - I'm just asking if we should drop bdb support for the maintainer scripts
[23:31] <bryce> so I would keep an eye out for that pattern, particularly with code that makes X calls
[23:31] <slangasek> mathiaz: right, I don't know the answer to that, we should get upstream's opinion :)
[23:32] <mathiaz> slangasek: ok - I'll ask upstream then.
[23:32] <bryce> LaserJock: also, I posted a noxcb version of libx11 to people.ubuntu.com/~bryceharrington/Testing/libx11 that you're welcome to grab for testing
[23:33] <bryce> LaserJock: like I mentioned, it's too risky to consider putting into hardy, but it oculd be handy for isolating if it is indeed an xcb-related issue
[23:41] <calc> grr i can't remember the word i am looking for
[23:41] <calc> what is the name for code that has no license
[23:42] <calc> ah i am thinking of public domain
[23:42] <beDrung> in germany it is not possible to declare code as public domain
[23:49] <LaserJock> bryce: ah cool, thanks. I'd be happy if I can just isolate it. The install is pretty single-use so if we get the app working we'd be happy
[23:50] <calc> beDrung: yea i thought so