[04:00] <ebroder> Who do I need to annoy to get bug #369203 fixed?
[04:24] <ScottK> ebroder: Is there a patch and a test case?
[04:25] <ebroder> Sure. The patch is attached in my comment. The test case is `python -c 'import curses; curses.initscr()'`
[04:25] <ebroder> I can edit the bug description to more clearly link to my patch if you'd like
[04:29]  * ScottK didn't open the bug.  Let me look.
[04:31] <ScottK> doko: What do you think about the proposed fix in 369203?
[04:31] <ScottK> Let's wait a bit and see what that brings us.
[04:31] <ebroder> Sounds good
[06:10] <pitti> Good morning everyone! end of holidays, at last :)
[06:11] <TheMuso> Hey pitti!
[06:13] <pitti> hey TheMuso, how are you?
[06:14] <TheMuso> pitti: Well thanks.
[06:15] <thumper> anyone know the quality of the ati HD3450?
[06:15] <thumper> I'm looking at a new laptop and can have either this or on-board intel
[06:15] <thumper> wondering about upcoming KMS
[06:19] <thumper> bryce: if you read the scrollback, ATI radeon hd 3450, good or not, KMS?
[06:39] <dholbach> good morning
[06:53] <highvoltage> good morning dholbach
[06:53] <dholbach> heya highvoltage!
[06:53] <highvoltage> had a good weekend dholbach?
[06:53] <dholbach> absolutely - we had some friends here from Austria
[06:54] <dholbach> how about yours?
[06:54] <highvoltage> heh, I watched Sound of Music again Saturday afternoon, so saw some old Austria scenes and got an Austria fix as well
[06:54] <dholbach> haha :-)
[06:55] <highvoltage> visited that computer lab in that poor area I told you about saturday morning, it was going better there than I expected. it was nice seeing it in use, there was a class running on how to use gmail and search things on the internet.
[06:56] <dholbach> cool - so they had no specific complaints?
[06:58] <highvoltage> nope, there was a few computers that weren't set to boot from the network and that's why they weren't working, so I just showed them how to set the bios settings and that already fixed most of their problems
[06:59] <highvoltage> I got the relevent contact details, I'll put them in touch with the ngo-interviewers
[06:59] <dholbach> rock and roll :)
[07:21] <stochastic> In Bug #416778 lool has requested some further public discussion on including the Jack audio server in Main.  I'm not sure where to initiate that discussion, is here appropriate?
[07:21] <stochastic> or is the bug tracker the best place for that conversation?
[07:22] <StevenK> stochastic: ubuntu-devel-discuss@lists.ubuntu.com would be my suggestion
[07:33] <tkamppeter> pitti, hi
[07:33] <\sh> moins
[07:37] <pitti> hi tkamppeter
[07:37] <pitti> tkamppeter: BTW, we can change the pdftoopvp enabling to be an Ubuntu specific patch, then we can add it to the Debian trunk and drop the Ubuntu branch again
[07:37] <pitti> I'll do that soon
[07:45] <tkamppeter> pitti, OK
[07:47] <tkamppeter> pitti, I have discovered that CUPS now does not only have 2 libs (libcups, libcupsimage), but 4 new libs added (libcupscgi, libcupsdriver, libcupsmime, libcupsppdc). Do we need 8 additional binary packages (including -dev) now?
[07:47] <mvo> could someone please have a quick look at http://launchpadlibrarian.net/30714313/zlib_1.2.3.3.dfsg-13ubuntu2.debdiff if that looks ok?
[07:47] <mvo> (context is bug 402178)
[07:50] <pitti> tkamppeter: I think for now we can probably keep them in libcups, unless they have different SONAMEs (or likely to get different ones in the future)
[07:51] <pitti> tkamppeter: ah, just saw your 1.4 updates
[07:51] <tkamppeter> libcups has SONAME 2, all the new ones SONAME 1.
[07:52] <StevenK> That sounds like the SOVER, not SONAME
[07:54] <pitti> tkamppeter: then the new ones need a new package
[07:54] <pitti> StevenK: SOVER?
[07:54] <tkamppeter> I have done everything to make the new CUPS build: adapted patches, taken a patch from Red Hat to make the new dnssd backend build (the original uses an API which is probably not available under Linux), adapted the PDF filter package to work with both 1.3 and 1.4, fixed small bugs in the new CUPS, ...
[07:55] <tkamppeter> StevenK: pitti called this SONAME in a conversation with robert_ancell on #ubuntu_desktop.
[07:55] <pitti> tkamppeter: thanks muchly
[07:57] <tkamppeter> pitti: Remaining is now to obsolete cupsddk and to distribute the files to the binary packages of CUPS and to package all the new libraries.
[08:08] <tkamppeter> pitti, if you make a conditional patch to solve the pdftoopvp problem, can you make it in a way that it applies only to Debian and not to Ubuntu, this way one can have the debian/local/filters/pdf-filters being exactly the upstream tarball.
[08:09] <pitti> tkamppeter: yes, I can also do it the other way around ("disable-pdftoopvp.dpatch")
[08:09] <pitti> tkamppeter: I won't actually check for "Ubuntu", I'll check the version number of poppler
[08:09] <liw> pitti, hmm... I have devicekit-disks 006-0ubuntu1 installed, but I still get the dialog that wants me to mount an unmounted partition on my hard disk
[08:10] <pitti> liw: right, that's expected; gvfs doesn't yet use the new "no interactive" option
[08:10] <pitti> there's a gvfs task still open
[08:10] <liw> pitti, ok, then I'll wait some more
[08:10] <tkamppeter> pitti, this is even better
[08:12] <soren> lool: Hey. Thanks for your work on euca2ools!
[08:13] <soren> lool: The binary depends on pyton-boto 1.8a, but we're at 1.7c. Can you sync 1.8a from Debian?
[08:13] <pitti> soren: he can't, but I can
[08:13] <soren> pitti: Oh, lovely. Thanks!
[08:13]  * soren thought lool was archive admin
[08:14] <StevenK> He's in ubuntu-mir, but he isn't an archive admin
[08:14] <soren> Ah.
[08:14]  * soren is having trouble keeping up with people's hats.
[08:15] <liw> is there a tool to compare two versions of the same lib*.so and see if there are changes in the exported symbols?
[08:16] <pitti> liw: hm, diff the nm -D output?
[08:17] <dholbach> or use check-symbols from the ubuntu-dev-tools package?
[08:17] <soren> pitti: \o/ Thanks for the boto sync.
[08:17] <pitti> soren: de rien
[08:17] <dholbach> nm -D <lib1> | cut -d' ' -f3 | sort -u > lib1; nm -D <lib2> | cut -d' ' -f3 | sort -u > lib2; diff -u lib1 lib2
[08:18] <pitti> dholbach: do you know bash's <() trick?
[08:18] <pitti> diff -u <(nm -D ...) <(nm -D ...)
[08:18] <dholbach> how'd you rephrase it?
[08:18] <dholbach> ah
[08:19]  * dholbach needs to try that
[08:19] <pitti> pretty handy to work without creating temporary files
[08:19] <pitti> <(command) runs command in a pipe and its stdout becomes a file name-like argument
[08:19] <dholbach> although the mighty slangasek says that objdump -T or readelf -s would be better than nm -D
[08:20] <dholbach> https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/184906
[08:20]  * pitti bows to slangasek's ELF skills
[08:22] <mpontillo> remember to pass -W to 'readelf' - otherwise long symbol names can get cut off!
[08:23] <liw> . o O (nothing is ever easy with shared libs, is it?)
[08:24] <dholbach> probably best to just read the diff ;-)
[08:57] <tkamppeter> pitti, any suggestion about the library packaging for CUPS?
[08:57] <pitti> tkamppeter: as I said, if they have a different soname, they need a new package
[08:58] <pitti> tkamppeter: will any other program actually use these libraries, though?
[08:58] <tkamppeter> pitti, that is the case.
[08:59] <tkamppeter> pitti, currently most probably not.
[09:03] <lool> soren, pitti: I had filed a sync request saturday though
[09:09] <soren> lool: I wonder why I didn't see that..
[09:10] <soren> lool: Oh, right, I decided not to wait for Launchpad to load because I (mistakenly) "realised" that you were an AA and could have done it yourself if you wanted.
[09:11] <lool> soren: I think I saw no subscriber to euca2ools bugmail either
[09:11] <soren> lool: No, I hadn't gotten around to that yet.
[09:12] <soren> (it was only synced on Friday)
[09:12] <lool> I mean that explains you didn't see the sync bug
[09:12] <soren> Oh, right, right.
[09:12] <lool> I sent the changes to the euca folks in the changelog and at the top of /Makefile BTW
[09:13] <lool> Didn't get any answer yet but that was over the WE
[09:25] <mvo> slangasek: what is your opinion on bug #414943 ? do you think its important enough to add code to update-manager to check for this situation (that the user has a old kernel as default in his grub.cfg?)
[10:27] <cjwatson> mvo: thanks for clearing up that lsb_release bug!
[10:31] <mvo> cjwatson: my pleasure :)
[11:27] <tkamppeter> pitti, what about creating packages libcups-extra1 and libcups-extra-dev for the 4 extra CUPS libraries?
[11:28] <pitti> tkamppeter: they all have soname 1? "extra" sounds a bit weird, maybe pick one of the existing names?
[11:29] <tkamppeter> They are all of soname 1, but picking one of the lib names is also not good, they are completely different.
[11:29] <pitti> tkamppeter: however, I don't really like "extra", it's a hack; either we put them all into an existing package, or we should package them properly
[11:30] <tkamppeter> putting them into "cups" is bad, as then a program only needing one of the libs would pull in the CUPS daemon.
[11:30] <pitti> tkamppeter: there's no way to statically link them to cupsd, until other programs actually need them?
[11:30] <pitti> well, other binaries might need them as well
[11:30] <pitti> seems there's no really good way of avoiding 4 new libs :/
[11:30] <tkamppeter> pitti, they can also be used by CUPS clients on a daemon-less server
[11:31] <pitti> right
[11:31] <tkamppeter> Or by PPD-generating programs, imagine the CUPS daemon would run on OpenPrinting, only because there is a program generating driver packages.
[11:36] <tkamppeter> pitti, now I discovered that there is a package named cups-common, I could put the libraries there.
[11:37] <pitti> tkamppeter: no, that's arch:all, and not meant for libraries
[11:37] <pitti> tkamppeter: let's just package them properly instead of wasting time on ugly and policy breaking hacks which we'll need to fix later anyway
[11:37] <tkamppeter> pitti, I could switch that to arch:any
[11:38] <pitti> once one of the libs changes ABI, it would break everything
[11:38] <tkamppeter> So I will make real library packages. Even if these libraries are not meant as API libs for apps, sooner or later someone will use them and then we have to change our packages to avoid side effects.
[11:43] <ogra> pitti, hey, what is supposed to provide IRC in the default install ? testing my armel images i cant find anyone
[11:43] <ogra> s/anyone/anything/
[11:44]  * ogra wonders if armel is missing something, given that much of out user support is centered around IRC i cant imagine we dont have it by default
[11:46] <pitti> ogra: we don't have IRC right now; we'd need to install telepathy-idle for that
[11:46] <pitti> it's a known issue
[11:46] <pitti> you can install it in the live system, of course
[11:46]  * pitti -> lunch
[11:46] <ogra> pitti, but we'll pull it in ?
[11:46] <ogra> (later)
[11:46] <pitti> ogra: probably, yes
[11:47] <ogra> i would see it as a large regression to not have IRC by default
[11:47] <ogra> enjoy your lunkc, thanks
[11:47] <ogra> *lunch
[12:18] <Laney> Is there any way to retry a build which was attempted on a previous release, short of an upload?
[12:20] <sistpoty|work> Laney: you mean as in binNMU?
[12:20] <Laney> no, there was an FTBFS which was attempted in Jaunty
[12:20] <Laney> I was wondering if it could be tried again under Karmic
[12:21] <Laney> give-back
[12:21] <sistpoty|work> Laney: ah, no idea actually then
[12:22] <cjwatson> err, it ought to have had a karmic build record created, I'd've thunk
[12:22] <cjwatson> ask #launchpad?
[12:23] <Laney> doesn't seem to have
[12:23]  * Laney moves over there
[12:47] <ogra> does anyone see a reason why Arch: all packages wouldnt be built with a debian/control like: http://paste.ubuntu.com/258590/
[12:48] <cjwatson> debian/rules is relevant too
[12:48] <ogra> well, rules is pretty empty
[12:48] <Cyberkilla> Hello, does anyone here know anything about the nvidia drivers in karmic a4?
[12:48] <ogra> http://paste.ubuntu.com/258615/
[12:49] <Cyberkilla> For some reason, 185.18.31, 185.18.36 and 190.x.x give me artifacts, then system crashes (laptop resets itself).
[12:49] <cjwatson> ogra: debian.mvl-dove/rules then
[12:49] <cjwatson> follow the yellow brick road
[12:50] <Cyberkilla> I had to revert to 185.18.14.
[12:50] <Cyberkilla> You're speaking in riddles to eachother:O
[12:50] <ogra> http://paste.ubuntu.com/258616/
[12:50] <cjwatson> not especially
[12:50] <ogra> right, the dove rules are a bit more intresting :)
[12:51] <cjwatson> ogra: now you need to find which of the included files defines the binary-indep target
[12:51] <Cyberkilla> It is an NVidia GeForce 8400M GT, inside of a Sony Vaio VGN-AR41E laptop
[12:53] <cjwatson> Cyberkilla: I don't know anything about this but perhaps generic advice is better than nothing. https://wiki.ubuntu.com/X/Reporting has general advice on reporting good-quality X bugs that contain a decent amount of information, and links to some pages with more details. #ubuntu-x may have more experts paying attention, although not necessarily right at this moment
[12:53] <Cyberkilla> Thanks a lot. I appreciate your response: )
[12:54] <ogra> hmm, looks ok to me, it properly calls the dbheper commands with -i ... unless the package names dont get handed over i dont see why it wouldnt even attampt a build
[12:55] <ogra> though, hmm, i wonder if the "build-indep:" at the top prevents it somehow
[12:55] <ogra> http://paste.ubuntu.com/258619/
[12:56] <stefanlsd> pitti: are you ok if i upload the calibre stuff i've done?
[12:56] <ogra> seems to be an empty target
[12:57] <pitti> stefanlsd: sure; I need to commit all the changes back to the debian bzr branch anyway, a couple of more changes don't make a big difference
[12:58] <pitti> stefanlsd: we should have an Ubuntu branch probably, since I can't upload 0.6 to Debian right now (blocked on doko's magic --install-layout=deb change in python2.5)_
[12:59] <doko> pitti: ???
[12:59] <stefanlsd> pitti: ok, great. wont we get a branch now with james_w import stuff anyways?
[12:59] <pitti> oops, sorry, that was meant to be "2.6 available in experimental"
[12:59] <pitti> doko: sorry, the --install-layout=deb change was just blocking the cdbs distutils.mk fix
[13:00] <pitti> not calibre
[13:00] <pitti> stefanlsd: yes, but please don't use it
[13:00] <pitti> for packages which already have a bzr branch, the auto-import stuff is pretty useless
[13:01] <doko> ahh, ok
[13:02] <cjwatson> ogra: build-indep is probably irrelevant
[13:02] <ogra> well, the main file calls it, but comparing to the generic kernel package its identical
[13:02] <cjwatson> ogra: I suggest setting DH_VERBOSE=1 and going through the output with a fine tooth-comb
[13:03] <ogra> well, thats more than i want to do personally, its actually rtg's package, but he is "fixing" it by just dropping all Arch: all packages, i thought i could find something obvious to suggest
[13:04] <ogra> i dont mind losing Arch:all -headers ... and -docs should be identical to the mainline kernel anyway
[13:05] <ogra> -source concerns me a bit if users want to cross build kernels for armel SoCs though
[13:05] <cjwatson> I sympathise but am unlikely to have a chance to figure this out, sorry
[13:06] <cjwatson> of course the debhelper commands that are called with -i are not the only relevant parts; you need to make sure that something is actually installed into the package build directories too
[13:06] <ogra> yeah, i would have asked "cjwatson can you help with ..." if i really wanted you to help solving it ;) thanks a lot for the pointers though :)
[13:07] <ogra> dont want to keep you from your actual work ;)
[13:07] <ogra> i'll discuss with rtg
[13:07] <cjwatson> that's ok, I just wanted to make it clear that I was disengaging rather than just going silent :)
[13:23] <ogra> slangasek, rtg claims the "Arch: all" packages of linux-fsl-imx51 were not built because you objected, i dont see how you would technically have been able to prevent them from building nor why they wouldnt have at least been in the NEW queue, can you tell me anything about that ?
[14:01] <tkamppeter> pitti, which maintainer scripts are needed for library packages? AFAIK one has to call "ldconfig" after installation and after removal. Or is this done automatically, without needing an explicit maintainer script?
[14:01] <pitti> tkamppeter: don't add explicit scripts, dh_makeshlibs will care about it
[14:02] <tkamppeter> pitti, then I can perhaps remove some superfluous scripts from the CUPS package.
[14:02] <cjwatson> dh_makeshlibs> assuming that you have the #DEBHELPER# token in any explicit maintainer scripts you do have in the source package
[14:03] <cjwatson> (obviously if you don't have explicit maintainer scripts in the source package then there's no need to add them just for #DEBHELPER#)
[14:04] <tkamppeter> pitti, debian/libcups2.postinst and debian/libcupsimage2.postinst do nothing more than providing #DEBHELPER#, so they can get removed.
[14:05] <pitti> tkamppeter: correct, they are just cruft
[14:34] <happyaron> pitti: hi, I've replied to that bug about tor
[14:54] <lool> Hey who's administering http://qa.ubuntuwire.com/ ?
[14:54] <lool> I'd like to get a package or two installed to fix http://qa.ubuntuwire.com/uehs/no_updated.html
[14:54] <lool> It's lacking the perl ssl support libs to use https
[14:58] <ogra> lool, i think that was siretart once, not sure thats still true though
[14:58] <sistpoty|work> lool: you can ask at #ubuntuwire or write a mail to admin@lists.ubuntuwire.com
[15:00] <geser> lool: or ask wgrant
[15:00] <lool> sistpoty|work: thanks
[15:00] <lool> Too many people to ask  :)
[15:00] <lool> I prefer shooting an email
[15:00] <sistpoty|work> heh :)
[15:01] <ogra> why ? many people means many options to pick your favorite answer *g*
[15:01] <sistpoty|work> or many possibilities to say "no, I'm not responsible..." *g*
[15:11] <highvoltage> Riddell: heh, in Africa, "eina" means "ouch"
[15:11] <highvoltage> (just saw it coming through karmic-changes)
[15:13] <tkamppeter> pitti, is bug 418097 really a CUPS bug?
[15:14] <tkamppeter> pitti: Or is it of ia32-libs providing 32-bit libcups2?
[15:15] <pitti> tkamppeter: looks like an ia32-libs bug; cups itself doesn't build 32 bit libs on amd64
[15:33] <happyaron> pitti: hi, if only for hardy to karmic, or rather say in 4-5 releases, I can do it.
[16:37] <kirkland> NCommander: ping
[16:37] <kirkland> NCommander: what's the status with the kvm backports to hardy/intrepid ?
[16:37] <kirkland> NCommander: those have been sitting there for a while, now
[16:40] <NCommander> kirkland, let me check, libvirt should have gone through, its been in the NEW queue for awhile
[16:42] <sistpoty|work> kirkland: I just took a glance at qemu-kvm... are the sources of the bios files in pc-bios somewhere in the package? I can't find the source for openbios-* for example
[16:44] <kirkland> sistpoty|work: lemme check
[16:44] <sistpoty|work> kirkland: thx
[16:45] <kirkland> sistpoty|work: i'm just responding to your email about qemu-kvm on -devel
[16:46] <sistpoty|work> kirkland: cool, thanks :)
[16:46] <kirkland> sistpoty|work: thanks for looking at that package; i *welcome* more eyes on it :-)
[16:46] <sistpoty|work> sure thing, no problem ;)
[16:48] <kirkland> sistpoty|work: the source is at http://www.openfirmware.info/OpenBIOS, though upstream qemu is releasing those as blobs in 0.11
[16:49] <cr3>  /join #python
[16:49] <cr3> nice! :)
[16:49] <sistpoty|work> kirkland: hm... that's gpl-2, right? can we distribute it that way in ubuntu then?
[16:51] <kirkland> sistpoty|work: hmm, well qemu is GPLv2 and LGPL
[16:51] <NCommander> cjwatson, any archive admin, can you please promote the linux-mvl-dove udebs so d-i can build? The kernel itself got kicked to main, but the udebs are still in universe
[16:51] <sistpoty|work> kirkland: yep, but I mean the bios... don't we as ubuntu have to make the sources available or offer s.th. written then? (I'm no licensing expert though)
[16:52] <cjwatson> NCommander: done
[16:53] <NCommander> cjwatson, thanks, I'll have a revised branch that has been fully test built for you ASAP
[16:54] <doko> ScottK: looks ok
[16:54] <ScottK> doko: Thanks.
[16:54] <kirkland> sistpoty|work: hmm, i'm not sure about that one ...  qemu and kvm have always shipped at least some bios.bin's as prebuilt bios blobs;  I'll have to check under what conditions this has been approved in the past
[16:55] <sistpoty|work> kirkland: I think if the source from which a prebuilt blob is available in the package, that would work... but as I wrote, I don't have too much clue with legalize ;)
[16:56] <sistpoty|work> is available along with the blob even.
[16:57] <kirkland> sistpoty|work: so you're suggesting I grab that source, and drop it in the debian dir and debian/copyrights for good measure?
[16:57] <sistpoty|work> kirkland: yes, but the tough thing is to make sure that it matches the blob. and I'm suggesting to ask someone who knows for sure ;)
[16:58] <kirkland> sistpoty|work: the other option is to add --disable-blobs to the ./configure optiosn
[16:58] <sistpoty|work> kirkland: and to remove it from the source tarball, yes, if it's still working then
[16:59] <kirkland> sistpoty|work: well, it would break some of qemu's arches, IIUC
[16:59] <_sick> anyone knows if the idb (intel debugger) works with the gdb machine interface ?
[17:00] <sistpoty|work> kirkland: hm... :/
[17:00] <kirkland> sistpoty|work: talking with the qemu maintainers privately right now, they feel that they're covered, because one of the qemu maintainers is also an openbios maintainer
[17:00] <kirkland> sistpoty|work: and their intention is to ship the source of the openbios blobs in 0.12
[17:01] <sistpoty|work> kirkland: oh, cool :)
[17:01] <kirkland> sistpoty|work: but 0.12 is karmic+1
[17:01] <kirkland> sistpoty|work: they're in 0.11-rc1 right now ... i just asked if they'd add the openbios sources to -rc2 ...  discussing now
[17:04] <kirkland> sistpoty|work: qemu upstream says shipping those sources in -rc2 is probably not going to happen;  i'd need to drop them in our package
[17:07] <mathiaz> jdstrand: bug 407428 - this is a hard one
[17:07] <jdstrand> mathiaz: yes it is. I haven't found a reproducer yet
[17:07] <jdstrand> mathiaz: I've tried for some time, off and on
[17:08] <mathiaz> jdstrand: yeah - I run into this one all the time
[17:08] <jdstrand> me too
[17:08] <mathiaz> jdstrand: when I clone vm
[17:08] <mathiaz> jdstrand: and they start for the first start, I run into this issue
[17:08] <mathiaz> jdstrand: but I haven't been able to reliably reproduce it
[17:08] <jdstrand> mathiaz: does it happen every time you clone a vm?
[17:08] <mathiaz> jdstrand: yes
[17:09] <mathiaz> jdstrand: if I reboot the vm, it's gone - sometimes
[17:09] <jdstrand> mathiaz: maybe the bug can be triggered when ssh notices a new interface and starts listening on it
[17:09] <jdstrand> mathiaz: oh, in the vm or the host do you see this?
[17:09] <mathiaz> jdstrand: in the vm only
[17:09] <jdstrand> ok, nm my comment then
[17:16] <tkamppeter> pitti, I have completed the packaging of CUPS 1.4.0 now.
[17:18] <tkamppeter> pitti, can you now add the conditional patch for deactivating pdftoopvp in Debian and then upload the resulting package to Debian and Ubuntu. Thanks.
[17:18] <pitti> tkamppeter: great, thanks!
[17:18] <pitti> tkamppeter: yup, on my list
[17:23] <tkamppeter> pitti, another problem is that we now have to blacklist the usblp kernel module. How should this be done? Should CUPS add a config file to /etc/modules.d for doing that or should it simply be part of the default configuration for the kernel modules?
[17:24] <tkamppeter> With the module loaded the "usb" CUPS backend does not see any printer.
[17:25] <pitti> tkamppeter: blacklist? why?
[17:25] <pitti> tkamppeter: oh, so that the module doesn't grab the raw device?
[17:26] <pitti> tkamppeter: ideally we'd just not build it at all in the kernel
[17:26] <pitti> tkamppeter: but that's an issue in Debian as well then
[17:26] <tkamppeter> pitti: Yes.
[17:26] <pitti> it just seems like a bad design to me, though
[17:27] <pitti> tkamppeter: I guess for now we need to add it to the default blacklist in module-init-tools, yes
[17:27] <tkamppeter> pitti, OK.
[17:27] <pitti> ok, need to run (dinner and Taekwondo), see you all tomorrow!
[17:28] <tkamppeter> pitti, it is really a bad design, a good usb backend would work both with and without usblp kernel module.
[17:32] <NCommander> cjwatson, publisher runs every hour, on :03, right?
[17:39] <ScottK> Last I heard publisher runs were taking over an hour to finish though (this may have been fixed).
[17:43] <mathiaz> james_w: hey - are you going through the NEW queue?
[17:43] <mathiaz> james_w: and rejected merb?
[17:43] <james_w> yeah
[17:43] <cjwatson> NCommander: yes
[17:44] <NCommander> cjwatson, hrm, then the udeb should be in main now, no?
[17:44] <mathiaz> james_w: the reason for rejection was the inclusion of spec testing?
[17:44] <james_w> mathiaz: I rejected it as I sponsored a newer version in to NEW
[17:44] <mathiaz> james_w: oh - cool
[17:44] <mathiaz> james_w: does this mean that merb has been accepted now?
[17:44] <NCommander> cjwatson, I'm just wondering if udebs are special w.r.t. to promotion and such
[17:45] <cjwatson> ScottK: that was fixed - they're down to a bit over half an hour now - but the publisher is crashing
[17:45] <ScottK> cjwatson: Thanks.  Good to know (the fixed part anyway).
[17:45] <cjwatson> NCommander: they're not special, the publisher's crashing
[17:45] <NCommander> cjwatson, oh. bah :-/
[17:45] <NCommander> cjwatson, sorry for the noise, I was just wondering what was going on
[17:46] <james_w> mathiaz: no
[17:46] <james_w> mathiaz: I don't have time to complete the review today
[17:47] <mathiaz> james_w: ok - so there is a new version of merb in the NEW queue that fixes the issue you've found?
[17:47] <james_w> yeah
[17:47] <mathiaz> james_w: but you won't have to process the NEW queue today?
[17:47] <james_w> it's a repacking to remove all the embedded code
[17:47] <james_w> well, I've spent a few hours on it today
[17:47] <james_w> so it's that I want to do some other things today
[17:47] <mathiaz> james_w: sure :)
[17:48] <mathiaz> james_w: thanks for sponsoring a new upload of merb :)
[17:48] <james_w> np
[17:48] <mathiaz> jtimberman: ^^ - so your last upload to REVU for merb is already in the NEW queue (ie has been sponsored by james_w) ?
[17:49] <jtimberman> Guess so, I haven't seen an email about that from the system.
[17:49] <james_w> it is
[17:49] <jtimberman> mathiaz: i fixed the issue it was rejected for, and a new issue james_w found.
[17:50] <jtimberman> does that mean it still needs archive admin review and upload to the universe?
[17:50] <james_w> yeah
[17:51] <james_w> https://edge.launchpad.net/ubuntu/karmic/+queue
[17:51] <jtimberman> Ahh
[17:52] <jtimberman> oh, stompserver is in the queue.
[17:53] <mathiaz> jtimberman: right - merb and stompserver are already in the queue
[17:53] <mathiaz> jtimberman: and chef needs another advocation
[17:53] <mathiaz> jtimberman: ^^ is that accurate picture of the chef packaging effort?
[17:54] <mathiaz> jtimberman: coderay and libsyntax are available in karmic
[17:54] <jtimberman> mathiaz: stompserver was rejected on Friday and I uploaded it fixed on REVU, is the one in the queue the right one?
[17:55] <jtimberman> mathiaz: stompserver was rejected, and i uploaded the new version to REVU that fixed the blocking issue.
[17:55] <jtimberman> mathiaz: i see it as rejected on the queue too, does it need a new upload to NEW?
[17:57] <mathiaz> jtimberman: meh - I don't know
[17:57] <mathiaz> jtimberman: the times are all different
[17:57] <jtimberman> one time zone to rule them all.
[17:58] <mathiaz> jtimberman: I can't figure out whether I've uploaded the latest
[17:58] <mathiaz> jtimberman: let me look into that a bit later.
[17:58] <jtimberman> mathiaz: okay.
[18:00] <slangasek> ogra: er, I never said to not build the Architecture: all packages - are we playing telephone, here?
[18:00] <ogra> slangasek, well, something is wrong
[18:00] <ogra> the 300.4 package had three Arch: all packages
[18:00] <ogra> but they werent picked up anywhere for build it seems
[18:01] <ogra> doing a local armel build they appear
[18:01] <ogra> ogra@dove:~/linux-mvl-dove-2.6.31$ ls ../*.deb
[18:01] <ogra> ../linux-headers-2.6.31-200_2.6.31-200.4_all.deb         ../linux-image-2.6.31-0-dove_2.6.31-0.1_armel.deb      ../linux-mvl-dove-doc_2.6.31-200.4_all.deb
[18:01] <ogra> ../linux-headers-2.6.31-200-dove_2.6.31-200.4_armel.deb  ../linux-image-2.6.31-200-dove_2.6.31-200.4_armel.deb  ../linux-mvl-dove-source-2.6.31_2.6.31-200.4_all.deb
[18:01] <slangasek> ogra: then you're not doing a proper local armel build the way the buildds do.  The buildds only build Arch: all packages on the i386 buildd
[18:01] <ogra> i'll try buiulding the package on a i386 machine, but i suspect we hit a soyuz bug or some weird PAS wildcard setting
[18:02] <ogra> yes, i know how our infrastructure works :)
[18:02] <ogra> i did the local build to exclude packaging bugs
[18:02] <slangasek> the relevant detail here is https://launchpad.net/ubuntu/karmic/+source/linux-fsl-imx51/2.6.31-100.7 showing only armel in the 'builds' tab
[18:02] <ogra> but our infrastructure seems to not like that setup
[18:03] <ogra> 100.7 has all ARCH: all packages dropped
[18:03] <ogra> that was rtg's workaround for now
[18:03] <ogra> 100.4 and 100.5 had them enabled
[18:04] <slangasek> er
[18:04] <ogra> ah, no only 100.4
[18:04] <ogra> there seem to be no build attempts on i386 for 100.4
[18:04] <slangasek> I don't see why he would have dropped the doc and source packages
[18:04] <ogra> and i think thats either soyuz or PAS
[18:05] <ogra> yes, i wanted to keep -source :(
[18:05] <slangasek> (the headers package, yes, I did say there was no point in having the headers split between two packages)
[18:05] <ogra> for people cross compiling the kernel packages
[18:05] <ogra> i dont care about .docs
[18:05] <ogra> *-docs
[18:05] <ogra> since i assume there is nothing added to the fsl version
[18:06] <ogra> keeping -source would have been nice and i'd like to see it coming back ...
[18:06] <slangasek> it doesn't matter whether there's anything added - you want the -docs package built so that the -docs package matches the kernel package and can be pulled in via linux-meta
[18:06] <ogra> anyway, do you have an idea what blocks them from building on i386 ?
[18:07] <ogra> slangasek, well, rtg sees the issue as resolved and i couldnt convince him of the opposite
[18:07] <slangasek> ogra: it's not P-a-s, so you'll have to ask soyuz folks
[18:07] <ogra> ok, thanks for looking
[18:09] <ogra> hmm, wasnt there a dedicated soyuz channel ?
[18:09] <al-maisan> ogra: yes, #soyuz
[18:10] <al-maisan> on the Canonical Ltd. server
[18:10] <ogra> heh, i meant a public one :)
[18:10] <ogra> doesnt seem like though
[18:10] <al-maisan> try #launchpad then, and ping cprov :)
[18:12] <cjwatson> the publisher seems like it might be running again, so we'll see
[18:16] <james_w> cjwatson: hi, is there anything special to watch out for with -di packages in NBS?
[18:16] <james_w> there's a whole bunch in there currently, and I didn't clear them out earlier with the rest as I didn't want to create havoc
[18:19] <cjwatson> james_w: don't process them yet, I have a d-i upload in the works to move to -6
[18:19] <cjwatson> NCommander: are you waiting for this publisher run in order to do a test build?
[18:19] <james_w> so my wariness was well placed :-)
[18:20] <cjwatson> NCommander: you could just add universe/debian-installer to UDEB_COMPONENTS in build/config/common
[18:20] <ogra> cjwatson, now that the mvl and fsl kernel packages are in main, is there anything special we need to do for d-i to pick them up ?
[18:20] <NCommander> cjwatson, ah
[18:21] <mathiaz> jtimberman: the stompserver package sitting in the NEW queue is the last one you've uploaded to REVU (fixing the issue from the first rejection)
[18:21] <ogra> they both should have the proper naming scheme now
[18:21] <cjwatson> ogra: stuff like what NCommander's doing for dove, presumably
[18:21] <jtimberman> mathiaz: cool, thanks for checking!
[18:21] <ogra> well, that had happened for imx51 already
[18:21] <ogra> unless you dropped it :)
[18:23]  * ogra hugs lamont for ARMv7 buildd love 
[18:23] <ogra> and you even doubled the amount !!!
[18:24] <lamont> ogra: 4 -> 6 isn't double. :-p
[18:24] <lamont> one more inbound though - look forward to seeing korlan
[18:24] <lamont> and a rimu replacement
[18:24] <ogra> it was 3 for nearly all of the last 6 months
[18:24] <lamont> and then we get more
[18:25] <cody-somerville> doh. The latest nvidia updates broke my X.
[18:25] <ogra> the fourth one was rarely seen online
[18:25] <ogra> cody-somerville, get proper hardware :P
[18:26] <cody-somerville> ogra, whats considered proper hardware these days? :P
[18:26] <ogra> intel ?
[18:26] <cody-somerville> no thanks
[18:26] <ogra> no probs here even with external 1920x1200 LCD
[18:26] <lamont> ogra: yeah - podocarpus was offline for much of that
[18:27] <ogra> yup
[18:28] <mathiaz> james_w: http://paste.ubuntu.com/258796/ <- have you already seen this?
[18:28] <mathiaz> james_w: I was trying to import an upstream tarball in a bzr branch
[18:28] <cjwatson> ogra: sure, it needs one set of config files per subarchitecture
[18:29] <james_w> mathiaz: I think so, one minute
[18:29] <ogra> cjwatson, well, then i assume imx51 is fine from jaunty still
[18:30] <ogra> though we might have to add hardware detection strings for the newer babbage boards, i will have to compare them
[18:30] <cjwatson> ogra: yes. mvl == dove, fsl == imx51?
[18:30] <cjwatson> (ish)
[18:30] <ogra> right
[18:31] <ogra> fsl is only in the source package names
[18:31] <ogra> the binaries should be mainly compatible to jaunty
[18:36] <james_w> mathiaz: yeah, that should be fixed in the next upload
[18:36] <james_w> mathiaz: remember you found that problem with the spurious conflicts when merging from Debian?
[18:36] <mathiaz> james_w: when is the next upload schedule?
[18:36] <mathiaz> james_w: or is there a version available from a PPA?
[18:36] <mathiaz> james_w: for testing?
[18:37] <mathiaz> james_w: yes
[18:37] <james_w> mathiaz: that will now be gone if you use the merge-package command, thanks to al-maisan
[18:37] <james_w> I can upload now
[18:37] <mathiaz> james_w: \o/
[18:37] <mathiaz> james_w: that would be great
[18:37] <al-maisan> :)
[18:37] <mathiaz> james_w: so another question
[18:38] <mathiaz> james_w: there is an upstream bzr branch as a git import
[18:38] <mathiaz> james_w: https://code.launchpad.net/~vcs-imports/sssd/trunk
[18:38] <mathiaz> james_w: I've been working on packaging it - lp:~mathiaz/sssd/ubuntu-pkg
[18:39] <mathiaz> james_w: and doing daily builds of the upstream branch using bzr builddeb
[18:39] <mathiaz> james_w: as a native package
[18:39] <mathiaz> james_w: now upstream is going to release a tarball
[18:40] <mathiaz> james_w: how should I proceed for applying the debian packaging to the upstream tarball?
[18:40] <james_w> hmm
[18:40] <mathiaz> james_w: I've tried to branch the lp:~mathiaz/sssd/ubuntu-pkg branch but I don't see I could import the upstream release tarball
[18:41] <james_w> mathiaz, al-maisan: uploaded
[18:42] <james_w> mathiaz: you need something to do with merge-upstream
[18:42] <mathiaz> james_w: so the other option was to have two different set of branches
[18:42] <james_w> you've just been using "bzr merge" on the upstream branch?
[18:42] <mathiaz> james_w: which is when I run into the bug mentionned above as
[18:42] <Tonio_> siretart: hi ! I just found out a little issue with your latest ffmpeg upload...
[18:42] <mathiaz> james_w: hm - for my daily builds (native package) I've just bzr merge ../trunk into ubuntu-pkg/
[18:43] <mathiaz> james_w: that works fairly well
[18:43] <james_w> ah, native package
[18:43] <james_w> yeah
[18:43] <Tonio_> siretart: the unstripped libavformat seems to have been dropped from it, but there are still conditionnal deps to it on the -dev package and so on...
[18:43] <mathiaz> james_w: yes - because it's an snapshot from the upstream git-import
[18:43] <james_w> so I need to think about the best UI for this, but I can tell you how to get unblocked
[18:44] <Tonio_> siretart: it the removal an error, or should the deps be fixed ? although I couldn't find the package in debian, when it's supposed to be a merge... so I don't know what to do on that point :)
[18:45] <james_w> mathiaz: if you run "bzr merge-upstream <released tarball> <upstream branch> [-r revision tarball corresponds to]"
[18:45] <james_w> mathiaz: then it will fail because it can't find an "upstream-" tag, but as it is currently a native package then it doesn't
[18:45] <james_w> mathiaz: make sense for there to be one.
[18:45] <Ampelbein> hey there. could some core-dev restart the builds for gnome-system-tools? https://edge.launchpad.net/ubuntu/+source/gnome-system-tools/2.27.3-0ubuntu1 - The dependency (libpolkit-gtk-1-dev) is available and published now.
[18:46] <james_w> mathiaz: so I suggest you tag the tip of your current branch with the "upstream-" name it specifies, run the command again, and then delete the tag
[18:47] <james_w> mathiaz: we need some way to say "stop looking for the tag and just use the tip".
[18:58] <geser> Ampelbein: depwait should get retried automatically
[19:00] <Ampelbein> geser: is there a timeframe for retrying?
[19:00] <geser> Ampelbein: libpolkit-gtk-1-dev needs to be promoted to main as g-s-t is in main
[19:04] <Ampelbein> geser: ok, I thought that binaries automatically get promoted when their respective sourcepackage is in main.
[19:04] <geser> no, it possible that a source package in main build packages which are in universe
[19:16] <mathiaz> cr3: http://paste.ubuntu.com/258821/ <- checkbox upgrade testing failed
[19:19] <cr3> mathiaz: beautiful, patch doesn't preserve permissions :(
[19:20] <cr3> mathiaz: fix pushed to alpha-4 branch
[19:24] <ogra> seems that since a while my machines dont have any DPMS functionallity anymore, does anyone else see that ?
[19:24]  * ogra wonders what that is 
[19:26] <maco> Keybuk: wow that init/upstart logging bug sure gets a lot of attention
[19:26] <ogra> maco, it did even before upstart existed
[19:27] <ogra> bootlogd is broken since ubuntu exists
[19:27] <maco> i thought it broke around feisty
[19:27] <maco> but i dont recall seeing multiple-comments-per-day until the last month o so
[19:27] <maco> *or so
[19:28] <ogra> no, i remember i had a spec i worked on at ubuntu down under (pre-hoary uds)
[19:28] <maco> though on the other hand quite a lot were people arguing with scott about which should be the master bug :P
[19:28] <maco> wow
[19:28] <ogra> and then upstart came
[19:28]  * maco bows to your ancientness :P
[19:28] <mathiaz> cr3: so you don't need any patch to upgrade to 0.8?
[19:28] <ogra> so even if bootlogd would have been fixed, it couldnt have been implemented
[19:29] <cr3> mathiaz: that particular patch was backported to 0.7.2, so I removed the file
[19:29] <ogra> maco, there was some noise about logging boot messages at the ubuntu-users ML ... if they pick up a topic they dont let loose easily ;)
[19:31] <maco> ogra: ah just like u-d-d
[19:31] <ogra> way noisier, but similar, yes
[19:31] <ogra> average amount of posts per day is around 300
[19:31] <maco> yikes! glad im not sub'd to that
[19:32] <maco> i left u-d-d and started taking advantage of kmail's ignore-thread feature to avoid such things
[19:32] <ogra> heh
[19:34]  * ogra calls it a day anyway 
[19:40] <highvoltage> ogra: at 20:34, it's a bit overdue :)
[19:43] <lamont> dchroot: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
[19:43] <lamont> have we figured out why jaunty likes to do that (armel)?
[19:45] <mathiaz> cr3: I've uploaded a new version of checkbox
[19:45] <mathiaz> cr3: https://code.launchpad.net/~cr3/ubuntu/karmic/checkbox/alpha-4/+merge/10445
[19:46] <mathiaz> cr3: however I can't set the merge proposal to 'Merged'
[19:46] <mathiaz> cr3: I think only you can set the Status of branch
[19:47] <cr3> mathiaz: done thanks man! sorry for the few problems encountered, I guess that's to be expected from not proposing a merge in such a long time :(
[19:47] <evand> is it sufficient to put a universe package waiting to go into main in the live seed for it to appear in component mismatches?
[19:49] <ScottK> Yes.
[19:51] <evand> weird, it's (ubiquity-slideshow-ubuntu) not appearing in component-mismatches.txt on p.u.c/~ubuntu-archive, despite me making the seed change at 15:42
[19:51] <evand> perhaps I'm just being impatient :)
[19:51] <evand> thanks ScottK
[19:55] <ScottK> evand: I think component-mismatches is only updated ~4 times a day.
[19:55] <evand> ah, that would do it
[20:00] <mathiaz> james_w: hm - trying your receipe for bzr builddeb you mentionned above about sssd
[20:01] <mathiaz> james_w: I'm running into the same error (in import-dsc)
[20:01] <mathiaz> james_w: I don't see the new bzr-builddeb package uploaded to karmic yet?
[20:02] <ScottK> sistpoty: Time for motu-release meeting on #ubuntu-meeting.
[20:03] <sistpoty> hi ScottK
[20:03] <sistpoty> thanks for the reminder
[20:03] <ScottK> No problem.
[20:03] <sebner> huhu sistpoty ScottK :D
[20:03] <sistpoty> hi sebner
[20:03]  * ScottK tries to remember who's on the team.
[20:04] <ScottK> At 5 after I say we go with who we have.
[20:05] <sistpoty> makes sense
[20:05] <ScottK> Wrong channel though.  Whoops.
[20:12] <highvoltage> "About me: Reinhard Tartler, PHD Student of Computer Science in Erlangen, Germany"
[20:12] <sebner> highvoltage: ?
[20:12] <highvoltage> the Germans actually have a city named after Erlang!? brilliant.
[20:12] <sebner> highvoltage: I think the city is older :P
[20:13] <highvoltage> sebner: :)
[22:03] <jtimberman> i'm looking into creating a build environment for packages, and am interested in sbuild, if i'm running on a jaunty system, i can build packages for other ubuntu and debian releases as well right?
[22:05] <robbiew>  slangasek: is it worth announcing on the mailing list that Feature Freeze is this Thursday?...or was that already done and I just missed it :/
[22:07] <kirkland> bryce: hiya
[22:07] <kirkland> bryce: so i'm looking at a few things with kvm + X
[22:09] <bryce> kirkland, hey
[22:09] <kirkland> bryce: hey
[22:09] <kirkland> bryce: first, there seems to be a regression in the qemu/sdl since this morning
[22:09] <kirkland> bryce: http://pastebin.ubuntu.com/258928/
[22:10] <thumper> hi guys
[22:10] <bryce> since this morning?
[22:10] <thumper> where do I find the level of X support for various chipsets?
[22:10] <kirkland> bryce: i think so...  i was running qemu-kvm this morning, did a few graphical installs
[22:10] <kirkland> bryce: now, i'm bombing out with that sdl or framebuffer erro
[22:10] <kirkland> error
[22:10] <bryce> kirkland, new kernel?
[22:10] <kirkland> crw-rw---- 1 root video 29, 0 2009-08-24 09:30 /dev/fb0
[22:11] <kirkland> bryce: yeah, i think so
[22:11]  * kirkland notes that he's not a member of video
[22:11] <kirkland> bryce: i don't *think* i need the framebuffer ... i just want an sdl window to pop open
[22:12] <bryce> yeah I don't even have the /dev/fb0 device on this bux
[22:12] <bryce> box
[22:12] <bryce> kirkland, however I *am* in the video group
[22:12] <kirkland> bryce: okay, nevermind ...
[22:12] <bryce> could it just be a quirk of how your user account got setup?
[22:12] <kirkland> bryce: that one was a dumb mistake on my part
[22:13] <kirkland> bryce: i was ssh'd to localhost :-/
[22:13] <bryce> heh!
[22:13] <kirkland> bryce: okay, that one is solved ...
[22:13] <kirkland> bryce: now to your questions :-)
[22:13] <kirkland> bryce: regarding the X server
[22:13] <kirkland> bryce: let me first make sure I understand the purpose of those hacks
[22:14] <bryce> sure
[22:15] <slangasek> robbiew: yes, will send an announcement mail this afternoon
[22:15] <kirkland> bryce: okay karmic host, karmic guest .... default desktop loads at 800x600
[22:15] <robbiew> slangasek: cool...thnx
[22:16] <bryce> kirkland, the purpose of dexconf is to write out the default xorg.conf
[22:17] <kirkland> bryce: the goal is to run without an xorg.conf, right?
[22:17] <bryce> kirkland, so what these hacks do is detect if kvm/qemu/vbox is in use, and if so to hardcode a particular driver in the xorg.conf
[22:17] <bryce> kirkland, indeed; in fact already we've switched to running without xorg.conf in karmic
[22:17] <bryce> so... dexconf has become vestigial
[22:18] <bryce> thus, two options
[22:18] <bryce> one is to have the kvm/qemu/vbox use cases deliberately run 'sudo dexconf' during install so the hacks still get triggered and an xorg.conf still gets put in place
[22:19] <bryce> two is to get rid of the hacks and move the logic into the xserver's automatic driver selection code, so xserver "knows" about kvm/qemu/vbox
[22:19] <kirkland> bryce: cool, so i think i agree that (2) is preferential
[22:19] <bryce> the latter is not has hard as it sounds, just add an extra case section in a switch statement
[22:20] <bryce> most of the effort is testing, to make sure it's set up right
[22:20] <bryce> what I can do is, if you tell me the pci id's, rough up a patch that I *think* will do it
[22:21] <bryce> then you can test and/or tweak the patch to make sure it works well, and we stick it in
[22:21] <kirkland> bryce: you want the pci id's of the cirrus video device in the qemu-kvm guest?
[22:21] <bryce> kirkland, that's right
[22:21] <kirkland> bryce: sure, let me fire one up
[22:21] <bryce> also vbox if that's handy
[22:22] <kirkland> bryce: i can't help you there, sadly :-/
[22:23] <kirkland> bryce: we should be able to offer higher than just 800x600 with the cirrus driver, huh?
[22:23] <kirkland> bryce: at least 1024x768?  any higher?
[22:24] <bryce> kirkland, I would imagine so... does kvm implement the asm call to retrieve EDID from the virtual monitor?
[22:24] <bryce> that's the proper way that video modes are communicated these days
[22:25] <kirkland> bryce: i'm in the qemu code right now... what am I looking for?
[22:26] <kirkland> bryce: http://pastebin.com/f5584d17e
[22:26] <kirkland> bryce: that's lspci -v on a karmic host/guest with cirrus driver
[22:27] <sbeattie> bryce: one sec, and I'll grab the pci-ids from vbox (at least with jaunty host/guest)
[22:27] <kirkland> sbeattie: thx
[22:29] <bryce> kirkland, ok now my knowledge of how all this dark magic works is a bit incomplete
[22:30] <kirkland> bryce: okay, i don't see any references in the source code to edid
[22:30] <kirkland> bryce: i'm talking to upstream, though
[22:30] <kirkland> bryce: so, i suspect the answer is "no"
[22:30] <bryce> however on the X side it queries...  I2CBus (?) with the monitor id, which returns an EDID_block structure
[22:30] <bryce> this is done through DDC or DDC2, which is the communication protocol for the monitor
[22:31] <sbeattie> bryce: lspci -vvnn at http://pastebin.com/f2dc49bb8
[22:31] <bryce> kirkland, I'm looking at the code in xorg-server-ubuntu-git/hw/xfree86/ddc/ btw
[22:32] <bryce> mm, there's a DDC.HOWTO in that directory too
[22:35] <kirkland> bryce: okay, upstream says "no" to EDID/asm call
[22:35] <kirkland> bryce: it's not implemented
[22:36] <bryce> kirkland, alright, so then in the kvm case unless resolutions are set in xorg.conf, you'll be stuck with generic defaults
[22:37] <bryce> (which might include 1024x800, I'm not sure)
[22:37] <bryce> er 1024x768
[22:37] <bryce> kirkland, hey can you post 'lspci -vvnn'?  The default lspci output does not provide the pci id's
[22:37] <bryce> sbeattie, thanks
[22:38] <kirkland> bryce: sure
[22:38] <bryce> sbeattie, hehe 80ee:beef
[22:41] <kirkland> bryce: http://pastebin.com/f1302c310
[22:42] <sbeattie> bryce: in vbox's case, X defaults to 640x480 and 800x600. vbox supports many more modes, dapper's X config sets 1024x768 and that works and hwinfo --framebuffer is able to find a bunch.
[22:42] <bryce> kirkland, hmm, cirrus is already in there
[22:42] <bryce>         case 0x1013:                driverList[0] = "cirrus"; break;
[22:43] <bryce> kirkland, try moving aside your xorg.conf and restarting X and see if it gets the driver right
[22:43] <kirkland> bryce: k
[22:44] <bryce> sbeattie, got an Xorg.0.log you can pastebin for me?
[22:44] <kirkland> bryce: i have no xorg.conf :-)
[22:45] <bryce> sbeattie, fwiw vbox's driver wasn't already in there; I can add it easily though.  Maybe the reason for the reduced resolution set is just missing its driver
[22:45] <sbeattie> bryce: one sec.
[22:45] <bryce> kirkland, so... you're up and running with no xorg.conf?  how is the resolution selection (run 'xrandr')?
[22:46] <kirkland> bryce: correct
[22:46] <kirkland> bryce: up and running, no xorg.conf (fresh karmic kvm install from this morning)
[22:46] <kirkland> bryce: resolution options are 800x600 and 640x480
[22:47] <bryce> kirkland, ok, had you also tried with the xorg.conf present?  If not, try running 'sudo dexconf', restarting X, and seeing if they pop in at that point
[22:47] <kirkland> bryce: http://pastebin.com/f4dbc041d
[22:48] <sbeattie> bryce: http://pastebin.com/f2dc49bb8 from an alpha-3ish karmic amd64 guest.
[22:49] <kirkland> bryce: dexconf fails with exit code 10
[22:49] <bryce> kirkland, hrm, any error messages other than that?  I guess it didn't produce an /etc/X11/xorg.conf?
[22:49] <kirkland> bryce: no xorg.conf written
[22:49] <kirkland> bryce: no errors
[22:50] <kirkland> bryce: sh -x just shows it exec'ing debconf dexconf
[22:50] <bryce> kirkland, ok well the good news is kvm still works even in the new X setup... just that due to lack of EDID it's not getting its full set of resolutions
[22:50] <kirkland> bryce: heh, yeah
[22:51] <bryce> sbeattie, I'm guessing this same thing will affect vbox, unless it also provides a virtual monitor with EDID
[22:51] <bryce> the dexconf breakage is... troubling...
[22:51] <bryce> but let's leave that aside for the time being
[22:51] <kirkland> bryce: this launch-from-the-command-line i think is mostly a developer-only use case
[22:51] <kirkland> bryce: i suspect most users will use some form of libvirt, which will launch with a vnc server
[22:52] <bryce> kirkland, ok, how does that use case differ exactly?
[22:52] <kirkland> bryce: well, most of my developer-level testing, i just run kvm from the command line, which pops open an SDL window
[22:52] <kirkland> bryce: most users, though, i think will use something like virt-manager
[22:53] <kirkland> bryce: which adds a bunch of options to kvm, including -vnc
[22:53] <kirkland> bryce: i'm testing that now ....
[22:53] <kirkland> bryce: stand by :-)
[22:55] <kirkland> bryce: when i'm launching from the command line, mine looks like this: "/usr/bin/kvm -m 512 -hda karmic-desktop.img"
[22:55] <kirkland> bryce: when virt-manager launches, it looks like: /usr/bin/kvm -S -M pc -m 512 -smp 1 -name karmic-desktop -uuid 132868d4-ba99-3c44-a158-20e51435b9f6 -monitor pty -no-reboot -boot d -drive file=/local/virt/iso/karmic-desktop-amd64.iso,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/karmic-desktop.img,if=virtio,index=0 -net nic,macaddr=54:52:00:03:06:95,vlan=0,model=virtio -net tap,fd=18,vlan=0 -serial pty -par
[22:55] <kirkland> allel none -usb -vnc 127.0.0.1:0 -k en-us -soundhw es1370
[22:55] <kirkland> bryce: note the -vnc
[22:57] <cjwatson> ScottK: FWIW component-mismatches is supposed to be updated hourly
[22:58] <bryce> sbeattie, kirkland: ok here's the patch for driver detection goodness - http://people.canonical.com/~bryce/virtual_devices.patch
[23:02] <kirkland> bryce: cool, are you going to build that somewhere that I can verify it for you?
[23:04] <bryce> kirkland, I don't think there is a need for you to test this one since it won't fix anything for your kvm
[23:05] <bryce> checking bug reports...
[23:05] <kirkland> bryce: how complicated is this EDID response?
[23:05] <kirkland> bryce: is that something I can craft easily enough?
[23:06] <kirkland> bryce: from the qemu side, i mean
[23:06] <bryce> kirkland, no clue but I've located a patch that mdeslaur found from redhat for this
[23:07] <bryce> kirkland, see bug 349331
[23:09] <bryce> bug 237164 looks similar/dupe-ish
[23:09] <kirkland> bryce: that cirrus driver patch looks promising; is that something we could carry as well?
[23:09] <kirkland> bryce: yes, the latter was the one I was most aware of
[23:09] <kirkland> bryce: and trying to solve in this half-day of working on qemu-kvm's video issues
[23:11] <bryce> kirkland, see in particular https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/237164/comments/13
[23:11] <bryce> kirkland, yeah I can pull that patch in
[23:11] <NCommander> kirkland, an archive admin should have done the backport ages ago
[23:11] <NCommander> kirkland, (sorry, just got to looking at this)
[23:12] <NCommander> kirkland, its properly subscribed on our end
[23:15] <kirkland> NCommander: thanks
[23:16] <NCommander> kirkland, I dunno why its stuck :-/
[23:18] <kirkland> bryce: i can confirm that an F11 guest has much higher resolutions available :-)
[23:18] <bryce> hrm, -cirrus lacks a patch system...
[23:19] <kirkland> bryce: well, it has 1024x768
[23:19] <kirkland> bryce: which is much better
[23:19] <bryce> kirkland, so nice of redhat to fix it !upstream ;-)
[23:19] <kirkland> bryce: *wink*
[23:20] <cjwatson> I'm currently engaged in upstreaming a patch that originated with Red Hat
[23:20] <cjwatson> it happens more often than the marketroids might care to think ;-)
[23:21] <cjwatson> (actually, we're reimplementing the significant bits in a different way)
[23:21] <kirkland> cjwatson: if you have any AA bandwidth available, could you finish the kvm-84 backport task?
[23:22] <kirkland> cjwatson: it's been in the queue for several weeks now
[23:25] <cjwatson> kirkland: done for intrepid-backports
[23:26] <kirkland> bryce: i added a task for xserver-xorg-driver-cirrus (Ubuntu) to bug #349331
[23:26] <kirkland> bryce: you can close that task in your upload
[23:26] <bryce> cjwatson, yeah it seems like it redhat used to be better at pushing patches upstream; only really distro-specific patches sat there.  Lately though I'm finding I have to pull more stuff from their trees.
[23:26] <bryce> kirkland, thanks
[23:27] <bryce> sbeattie, ok your vbox pci id support is uploaded to karmic.  You should be able to run vbox with no xorg.conf now
[23:27] <sbeattie> woo
[23:27] <bryce> sbeattie, although potentially you may see reduced resolutions available when doing so, as kirkland has run into
[23:28] <bryce> sbeattie, let me know if that's the case and we can maybe adopt a similar approach for fixing that
[23:28] <bryce> sbeattie, the fix is in xorg-server_1.6.3-1ubuntu4
[23:29] <sbeattie> bryce: cool, thanks so much; I'll give it a go and let you know what the result is.
[23:31] <kirkland> NCommander: okay cjwatson approved it for intrepid-backports;  so we're going to give that a few days before approving it for hardy-backports?
[23:31] <NCommander> kirkland, he has to accept kvm, and autobackport libvirt as per the bug, but yes
[23:31] <kirkland> NCommander: okay, i'll sit tight
[23:33] <NCommander> kirkland, sorry about this getting lost in the pile
[23:34] <kirkland> NCommander: it happens, no worries;  let's try to get it out to hardy by week's end, cool?
[23:34] <NCommander> kirkland, sure
[23:47] <bryce> kirkland, okay!  Patch uploaded for -cirrus
[23:47] <kirkland> bryce: cheers, thanks;  i'll try it out in a bit
[23:47] <bryce> kirkland, I had to re-add the patch system and stuff, and to the best of my knowledge it should load and work, but please test and let me know.
[23:47] <kirkland> bryce: you bet
[23:48] <bryce> ok, heading out to buy some fish.  be back later.
[23:56] <fbond> slangasek: https://wiki.ubuntu.com/PointReleaseProcess indicates that an archive snapshot is made for point releases.  Is this snapshot publicly accessible somewhere?
[23:56] <slangasek> fbond: no, it isn't
[23:58] <fbond> slangasek: I'm building a product on top of Ubuntu.  For this product, many builds will be created over time, and I'd like to be able to choose a consistent set of package versions for builds made at different times.
[23:58] <fbond> Is my best option to mirror the archives and create my own snapshots?
[23:59] <slangasek> fbond: hmm, for those purposes I think that's what makes the most sense
[23:59] <fbond> (Basically, I need to organize my builds around my own concept of a "release".  My plan was to mimic Ubuntu's releases, e.g. 8.04.2, etc.)
[23:59] <fbond> slangasek: Is there at least some way to determine which package versions are present in the official snapshots?