[03:25] <YokoZar> Hmm, it seems like wine1.2-gecko was deleted from the archive
[03:26] <YokoZar> or maybe it never built in the first place...
[03:30] <TheMuso> /c/c
[04:26] <Redman> #ubuntu-programming
[05:02] <al-maisan> Hello there! The new 2.6.31-7-generic kernel gets stuck  (i.e. just sists there, won't boot up) on my lenovo T61 after unlocking an encrypted physical volume. What's the best way to debug this?
[05:03] <StevenK> al-maisan: Does it work if you boot -6?
[05:04] <al-maisan> StevenK: yes, that's what I fell back to ..
[05:04] <al-maisan> i.e. that's the kernel I am running presently
[05:12] <TheMuso> al-maisan: Someone reported that the 7 kernel breaks encrypted lvm in here yesterday, I think it was dtchen, who is not currently around atm.
[05:12] <al-maisan> TheMuso: ah, I see, so it's a known issues. That's good. Thanks for letting me know!
[05:13] <TheMuso> Whether a bug has been filed, I don't know.
[05:13] <TheMuso> I'd say there has been.
[05:13] <al-maisan> OK. I'll search for it.
[05:30] <al-maisan> TheMuso: Bug #418514
[05:37] <TheMuso> al-maisan: good to hear that there is one.
[05:37]  * TheMuso notes that he is not affected by this.
[05:37] <al-maisan> Yeah .. just wanted to make sure it's a known issue.
[05:51] <TheMuso> Hrm so its not just encrypted LVM, but LVM as well. Hrm maybe I'll have to avoid that kernel as well, since I use LVM not encrypted here...
[05:52] <al-maisan> yep.
[06:12] <dholbach> good morning
[06:14] <vorian> evening!
[06:20] <al-maisan> good morning dholbach :)
[06:20] <dholbach> hey al-maisan!
[06:22] <pitti> Good morning
[06:23] <StevenK> pitti: Morning!
[06:23] <pitti> hey StevenK
[06:23] <StevenK> pitti: It seems all of libcupscgi1 libcupsdriver1 libcupsmime1 libcupsppdc1 cups-ppdc ended up in universe, I promoted them about 15 minutes ago
[06:23] <pitti> StevenK: ah, thanks
[06:26] <StevenK> pitti: When you have a sec, could you look at bug 419029 ?
[06:28] <pitti> StevenK: approved, bug updated
[06:29] <pitti> no-brainer
[06:34] <StevenK> pitti: Thanks, I'll promote it
[06:41] <dholbach> can we all try to unsubscribe the sponsors teams from requests that are very old and waiting for input?
[06:41] <dholbach> the list is HUGE
[06:42] <dholbach> vorian: what about bug 386428?
[06:46] <dholbach> ArneGoetje: what about bug 407649?
[06:49] <dholbach> ogra: can you take a look at bug 385850?
[06:59]  * nixternal hugs dholbach 
[07:00]  * dholbach hugs nixternal back
[07:21] <ArneGoetje> dholbach: pitti will take care of the sync today
[07:21] <pitti> already done
[07:21] <pitti> oh, I didn't know that you filed new sync bugs, please close them
[07:22] <pitti> I thought the requests in the MIR bug were enough
[07:22] <pitti> dholbach, ArneGoetje ^
[07:22] <ArneGoetje> pitti: oh, sorry, that one is scim-anthy
[07:23] <pitti> oops, indeed, sorry
[07:23] <dholbach> yep
[07:23] <pitti> I synced ibus
[07:23] <pitti> nevermind me then
[07:23] <dholbach> if scim-anthy should go to universe, we should be able to sync it
[07:23] <dholbach> and not promote a new recommends to main
[07:26] <ArneGoetje> dholbach: well, I will change the language-support-input-* dependencies today to pull ibus instead of scim. So, I think it's safe to put it into universe
[07:27] <dholbach> pitti: looks good to you?
[07:27] <pitti> sure, but it shouldn't be done before it actually gets demoted
[07:27] <dholbach> ok
[07:27] <dholbach> I'll leave it like that then
[07:28] <ArneGoetje> so, change the seeds and language-support- stuff first?
[07:28] <pitti> yes
[07:37] <dholbach> if anybody could double-check bug 414298 I'd appreciate it
[07:42] <ojwb> mvo: any issues with that xapian-core patch?
[07:44] <mvo> ojwb: no, its seems to be working just fine. no open bugs or crashreports since I uploaded it
[07:45] <mvo> thanks again for the patch!
[07:46] <ojwb> cool, I'm just preparing a new upstream release
[07:48] <dholbach> I guess the "machine does not power down on shutdown" bug is already known? IIRC it happens since the -7 kernel
[07:52] <mvo> dholbach: I have it here too
[07:58]  * pitti too
[08:00]  * TheMuso is not yet on 7 due to the lvm bug.
[08:59] <ArneGoetje> pitti: would it be possible to seed ibus-m17n with its dependencies onto the LiveCD?
[08:59] <pitti> ArneGoetje: I didn't compare sizes yet; how much space does scim and the default tables take?
[09:00] <ArneGoetje> pitti: how do I find out?
[09:00] <pitti> apt-cache show packagename | grep ^Size
[09:00] <pitti> for all the scim related packages we ship by default
[09:01] <pitti> you can use the .manifest files on cdimage.u.c. daily-live/current to see the list of packages which we ship by default
[09:01] <ArneGoetje> thanks, that would help alot
[09:02] <pitti> an easier method might be to have a clean chroot, and then do "apt-get install <all packages>" and see how much stuff apt needs to download
[09:02] <pitti> with "all packages" being either all seeded scim or all to-be-seeded ibus packages
[09:02] <pitti> that's quick for comparing, since it also considers all library dependencies
[09:03] <pitti> sudo apt-get install ibus ibus-m17n on my system -> 3370kB
[09:03] <pitti> (I think you needed some more, right?)
[09:05] <kagou> Hi,is it possible to collect data for an existing bug ? I mean that ubuntu-bug collect data for a package or a PID but not for an existing bug.
[09:05] <pitti> kagou: yes; man apport-collect
[09:06] <kagou> oh
[09:06] <kagou> damned ! thanks pitti
[09:06] <pitti> :)
[09:07] <kagou> may be ubuntu-bu should be enhanced to report to bug too ?
[09:07] <ArneGoetje> pitti: I'll make a list
[09:07] <pitti> kagou: yes, it could be made clever enough for that
[09:16] <cjwatson> oh, seriously, -7 breaks lvm? that's going to be amusing for the installer work I need to get done TODAY
[09:17] <cjwatson> how exactly does it break lvm? the bug is not very clear, and the one clear symptom (padlock_sha failing to load) wouldn't affect ordinary lvm
[09:17] <cjwatson> so I wonder if some bug conflation is going on
[09:19] <kagou> pitti, I'v open a bug for that #419093
[09:36] <slytherin> Hi, with latest pulseaudio in karmic, I have very low volume for songs etc. Is this expected?
[09:38] <TheMuso> slytherin: No, this is not expected.
[09:39] <slytherin> Ok. I will log a bug when I go home.
[09:41] <TheMuso> slytherin: Is this on your ibook?
[09:42] <slytherin> TheMuso: No. My PC. I never had to turn the speaker volume to full before (in jaunty).
[09:43] <TheMuso> slytherin: ok then, please file a bug when you get the chance.
[09:44] <slytherin> I will tonight.
[09:44] <\sh> I wonder how do I get sound from flashplayer on karmic 64bit again..the app doesn't show up in pulse mixer somehow...so I don't know where pulseaudio is routing the audio stream to
[09:45] <ogra> mumble, no glazor
[10:08] <ArneGoetje> pitti: are you sure I need to gret for ^Size: and not for ^Installed-Size?
[10:08] <ArneGoetje> grep
[10:09] <dholbach> TheMuso: not sure if you noticed, but python-louis is in universe
[10:10] <TheMuso> dholbach: an MIR has been written for it and it has been approved.
[10:10] <TheMuso> dholbach: I would not have done that otherwise.
[10:10] <dholbach> ah ok
[10:17] <pitti> ArneGoetje: yes; we are interested in the compressed size (.debs)
[10:17] <ArneGoetje> pitti: ok...
[10:19] <taavikko> any way for ubuntu-bug to just create the report e.g"test.report" which then could be sent via ssh to other machine and reported that way?
[10:19] <pitti> taavikko: unfortunately not with ubuntu-bug; it's meant to be a parameter-less easy interface
[10:20] <pitti> taavikko: you can use apport-cli -f -p <package> and save the report, see manpage
[10:20] <pitti> taavikko: or, if it's a crash (not a bug report), just don't send it and scp /var/crash/... file
[10:21] <taavikko> thanks pitti :) seems ubuntu-bug works in xterm session so no nee
[10:26] <pitti> taavikko: yes, it uses apport-cli if there's no $DISPLAY
[10:26] <\sh> if any archive admin of the day can look at bug #419099 that would be great...we would like to get this solved before FF
[10:27] <taavikko> thanks for all the work on ubuntu-bug/apport it makes it so much easier to provide better info on bugs.
[10:27] <pitti> *beam* :)
[10:27]  * pitti does the finishing touches for intercepting assertion messages in apport
[10:29]  * directhex calls assert() in some platform code, to make pitti feel needed
[10:29] <pitti> directhex: Keybuk has plenty of them apparently :)
[10:30] <directhex> pulse is chock full of 'em
[10:33] <pitti> ArneGoetje: so, ibus ibus-gtk ibus-m17n pull in 3.5 MB
[10:33] <ArneGoetje> pitti: http://pastebin.ubuntu.com/259752/
[10:33] <pitti> ah, that's probably imprecise since I have scim installed
[10:33] <pitti> which might share some tables
[10:34] <ArneGoetje> pitti: the numbers in that list are the grep'ed Size: field
[10:34] <pitti> ArneGoetje: ah, nice
[10:34] <ArneGoetje> pitti: what apt-get gives you is the Instaled-Size, AFAIK
[10:34] <pitti> ArneGoetje: that's not just scim->ibus, but also font changes? or are the fonts related to ibus?
[10:34] <ArneGoetje> pitti: no, font changes are extra
[10:34] <pitti> ArneGoetje: it gives you both ("Es müssen 3459kB an Archiven heruntergeladen werden." -> deb size)
[10:34] <pitti> ArneGoetje: ok
[10:35] <ArneGoetje> pitti: I might do some more font shuffeling, so this list is not final in that regard
[10:35] <pitti> ArneGoetje: thanks for the analysis
[10:36] <pitti> ArneGoetje: the seed changes are blocked by the im-switch update, right?
[10:36] <ArneGoetje> pitti: yeah
[10:38] <ArneGoetje> pitti: can we discuss the im-switch changes somewhere?
[10:38] <pitti> sure, /msg?
[10:39] <ArneGoetje> pitti: ok
[10:51] <ogra> glatzor, moo
[10:53] <glatzor> ogra, servus!
[10:53] <glatzor> ogra, the armel failure?
[10:53] <ogra> glatzor, you dropped my fix from packagekit :'(
[10:53] <ogra> yeah
[10:54] <ogra> hughsie always forgets to drop -Werror from his tarballs
[10:54] <glatzor> ogra, in the 0.5 series it is optional
[10:54]  * ogra had that issue a thousand times with gnome-power-manager beforte
[10:54] <ogra> well, it makes armel ftbfs
[10:55] <glatzor> ogra, I will rework the patch
[10:55] <ogra> thanks a lot
[10:55] <ogra> though it would be nice if he could disable it upstream before rolling a release
[10:55] <ogra> i know seb128 rants about that all the time too :)
[10:55] <glatzor> ogra, it is also always a topic on the maling list :)
[10:56] <pitti> ogra: what's wrong with -Werror?
[10:56] <pitti> ogra: I'd rather get an armel build fix upstream than to kludge around with it?
[10:56] <ogra> pitti, armel (sparc and ppc too) often have simple warnings ...
[10:57] <ogra> pitti, seb always tells me its gnome policy that there is no -Werror in the released tarballs
[10:57] <liw> why does armel have lots of simple warnings?
[10:57] <pitti> ogra: I don't know, if that's the policy he should stick to it of course
[10:58] <pitti> but still, I actually like programs which don't have warnings, too
[10:58] <ogra> liw, feel free to fix them ... if the app works fine but a build dies because of Werror i perfer to just drop the Werror according to the upstream policy
[10:58] <liw> ogra, why do the warnings happen on armel but not on x86?
[10:58] <pitti> that should depend on the actual warning
[10:59] <ogra> right
[10:59] <pitti> we had warnings about pointer misalignments which were real bugs
[10:59] <liw> (I'm not worried, merely mildly curious)
[10:59] <pitti> ^ me too
[10:59] <ogra> liw, because certain kinds of vars are handled differemntly for example
[11:00] <ogra> /usr/include/gstreamer-0.10/gst/gstmessage.h: In function 'gst_message_ref':
[11:00] <ogra> /usr/include/gstreamer-0.10/gst/gstmessage.h:302: error: cast increases required alignment of target type
[11:00] <ogra> thats the current warning that makes packagekit die for example
[11:00] <liw> that sounds like a real bug to me :)
[11:00] <liw> (but then I'm a C standards compliance purist)
[11:01] <ogra> the app functions as its supposed to
[11:01] <pitti> sounds like a potential bug, though
[11:01] <lifeless> even on sparc ?
[11:01] <lifeless> :)
[11:01] <pitti> it wouldn't be the first time that sparc crashes because of a misaligned variable
[11:01]  * liw wants to sell his hardcover paper copy of the 1999 C standard, thoug
[11:01] <dholbach> cjwatson: should juli_ be able to upload stuff (libnb-javaparser-java) already?
[11:02] <cjwatson> yes
[11:02] <dholbach> thanks cjwatson
[11:02] <ogra> lifeless, well, http://qa.ubuntuwire.com/ftbfs/ ... packagekit is dep wait on sparc :)
[11:03]  * ogra thinks if a warning should be a bug or error it should actually spit out an error and not a warning
[11:04] <ogra> we have tons of packages that build with warnings in the build logs
[11:04] <ogra> they simply dont have Werror set :)
[11:04] <Keybuk> pitti: but sadly my asserts don't make it into apport :-(
[11:05] <pitti> Keybuk: they should now :)
[11:05] <Laney> happyaron: I'm just looking at tor. Do you know if upstream are going to give you any help with supporting old releases?
[11:05] <pitti> (not uploaded yet, still finishing touches)
[11:05] <Keybuk> pitti: how?  I don't use assert() :p
[11:05] <Keybuk> pitti: also the kernel doesn't wait for apport to complete before panicing yet
[11:05] <pitti> Keybuk: ah, I thought you did, since you pushed for it in https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort
[11:05] <pitti> Keybuk: the latter point is what I asked about in the whiteboard, that point isn't clear to me
[11:06] <happyaron> Laney: they seems won't, but I think if update the package in repository is acceptable for us, I can do it
[11:06] <Laney> you mean a new upstream version?
[11:06] <Keybuk> pitti: the __assert_msg stuff?  If that works, I can certainly put the message in there :-)
[11:06] <pitti> Keybuk: right
[11:07] <happyaron> Laney: I can catch up with the new releases in upstream repository, and re-pack the packages for ours
[11:07] <Keybuk> pitti: I saw that someone has proposed a patch to make the kernel wait for apport to finish before making the process a zombie as well
[11:07] <Laney> happyaron: The SRU policy doesn't usually allow for that though
[11:08] <happyaron> Laney: yeah, this is the key problem now
[11:08] <pitti> Keybuk: I thought the whiteboard said something about apport needing to defer close()ing stdin until it's fully done or so?
[11:09] <happyaron> Laney: I've mentioned in that bug, upstream can raise version number however they like to
[11:10] <pitti> Keybuk: actually, apport doesn't do any special magic to close stdin
[11:10] <pitti> it just reads until EOF
[11:11] <Laney> it's a bit of a difficult issue really
[11:11] <Keybuk> pitti: doesn't work, the kernel still panics too early
[11:12] <Laney> happyaron: I would appreciate it if you could talk to some members of the SRU team
[11:12] <Laney> if you can work out some arrangement with them then we should go ahead
[11:12] <happyaron> Laney: where can I find them?
[11:12] <Keybuk> pitti: http://lkml.org/lkml/2009/6/22/368
[11:13] <Keybuk> pitti: we need part of that patch set
[11:13] <Laney> happyaron: https://launchpad.net/~motu-sru/+members
[11:14] <happyaron> Laney: how much time do we still have from now to DIF?
[11:14] <Laney> FF is what you care about, and it's tomorrow
[11:15] <Laney> I would rather get an exception than rush though
[11:15] <didrocks> liw: Hey, I'm reading this discussion (bug #329060) about the automatic symlinking of identical changelog files. What does this (as I have it also in my pbuilder), dpkg-buildpackage, pkgbinarymangler?
[11:16] <happyaron> cody-somerville: hi
[11:17] <cody-somerville> happyaron, hello
[11:17] <liw> didrocks, I don't know what does the symlinking of identical changelogs
[11:17] <happyaron> cody-somerville: I would like to ask you about some SRU issue about tor
[11:17] <cody-somerville> happyaron, Okay.
[11:18] <didrocks> liw: ok, and there is nothing written in wiki.ubuntu.com? In any case, I think i'll try to patch at least lintian
[11:18] <cjwatson> didrocks: cdbs
[11:18] <liw> didrocks, patching lintian (in Ubuntu) to not warn about that would be good, yes
[11:19] <happyaron> cody-somerville: as I want tor could reintroduce to ubuntu, we need to update it whenever upstream update the package, or upstream will be unhappy to the packages they don't support
[11:19] <cjwatson> the warning is still correct for Debian though, so that isn't upstreamable
[11:19] <didrocks> cjwatson: I'm using debhelper 7 in the present case, so where is the common denominator? :)
[11:19] <cjwatson> if you're using debhelper 7 I'm not sure I believe you that automatic symlinking is happening :)
[11:20] <cjwatson> to the best of my knowledge dh7 doesn't do that
[11:20] <happyaron> cody-somerville: I mean we need to keep the package up-to-date rather than keep it a specific version in our repository as other packages
[11:20] <cjwatson> try DH_VERBOSE=1 to see what's going on?
[11:20] <didrocks> cjwatson: It's just appear on a package which uses dh7 (and I didn't notice it before)
[11:20] <cjwatson> maybe the package is doing it for itself?
[11:20] <didrocks> cjwatson: yeah, I'm testing that now :)
[11:20] <cjwatson> as in, hand-coded stuff in debian/rules
[11:20] <pitti> cjwatson, didrocks: it's done by /usr/share/cdbs/1/rules/debhelper.mk
[11:20] <didrocks> cjwatson: not from what I see
[11:21] <cjwatson> pitti: right, that's why I said "cdbs", but it's not a native debhelper thing
[11:21] <cody-somerville> happyaron, Is there a particular reason why?
[11:21] <pitti> so all cdbs packages which include that (IOW, pretty much _all_ cdbs packages) get it
[11:21] <pitti> cjwatson: right, just to confirm you, it's not done in dh proper
[11:22] <didrocks> pitti: cjwatson : ok, i didn't see but the package is using dh 7 commands, but it includes debhelper.mk. So, here is the explanation :/
[11:22]  * didrocks will fix this
[11:23] <didrocks> thanks ;)
[11:23] <happyaron> cody-somerville: we have tor in our repository before, but once upstream filed a bug to request a deletion of it because they don't want us ship the old version of their software that they don't support any more, and if we want to reintroduce it, we need to keep it up-to-date or upstream may file another bug to do it again
[11:24] <cody-somerville> happyaron, What sort of changes are made between versions? How often do they release?
[11:25] <pitti> didrocks: what package in particular, BTW?
[11:25] <pitti> didrocks: (please note that if you drop cdbs for packages which have translations, you also need to do a lot of other stuff manually, like createing POT files, adding gettext domains to desktop files, and the like)
[11:26] <didrocks> pitti: it's upstream cairo doc package (not yet in ubuntu). They want to replace the current ubuntu package but I have to fix a lot of issues first.
[11:27] <pitti> didrocks: ok, doesn't sound like something that would be on the CDs then
[11:27] <happyaron> cody-somerville: mostly security updates, and they update it not very frequently but not very regular, either
[11:27] <didrocks> pitti: ok, so maybe, it's better to remove the debhelper 7 overrides call and change them in cdbs equivalent?
[11:27] <pitti> didrocks: your choice
[11:27] <didrocks> pitti: yes, little chance it hits the CD ;)
[11:28] <cody-somerville> happyaron, ever any non-security updates? ie. new features
[11:28] <happyaron> cody-somerville: we can jump over several releases, just keep the package's version is still supported by upstream is bearable
[11:28] <happyaron> cody-somerville: that will take nearly one year for a new one, and the old one will be dropped to unsupported
[11:32] <jack> meep...i'm someone who "steals" a lot of ubuntu packages and stuff for fink/macos x
[11:32] <jack> just packaging indicator-applet...i wonder what else i need to make that worthwhile ;)
[11:33] <jack> libdbusmenu is done already, too
[11:33] <pitti> jack: I think it's best to talk to tedg or kenvandine in #ubuntu-desktop, but both of them are in USish timezone and still asleep
[11:33] <jack> :)
[11:34] <jack> no suggestions? any fancy apps that use libindicate or libdbusmenu?
[11:34] <pitti> jack: indicator-applet itself is just the base functionality, you need "plugins" to do useful stuff with it; like indicator-evolution, the pidgin plugin, or indicator-session
[11:34] <ojwb> look at the reverse dependencies?
[11:34] <jack> the ubuntu pdb unfortunately doesn't let me walk dep chains
[11:34] <pitti> indicator-messages, too
[11:34] <jack> ojwb: sure, just what i was thinking :)
[11:35] <ojwb> jack: ah, no ubuntu install i guess?
[11:35] <jack> pitti: ok cool, will try the pidgin stuff next
[11:35] <jack> ojwb: i'm still running kubuntu-feisty on my old craptop
[11:35] <jack> the rest are all macs
[11:35] <Laney> happyaron: How does Debian get away with it? The version in Lenny hasn't been updated
[11:36] <happyaron> Laney: they have a so-called trust chain, and the maintainer of tor in Debian is who work for upstream deb repository
[11:36] <Laney> does that get around the security holes?
[11:36] <Riddell> jack: a chroot would work.  on the kubuntu side konversation has support and I should upload kmail and kopete today with it
[11:37] <jack> Riddell: work for what? feisty!
[11:37] <jack> that's almost previous-millenium-ubuntu
[11:37] <Riddell> a karmic chroot would work for feisty yes
[11:37] <Riddell> jack: oh and libindicate-qt of course
[11:37] <jack> but i don't have a box that would be good enough for karmic ;)
[11:38] <Riddell> jack: so make a chroot so you can find the rdepends and do apt-cache search and whatnot
[11:38] <jack> but i can't install current ubuntu pkgs without a working karmic ;)
[11:39] <jack> i just harvest from packages.ubuntu.com, mainly
[11:39] <ttx> james_w: around ?
[11:39] <jack> without ever having seen the stuff running on a current ubuntu box
[11:39] <james_w> hi ttx
[11:39] <ttx> james_w: hey :)
[11:39] <ttx> james_w: about the repacking notes for jetty6
[11:40] <ttx> james_w: it's the orig.tar.gz from debian experimental. There is a README.source that documents it. Do you want me to +dfsg it ?
[11:42] <ttx> james_w: also do you know how repacking should be stated in the new debian/copyright format ?
[11:42] <happyaron> Laney: they update it in unstable as far as I know, I didn't do research on how they solve it for stables
[11:45] <ttx> james_w: note sure adding non-URI stuff to the Source: line is ok. Maybe I can use Disclaimer:
[11:45] <james_w> ttx: I'm not sure I'm afraid
[11:46] <james_w> ttx: I wouldn't consider it a blocker seeing as it is already in
[11:47] <Laney> happyaron: That's the main issue though isn't it?
[11:47] <ttx> james_w: well, kees sees it as a MIR blocker. Maybe you can chime in on bug 418836
[11:47] <happyaron> Laney: okay, I will do it right now
[11:47] <Laney> ie why is it OK for Debian to ship old releases but not Ubuntu
[11:48] <james_w> ttx: yeah, I'd use disclaimer
[11:49] <happyaron> Laney: they update it to the version upstream support, 0.2.0.34 in lenny and etch-backports
[11:49] <happyaron> Laney: upstream requested a deletion for our 0.1.x version's packages
[11:50] <Laney> so that changes things a bit
[11:50] <Laney> ie we don't need to update to the current release all the time
[11:51] <happyaron> Laney: yes, I agree, keep it the version upstream support is ok, only when it's not supported any more we need to update it
[11:51] <Laney> right
[11:51] <Laney> cody-somerville: ^^^
[11:53] <cody-somerville> Are they fine with the updates going into -backports instead of -updates?
[11:56] <happyaron> cody-somerville: for older releases is ok, but how to do it for current release if update is needed?
[11:56] <cody-somerville> happyaron, You simply need to request a backport.
[11:56] <cody-somerville> happyaron, If the new version is only security fixes, a security upload can also be done.
[11:58] <happyaron> cody-somerville: but if there is a new release with new features, I think this is the most difficult thing to concern?
[11:58] <cody-somerville> happyaron, If there is new features, the updated version could go into backports.
[11:59] <happyaron> cody-somerville: I have said it's okay for older releases, but what about current release, just like Jaunty, there is no backports before Karmic is out
[12:00] <cody-somerville> happyaron, AFAIK, there is.
[12:01] <cody-somerville> happyaron, I just looked and there is definitely packaged in jaunty-backports
[12:01] <happyaron> cody-somerville: oh, that's good, what I need to do is request for security updates/backports, right?
[12:02] <cody-somerville> happyaron, https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages <-- backports process
[12:02] <happyaron> cody-somerville: that's good
[12:03] <happyaron> Laney: ~
[12:03] <cody-somerville> happyaron, https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures <-- Security updates process
[12:03] <Laney> depends if you consider backports to be first-class
[12:04] <happyaron> Laney: I don't think so in fact
[12:04] <Laney> they aren't enabled by default for example
[12:05] <happyaron> Laney: security updates can solve part of the problem, but -updates will be better than -backports I think
[12:05] <happyaron> cody-somerville: if a new releases with features updated, how can it added to -updates?
[12:05] <Laney> When upstream decide to stop supporting a series, it's likely that the new one introduces new features right?
[12:05] <Laney> but also has security fixes and so on
[12:06] <cody-somerville> happyaron, It won't, it'll go into -backports
[12:06] <happyaron> Laney: yes, new feature and unsolved bugs
[12:07] <happyaron> Laney: oh, I mean the old one has unsolved bugs, a typo
[12:07] <Laney> well the original problem is that upstream don't want us to ship their unsupported releases right?
[12:08] <happyaron> yes
[12:08] <Laney> So is an update in -backports good enough for them?
[12:09] <happyaron> Laney: debian just backport it, if we can include it to -updates, things will be better
[12:10] <happyaron> Laney: and debian deleted the package from etch but include it again in backports, that means users can only get in in backports
[12:12] <tkamppeter> pitti: Hi
[12:19] <pitti> hi tkamppeter
[12:20] <tkamppeter> pitti, we have talked about a CUPS SRU for Hardy in DFublin, do you remember which problem we talked about?
[12:20] <pitti> tkamppeter: no, I'm afraid not
[12:24] <tkamppeter> I have found two SRU candidates: bug 372118 and bug 307471, but what we talked about in Dublin was something else.
[12:24] <tkamppeter> pitti: ^^
[12:24] <pitti> two weeks of holiday don't help for remembering..
[12:25] <pitti> anyway, lunch time, bbl
[12:26] <happyaron> Laney: what to do next?
[12:53] <Laney> happyaron: I don't know :(
[12:56] <taavikko> Any thoughts? https://bugs.launchpad.net/bugs/419126
[13:10] <TheMuso> cody-somerville: What has xubuntu done regarding theming the new gdm for karmic?
[13:10] <cody-somerville> TheMuso, I'm going to upload gdm-2.20 today
[13:11] <TheMuso> cody-somerville: Oh so the older GDM? Ok.
[13:11] <cody-somerville> TheMuso, right
[13:12] <TheMuso> Fair enough, I can understand why you want to stick with that.
[13:23] <ogra> hrm, who made my laptop so unstable
[13:23] <Daviey> o/
[13:23]  * ogra just upgraded and experiences hangs 
[13:25] <debfx> is pidgin 2.6 going to make it into karmic?
[13:25] <hyperair> if not today, never =(
[13:25] <slytherin> hyperair: why never?
[13:25] <hyperair> er unless you count backports
[13:25] <ogra> up to the MOTU i'd guess
[13:26] <TheMuso> Afaik pidgin is still main.
[13:26] <hyperair> yeah pidgin's still in main
[13:26] <ogra> given the default gets switched to telepathy anyway i would guess it goes to universe
[13:26] <hyperair> no, there are a fair few things in main that aren't default
[13:26] <hyperair> e.g. irssi
[13:26] <ogra> right
[13:26] <Laney> there's a diff up for sponsoring
[13:26] <ogra> because main devs take care for irssi
[13:26] <hyperair> quickly sponsor it then! =O
[13:27] <ogra> if nobody does that for pidgin it will go to universe
[13:27] <debfx> telepathy depends on libpurple (pidgin)
[13:27] <ogra> so that lib would sty in main
[13:27] <ogra> *stay
[13:27] <Laney> can you have source in universe and binary in main?
[13:28] <TheMuso> No
[13:28] <Laney> thought not
[13:28] <TheMuso> You can have the other way around however.
[13:28] <Laney> yes
[13:28] <hyperair> you can?
[13:28] <hyperair> how does that work?
[13:29] <ogra> ah, i didnt know libpurple has no own source
[13:29] <hyperair> isn't pool/ sorted by component/source/?
[13:30] <TheMuso> Binaries can be built from source packages in main and they go to universe due to not being needed/depended on by anything in main eg seeds etc.
[13:30] <ogra> right
[13:30] <ogra> TheMuso, while i have you here, any idea about the FTBFS of pulse on armel ?
[13:30] <hyperair> hmm i thought you could only copy source packages, not binaries without sources
[13:31]  * ogra doesnt really get why pulse needs CPU assembler for volume control
[13:31] <hyperair> heh assembler? seriously?
[13:31] <TheMuso> ogra: Nor do I, but there are CPU optimizations for arm, SSE, and mmx. I have pinged the guy who wrote the arm code about the error.
[13:31] <TheMuso> ogra: It was not Lennart who wrote it.
[13:31] <ogra> ah, k, but it was forwarded, thats good
[13:31] <TheMuso> The SSE/MMX code is in x86 assembler as well.
[13:31] <ogra> TheMuso, thanks for that
[13:32] <TheMuso> ogra: np.
[13:32] <TheMuso> No response so far.
[13:32] <ogra> well, i didnt know there is specific arm code, probably we just need to make sure it gets actually used, i'll take a look later
[13:32] <TheMuso> ok thanks
[13:33] <slytherin> hyperair: Tomorrow is FF, If someone prepares detailed report for FFE for pidgin and FFE is approved it can still go on.
[13:33] <ogra> might be it doesnt know its actually on arm
[13:33] <ogra> and tries SSE
[13:33] <TheMuso> ogra: No it knows its on arm.
[13:33] <ogra> hmm, k
[13:33] <TheMuso> ogra: I suggest you look at the build log, that will probably help you work out a lot at a glance.
[13:34] <ogra> i did already
[13:34] <ogra> i'll try a local armel build though
[13:34] <hyperair> slytherin: hmm true, that
[13:40] <debfx> could someone consider sponsoring pidgin-plugin-pack (bug #256419), the current version in ubuntu is really old
[13:56] <pitti> ttx: hm, is https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages supposed to be complete? it's e. g. missing axis and axis2c
[13:57] <ttx> pitti: the C bits have their own MIR pages. This was supposed to track java stuff
[13:57] <pitti> ttx: ah, ok
[13:57] <ttx> pitti: what do you mean by "axis" ? there is just axiséc and rampart on the C side
[13:57] <ttx> axis2c, even
[13:57] <pitti> ttx: I wanted to promote the lot now, and review it afterwards, but we need open MIR bugs or being in that table for everyting
[13:58] <ttx> pitti: those were opened.
[13:58] <ttx> Note that component-mismatches lists a lot of unnecessary stuff
[13:58] <pitti> ttx: it's a build dep of libmx4j-java
[13:58] <ttx> pitti: for some reason it thinks the old "eucalyptus-javadeps" is needed
[13:58] <pitti> ttx: not really, it's usually fairly accurate; what's an example of "unnecessary"?
[13:58] <ttx> pitti: axis was in main before, methink
[13:59] <ttx> pitti: unnecessary = eucalyptus-javadeps and all its dependencies.
[13:59] <pitti> ttx: ok, I think I'll do it the other way around; I promote eucalyptus and all the packages on that wiki page, and then we'll see in c-m what's left
[13:59] <ttx> pitti: that includes the scary glassfish and the jboss stuff
[13:59] <pitti> o eucalyptus-javadeps: eucalyptus-javadeps
[13:59] <pitti>    [Reverse-Depends: eucalyptus-cloud]
[14:00] <ttx> pitti: "apt-cache show eucalyptus-cloud" doesn't show eucalyptus-javadeps
[14:00] <ttx> (and it is right)
[14:01] <ttx> pitti: it was required for euca 1.5. But I spent the most part of this cycle getting rid of it
[14:01] <ttx> no clue why it shows now as a eucalyptus-cloud dep.
[14:02] <pitti> cjwatson: hm, any idea why c-m shows above dependency, although it doesn't exist?
[14:02] <cjwatson> I answered this yesterday in ttx's hearing :)
[14:02] <cjwatson> it's because c-m checks all architectures and it's still needed on ia64
[14:02] <ttx> beh
[14:02]  * ttx blames soren, then :P
[14:03] <pitti> ah, thanks
[14:03] <ttx> I guess 1.6 failed to build on ia64 and still carries 1.5
[14:03] <cjwatson> 14:24 London time on this channel
[14:03]  * ttx is too busy trying to enable testsuites in poorly-coded java stacks
[14:03] <cjwatson> somebody could remove the ia64 packages for the time being as a slightly unusual option, perhaps
[14:04] <pitti> okay, will do that
[14:04] <apachelogger> mvo: do you want apturl to either start apturl-gtk or apturl-kde, or just use 2 bins (latter would obviously make -gtk and -kde conflict due to registration in firefox)
[14:05] <Riddell> conflicting isn't good, then you probably couldn't install ubuntu-desktop and kubuntu-desktop together
[14:05] <apachelogger> true
[14:06] <pitti> ttx: ok, ia64 packages removed; thanks for the heads up
[14:06] <pitti> this should clear c-m in two hours
[14:07] <ttx> pitti: cool. I tried to triplecheck the list for any missing stuff but had trouble with that in the way.
[14:07] <mvo> apachelogger: hm, better to have a single binary I guess, but if two packages is easier, that is fine with me as well
[14:07] <pitti> ttx: after promoting the list in the wiki, we'll see what's left
[14:09] <soren> cjwatson: I'm /reasonably/ sure it would build on ia64 if only the buildd's would ever get to it.
[14:11] <soren> cjwatson: So if someone with the appropriate powers could put it to the front of the queue...
[14:11]  * soren forgets who can do that these days
[14:12]  * soren will brb
[14:20]  * soren returns
[14:21] <apachelogger> mvo: how about that: have apturl check for KDE_FULL_SESSION invoke apturl-kde if set, otherwise apturl-gtk ... keep -kde and -gtk as binaries as well, so the user can also call apturl-kde if KDE_FULL_SESSION is not set accordingly
[14:22] <mvo> apachelogger: sounds good to me
[14:25] <cjwatson> soren: I can, one moment
[14:26] <soren> cjwatson: Excellent, thank you!
[14:27] <cjwatson> soren: yes, well. the problem is that the kees/toolchain PPA is DOSing the buildds. It's next in the queue, but that's 23 hours from now
[14:29] <soren> *blink*
[14:29] <soren> He has a single job that takes that long?
[14:29] <ScottK> Might have been nice to do that the day AFTER feature freeze.
[14:30] <cjwatson> soren: openjdk apparently
[14:31] <cjwatson> ScottK: we can probably live with the ia64 and powerpc buildds being unavailable even today; the other buildds are fine
[14:31] <ScottK> Certainly.
[14:34] <pitti> soren: even more curious, two different openjdk versions are building at the same time..
[14:34] <pitti> but there's still no LP API to cancel a build, so I can't help here; you need lamont for that if its urgent (which it isn't, I think)
[14:36] <lamont> we've been giving kees crap about that :-)
[15:20] <pitti> how does one get the grub menu nowadays?
[15:21] <slytherin> pitti: what do you mean by 'get'?
[15:21] <rickspencer31> Keybuk: ^
[15:21] <pitti> well, I want to see and use it
[15:21] <rickspencer31> slytherin: well ... when I boot, it just skips grub
[15:21] <superm1> Keybuk, are you going to plan on pulling in newer udev releases after FF still, or will you start cherry picking fixes as necessary?
[15:21] <pitti> it's apparently the new grub2 default
[15:21] <rickspencer31> and doesn't ask me how to get there
[15:21] <Keybuk> superm1: depends what else goes into the udev releases
[15:21] <slytherin> pitti: rickspencer31: the timeouts are very small (5 sec and 3sec).
[15:21] <bdrung_> Keybuk: you talked yesterday about three unit standards and O'Reilly Style Guide, do you have a link for that?
[15:22] <pitti> slytherin: they are 0 for me
[15:22] <pitti> (apparently)
[15:22] <pitti> I don't see the menu at all
[15:22] <Keybuk> bdrung_: http://oreilly.com/oreilly/author/stylesheet.html
[15:22] <Keybuk>  * K = 1024; k = 1000. So a 56 kbps modem is equal to 56,000 bps, while 64K of memory is equal to 65,536.
[15:22] <lamont> would someone please find whoever thought having the transcodebuild do "make -j" was a good idea and beat them over the head with some hardware?
[15:22] <lamont> oh wait.  did I say that out loud?
[15:24] <slytherin> pitti: yu canc hange the timeouts in /etc/default/grub and then run upgrade-grub
[15:24] <bdrung_> Keybuk: but that would only apply for K/k, not for M or G
[15:24] <evand> pitti: I believe you can still hit escape to enter the menu.
[15:25] <cjwatson> what he said
[15:25] <slytherin> And yes, escape should work, provided you figure out when to use it
[15:25] <Keybuk> bdrung_: indeed
[15:25] <cjwatson> this will change
[15:25] <rickspencer31> yes
[15:25] <rickspencer31> thanks evand
[15:25] <cjwatson> specifically it will change to showing you the menu if (a) you are multi-booting or (b) you hold down shift at boot
[15:25] <bdrung_> Keybuk: so it is no alternative
[15:25] <Keybuk> bdrung_: still worth mentioning
[15:25] <cjwatson> or if you change the default configuration of course
[15:25] <bdrung_> so we are back to 2 solutions
[15:26] <Keybuk> cjwatson: is it still waiting during a timeout, or did that get fixed?
[15:26] <cjwatson> Keybuk: I'm working on it with upstream
[15:26] <cjwatson> it's actually quite difficult to get it right in a way that doesn't totally funt upgrades, but I'm working on it
[15:27] <cjwatson> I have something that *works*, but only if you are careful to run grub-install as well as update-grub
[15:27] <cjwatson> so I'm holding off until I get a bit of backward compatibility sorted out
[15:27] <Keybuk> upgrades from grub1->grub2
[15:27] <Keybuk> or just updates from grub2->grub2?
[15:27] <cjwatson> grub2->grub2
[15:28] <cjwatson> don't worry, I will get it done
[15:29] <Keybuk> ah right, at worst that's only developers and competent people :p
[15:29] <cjwatson> my bug mailbox disagrees with the latter :-/
[15:29] <jdstrand> soren: oh! I forgot to mention I added an apport hook for libvirt-bin
[15:29] <Keybuk> cjwatson: I said "developers and" :P
[15:30] <cjwatson> hah
[15:30]  * liw wonders what Kelvin-Bels would measure
[15:31] <Keybuk> dh_installinit is making my head explode
[15:31] <jdstrand> soren: it'll grab stuff related to apparmor debugging when using apport*. Having people use 'apport-collect -p libvirt-bin <bug number>' after the initial report will likely prove helpful :)
[15:31] <Keybuk> the parts of my brain that understood Perl have long since atrophied
[15:34] <cjwatson> I actually have the backward compat entirely working now apart from USB keyboards, and USB is making my head hurt
[15:35] <Keybuk> :-/
[15:35] <soren> jdstrand: You rock! :)
[15:36] <jdstrand>  5
[15:36] <jdstrand> o/
[15:37] <mathiaz> apw: hey - I'm trying to debug an issue with an upstream
[15:38] <mathiaz> apw: and one of the question is whether the karmic kernel carry specific scheduler patches
[15:41] <cjwatson> hmm, I'm beginning to wonder if I've found a bug in qemu's USB keyboard implementation
[15:44] <evand> cjwatson: is it the ctrl-alt-arrow issue?
[15:44] <cjwatson> no
[15:44] <evand> ah, nevermind then
[15:44] <cjwatson> it doesn't seem to be reporting modifier keys held down at boot
[15:44] <cjwatson> despite me prodding the idle rate
[15:46] <ttx> pitti: component-mismatches was refreshed. There are a few on that list that were in main before, thus shouldn't require MIR: axis backport-util-concurrent bouncycastle commons-beanutils dom4j jaxme junitperf libcommons-collections3-java libcommons-discovery-java libjaxen-java libjdom1-java libmx4j-java libxpp2-java libxpp3-java xom
[15:46] <cjwatson>             /* TODO: Implement finite idle delays.  */
[15:46] <cjwatson> hmm :-)
[15:47] <ttx> pitti: commons-beanutils has new depends (maven-repo-helper/libstax-java) but I'll fix that now. Someone must have synced a part of the new debian maven stack inadvertantly
[15:49] <pitti> ttx: we need to check them again for complying with the default-jdk policy, though
[15:51] <pitti> ttx: there also seem to be some stragglers, like rampart
[15:52] <slytherin> ttx: Only yesterday I was wondering why libcommons-collections3-java got moved to universe. :-)
[15:52] <ttx> pitti: So you want to track them in the MIR page as well ? Or my promise to fix default-jdk on them is sufficient ?
[15:53] <mathiaz> Keybuk: hi - we're still tracking down the libdbus issue we ran into yesterday for sssd
[15:53] <ttx> pitti: for axis2c and rampart, please see soren. I already have trouble staying afloat with the java stuff.
[15:53] <pitti> ttx: oh, did you already check them?
[15:53] <pitti> ttx: would be nice to add the ones to the wiki page which still need conversion
[15:53] <mathiaz> Keybuk: dropping Rawhide libdbus into karmic doesn't fix the problem
[15:54] <ttx> pitti: no. and based on my experience, they probably are not ok.
[15:54] <mathiaz> Keybuk: however it works correctly on a rawhide system
[15:54] <pitti> ttx: ok, can you put the lot on the wiki page for now, then?
[15:54] <pitti> I get them promoted
[15:54] <mathiaz> Keybuk: so we're not sure if libdbus is the culprit here. But that's the only symptom we have so far
[15:54] <ttx> pitti: worksforme.
[15:54] <mathiaz> Keybuk: We successfully open a socket and start the D-BUS communication, but it never completes the handshake
[15:55] <mathiaz> Keybuk: We see about half of the handshake (it requires a BEGIN/OK and an ID/ACK). We're only seeing BEGIN/OK, but the ID/ACK never gets sent, and so subsequent requests don't go through
[15:55] <mathiaz> Keybuk: what else could wrong at this level?
[15:55] <Keybuk> mathiaz: that usually indicates a bug in main loop handling in the application
[15:55] <Keybuk> it's not supplying libdbus with the new data received on the socket
[15:56] <mathiaz> sgallagh: ^^
[15:56] <pitti> ttx: promoted; let's see in 1.5 hours, when publisher ran and c-m refreshes again
[15:56] <sgallagh> Keybuk: Yeah, that's what I'm investigating now
[15:57] <ttx> i'm fixing commons-beanutils in the meantime, shouldn't require any maven-repo-helper stuff in main
[15:57] <Keybuk> sgallagh: are you using libdbus directly in native mode?
[15:57] <ttx> (yet)
[15:57] <sgallagh> Keybuk: Thing is, though, I LD_PRELOADed the tevent library that is working in Fedora, and I still don't get a result
[15:57] <Keybuk> or are you using some other bindings (like gdbus, gbus, egg-dbus, dbus-glib, etc.)
[15:57] <sgallagh> That provides our entire mainloop
[15:57] <sgallagh> Keybuk: I wrote the mainloop integration for libtevent
[15:57] <Keybuk> ok
[15:57] <sgallagh> Keybuk: As previously stated, it works fine on Fedora and OpenSUSE
[15:57] <Keybuk> it could be any kind of difference though
[15:58] <sgallagh> Keybuk: I don't follow that
[15:59] <Keybuk> follow which?
[15:59] <sgallagh> "it could be any kind of difference though"
[15:59] <sgallagh> Keybuk: Can you elaborate?
[16:00] <Keybuk> if you're starving a socket, any number of differences between Ubuntu and Fedora could be the casue
[16:00] <Keybuk> even down to kernel scheduling
[16:00] <Keybuk> buffer sizes
[16:00] <Keybuk> differing glibc versions
[16:00] <Keybuk> differing optimisation flags
[16:00] <Keybuk> etc.
[16:01] <Keybuk> it would still mean the bug was in your main loop
[16:01] <sgallagh> Keybuk: Ok, I can eliminate most of those (I've already tested them)
[16:01] <sgallagh> I mounted my Ubuntu disk in Fedora and chrooted it, so that eliminates the kernel scheduling
[16:01] <Keybuk> do you have a full strace of the each side of the attempt to make a connection?
[16:01] <sgallagh> Keybuk: Yeah, I sent it to you yesterday, didn't I?
[16:02] <Keybuk> no
[16:02] <sgallagh> Keybuk: (02:59:42 PM) sgallagh: Keybuk: http://paste.ubuntu.com/259446/ (the Karmic version)
[16:02] <sgallagh> (02:59:54 PM) NCommander: or any archive admin?
[16:02] <sgallagh> (03:00:43 PM) sgallagh: Keybuk: http://paste.ubuntu.com/259449/ (the working Fedora version)
[16:03] <sgallagh> That's just the side making the connection, not the side receiving it, but since that's the side that's failing to send the second half of the message, it should be sufficient for examination
[16:03] <Keybuk> sgallagh: no, I need to see both sides
[16:03] <Keybuk> and only on Ubuntu
[16:03] <sgallagh> Keybuk: Ok, just a minute. I have that one too
[16:04] <sgallagh> Hmm, gotta regenerate it. /tmp got wiped out
[16:04] <Keybuk> can you regenerate both at the same time then please
[16:04] <sgallagh> Keybuk: Of course.
[16:08] <Awsoonn_> Has anyone installed using today's alt cd image with success?
[16:11] <sgallagh> Keybuk: http://fedorapeople.org/~sgallagh/sssd_err.tar.bz2
[16:12] <Awsoonn_> Should I file a bug on the fact installation will not complete, and grub2 appears to not be configureing itself correctly or wait for the next alpha?
[16:12] <sgallagh> Keybuk: .2114 is the monitor, which receives the connection, .2115 is the data provider, which initiates the connection to the monitor
[16:13] <sgallagh> Keybuk: On .2114, FD 10 is the connection from the data provider. On .2115, FD 11 is the connection to monitor
[16:14] <Keybuk> sgallagh: err, so
[16:14] <Keybuk> the monitor says OK
[16:14] <Keybuk> write(10, ""..., 37)                      = 37
[16:14] <Keybuk>  | 00000  4f 4b 20 37 33 64 36 34  39 33 61 38 65 38 34 30  OK 73d64 93a8e840 |
[16:14] <Keybuk>  | 00010  66 35 31 33 39 35 39 62  65 64 39 34 61 39 35 34  f513959b ed94a954 |
[16:14] <Keybuk>  | 00020  66 66 61 0d 0a                                    ffa..             |
[16:16] <Keybuk> sgallagh: honestly though
[16:16] <Keybuk> this strace looks rather broken
[16:16] <Keybuk> you have multiple dbus socket connections on both ends
[16:17] <sgallagh> Keybuk: It's not broken, they both act as a D-BUS server for different processes
[16:17] <sgallagh> That's why I specified the specific file descriptors for one example
[16:18] <Keybuk> right
[16:18] <sgallagh> Keybuk: A quick architecture description:
[16:18] <Keybuk> but you never read from it in the client again
[16:18] <Keybuk> in fact
[16:18] <Keybuk> you appear to be not even checking your epoll_ctl return values
[16:18] <Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=26154624, u64=26154624}}) = -1 EEXIST (File exists)
[16:18] <Keybuk> so you're not even *polling* for read
[16:18] <Keybuk> (the last epoll_ctl on fd 11 is:
[16:18] <Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=26154448, u64=26154448}}) = 0
[16:18] <Keybuk> so there's no EPOLLIN there
[16:18] <Keybuk> so you'll never get notified of the pending data
[16:18] <Keybuk> and thus never complete
[16:19] <rtg> kirkland, any more info on padlock-sha ?
[16:19] <sgallagh> Keybuk: Uh, read a little further. We're doing an EPOLLIN immediately after the write
[16:19] <sgallagh> And that's the last thing we see
[16:19] <Keybuk> no you're not
[16:20] <sgallagh> Keybuk: Which file are you looking at?
[16:20] <tkamppeter> pitti, hi
[16:20] <Keybuk> sssd_err.2115
[16:20] <Keybuk> write(11, ""..., 18) = 18
[16:20] <Keybuk>  | 00000  41 55 54 48 20 45 58 54  45 52 4e 41 4c 20 33 30  AUTH EXT ERNAL 30 |
[16:20] <Keybuk>  | 00010  0d 0a                                             ..                |
[16:20] <Keybuk> epoll_ctl(5, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=26154624, u64=26154624}}) = -1 EEXIST (File exists)
[16:20] <sgallagh> Keybuk: EPOLLIN is right on that line you copied...
[16:21] <Keybuk> can you paste me that line of source code ;)
[16:21] <kirkland> rtg: hadn't gotten to that yet today :-/
[16:21] <rtg> kirkland, np, I've been buried myself
[16:21] <sgallagh> Keybuk: I have no idea where that line of code is. It's buried in D-BUS
[16:21] <Keybuk> no
[16:22] <Keybuk> it's in your main loop integration
[16:22] <sgallagh> sorry, buried in TEVENT
[16:22] <Keybuk> right
[16:22] <Keybuk> anyway
[16:22] <Keybuk> tevent is broken
[16:22] <sgallagh> Keybuk: Except that it works on non-Ubuntu platforms
[16:22] <Keybuk> so?
[16:22] <Keybuk> it's still broken
[16:22] <sgallagh> Keybuk: You still haven't explained to me what's wrong with that line
[16:22] <Keybuk> yes I have
 you appear to be not even checking your epoll_ctl return values
[16:23] <sgallagh> Keybuk: You said "You never do an EPOLLIN", but what you pasted specified EPOLLIN...
[16:23] <Keybuk> your attempt to add EPOLLIN to the set is returning an *error*
[16:23] <Keybuk> therefore it *failed*
[16:23] <Keybuk> your code obviously doesn't even check
[16:24] <sgallagh> Keybuk: Ok, I'll accept there's a bug there and I'll open that upstream.
[16:24] <sgallagh> Keybuk: However, why did it fail?
[16:25] <sgallagh> Keybuk: Why are we getting EEXIST when trying to do epoll_ctl? That doesn't even make sense
[16:25] <james_w> "EEXIST op was EPOLL_CTL_ADD, and the supplied file descriptor fd is already registered with this epoll instance."
[16:26] <Keybuk> sgallagh: yes it does
[16:26] <Keybuk> sgallagh: james_w quoted the relevant bit of the epoll_ctl(2) manpage
[16:26] <cjwatson> shame about the historical strerror(EEXISTS)
[16:26] <james_w> eglibc difference perhaps?
[16:26] <Keybuk> doubt it
[16:26] <cjwatson> I'd be amazed
[16:26] <Keybuk> more likely Fedora patched their libc to workaround some bug ;)
[16:26] <james_w> good :-)
[16:26] <Keybuk> they like to do that
[16:27] <Keybuk> anaconda does something wrong, rather than fix anaconda, they workaround it in libc
[16:27] <sgallagh> Keybuk: Well, opensuse must have patched it somehow too, then
[16:27] <Keybuk> sgallagh: probably just took the patches from fedora verbatim
[16:27] <Keybuk> could be a difference between glibc 2.9 and 2.10 of course too
[16:28] <Keybuk> or a kernel difference
[16:28] <sgallagh> Keybuk: rawhide is using glibc 2.10, and I already mentioned that I tried running it under the rawhide kernel using a chroot
[16:28] <Keybuk> right, we're using eglibc 2.9
[16:29] <james_w> are we?
[16:29] <Keybuk> I think so
[16:29] <james_w> confusing version number if so
[16:29] <Keybuk> oh, no 2.10
[16:29]  * Keybuk ran that on jaunty :p
[16:30] <sgallagh> Keybuk: If you're running that crazy libc wanna-be, how can you be sure the problem is on my end? :-P
[16:31] <Keybuk> sgallagh: because the manpage says what you're trying to do is not supposed to work
[16:32] <sgallagh> Keybuk: Is it because we're trying to set EPOLLERR and EPOLLHUP again there?
[16:32] <Keybuk> no
[16:32] <Keybuk> it's because you may only call EPOLL_CTL_ADD *once* for any file descriptor
[16:32] <Keybuk> all subsequent calls must be EPOLL_CTL_MOD
[16:33] <sgallagh> ah, gotcha
[16:35] <sgallagh> Keybuk: Thanks for the help. I'll get this over to the tevent upstream
[16:38] <pitti> tkamppeter: heh, flooding Mike with STRs.. :)
[16:43] <BluesKaj> Riddell, a report : seems the Kubuntu Karmic Printer Configuration GUI has been fixed for my setup , at least .
[16:43] <tkamppeter> Yes, there are a lot of bugs in the new web interface.
[16:44] <Riddell> BluesKaj: great, thanks
[16:44] <tkamppeter> pitti, what should we do concerning the usblp kernel module? Did you do anything in this direction already?
[16:44] <ttx> pitti: new component-mismatches run: wsdl4j: was in main before, please promote, will add to the default-java watchlist. libstax-java and maven-repo-helper should disappear from list as soon as the new commons-beanutils is published. That leaves axis2c (bug 418225) and rampart (bug 418223).
[16:44] <pitti> tkamppeter: no, I didn't; for now we should add it to /etc/modprobe.d/blacklist.conf, I think
[16:45] <ogra> cjwatson, in the installed seed i see "* Kernel-Version: 2.6.31-7-imx51 2.6.31-7-iop32x 2.6.31-7-ixp4xx 2.6.31-7-orion5x 2.6.31-7-versatile" ... could that be the cause i dont get any udebs for 2.6.31-100-imx51 on the alternates ?
[16:45] <ogra> s/installed/installer/
[16:45] <pitti> ttx: where is that list, btw? not on https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages ?
[16:46] <tkamppeter> pitti, would it work to add a file /etc/modprobe.d/cups.conf to the CUPS package which contains only the line "blacklist usblp"?
[16:46] <pitti> tkamppeter: it would (well, shoudl be blacklist-usblp.conf then), but I'm not sure we want that
[16:46] <ttx> pitti: what list ? the default-java watchlist ? or the component-mismatches list ?
[16:46] <pitti> ttx: the default-java checklist
[16:46] <ttx> it's on  https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages
[16:47] <ttx> below the "MIR needed" stuff
[16:47] <slangasek> ttx: in bug #303458, your last comment is that you would nominate bug #357581 for an SRU... were you intending to prepare the SRU, and if so, could you go ahead and do that and upload it to the queue?  The 'nominated for $release' list is all noice, and the SRU team doesn't look at it
[16:47] <pitti> ttx: aah, got it
[16:47] <tkamppeter> pitti, can you contact the appropriate person or modify and upload the appropriate package by yourself?
[16:48] <ttx> slangasek: we intend to use that list, in fact, for server packages. So that accepted nominations can be used as a starting point for those wanting to work on MIR.
[16:49] <ttx> slangasek: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20resources
[16:49] <mathiaz> ttx: s/MIR/SRU/
[16:49] <pitti> tkamppeter: I can upload it, I just wonder if usblp is still useful, or whether having it should depend on having cups installed
[16:49] <ttx> mathiaz: right. Man, I need some rest
[16:49] <slangasek> ttx: ok, so your nomination didn't mean you had any plans to work on it yourself?
[16:49] <mathiaz> slangasek: that is correct.
[16:49] <pitti> ttx: re-promoted
[16:49] <ttx> slangasek: no. If I intend to work on it, I'd assign myself
[16:50] <slangasek> ttx: ok; the nomination happened before this new server team nomination scheme was discussed, so I wasn't sure
[16:51] <cjwatson> ogra: yes, you need to make the seeds match
[16:51] <ttx> slangasek: that said, I should really work on that. Just didn't have time so far[tm]
[16:51] <ogra> cjwatson, right, i guess thats also the reason why i see things like "! Pruned block-modules-2.6.31-100-imx51-di from installer"
[16:52] <ogra> cjwatson, what i dont get though is why it is also doing: "! Pruned block-modules-2.6.31-0-babbage-di from installer" ... it shouldnt know anything about babbage
[16:53] <cjwatson> it's pruning all the stuff in the archive that provides block-modules (which it's been asked to install) but that doesn't have any of the possible Kernel-Version field values
[16:53] <cjwatson> it knows about babbage because babbage is in the archive
[16:53] <ogra> well, in universe
[16:53] <cjwatson> yes, and it's been asked to look at universe, evidently!
[16:53] <ogra> i thought d-i doesnt take universe into account
[16:53] <ogra> ah
[16:53] <cjwatson> that's not d-i. that's germinate.
[16:53] <ogra> ok
[16:53] <cjwatson> "pruned" means that it is *not* going to include the package
[16:53] <ogra> yep
[16:54] <ogra> thats what i guessed with my sparse english knowledge :)
[16:54]  * ogra curses LP
[16:54] <cjwatson> germinate does what you tell it to do - it's only in sync with d-i's behaviour if you give it options that match d-i's behaviour
[16:54] <tkamppeter> pitti, with CUPS usblp is useless and disturbing, at least for all backends shipping with Ubuntu, but I am notr sure whether there are proprietary manufacturer-supplied backends based on usblp.
[16:54] <ogra> does anyone get https://code.launchpad.net/~ubuntu-core-dev to load ?
[16:54] <beuno-lunch> ogra, s/curse/files a bug
[16:54] <ogra> the recent days code.lp.net gives me timeout over timeout
[16:55] <beuno-lunch> ogra, it does on edge: https://code.edge.launchpad.net/~ubuntu-core-dev
[16:55] <ogra> right, edge works fine
[16:55] <beuno-lunch> I think there have been optimizations done to that page, that have not propagated to production
[16:55] <tkamppeter> pitti, without CUPS (for example with LPRng from Universe) the usblp module is useful as only access to USB printers via /dev/usb/lp*.
[16:55] <Keybuk> I wish LP would pick a theme
[16:55] <ogra> non edge tells me i can choose to disable access to edge for the next 2h
[16:55] <Keybuk> pages jumping style is damned confusing
[16:55] <ogra> which i didnt even try to reach :P
[16:56] <beuno-lunch> Keybuk, the 3.0 goal is for *all* pages to have the same styling
[16:56] <beuno-lunch> which is why we're not rolling out to production
[16:56] <beuno-lunch> untill the 420 templates have been updated
[16:56] <beuno-lunch> they will look like the project page in edge, roughly
[16:57] <dholbach> kirkland: rtg said you might know a bit about bug 277556 - I was pinged about it and really don't know what to do with it
[16:58] <Keybuk> beuno-lunch: oh, I know ;)  it's just confusing ;P
[16:59] <beuno-lunch> Keybuk, but it keeps you guessing, which is always "fun"
[16:59] <beuno-lunch> Launchpad: The game
[16:59] <Keybuk> Launchpad so needs a fail whale equivalent for timeout errors
[17:00] <evand> ta-widder
[17:02] <Keybuk> INTO THE LAUNCHPADSPHERE!
[17:03] <evand> lol
[17:04] <lool> I understand what the live and ship-live seeds are for but I need a refresh on what the ship seed is for -- is this for .debs included on the alternate CD?
[17:05] <Keybuk> yes
[17:05] <Keybuk> (and this is the point cjwatson comes along and says "no, it used to be, but I changed it")
[17:05] <ogra> lol
[17:08] <kirkland> dholbach: looking ...
[17:11] <kirkland> dholbach: so i'd agree that dkms is good for this sort of thing
[17:12] <cjwatson> Keybuk: not in this case :)
[17:12] <kirkland> dholbach: seeing as i spend almost every day, all day working on kvm, i don't know much about open-vm-tools
[17:13] <dholbach> kirkland: who could help out with this?
[17:13] <kirkland> dholbach: hmm, good question; someone in #ubuntu-virt probably
[17:13] <kirkland> dholbach: would probably be a community person, MOTU
[17:13] <dholbach> I was pinged about it and don't know what to do about it
[17:13] <kirkland> dholbach: b/c we canonical-server are very kvm focused
[17:14] <dholbach> well, we all touch packages that we probably don't use every day :-)
[17:14] <dholbach> kernel modules and dkms is nothing I'm good at or would be comfortable judging
[17:23] <tkamppeter> pitti: Got answers on some of the CUPS STRs, GUI stuff gets all postponed to 1.5, due to I18n.
[17:23] <tkamppeter> pitti, superm1: Have fixed bluez-cups for CUPS 1.4, will make it available soon and also report upstream.
[17:28] <ogra> cjwatson, is there any delay wrt germinate pulling the most recent seed versions ? i triggered a ports alternate build after the seedchange showed up on the LP ui but germinate didnt pick up my change
[17:30] <cjwatson> ogra: none in germinate, but there may be a slight delay (wouldn't expect any more than a few minutes) in the internals of codehosting
[17:31] <ogra> ok, i'll wait for 20min before starting my next try to be sure
[17:33] <dholbach> cjwatson: shouldn't juli_ and apw be members of ~ubuntu-dev?
[17:33] <cjwatson> oh yes, thanks, I'll correct that
[17:33] <dholbach> super, thanks :)
[17:33] <ogra> did they pay the bribe ?
[17:33] <dholbach> yes, all well-received over here
[17:33] <ogra> oh, *you* get it ?
[17:34] <ogra> thats why my account is always empty, damned
[17:34] <cjwatson> fixed
[17:34] <dholbach> thank cjwatson
[17:34] <Daviey> it's offical, dholbach is a reciever not a giver.
[17:34] <ogra> oh, how mean
[17:37]  * Daviey retracts.
[17:42] <tgpraveen1> Andreas Moog
[17:42] <tgpraveen1> ^^ anyone his irc name?
[17:42] <ion> /who
[17:43] <Daviey> tgpraveen1: Ampelbein
[17:44] <cjwatson> tgpraveen1: https://launchpad.net/people in future
[17:44] <cjwatson> his Launchpad user page has his IRC nick
[17:50] <kees> soren: I was trying to solve some feature issues before feature-freeze in openjdk-6.  the testsuite doesn't behave the same between local system, Xen PPAs, and bare-metal buildds.
[17:51]  * soren desperately tries to remember the question he asked kees
[17:53] <kees> soren: actually, I guess that was also directed at ScottK (openjdk-6 test builds)
[17:53] <bdmurray> cjwatson: should the postfix bug task for bug 383697 still be open?
[17:53] <dholbach> slangasek: hum... pam asked me if it should restart gdm - was that always the case?
[17:53] <lamont> bdmurray: ew
[17:54] <slangasek> dholbach: did it ask /only/ about gdm?
[17:54] <dholbach> slangasek: no gdm cups cron and something else
[17:55] <slangasek> hmm, there's supposed to be an exception if the only services running are defaults
[17:55] <dholbach> gdm cups cron atd
[17:55] <dholbach> now on the other machine
[17:56] <slangasek> dholbach: using update-manager, or apt-get?
[17:56] <dholbach> apt-get
[17:56] <slangasek> ah
[17:56] <slangasek> yes, that happens then
[17:56] <dholbach> ok
[17:56] <dholbach> nevermind then
[17:56] <slangasek> we suppress the message if using update-manager
[17:56] <dholbach> I just thought "my mom would probably just clicked 'ok go ahead'" :)
[17:57] <dholbach> have a great rest of your day - I'm out, see you tomorrow!
[17:57] <cjwatson> bdmurray: maybe
[17:57] <slangasek> dholbach: and clicking 'go ahead' is the right thing to do
[17:57] <slangasek> it sends gdm a kill -HUP
[17:58] <dholbach> if it's done differently in update-manager that's fine
[17:58] <slangasek> (well, it calls /etc/init.d/gdm reload)
[17:58] <cjwatson> bdmurray,lamont: probably not TBH, in order to fix debconf we had to make lsb_release quasi-essential
[17:58] <cjwatson> bdmurray: but I think it's lamont's decision whether to close it
[17:58]  * dholbach -> dinner
[17:59] <lamont> cjwatson: I'll look at it late tonight/tomorrow
[18:01] <bdmurray> lamont,cjwatson: thanks
[18:07] <ogra> cjwatson, Running tools/boot/karmic/boot-armel+imx51 1 /srv/cdimage.ubuntu.com/scratch/ubuntu/ports_daily/tmp/karmic-armel+imx51/CD1
[18:07] <ogra> debian-installer has kernel ABI 2.6.31-200-dove, but no corresponding udebs are on the CD!
[18:07] <ogra> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/ports_daily/tmp/karmic-armel+imx51/bootable-stamp] Error 1
[18:07] <ogra> cjwatson, but ... ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep KERNELVERSION build/config/armel/imx51.cfg
[18:07] <ogra> KERNELVERSION = 2.6.31-100
[18:07] <ogra> KERNELVERSION := $(KERNELVERSION)-imx51
[18:07] <ogra> any idea what i'm doing wrong here ?
[18:13] <kees> pitti: I've replied to your whiteboard questions for security-karmic-apport-abort.  I'm excited to test the new feature!  :):)
[18:13] <cjwatson> ogra: sorry, I'm out for a while
[18:13] <ogra> ok
[18:14] <pitti> kees: \o/
[18:14] <pitti> kees: so far I just have test cases on various levels, I didn't really test it end-to-end yet
[18:15] <pitti> kees: but I wanted to kick in the feature in time for FF :)
[18:20] <kees> pitti: yeah, absolutely.  I will poke at it too -- I actually had a situation last night where I was wishing this feature was done (having an assert in a sub-process's thread and gdb didn't want to attach to it)
[18:22] <pitti> kees: right, I couldn't quickly find a packaged program which would assert for me :)
[18:23] <kees> pitti: heh, normally, that's a good thing.  ;)
[18:25]  * ccheney` bbl, lunch
[18:40] <slangasek> pitti: heck yeah, you don't have to tell me twice to remove files from acpi-support :-)
[18:40] <pitti> that particular bug seems to be tricky, though
[18:40] <pitti> I don't really know where that duplication comes from
[18:41] <slangasek> pitti: it can't be caused just by brightness control in hardware; that doesn't explain where the X keypress is coming from
[18:41] <pitti> slangasek: right, I wrote that in the recent followup
[18:41] <slangasek> ok
[18:41] <pitti> obviously the key is hardwired
[18:41] <slangasek> hmm?
[18:41] <pitti> but there should still just be one event per keypress
[18:41] <slangasek> he's seeing an X event
[18:41] <slangasek> without the udev keymap, without acpi-support
[18:41] <pitti> and it's apparently not from acpid
[18:42] <slangasek> so where is that getting into X?
[18:42] <slangasek> "hardwired" doesn't answer this
[18:42] <pitti> slangasek: right, I suppose the kernel default is already correct?
[18:42] <pitti> ah, no, that wouldn't explain the "unknown key" dmesg spam
[18:42] <pitti> is it possible that there's a kernel module which also translates the acpi events to input events somehow?
[18:43] <slangasek> sure, possible
[18:44] <slangasek> we probably need 'lsinput' from him (or /lib/udev/findkeyboards)
[18:45] <pitti> there's lsinput.log and udev db dump
[18:45] <slangasek> oh
[18:45] <tkamppeter> superm1: I have attached the fix for bluez to bug 418465, can you upload it? Thanks.
[18:45]  * slangasek looks at the bug, then :)
[18:45] <pitti> slangasek: http://launchpadlibrarian.net/30857479/lsinput.log doesn't seem to have anything magic, though
[18:46] <tkamppeter> superm1: I will also submit my patch upstream.
[18:47] <slangasek> pitti: right; no kernel module input device listed there
[18:47] <pitti> and http://launchpadlibrarian.net/30857464/udev-db.txt looks okay, too
[18:48] <pitti> slangasek: hardwired> the dells are the same; pressing them controls the screen brightness, and their events are just used for notification feedback
[18:48] <pitti> but I still have no clue where the xevs come from with no udev and no acpid
[18:49] <pitti> ♩ it's a kind of magic ♫
[18:49] <pitti> so we spent so many hours to figure out how to get these keys _working_
[18:49] <pitti> and now we struggle with getting them to work a little less intensely..
[18:52] <kees> slangasek: so, selinux loads policy from the root filesystem, while in the initramfs.  why can't it use tools in /sbin to do that?
[18:52] <slangasek> kees: well, I suppose it can in that case, but twitch
[18:55] <slangasek> kees: TTBOMK, the only other thing the initramfs ever execs off the root fs is init
[18:55] <kees> slangasek: very true, but I'd like to avoid having them rearchitect it the day before feature freeze (it's been like this since hardy, IIRC).
[18:56] <slangasek> ok
[18:56] <kees> the recent /share bug was due to mistakes in trying to minimize deltas with debian (and will absolutely get fixed)
[18:56]  * slangasek nods
[18:57] <slangasek> kees: fwiw, I latched onto that bug reading #debian-devel in passing, where Manoj had a good rant going about why this shouldn't be needed - feel free to check with him how this is actually working in Debian, if at all :)
[18:57] <kees> slangasek: okay
[18:59] <pitti> hm, for a while DNS resolution takes ages here; I thought it'd be a problem with my provider, but my wife doesn't have this problem; and now I discovered this:
[18:59] <pitti> $ host archive.ubuntu.com
[18:59] <pitti> archive.ubuntu.com has address 91.189.88.40
[18:59] <pitti> ;; connection timed out; no servers could be reached
[18:59] <pitti> (also takes several seconds)
[19:00] <pitti> does someone else have that, too? (current karmic)
[19:00] <slangasek> not here
[19:00] <pitti> I just have one NS in /etc/resolv.conf, and no resolvconf
[19:00] <slangasek> "no servers could be reached" means it's not reaching your own NS, surely?
[19:00] <kees> pitti: not me either, though I'm not strictly fully up to date.
[19:00] <pitti> I just added archive.u.c. to /etc/hosts, and now apt-get update etc. is snappy again
[19:01] <pitti> ok, thanks for checking
[19:02] <pitti> dig @192.168.2.1 archive.ubuntu.com works fine
[19:02] <pitti> hmm
[19:06] <pitti>  28197/host
[19:06] <pitti> udp        0      0 0.0.0.0:5353            0.0.0.0:*
[19:06] <pitti> does that look normal?
[19:06] <pitti> (while host is running)
[19:09] <tkamppeter> pitti, superm1: I have fixed bug 418465, and also reported it to bluez upstream with my patch.
[19:16] <superm1> tkamppeter, okay i'll take a look at soon.  i'd like to make sure that upstream accepts it without requesting changes first
[19:20] <ogra> cjwatson, i think i found one of the probs at least, debian-cd/tools/boot/karmic/boot-armel+imx51.calc is never read bacause build_all.sh seems to look for boot-armel.calc (i.e. $FULLARCH only) ... (that doesnt explain why it tries to install the dove kernel on imx51 though)
[19:24] <Caesar> Hey slangasek has there been any decision made yet on whether 10.04 *won't* be LTS?
[19:28] <slangasek> Caesar: I believe we're still waiting to find out what Debian is deciding to do for squeeze, and whether there's any advantage to deferring the LTS to better cooperate with the squeeze freeze
[19:29] <ogra> cjwatson, oh, ignore me FULLARCH=$ARCH+$SUBARCH, i was worng
[19:30] <Caesar> slangasek: ok, is there some sort of drop-dead date for a decision?
[19:31] <slangasek> Caesar: the Debian release team has said they'd gather input throughout the month of August and make a decision at the end of this month; the Ubuntu decision should come shortly thereafter
[19:35] <Caesar> slangasek: ok thanks
[19:35] <sebner> slangasek: did you already make a decision about boson(-data), I made another comment on the bug
[19:36] <slangasek> sebner: I was looking at it because it was my archive day; I figured the next AA on duty would pick it up :)
[19:37] <sebner> slangasek: ah so I'm sorry, and still if you have time ... FF is annoying :P
[19:40] <slangasek> sebner: "b-p"?
[19:40] <slangasek> (https://bugs.launchpad.net/ubuntu/+source/boson-data/+bug/418268/comments/2)
[19:40] <sebner> slangasek: build-dependency
[19:40] <slangasek> ok
[19:40] <sebner> slangasek: MOTU slang :P
[19:41] <slangasek> why is it not b-d? :)
[19:41] <sebner> slangasek: because I'm stupid xD
[19:41] <slangasek> sebner: so anyway, my understanding is that we were getting rid of all the reverse-deps of the KDE3 libs if they're not getting ported to KDE4
[19:41] <slangasek> not just because of FTBFS, but because the libs are obsolete
[19:42] <slangasek> the removal bug was #288949
[19:42] <sebner> slangasek: IIRC it FTBFS because some old libs had dependencies on new ones and there were conflicts etc. (It was just the time kde3 -> kde4) but it builds now again. don't ask me why
[19:43] <slangasek> ah, and that does say it needed a KDE3 kdemultimedia to build... so if that's not an issue, yeah, the removal reason seems to no longer stand
[19:43] <slangasek> ok, I'll bring it back
[19:43] <sebner> slangasek: thx, and as you can see (my ppa) it really builds
[19:43] <sebner> slangasek: I'll upload boson myself (needs fakesync)
[19:44] <sebner> slangasek: at the rest of his life (as I consider upstream dead)
[19:44] <slangasek> sebner: please add tasks for other source packages you're asking to sync, rather than just commenting in the bugs, btw :)
[19:44] <sebner> slangasek: it's just those two :P
[19:44] <sebner> but ok
[19:44] <sebner> ^^
[19:45] <slangasek> yes; the difference is that the archive admin tools pick up the source package names from bug tasks automatically for syncing
[19:45] <sebner> slangasek: I thought your run them like: "sync-package foo foo1 bar bar1"
[19:45] <sebner> *you
[19:46] <slangasek> no, we run 'sync <bugnum>' :)
[19:46] <sebner> uhh nice
[19:46] <sebner> slangasek: I'll file another sync bug for the music package then
[19:46] <slangasek> sebner: boson-data can't be synced, because 0.13-3 was previously in the archive
[19:46] <slangasek> needs a version bump
[19:47] <sebner> slangasek: versions bump or fakesync?
[19:47] <slangasek> version bump
[19:47] <slangasek> just 0.13-3build1
[19:47] <sebner> slangasek: ah kk, Thanks for your help and sorry for the noise :)
[19:47] <slangasek> no worries
[19:59] <tkamppeter> superm1: I got already an aanswer from upstream, they want it, but ask me to send the patch in GIT format.
[19:59] <RainCT> james_w: can rejected source packages be downloadeed from LP or are they deleted?
[20:00] <james_w> deleted I think
[20:00] <RainCT> ok nvm then :)
[20:16] <tkamppeter> superm1: I have sent the GIT-formatted patch now.
[20:17] <ogra> cjwatson, ha ! got it the check_kernel_sync call just needed $FLAVOUR appended (must be funny to read your backlog seeing me going back and forth through the code :) )
[20:17] <jsteel> Does anybody know how ubuntu kernels are versioned? Specifically I'm looking for what exactly the 60 means in 2.6.24-24.60. I'm trying to create a custom kernel and want to know if I should name it 2.6.24-24foo1 so that I can upgrade it to 2.6.24foo2 and so on. Or should I call it 2.6.24-24.60foo1? I cant find anywhere a reference that describes Ubuntus kernel versioning.
[20:19] <evand> jsteel: I'd suggest using 2.6.24-24.60~foo1
[20:19] <jsteel> evand: why the ~?
[20:19] <jsteel> evand: And then when 2.6.24-24.61 comes out, would it upgrade overtop of mine?
[20:20]  * ogra suggests #ubuntu-kernel :)
[20:20] <jsteel> ogra: thanks. I was looking for that channel but I couldnt find it.
[20:21] <evand> jsteel:  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version and yes, it would install over top of yours
[20:22] <jsteel> evand: Thanks a lot. I'll check that out
[20:22] <pitti> kenvandine, StevenK: if gwibber should stay in universe, can it then be removed from the UNR seeds? othewise it does need an MIR (but I thought it wasn't quite ready for that?)
[20:23] <jsteel> evand: Ah yes, I've already read that. It didn't help me with the difference between 24 and 60 in 24.60
[20:23] <pitti> kirkland: qemu-kvm b-deps on bochs; is that really intended? if so, needs a MIR
[20:24] <kenvandine> pitti, yes... it can be removed
[20:26] <kirkland> pitti: arg.... yeah so it does need an MIR :-/
[20:28] <lool> Is an archive admin around?
[20:28] <lool> I mistakingly uploaded a package to karmic instead of ppa
[20:28] <lool> It's ubuntu-moblin-ppa-keyring; should be rejected from NEW
[20:31] <kirkland> lool: i'll kick it
[20:31] <lool> Thanks a lot
[20:31] <kirkland> lool: gone
[20:31] <lool> It just showed up
[20:31] <lool> and gone thanks
[20:57] <kirkland> james_w: ping
[20:57] <james_w> hey kirkland
[20:57] <kirkland> james_w: hey, i'm going to give mass-sync.py a try ... where can I find it?  i don't see it on cocoplum
[20:58] <james_w> lp:ubuntu-archive-tools
[20:58] <kirkland> james_w: ah, gotcha
[20:58] <kirkland> james_w: my bad ... last week i meant that sync-bug-bot.py was flimsy for me
[20:58] <kirkland> james_w: i hadn't tried mass-sync.py
[21:00] <cjwatson> yeah, syncbugbot was always flimsy because it did screen-scraping
[21:00] <cjwatson> ogra: ah, glad to hear it
[21:04] <kirkland> james_w: hrm, not quite there yet
[21:04] <kirkland> james_w: http://pastebin.ubuntu.com/260028/
[21:04] <kirkland> james_w: i've gone to that page and given the tool access to LP
[21:05] <kirkland> james_w: but i still get the backtrace, rather than it waiting for me to hit enter
[21:05] <james_w> just run ./mass-sync.py first
[21:07] <kirkland> james_w: ah, it's crashing on the input file
[21:07] <kirkland> james_w: gotcha, thanks
[21:40] <james_w> mathiaz: I'm unsure about "usr/lib/cmpi/*.so" in debian/install in opendrim-lmp-baseserver
[21:41] <james_w> what sort of shared libraries only need *.so?
[21:42] <mathiaz> james_w: plugins
[21:43] <mathiaz> james_w: there are plugins for the sfcb daemon
[21:43] <mathiaz> james_w: these are plugins for the sfcb daemon
[21:43] <james_w> ok
[21:44] <mathiaz> james_w: cmpi is actually a standard interface defined for CIM brokers
[21:44] <mathiaz> james_w: sfcb is such a CIM broker - and thus can load these plugins
[21:45] <james_w> you had me at plugins
[21:45] <mathiaz> james_w: there are other CIM brokers (not available in Ubuntu for now) that could also load these
[21:45] <mathiaz> james_w: ok cool. Thanks for reviewing the package :)
[21:45] <mathiaz> james_w: are you reviewing them on REVU or in the NEW queue?
[21:46] <james_w> New
[21:46] <mathiaz> james_w: cool - thanks
[22:15] <mathiaz> slangasek: hi - so I'm waiting on openldap 2.4.18 for the disconnected mode for pcache that was discussed at UDS
[22:15] <mathiaz> slangasek: 2.4.18 is in final testing but won't be released before FF
[22:16] <mathiaz> slangasek: so I'm going to need a FF exception
[22:16] <mathiaz> slangasek: should I file it now?
[22:24] <james_w> kees: could I trouble you for a quick approval of bug 419506 so that I can fix that wadllib bug?
[22:25] <slangasek> mathiaz: yes, please go ahead
[22:29] <kees> james_w: sure, one sec
[22:30] <kees> james_w: done
[22:31] <cjwatson> superm1: I don't suppose you could use a dedicated user for dkms rather than nobody? you could use adduser --system on debian/ubuntu to create one
[22:31] <cjwatson> superm1: using nobody is really a bug, even though it works at the moment
[22:32] <superm1> cjwatson, i was hoping to avoid having to create another user just for builds, but yeah I can look into it
[22:32] <cjwatson> superm1: the problem with nobody is that running stuff as it dilutes the principle that user nobody has no non-trivial privileges - in this case it means that something allegedly sandboxed as user nobody can hijack your dkms builds and inject replacement kernel modules!
[22:34] <james_w> thanks kees
[22:35] <superm1> cjwatson, yeah that sounds sensible.  i was trying to get away from doing the builds as root so that a rogue makefile didn't have the potential to hijack your entire system during a build.  (figured this was a step in that direction)
[22:35] <cjwatson> right, it makes some sense to drop privileges I agree
[22:35] <cjwatson> but better to keep it contained
[22:35] <superm1> right.
[22:36] <mathiaz> slangasek: I've also been working on getting sssd in karmic
[22:37] <mathiaz> slangasek: unfortunately the daemon suffers from a  fatal bug that make it totally unusable in karmic for now
[22:37] <mathiaz> slangasek: upstream is working right on a patch
[22:37] <mathiaz> slangasek: upstream is working right *now on a patch
[22:38] <slangasek> mathiaz: that's a new package, then?  FFe bug once upstream has something ready then, please
[22:39] <mathiaz> slangasek: yes - it would be a new package
[22:39] <mathiaz> slangasek: ok
[22:42] <simon-o> Hi, when I want to request a merge which depends on another package being merged first (which I also requested), how do I mark that in the bug?
[22:48] <cjwatson> simon-o: just put it in the bug description
[22:48] <simon-o> cjwatson: thanks, will do that.
[22:52] <soren> When does FF actually kick in?
[22:53] <mathiaz> soren: in 2 hours 7 mn
[22:54] <soren> \o/
[23:02] <c_korn> does anyone know why there is only the remuco-server in karmic but not the client? http://packages.ubuntu.com/source/karmic/remuco-server also the debian bug report does not mention why the client directory has been removed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416379
[23:04] <c_korn> hm, ok README.Debian just mentions that the client jar has to be downloaded from sourceforge
[23:31] <Rudy27> Hi
[23:50] <kees> does anyone here have ATI (and/or use fglrx-installer)?  superm1: around?
[23:57] <mneptok> kees: i'd be happy to test anything superm1 wants to send me for free ;)
[23:58]  * mneptok is a magnanimous cat