[00:00] asac: there is some flexibility via ~ubuntu-sru that's true, but the process seems to dissuade quite a number of people from even trying [00:01] bryce: I think it might be a good idea to bring this up in the -devel mailing list. [00:01] and although i can see somewhat of a point in making it hard enough to do an SRU that people need to find a good reason for doing it, it can also have a negative effect on how upstreams look at Ubuntu, IMO [00:01] bryce: some gnome'rs have brought up the same issues [00:02] bryce: I am sure you're as jet lagged as I am [00:02] so going to move on at this point... [00:02] LaserJock: why do they get dissuaded? because they cannot set the right switches in launchpad, or because they don't want to provide patches that are properly documented for each individual issue? [00:02] and I think I am sick now; here comes the ubuflu [00:02] likely a combination. [00:03] jcastro: get well soon :-P [00:03] jcastro: take some airborne; I find it really helps [00:03] asac: because they feel they did the responsibility of releasing a bug-fix and are being told that they now need to fill out Ubuntu paperwork [00:03] jcastro: I make it a habit of bringing a tube of it when I'm out of town and take one a day [00:03] I think the situation would be very much different if we had enough eyes and hands to actively keep up with upstreams [00:03] bryce: lots of liquids seem to help [00:04] LaserJock: usually the paper work is done by ubuntu devs or contributors that want to see those fixes in it. so somehow you are right that we don't have enough hands to do that. but changing the policy won't help here imo [00:05] well, a know that we've had problems in the past where devs and contributors were not filing SRUs because it was excessive paperwork [00:06] it depends on somebody actually caring enough to do it, and at present I'm not sure we have enough people to even cover Main well if it's a "well if you care so much why don't you file a SRU" kind of thing [00:06] asac: I disagree; there are many, many cases where people request an Xorg / driver fix be put out for Gutsy, that I don't do because of all the paperwork. [00:08] asac: In fact, I've pretty much given up on the idea of SRU's for Xorg driver updates, and have been working on building something on Envy [00:09] which I think is going to be a better solution all around, but it's admittedly working around the sru process, not fixing it [00:11] bryce: hmm ... imo if they are not critical enough to do that paper work it might be a good indicator that they shouldn't go in imo. and drivers usually have a high risk to come with hard-impact regressions. if they break they might just break a previously working system completely. [00:14] asac, yes this is the circular logic that irritates the heck out of me - "If it's important enough, you ought to be willing to do 3 days worth of paperwork to get it in. If you're not willing to do 3 days worth of paperwork, then obviously it isn't important enough." [00:15] if you're not a terrorist, then why should you have a problem with being cavity searched each time you fly? If you have a problem, then maybe you are a terrorist? [00:16] bryce: for you a driver fix takes 3 days? how many bugs do they fix? [00:17] and yes, driver changes obviously carry more significant risk than a package like inkscape. but at the same time the bugs they fix tend to be more severe as well - usually solving "I can't get Ubuntu to work on my computer anymore due to X problems" compared with "Inkscape crashes when I cross my eyes" [00:18] asac, 3 days is a best case; obviously usually a driver SRU takes much, much longer [00:18] you mean it consumes 3 days of work or takes 3 or more days of your attention [00:19] asac, and "has a non-zero chance of breaking a previously working system" is why driver SRU's have proven impossible to file. [00:23] asac, packaging, building, and thoroughly testing a driver change can easily consume a day by itself. The paperwork takes additional time - maybe an afternoon, as does summarizing bug report commentary into problem descriptions and test cases, and then additional time/attention responding to review requests, usually requiring modifying the packaging and going through the rebuild/retest process a few times, then a whole bunch of [00:23] time spread over several days or weeks recruiting other people to also test the package and respond to their questions [00:24] so I would estimate 3 days of effort to be a minimum for filing a sru for a driver bug [00:24] but more likely it would take several week's of attention [00:24] and after this, it would almost always be denied. [00:24] bryce: yeah ... i see. imo the process is right still. if we cannot guarantee that there is no regression, we cannot really upload drivers [00:25] asac, ah and I gather you do not see this as an issue? [00:25] so it does the right thing .... under the assumptions that we follow a "stable release policy" as we currently define it. [00:26] bryce: of course, but not an issue that can be easily fixed [00:26] asac, and in any case, wouldn't it save more time and angst to simply say, "Our policy is no changes to drivers in a Ubuntu release due to risk of regressions," rather than elaborating this extremely lengthy SRU process document with all this paperwork? [00:27] asac, it seems like the process is documented with the idea of handling something severe and high risk like Xorg, but is being applied even in cases like Inkscape where really there isn't such a high risk [00:27] so it ends up being inapplicable for the former, and too complicated to bother with for the latter [00:39] well ... we have two big classes of regressions that we care about: 1. complete system breakage ... 2. feature breakage. [00:39] if 1. can happen we cannot upload at all (as we found out for the drivers) [00:40] 2. we can only prevent by thoroughly reviewing and not letting in bug fixes that are not high-impact or whose patches don't look reasonably minimal imo. [00:45] maybe really raise this on ML. maybe we can really find something we can improve [00:45] well, I return to my original point - solving this by imposing a lot of paperwork to the point that people stop bothering to try doing sru's is just sweeping problems under the rug, not really solving the problem. [00:46] bryce: the paparwork is done to take load from rare resources: sru reviewers [00:46] you cannot expect the reviewer to figure out how to get the patches to review them et al [00:47] (i don't say that all is perfect, but in general it does what we want imo) [00:47] I can understand that. What I'm saying is that pushing that workload back onto the sru requestor ends up reducing the number of sru requestors [00:47] so yes, in a way it solves the problem of the sru reviewer's workload [00:47] ... which can or cannot be a bad thing ... [00:48] sigh [00:48] :) [00:48] * asac hugs bryce [00:48] ok i am off going to bed. we should go ahead on ml [00:48] in any case, it feels like the process is broken, and trying to get it fixed is just wasted breath [00:48] night [00:49] well, like I said, for my own issues (both inkscape and xorg) I'm just bypassing using sru's to get the work done [00:50] I just hope that other people's complaints about the sru process get listened to and not just dismissed as "whining" [00:50] since I think long term it could hinder Ubuntu in general [00:54] i think nobody declares this discussion as whining ... if we can improve things, we should improve them. but i don't see how we can lower the documentation bar because its essential for reviewers. only accepting high-impact bugs is in some way a measure to overcome that we don't have endless resources and the vague definition of high-impact already gives us enough flexibility to approach special cases imo. [01:26] How do I make my own window border theme? [01:28] How do I make my close button be red and the minimize button blue without writing a completely new theme? (GNOME, GTK, etc) === kyle__ is now known as kylem === ln-_ is now known as ln- === bigon is now known as bigon` [06:32] Good mornign [06:33] Afternoon, pitti [06:34] hi pitti! [06:34] back from the Sprint? [06:37] LaserJock: yeah, got home Saturday evening [06:40] * Fujitsu was wondering how jcastro got his photo of a couple of distro-teamers recovering from NM 0.7. [07:12] well, he walked into the room and pointed his cam at us, easy :) [07:14] pitti: was it a pretty productive sprint? [07:14] pitti: Well, yes, but I didn't realise there was a sprint. [07:16] LaserJock: I'd say so; lots of ad-hoc discussions, hands-on trainings, hacking, and clearing the TODO list [07:16] good morning [07:16] hey geser [07:17] Hi pitti [07:18] pitti: so we may get Hardy out the door after all? ;-) [07:24] possibly :) === bigon` is now known as bigon === hunger_t is now known as hunger [08:20] Heya all [08:20] i need some help. im appear to be missing glade-2.0 [08:21] i keep getting a message "ld: cannot find -lglade-2.0" [08:21] can someone help me? [08:21] i have installed glade3 and done "apt-get install glade" [08:21] l0wrd: Off topic for this channel (it's not development *of* Ubuntu). Also, you probably want libglade-dev, or somesuch package. [08:22] RAOF: i see your point. [08:24] RAOF: thank you for your help, everything is working now. [08:48] good morning === doko_ is now known as doko [08:58] hi [09:19] hey asac, hey dholbach [09:20] hey pitti, hey asac [09:21] * asac hugs pitti + dholbach === Xoff is now known as Xof [09:22] pitti: have you read the SRU discussion we had from 00:00 -> 02:00 yesterday? [09:22] aeh today :) [09:22] asac: no, seems my proxy had some trouble with freenode connection [09:23] oh unfortunate :) ... i saw you online iirc [09:23] but maybe that was at the end [09:25] pitti: starts at 23:11 here: http://irclogs.ubuntu.com/2008/01/27/%23ubuntu-devel.txt ... and continues on http://irclogs.ubuntu.com/2008/01/28/%23ubuntu-devel.txt [09:27] asac: ugh, that's a lot -- what was the problem and conclusion? [09:28] and I don't agree that it's overly bureaucratic [09:28] if you can demonstrate the problem, have a patch, and someone to test the upgrade, then you can just do an upload [09:28] i agree [09:28] and if you fail any of these three, then an SRU is absolutely not appropriate [09:28] its bryce, jcastro and laserjock that disagreed [09:32] [23:31] I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through. [09:32] bryce: ^ please tell me where the SRU process is labor-intensive which is not related to testing and necessary QA [09:33] bryce: attach a patch and justification to a bug, upload a fix, coordinate testing (or ask sru-verification), that's it for you [09:33] I've to admit the wiki page is not inviting [09:33] bryce: I don't see how it could become any less bureaucratic [09:33] I saw a lot of people doing SRUs in 'fire and forget' mode [09:34] and the process is deliberately designed to not move these into -updates automatically [09:34] bryce: I'm always open to suggestions how to improve it and make it less bureaucratic, so please tell me :) [09:34] pitti: the wiki description takes several pages, I would not say it looks easy for people who wants to contribute [09:34] seb128: maybe we can polish the wiki ... like make the main document leaner and put the details in kind of a "check-list" that is kept separate. [09:35] asac: would be nice [09:35] seb128: right, it's very detailled, since it's documentation [09:35] but people already do it incorrectly even with the current level of detail [09:36] and it's not nice to push all the work to me, to fix bug states, repeatedly bother people about "is it fixed in hardy yet?" and "please fix it in hardy first", "how can I reproduce", etc. [09:37] do you think they read it? or they run away because that looks too complicated? [09:37] pitti: I don't think anybody wants to push the work to you [09:37] but the wiki description should be something like [09:38] * describe the issues and how to trigger it easy [09:38] no, not 'want', but it ends up being me who does the work because people don't follow the documentation [09:38] * attach your changes [09:38] so I can always point them to '2.3 of policy' etc. [09:38] * subscribe the team and get testing [09:39] we discussed the wiki documentation with ogra at the bar some days ago, and I sort of agree with him, we have things too complicated and that scares users away sometimes [09:39] we should have a small and easy description [09:39] users shouldn't be concerned about this at all [09:39] and an another page with details [09:39] we communicate to them through bug reports [09:39] i. e. 'Please test the fix in -proosed and tell us how it goes' [09:39] users -> contributors [09:40] if a contributor is not able to understand this policy, we should not leave him anywhere near SRU [09:40] pitti: i think one special case that was discussed and for which the process (righly) is too complex is that of pushing new upstream "bugfix-only releases" ... [09:40] those instructions are not at all difficult; they are particularly easy and detailled [09:40] my comment was: ... upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments. [09:41] well, I've to admit I already delayed SRUs because I didn't do some for some months and I opening the wiki page was enough to make me not want to do it [09:41] asac: I see; well, that's orthogonal to the process document, though [09:41] seb128: you delayed some SRUs because nobody bothered to do at least a single test [09:41] I don't want to read complicated text, I just need to basic actions [09:41] seb128: i. e. the 'fire and forget' mode [09:41] which just doesn't work for SRUs [09:41] seb128: I did; I followed up with 'please test the package in -proosed' [09:41] no, when I said delayed, it's a SRU I had to do [09:42] ah [09:42] and honestly I find the wiki page too complicated and discouraging [09:42] so would it help to split it into a 'process' and a 'checklist for each step'? [09:42] I just want the: do the patch, subscribe sru, add a testcase [09:42] yes [09:43] the problem that i see is that nobody would bother to read the checklist any more [09:43] do you really think they do now? [09:43] and the SRU team would end up with getting a lot of bad or wrong SRUs [09:43] which in the end stalls the process much more [09:43] seb128: some don't [09:43] I think they just decide "it's too complicated, let's upload and tag" [09:43] and some other are discouraged and run away [09:44] some other do read it most likely too [09:44] I don't think that there's a brilliant solution to this TBH [09:44] but I'm not sure that those who read the pages would not look at the checklist if they have a doubt [09:44] an SRU process is inherently complicated, so you cannot really come up with a trivial three-line document to describe it [09:44] right, I'm not sure either [09:44] the current policy hasn't been invented out of thin air [09:45] it's not really complicated [09:45] we started with a very small process, got breakage, and added checks to it to fix that breakage in the future [09:45] it's basically: you have an easy patch which would make things nicer for lot of users, apply it to the stable package, test, write a testcase, upload [09:46] seb128: what we can do immediately is to split the process into one for the developer and one for the SRU team [09:46] seb128: right, that plus having a bug# and fixing it in hardy first [09:46] seb128: I specifically added the 'upload immediately without ack' case a few months ago [09:46] since that 'wait for SRU ack' was a discouraging delay [09:47] and it works well so far [09:47] right, I don't think SRU are too complicates [09:47] I think the wiki page is though [09:47] * pitti will split the process accordingly (dev vs. SRU team) [09:48] you have 6 sections there and up to 7 items in those [09:49] right, would be nice to split between what the uploader has to do [09:49] and what SRU team, etc have to do to validate [10:12] soren: feel free to send me a patch for the openssh host key thing you mentioned; I guess my only concern is that entropy might be scarce at init time and it could slow down boot substantially, and so it would still be better to generate them in the postinst if possible [10:12] \sh_away: the decision-tree stuff in console-data has been there for a while now, but you can drop it on merge if you like; we don't use console-data any more [10:13] CarlFK: you can if you like, but it won't make any difference since I'm already auto-notified of openssh bugs [10:15] CarlFK: I've followed up to your bug [10:18] cjwatson: Well, the postinst invokes the init script, so they'd be generated at install time regardless. [10:21] soren: right [10:21] cjwatson: The change just makes the process of distributing a VM with ssh installed in it much simpler. Currently, it needs to do various trickery to replace the host keys (so that not every instance of the vm shares their secret keys) on first install. With the change, you just remove the host keys as one of the last things before shutting down the vm and distributing it, and they'll get generated on boot. [10:21] soren: *nod* [10:21] Cool. I'll whip up a patch. [10:22] soren: though, I still think that stands a decent chance of having the VM sit there at boot trying to gather entropy - I'd still recommend regenerating the keys before shutdown [10:22] Erm.. How would that work? [10:26] I mean.. In the context of a use case where you want to create a vm image with ssh installed and distribute said image while avoiding that each instance will have the same secret key installed, I don't see how you can do the generation bit at shutdown? [10:27] cjwatson: ^ [10:28] soren: err, yeah, guess not [10:28] fair point [10:28] Unless you freeze the vm just before shutdown and distribute that, but that would be quirky, and the entropy would be the same for anyone who fires it up, and you'd have lost anyway :) [10:29] cjwatson: FWIW, I believe Fedora and RedHat have used this approach for a long time and it seems to work for them. [10:29] I'll run a few tests and see if it gets stuck on entropy starvation. [10:39] asac: ffox 3.0 for hardy-4? [10:40] asac: ^ ... alpha ... [10:50] soren: as you touched iptables last, would it be possible to include the patch from Debian bug #358637 to get a static library compiled with -fPIC? [10:50] Debian bug 358637 in iptables-dev "libip* should be compiled with -fPIC; attempt to link the current libiptc.a binary into a shared library on amd64 causes an R_X86_64_32S relocation error" [Important,Open] http://bugs.debian.org/358637 [10:50] pitti: i will try to do mono today ... if that works well, then yes. otherwise after alpha4 ... but ill try [10:52] asac: what does mono have to do with it? [10:53] mono is in main and has a gecko binding [10:53] geser: /me looks [10:53] pitti: so we could not dump firefox to universe [10:54] asac: isn't that pretty independent of making ffox-3.0 the default? [10:54] asac: or you mean mono will pull in ffox to the CDs, too? [10:54] soren: I see that the patch is for libiptc.a but I need a libipq.a with -fPIC. I guess a similar patch might work there too. [10:55] geser: I've not worked my way through all of it yet, but the patch I'm looking at right now adds a libipq_pic.a compiled with -fPIC? [10:57] geser: ...and I can't spot any other patches in it? [10:59] soren: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=003-dev_lib_fPIC.patch;att=1;bug=358637 adds only libiptc_pic.a [10:59] pitti: haven't looked ... i would like to have transition complete in main before replacing/conflicting firefox-3.0 on firefox. if you want it the way its now, i can do it though. [10:59] geser: Ah, so it does. My mistake. [10:59] asac: I'm just concerned about doing it RSN, for testing [10:59] geser: If you make a patch, I'd be happy to review and upload it. [11:00] ok [11:00] geser: I've got an iptables upload pending anyway. [11:06] pitti: personally, i don't have much concerns about a lack of testing. the package is pretty mature and we have had a bunch of users for quite some time already. but i understand the concerns from the release-managers point of view [11:06] pitti: let me try to get this mono thing done today. then we can decide [11:07] ok? [11:08] souds good [11:10] <_StefanS_> BenC: you there? [11:12] <_StefanS_> BenC: I was wondering if the acpi/hal problem that reports the double number of batteries will be fixed in the final hardy ? [11:12] StevenK: bit early for him as yet [11:12] _StefanS_, BenC: you mean the problem that CONFIG_ACPI_PROCFS_POWER=y is enabled? [11:13] _StefanS_, BenC: (which causes hal to pick up the battery from both /proc and /sys) [11:13] <_StefanS_> pitti: yep something like that [11:13] <_StefanS_> pitti: yes thats the one. [11:13] <_StefanS_> pitti: I saw it was fixed in the final 2.6.24 kernel (atleast partially) [11:13] _StefanS_: then we'll get the fix [11:13] <_StefanS_> pitti: sweet. Thanks [11:14] No, it's still present in 2.6.24 final. [11:14] <_StefanS_> crimsun: only on some systems, right? [11:14] <_StefanS_> crimsun: I think they patched it to just return an empty list in proc [11:16] <_StefanS_> crimsun: maybe a userspace app needs to changed (e.g. g-p-m / guidance-p-m) to make it skip the empty one (?), thats how I understood it anyways [11:25] seb128, thekorn: I found out why apport gets stuck in an endless loop, producing bug spam like bug 184306 [11:25] Launchpad bug 184306 in totem "totem-xine-video-thumbnailer crashed with SIGSEGV in xine_list_get_value()" [Undecided,New] https://launchpad.net/bugs/184306 [11:25] seb128, thekorn: I reported it as bug 186599; any idea? [11:25] Launchpad bug 186599 in python-launchpad-bugs "fails to remove tags sometimes" [Undecided,New] https://launchpad.net/bugs/186599 [11:25] pitti: good [11:27] soren: is it known that the generic hardy kernel does not boot in kvm? [11:29] mvo: Er... No. [11:29] mvo: -v [11:30] soren: let me poke a bit more, but currently it looks like I can not boot the hardy generic kernel in my kvm (I haven't tried -virtual or -server yet) [11:30] What happens? [11:30] soren: not sure, the kernel hangs and the last message is "time: pit clocksource has been installed" [11:31] mvo: Kernel version? [11:31] but let me ensure that everything is up-to-date here first [11:31] Cool. [11:31] Hobbsee, Riddell: do you have some minutes for checking/uploading the debdiff on bug 133944? [11:31] Launchpad bug 133944 in kdepim "package kitchensync 4:3.5.6-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/apps/ksync/ksyncui.rc', which is also in package ksync" [Low,Confirmed] https://launchpad.net/bugs/133944 [11:32] keescook, ping [11:34] pitti: the gutsy one? [11:34] Riddell: yes [11:34] pitti: hmm, looks strange, will have a closer look in about half an hour [11:34] thekorn: awesome, thanks [11:39] pitti: looks all good, want me to upload? [11:39] Riddell: would be great, I'll accept it right away then [11:41] pitti: done [11:41] * Hobbsee waves [11:41] hi Hobbsee! [11:41] pitti: that fix should be fine [11:41] * Hobbsee hugs pitti [11:44] soren: my kernel is 2.6.24-5-generic and I try to boot a 2.6.24-5-generic [11:46] * soren sighs heavily at git [11:49] soren: http://members.ping.de/~mb/tmp/iptables.debdiff is the debdiff for iptables. I've adapted the patch from the Debian bug for libipq and tested the new iptables-dev with building perlipq and nepenthes on AMD64 [11:53] soren: same problem with the virtual kernel image it seems, let me know if I can help you further (e.g. screenshot of the hang etc) [11:56] pitti: the delo FTBFS looks like a bug in pkg_create_dbgsym: http://launchpadlibrarian.net/11490461/buildlog_ubuntu-hardy-i386.delo_0.8-2.2_FAILEDTOBUILD.txt.gz [11:56] do you agree? [11:56] mvo: I'll be all over it as soon as I manage to beat git into submission. [11:57] pitti: it seems that removing tags does not work for bugreport which have a 'nickname' [11:57] geser: yes, I do; can you please open a bug for it? [11:58] geser: might even be the same one as we had for that ocaml package; it's again -X [11:58] thekorn: ah [12:01] pitti: the file it complains about isn't -X in the dh_strip call [12:01] * Hobbsee curses the evil keyboard bug [12:01] * Fujitsu does too, and fails to work out what triggers it. [12:06] mvo: How exactly do you invoke kvm? [12:07] soren: kvm -m 512 -hda root.qcow2 [12:08] mvo: Ok, nothing fancy I can blame it on, apparantly. :) [12:08] soren: I tried -no-acpi for the fun of it, but it does not make a difference [12:09] mvo: Exactly which kernel version is it? [12:12] soren: meh, I'm an idiot, ignore me. the "problem" is that the name of root changed from hda to sda in hardy (/me is hit by the plague apparently) [12:14] mvo: And the UUID magic doesn't work? [12:14] pitti: filed as bug 186610, looking at the meaning of dh_strip -X again it's an other incarnation of the same bug like in the ocaml package. [12:14] Launchpad bug 186610 in pkg-create-dbgsym "pkg_create_dbgsym fails if objcopy can't recognize the file format" [Undecided,New] https://launchpad.net/bugs/186610 [12:15] soren: is the debdiff for iptables enough for you or should I file a bug about it? [12:16] geser: It's fine. It's compiling as we speak. [12:17] soren: yes, that seems to be the case, vol_id returns the right ID_FS_UUID number and /etc/fstab looks good too [12:20] pitti: I committed a fix to the .main branch of py-lp-bugs [12:21] thekorn: many thanks! I'll apply that to the retracers [12:23] soren: I take a closer look after lunch [12:25] mvo: Awesome. Thanks. === asac is now known as asac_resurrected [12:26] geser: Uploaded. [12:32] jcastro: there? === asac_resurrected is now known as asac [12:35] jcastro: oh i see you are on holidays ... enjoy [12:40] pedro_, seb128: FYI, p-lp-bugs fixed locally with thekorn's patch and restarted [12:40] pitti: rock on, thanks [12:40] pitti: great, thanks :-) [12:41] soren: thanks === lamont` is now known as lamont [12:52] hi lamont [12:54] morning Pici [12:54] pitti, even [12:54] Morning :p === \sh_away is now known as \sh [12:58] geser: Oh, thank *you*. [13:01] StevenK, Mithrandir: hildon-fm-l10n promoted by your request, but please keep in mind that this won't actually give you anything but an useless empty package [13:02] StevenK, Mithrandir: TBH I'd much rather keep this in universe (since it doesn't make sense in main) until this is sorted out; if you prefer that, I can demote it agaih [13:02] s/h$/n/ [13:02] <\sh> bryce, ping bug #17601 [13:02] Launchpad bug 17601 in xterm "[xterm] add better charclass map" [Wishlist,Confirmed] https://launchpad.net/bugs/17601 [13:03] <\sh> pitti, what do you need from me to include some more libs to ia32-libs? :) [13:03] hi \sh [13:03] <\sh> hey bryce [13:03] \sh: a list of packages and a poke to do it :) [13:04] <\sh> pitti, ok...I just need at least 2 or 3 more libs to have wine on amd64 working like on x86_32 [13:05] <\sh> bryce, we introduced this change in xterm during breezy, now it's gone completly ... I re-added it...mind using it? :) [13:07] \sh yes it looks good [13:12] <\sh> bryce, do we have something like a bzr branch for xterm? [13:14] \sh nope, not for xterm [13:15] \sh, I believe it's contained in one of the x11- packages, I can check for you, one sec... [13:16] hmm, nope, looks like it's a discrete package [13:17] so it's just a straight upload [13:18] <\sh> bryce, yepp...it went from the X packages a long time ago :) [13:18] \sh actually we recently re-merged them into some collections of apps. But looks like this was retained as separate === Hobbsee is now known as LongPointyStick [13:21] bryce, \sh: xterm is separate in debian as well [13:22] \sh: please push that change to debian as well [13:23] tjaalton: any idea on why the patch got dropped? I don't see a mention of the bug# or 'charclass' in the changelog, so wonder if it just got accidentally dropped in a sync or something? [13:23] gdm in hardy is not playing the sound... is that an know issue? [13:23] bryce: don't know, I'll check [13:24] <\sh> bryce, when I introduced the patch I wonder if I used the LP bug number these days [13:25] \sh ah, that could explain it too [13:25] bryce: seems that it was uploaded to feisty in Dec. 2006, way before me :) [13:26] <\sh> bryce, ah now [13:26] um, "before I did anything related to X" [13:26] jwendell: ogra mentionned it some days ago but nobody really looked at why it's broken yet [13:26] <\sh> bryce, + Excluded patches: [13:26] <\sh> - charClass patch is merged to upstream [13:26] <\sh> xterm (208-0ubuntu1) dapper; urgency=low [13:26] <\sh> upstream dropped it somehow [13:26] <\sh> bah it was me too ,-) [13:26] seb128, should I fill a bug? [13:27] jwendell: if there is none yet feel free to open one [13:27] seb128, dint you say there would be hal involved ? [13:27] jwendell: that's likely an upstream issue though [13:27] after looking [13:27] ogra: that was for the login sound [13:27] <_MMA_> seb128: I think its related to the sound issues you and I had talked about. [13:28] _MMA_: I don't think so, gdmplay just calls aplay [13:28] it doesn't use libgnome [13:28] seb128, ah, k .... i just remembered that asac had ahl probs as well and was wondering if our hal pobably starts to late [13:28] seb128, maybe something related to esd->pulseaudio migration? [13:28] <_MMA_> Ahh.. [13:28] jwendell: not likely, it uses aplay directly [13:29] seb128, ok, i'll find any related bug in upstream (when b.g.o is back) [13:29] ogra: apparently hal startup has been moved back at some point ... i had 15 here ... while other users have 23 [13:31] asac, ah [13:32] strange though. [13:32] asac: I am around [13:34] jcastro: good ... currently talking in #mono on irc.gnome.org [13:35] <_MMA_> ogra: Have you done a clean Edubuntu install lately? Ubuntu Studio mirrors how Edubuntu sets things up but currently gets no login/out sounds. Im wondering if its the same for you on Edubuntu. [13:37] _MMA_, the edubuntu CD is going away in that form, so i dint test ... i had the prob on my classmate image which is a very specific setup and not really comparable to a normal install [13:37] <_MMA_> Ahh... Ok. Ill have to poke around more. Maybe tie crimsun down at some point. [13:44] pitti: there is a hal dependency issue somewhere, I did apt-get upgrade my desktop and now hal doesn't start [13:45] pitti: hal has been put on hold by I guess something else has been updated that doesn't work with the old hal or something [13:46] ah [13:46] I've libpolkit 0.7 installed with policykit 0.6 [13:47] seb128: can you please give some details? it works here [13:47] seb128: maybe because I introduced the Breaks: of policykit-gnome and policykit? [13:47] pitti: no, I think it's a lack of break [13:47] I've libpolkit 0.7 and policykit 0.6 [13:48] I guess the lib should not be updated without policykit [13:48] hal error is "Could not init PolicyKit context: (null)" [13:49] let me get libpolkit 0.6 [13:53] pitti: bingo, downgrading libpolkit and libpolkitdbus to 0.6 fixes the issue [13:53] pitti: either libpolkit 0.7 should Depends on policykit >= 0.7 or Breaks policykit <= 0.7 [13:53] the latter, I think [13:53] ok [13:54] should I file a bug about it? [13:54] it's about as fast to just fix it IMHO [13:54] that's a partial upgrade issue so not high importance [13:54] do you have that in bzr or should I just do the change? [13:55] seb128: already at it (no bzr) [13:55] pitti: ok, thanks [13:55] * seb128 hugs pitti [13:56] seb128: uploaded [13:56] excellent ;-) [13:58] hi all [13:59] maybe someone knows why there are not translation templates for brasero CD/DVD burner ? brasero is in main [13:59] see https://translations.edge.launchpad.net/ubuntu/hardy/+source/brasero [13:59] mantiena-baltix: likely because there has been no upload building a template since it has been promoted in hardy [14:00] mantiena-baltix: should be fixed when somebody does the 0.7.1 update [14:00] seb128: it seems so, tnaks [14:00] seb128: lmedinas should do that ;) [14:00] you are welcome [14:01] lmedinas already packaged 0.7.1 [14:01] mantiena-baltix: so it just require sponsoring? [14:02] maybe, if Lois isn't ubuntu developer ;) [14:02] mantiena-baltix: bug #186443 [14:02] Launchpad bug 186443 in brasero "New upstream version: 0.7.1" [Undecided,New] https://launchpad.net/bugs/186443 [14:02] mantiena-baltix: should be uploaded soon I think [14:02] seb128: I too ;) [14:03] I meant that it'll likely been uploaded soon since dholbach already commented on the bug [14:04] seb128: btw, ppa build daemons still removes translations from debs without universe in section ? [14:06] mantiena-baltix: no idea about this one [14:16] pitti: can you also backport the change from bug #184594 to the retracer? it fails retracing some bugs and just untag those due to it [14:16] Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594 [14:16] seb128: I'd love to, yes [14:16] or tell me how to do it maybe so next time I can do it myself rather [14:19] <_MMA_> seb128: Who should I talk to about Bug 186365? [14:19] Launchpad bug 186365 in kdelibs "Please move xdg-user-dirs depend to "recommend"" [Undecided,New] https://launchpad.net/bugs/186365 [14:20] _MMA_: kdelibs? the kubuntu team most likely [14:20] <_MMA_> Ok. === cjwatson_ is now known as cjwatson [14:22] _MMA_: not having xdg-user-dirs installed does bad things to kde apps [14:23] <_MMA_> Riddell: Many apps K apps are relying on these dirs now? [14:24] _MMA_: well kdelibs does [14:25] <_MMA_> Does xdg-user-dirs do more that stick those 5 dirs in a users home dir? [14:25] <_MMA_> s/that/than [14:25] Riddell: indeed, he also posted to the whiteboard on ubiquity-slideshow and to the ubuntu-installer ML. Thanks for the heads up, I'll be following up to his post on the ML. [14:32] <_MMA_> Riddell: Does xdg-user-dirs do more that stick those 6 dirs in a users home dir? And if they rely so heavily on them, why is one allowed to remove the folders? I'm just trying to figure out what it does. [14:34] _MMA_: that and xdg-user-dir to answer where the directories are [14:34] _MMA_ good questions; I've wondered the same [14:35] <_MMA_> Riddell: We're getting our users doing the same thinga as Bug #158146. "From what I have seen, a lot of new Ubuntu users moves half of the xdg dirs into trash right after installation." So we just decided to not take on this package from Ubuntu. Now it looks like we're forced to because our our inclusion of a K-app. [14:35] Launchpad bug 158146 in xdg-user-dirs "xdg-user-dirs should ignore ~/.Trash" [Undecided,New] https://launchpad.net/bugs/158146 [14:39] <_MMA_> Riddell: If its moved to a "recommend" anyone installing from the repo should get it right? And xdg-user-dir is already in the kubuntu-desktop seed. Isnt this enough? [14:42] _MMA_: maybe, looking for the bug that made me make that change [14:42] <_MMA_> Ok. [14:44] _MMA_: https://bugs.launchpad.net/ubuntu/+bug/175982 [14:44] Launchpad bug 175982 in ubuntu "Kdesktop in Kubuntu Hardy shows / icons rather than icons from /home/'usr'/Desktop" [Undecided,Confirmed] [14:44] * _MMA_ looks. [14:44] <\sh> pitti, do you have any clue about dh_strip and those error messages? BFD: /home/shermann/packages/hardy/wine/0.9.54/new/wine-0.9.54/debian/wine-dbgsym/usr/lib/debug/./usr/bin/wine-kthread: section `.note.ABI-tag' can't be allocated in segment 2 ? [14:45] so it breaks kdesktop not having it installed [14:45] \sh: ergh, no; I never saw anything like that, I'm afraid [14:48] <_MMA_> Riddell: Even if set as a depend in kubuntu-desktop? (I dont know if thats how you currently have it set up for Gutsy) And this is mostly an annoying cosmetic bug. Id like a better solution if there can be one but understand your position. [14:49] _MMA_: two options, the proper way would be to fix our xdg patches to do something sensible when xdg-user-dirs isn't installed, an easier way would be to make xdg-user-dirs a recomends on kdelibs and a depends on kdesktop (I'd just worry it would break other kde apps) [14:51] <_MMA_> Riddell: Yes. The latter is something like what I was hoping for as a quick solution but like I said, I understand your position. [14:52] _MMA_: lets do the latter then and see what breaks [14:52] <_MMA_> Ok. Let me know after the change if you want me to test thing. If it has to revert, I understand. [14:53] <_MMA_> s/thing/something [14:54] _MMA_: what kde app are you shipping? [14:55] <_MMA_> Rosegarden I believe. Might be another. [14:55] * _MMA_ looks. [14:57] <_MMA_> Riddell: Rosegarden and creox. Both sound apps we've shipped for 2 releases. [14:57] * soren hugs pedro_ [14:57] pedro_: Thanks for checking the bind9 updates. [14:58] soren: you're welcome :-) [15:06] pitti: retracers fixed now [15:06] seb128: yay you [15:06] pitti: I've changed the gutsy and hardy on i386 and amd64 and verified it retraced correctly a bug which failed before === psicus78_ is now known as psicus78 [15:17] <\sh> pitti, when do you have time to work with me for the octave3.0 transition? :) [15:17] <\sh> s/for/on/ [15:18] \sh: what do I need to do for that? [15:19] <\sh> pitti, first, we need to sync octave3.0 from debian sid :) second, get rid of octave2.1 and octave2.9, when octave3.0 is build we need to sync some other packages, and I'll upload some more :) [15:20] <\sh> pitti, and as a third point, get rid of koctave... there is a removal report pending :) [15:20] <\sh> pitti, there is a reference on https://bugs.edge.launchpad.net/ubuntu/+source/octave2.9/+bug/185959 [15:20] Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] [15:20] \sh: I can do that any time; just tell me what to do in IRC, and I'll do it [15:20] <\sh> pitti, cool :) [15:24] <\sh> pitti, so I think as a start, sync octave3.0 from debian sid (see bug #185653) [15:24] Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Wishlist,Confirmed] https://launchpad.net/bugs/185653 [15:26] \sh: shall I remove the older ones now? [15:26] <\sh> pitti, nope...let octave3.0 build first...we have enough time to get rid of 2.1 and 2.9 [15:27] \sh: ok [15:27] <\sh> pitti, thx a lot :) [15:27] you're welcome! [15:30]