[00:01] savvas: That's obviously a hard problem, as different websites will have different demographics and some will have incentives to lie. It's a similar problem to television ratings. That said, there are groups out there that do try and get wide, representative statistics by polling a whole bunch of different "representative" websites to some extent. Not surprisingly, their estimates of Linux usage vary, but generally not by mor [00:02] ajmitch: I imagine Ubuntu is more popular in regions of the world where internet access is really awful. I could be wrong about that though. [00:03] YokoZar: then the only way is to get out there and ask :) [00:03] savvas: pretty sure polling websites that have millions of visitors is a bit easier than asking millions of people ;) [00:03] I would have thought that at least in countries with more developed infrastructure that ubuntu is more popular amongst the technically literate [00:03] is invoke-rc.d supposed to be run by sysadmin or its usage is mainly reserved for maintainer scripts? [00:04] whether they balance out, I don't know :) [00:04] ajmitch: yeah, it's a good point. It's not clear at all which way it'll go [00:04] mathiaz: I believe it's to be used by the sysadmin instead of calling the initscript directly [00:04] at least I regularly use it :) [00:05] mathiaz: it's there so that the admin can enforce policy via. policy-rc.d I believe, so an admin probably knows their policy and doesn't need to use it [00:05] mathiaz: I don't think there would be an issue with them using it though [00:05] mathiaz: does kirkland use it for the service command? [00:06] james_w: good question I was looking into that as well [00:07] mathiaz: nope, he uses calls invoke-rc.d [00:08] the manpage doesn't say anything either way about it, but there is bash completion for invoke-rc.d which indicates that at least a few people use it directly [00:09] james_w: ajmitch: ok - thanks for your input :) [00:43] slangasek, I think I've got that grub branch working [00:43] oooooh [00:44] slangasek, I'll put my copy of the svn repository up somewhere - any chance you can double-check? [00:45] jelmer: sure; what am I double-checking? [00:46] slangasek, basically the way bzr-svn does the operations on history [00:46] http://samba.org/~jelmer/tmp/pkg-grub-svn-log [00:50] jelmer: I guess that looks sensible to me; why does it look all svn-y, though? That would seem to be the opposite of anything I would ever be doing with it [00:50] slangasek, this is the svn log [00:51] slangasek, not the bzr log [00:51] well, yes, I can see that it's an svn log, I just have no idea what that should signify :) [00:51] the bzr log just looks like the bzr branch you provided to me [00:53] slangasek: these operations match what's being done in bzr [00:54] slangasek, If it looks ok, I'll push these changes [00:56] jelmer: ok, then I think it looks right from what I can see [01:05] we aren't going to lose the committer information, are we? (noting that all the committers are "jelmer" there) [01:05] Keybuk: I like that you uploaded nut to fix the udev rule paths, but didn't notice it was calling udevtrigger :-) [01:06] cjwatson: The committer information from bzr will still be there, in revision properties (that bzr-svn will read back) [01:06] cjwatson, the person pushing the bzr revisions into svn will be marked as author of those revisions in svn though [01:07] jelmer: we never push any of this into svn [01:07] not sure if you missed that point? [01:07] (or if it matters to what you're doing) [01:08] slangasek, it's never been pushed in the past, but you intend to push it into svn now though, right? [01:10] no [01:10] I don't have write access to the svn repo [01:10] and am not seeking it [01:11] my concern is being able to /pull/ from svn [01:11] ahhh [01:11] I misunderstood then, sorry [01:12] does that change the scope of the problem? [01:13] yeah, I was fixed pushing the current bzr branch back into svn (which is also a nice feature :-) [01:13] right :) [01:14] s/was// [01:26] slangasek: So what is it exactly you'd like to get working? [01:26] basically "bzr merge " ? [01:26] jelmer: yes [01:26] so there are two things I can do [01:27] either merge in the existing revisions that were merged in previously. that'll duplicate the revisions in the log (once merged by you, once merged by me) [01:27] or I can fix up the revisions that were merged earlier, but that'll change the revision ids of the branch [01:28] the latter would require everybody who is using the branch to drop their old copies and refetch the bzr branch [01:28] is there either you'd prefer? [01:29] slangasek, ^ [01:29] jelmer: I'm checking whether there are any other branches published on LP that #2 would disrupt [01:30] kirkland: do you care if jelmer makes a change that breaks your existing branches on LP? [01:30] lool: do you have any outstanding changes based on the LP grub package branch? [01:32] jelmer: we might have to wait 18h or so to get those answers :) I'd prefer option 2 myself, is it ok to wait until we hear back from lool and kirkland before going ahead with this? [01:33] slangasek, yeah, no problemo [01:34] Is it just me, or is sudo broken on the latest amd64 alternate CD? I just did a fresh install on a box, to find that /etc/sudoers didn't have the admin group added. Could be either sudo or user-setup. [01:34] it shouldn't be user-setup; surely sudoers should ship right out-of-the-box in the sudo package? [01:36] well it appears that the admin group wasn't in sudoers, and I am not in the admin group. [01:36] oh [01:36] user-setup, then :-) [01:37] * TheMuso enters recovery mode to fix things. [01:37] not sure why we don't patch the sudoers generation in sudo itself, though === jcm is now known as jonmasters [03:10] fun tip: migrating from ext3 to ext4 changes the partition's uuid === hyperair_ is now known as hyperair__ === hyperair__ is now known as hyperair [04:58] <[reed]> hmm, three kernels just today? [04:58] <[reed]> (intrepid) === bluesmoke_ is now known as Amaranth [06:15] good morning [06:18] and so it is [06:19] pitti, i was wondering if i could pick your brain for other ideas you had (but just hadn't implemented) for jockey's package installation method. since switching to dbus, you lost package the progressive package install status (and support for a vte widget etc). is that stuff not passable over dbus at all easily? [06:20] pitti, i'm looking at needing something similar for a rewrite of another application that i've been working on and would like to policykitify it move the installation routines to a dbus spawned service [06:53] pitti, what i was thinking (but hadn't looked into much yet) was passing the DISPLAY and necessary X auth information over dbus to the service. if the service could then gain access to the display, it could spawn it's own methods for displaying status, and then when it finishes, send another dbus message telling the client to come back to life [07:13] slangasek: hmm, i'm curious what branches in LP would be affected [07:13] slangasek: i'll try to read some more back scroll [07:13] slangasek: i'm sort of on vacation today in Germany/Austria [07:15] james_w: mathiaz is right, i only use invoke-rc.d in /usr/bin/service [07:16] jelmer: slangasek: oh, if this would only affect my grub branches, go right ahead... i don't think i have anything un-merged in there [07:16] what's this about grub? [07:16] well, i do have an ubuntu logo'd grub splash screen, that hasn't been merged :-) [07:16] but that's fine [07:17] im having a great time with grub and ext4 right now. im assuming currently im doing it wrong [07:18] kirkland: where are you hanging out atm? [07:18] dholbach: munich atm, heading to innsbruck in a few minutes [07:18] enjoy :) [07:29] dholbach: cheers, see you in berlin ;-) [07:30] take care :) [07:31] Good morning [07:34] superm1: I have partial progress report, but it isn't very accurate (just what apt gives me) [07:35] superm1: no, unfortunately the backend doesn't have any connection to the frontend at all, same problem as with packagekit [07:35] superm1: passing $DISPLAY and cookie would certainly work, but it's really quite hackish and not really intended to be used that way [07:35] superm1: what happens in jockey is that the backend sends progress signals to the frontend, and the frontend listens to those and updates the UI accordingly [07:36] superm1: thus the lack of good progress information is really a packagekit/python-apt problem, not an intrinsic one of d-bus backends === hyperair_ is now known as hyperair__ === hyperair__ is now known as hyperair === hyper323 is now known as hyperair [08:28] pitti, hi === tkamppeter_ is now known as tkamppeter [08:34] hey tkamppeter [08:35] piiti, why did you reject bug 321164 for Intrepid? It is exactly this bug which caused the regression in the original SRU. The second SRU fixes exactly this bug. [08:35] Launchpad bug 321164 in foomatic-filters "Ubuntu 9.04 has a problem with Laser Printer HL-1435" [High,Fix released] https://launchpad.net/bugs/321164 [08:35] tkamppeter: right, but there was another bug for this regression already, which was reported against jaunty [08:38] Bug 318614 was originally reported about another segfault which the first SRU perhaps already fixed, but the original poster never answered. Later someone discovered the other problem in 4.0.0 final and hijacked this bug. I told him where "his" bug is to continue discussion there. [08:38] Launchpad bug 318614 in foomatic-filters "foomatic-rip crashed with SIGSEGV" [Undecided,Fix committed] https://launchpad.net/bugs/318614 [08:38] What confused you was probably that both bugs are segfaults.. [08:43] The segfault which caused me to fix the SRU was a bug which was perhaps already in the BZR rev 177 which came with Intrepid, but to trigger it one needs a driver which puts at least seven lines of PJL into its output or a PPD with at least seven PJL options. This is rather rare and by accident this was a user who downloaded the first SRU of foomatic-filters. It was not in the code which I added between 177 and 195 (final) but perhaps m [08:43] y code additions raised the probability to hit it. [08:45] tkamppeter: the changelog made it sound like it was the same bug [08:46] tkamppeter: okay, asking for testing on 321164 then [08:46] pitti, I have already asked for testing there, simply open the Intrepid task and add the tags. === thekorn_ is now known as thekorn [08:47] pitti, thanks. [09:33] slangasek: I actually have one grub patch in my mailbox, but I don't think it should block any grub upload if that's the reason you're asking [09:34] lool: it's not about grub uploads, it's about rebasing the ~ubuntu-core-dev grub branch to fix some bzr-svn brokenness and invalidate any branches based on it [09:37] slangasek, lool: 299847: only builds because test suite results are ignored. how do you want to track this? [09:38] doko_: oh. Ok, do we have any idea what the root cause is? Is it really related to this package..? [09:38] slangasek: no, I didn't check [09:38] ok [09:38] then reopen it, I guess :/ [09:38] slangasek: That's fine, I have the file as a patch [09:39] I thought it was a build failure earlier, though, and the version number has only incremented by 1x build? [09:39] Not a branch [09:39] lool: ok, thanks [09:39] slangasek: thanks for checking [09:39] jelmer: please go ahead with fixing up the repo using method #2 === seb128_ is now known as seb128 [09:42] retitled and reopened [09:45] slangasek: hi [09:45] seb128: heya [09:46] slangasek: about your gnome-screensaver issue do you set some im method setting? there is a recent gtk+2.0 similar to your gnome-screensaver one where user state they have issues only when changing im settings [09:46] I didn't investigate yet though [09:46] seb128: heh [09:46] So! Who wants to make f-spot and banshee simultaneously installable? [09:46] $ env|grep IM [09:46] GTK_IM_MODULE=xim [09:46] seb128: ^^ [09:46] slangasek: ok, you can dup the gtk+2.0 bug of yours which was opened before and reassign to gtk+2.0 then ;-) [09:47] slangasek: check before that you don't get the issue if you unset that [09:47] seb128: because the default GTK IM reinvents the wheel on compose sequences - I'd love to not have to set that :P [09:47] yep, testing now [09:47] bug #314516 has a nice big debdiff for it. [09:47] Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516 [09:47] dup which bug? [09:48] slangasek: the newest gtk+2.0 bug in the list if you ignore the installation bugs listed there iirc, let me check [09:49] just reassign yours to gtk+ if you want [09:49] I will do cleaning [09:49] ok, will test first [09:49] seb128: yep, works now :( [09:49] slangasek: ;-) [09:51] hmm, it's possible that I don't need GTK_IM_MODULE set anymore for my env, the compose settings seem to have caught up with iso8859-2 [09:52] but that's still a pretty big bug for CJK, I guess [09:53] slangasek: I wasn't looking for that at the time ;) [09:53] doko_, slangasek: libipc-sharelite-perl on my armel babbage: All tests successful. [09:54] lool: maybe it is fixed. re-upload and see if it testsuite results are ok on the buildds? [09:56] pushed [09:57] seb128: ok - which direction will you dupe them? I want to make sure the release-manager-y tags are all set right afterwards :) [09:57] slangasek: I will keep yours open which already has a jaunty task [09:58] ok [09:59] * slangasek heads off to bed to get a few hours of shut-eye before the release meeting [09:59] 'night slangasek [09:59] 'night! [10:00] pitti, what about the CUPS SRU? Can we already put ...ubuntu7 into -updates and let ...ubuntu8 into -proposed? [10:23] tkamppeter: no, the bug wasn't verified yet [10:24] cjwatson, Riddell: (preparing release team meeting) -- question about bug 310575, is it in the pipe, or blocked by something? [10:24] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 [10:25] cjwatson, Riddell: sorry, bug 309482 [10:25] Launchpad bug 309482 in oem-config "jaunty: Kubuntu OEM enduser setup fails" [Undecided,New] https://launchpad.net/bugs/309482 [10:27] pitti: I've not seen that bug, but I can try and look into it [10:27] pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify? [10:27] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 [10:28] pitti: I'd been planning to today, but of course it would probably be quicker if somebody who knows KDE did so [10:29] doko_, slangasek: Failed on the buildd; it could be a SHM conflict, but this would fail *all* tests, so it might be some missing underlying SHM support; this might be board specific [10:29] I'm trying on my evm === asac_ is now known as asac [10:37] Riddell: was there a decision about IRC client in the recent Kubuntu meeting? (for https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-jaunty-kde-packaging) [10:38] doko_: So it passed on my evm as well; I think this kind of renders the bug slightly less important, but it's blocked until we can have a look at the failure in the buildd's environment [10:47] pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify? [10:47] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 [10:47] pitti: we want to go for Quassel [10:48] Riddell: ah, cool; can you please update the spec accordingly? I'll review it immediately, so that we have this off the table [10:48] yep [10:48] Riddell: cheers [10:51] pitti: done [10:53] Riddell: and approved [10:56] pitti, what about my question concerning the CUPS SRU? [10:56] tkamppeter: getting to it, still finishing the release report [10:56] asac: FYI ogra tested firefox on armel and it worked fine in his experience (but it was a little while ago) [10:57] asac, you can test yourself next week :) [11:07] tkamppeter: yes, I prefer to not stack multiple updates on top of each other; by now, really none of intrepid's bugs are high-urgency [11:08] tkamppeter: if you want, you can upload ubuntu8 as ubuntu8~till1 into your intrepid PPA and ask reporters to test that (if you are unsure whether the patches really help) [11:10] lool: ogra: thanks. [11:11] pitti, I think this is not needed. So let us leave this week for getting an answer on bug 310575 and depending on whether we get the answer you advance the CUPS SRU queue on one of your next scheduled SRU day. In the time being I will simply commit SRU fixes as they come to the BZR. [11:11] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575 [11:11] tkamppeter: right; but please keep in mind that we really must slow down SRUs for intrepid; only truly major fixes [11:11] I hope there are no more SRU fixes needed, though. I think now all issues are covered. [12:07] mvo, seb128: the trigger upgrade issues with libxine segfaulting seem awfully similar to the xine-lib crash we had in intrepid-proposed: under some locales, xine will crash [12:09] lool: is there any xine code run during the install? [12:11] seb128: There's a trigger related to xine I think [12:11] seb128: There was a security update of xine, it would well have cause the problematic code to be run under a non-C locale [12:12] lool: ok, I see [12:21] slangasek, ok [12:21] asac: stupid question, but where does nm-applet keeps it's icons? [12:23] kwwii: http://pastebin.com/fe73ebf2 [12:28] asac: sweet, thanks [12:55] lool, seb128: Is there something wrong with the xine-lib security update? [12:59] mdeslaur: The upload I did to -proposed was addressing a crash when xine scans for plugins under some locales; I suspect your security update triggers this bug === thekorn_ is now known as thekorn [13:02] lool: oh, and you now pushed another to -proposed to fix it again? [13:03] mdeslaur: Yes, but it will take ~10 days [13:03] Since we need to retest [13:04] mdeslaur: Actually we pushed two fixes for this issue, either suffices [13:04] mdeslaur: https://bugs.launchpad.net/bugs/290768 [13:04] Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed] [13:05] Oh you know about it already [13:05] Since you sent the debdiff there [13:06] lool: yeah, that's what our procedure is...release a security update without what's in -proposed [13:06] cjwatson, slangasek, pitti: I uploaded langpacks 10 days ago [13:06] sorry about that [13:06] cjwatson, slangasek, pitti: Might be worth promoting the langpacks to -updates now [13:06] Context: 290768 might have been triggered in a new way via a -security update [13:07] mdeslaur: Not your fault; it's unfortunate but it's a race between fixing the crash and fixing the security holes [13:07] hehe [13:23] lool: main problem is that there seems to be no independent verification that the new language packs alone fix this [13:23] cjwatson: I sent an update to the TB thread [13:24] cjwatson: I find it weird that the installed xine version is the old -proposed one and the locales don't seem to be either german or italian [13:24] cjwatson: But it's really suspicious [13:47] asac, hmm, shouldnt FF offer me some gnash or swfdec love if i go to youtube (on armel) [13:48] all i get is the link to adobe that only offers x86 versions indeed [13:48] * ogra tries video.google.com instead [13:49] aha, there i get the proper thing [13:51] * ogra wonders if it will ever find something ... still checking for available plugins [13:52] ogra: no [13:52] ogra: yeah. video google works [13:52] ogra: unlikely [13:52] ogra: is armel on archive.ubuntu.com yet? [13:53] or ports? [13:53] asac, ports [13:53] and it will stay there [13:53] yeah. we currently dont index those [13:53] hmm [13:53] oh, we need to [13:53] lets talk about that next week then [13:54] there is also a flash for arm (maemo uses it) but not publically downloadable afaik [13:54] ogra: yes. needs a fix of the database updater. [13:54] lpia is also on ports afaik [13:54] right [13:58] cjwatson: I tried to reproduce the original xine-lib issue in a vm with the it langpack, the it locale generated, and running "xine-list-1.1 --all" under LANG=it_IT.UTF-8 to no luck (I even installed libxine1-all-plugins) [13:58] cjwatson: I suspect it might be ~/.xine/config or similar pointing at additional plugins to load [13:58] I couldn't find a way to trigger more verbose behavior [13:59] cjwatson: So I can't check whether the gxine issue relates [14:10] <__Ali__> how can i access the source directory name in debian/rules? [14:12] __Ali__: $(CURDIR) [14:13] <__Ali__> lool: $(CURDIR) doesnt work? dpkg-buildpackage extracts the source into a temp dir [14:13] james_w: Do you have a moment to discuss your latest changes to your DD/DebianImport spec? [14:14] ScottK: I have a moment, but little more right now I'm afraid [14:14] I'm happy to start discussing it, but we may have to take it to email if it's a longer discussion [14:14] Sounds good. [14:15] james_w: OK. The concern I have is social, not technical. I think that while you make a good technical argument for basing the Debian branches off the Ubuntu ones, I think it is likely to be perceived unfortunately in Debian. [14:15] If the DistributedDevelopment model is successful, it will be with us for a very long time. [14:16] __Ali__: I'm afraid I don't see what you're talking about then [14:16] * broonie seconds ScottK - that's going to play rather poorly with a lot of people. [14:16] And so it seems to me like your proposal, while technically sound, trades short term expediency for a long term source of friction with our major upstream. [14:16] ScottK: but these branches won't be. Whenever we rewrite, which has to be done at some point, it will end up the right way round [14:17] So this is a temporary, experimental set of branches? [14:17] not so much experimental [14:17] but it trades short-term expediency for possible medium-term friction [14:18] I think the friction will be immediate and ongoing. [14:18] You just got some. [14:18] <__Ali__> lool: i followed this instruction: http://www.debian.org/doc/manuals/maint-guide/ , it should be valid for ubuntu as well? [14:19] james_w: So that's my concern. Please consider it and we can discuss via email. [14:19] __Ali__: no, dpkg-buildpackage doesn't extract the source into a temporary directory. Some debian/rules implementations do that. [14:19] ScottK: heh, I was just making a fairly similar point to James by /msg :-) [14:19] ;-) [14:19] __Ali__: Perhaps you can be more specific in the error you see, which package, what you're trying to do etc. [14:20] cjwatson: I've got a thought for you on archive reorg too that I'd like to discuss when you have a moment. [14:20] ScottK: sure [14:20] IIRC, the discussion to date on sub-teams has been around seeds. [14:21] But in many cases I don't know that will be the best model. [14:21] ScottK: Mark feels quite strongly that we should also have the ability to have layers formed from hand-maintained lists of packages; I don't see that we lose anything by having that flexibility and so the spec does mention that possibility [14:21] As an example, currently clamav is in Main and only seeded on Server. I do most of the maintenance work on that and it's rdepends. [14:22] <__Ali__> cjwatson and lool: after running debhelper, I get mylib/debian dir, then i cd to mylib dir and run dpkg-buildpackage, obviously there is no source file in mylib dir which is $(CURDIR) [14:22] If I were not a core-dev, but only interested in server, with the current proposal, I'd lose access to upload all the non-server rdepends. [14:22] although there is also no reason we couldn't have extra miniature seed collections that correspond to things like clamav-and-friends [14:23] Alternatively, for the Kubuntu team, if someone is good enough to have upload rights to the KDE stuff we ship on CD, it makes no sense they can't upload the stuff that's not seeded. [14:23] __Ali__: your statement is very confusing on a number of levels. The debian/ subdirectory is typically a child of the top-level directory where the upstream package is extracted. [14:23] The more I think about what I think are the likely areas of interest, the less I think they are really likely to correspond well with seeds. [14:23] __Ali__: so if upstream ships foo_1.0.orig.tar.gz extracting into foo-1.0/, then you'd have foo-1.0/debian/ [14:24] there are plenty of cases that do, and plenty that don't [14:24] OK. [14:24] also, you're looking at the current set of seeds which are very very broad [14:24] if we were actually using them for access control, we'd have finer-grained sets, I think [14:24] OK. [14:24] <__Ali__> cjwatson: foo-1.0/ has only debian, nothing else, do i have to extract the source manually to foo-1.0/? [14:25] __Ali__: normally you would extract the upstream source *before* running dh_make or whatever [14:25] if you've just created a blank directory and run dh_make in that, you're doing it wrong [14:26] <__Ali__> cjwatson: i fed the tarball to debhelper, it wasnt extracted initially [14:26] you "fed the tarball to debhelper"? using what command? [14:27] ScottK: I think where the spec says "seeds", my intent was that people think of abstract seeds (i.e. list of top-level packages, dependency-expanded) rather than the ones we have now [14:27] <__Ali__> cjwatson: dh_make -f ../foo-1.0.tar.g [14:27] ScottK: maybe I was underestimating people's mental link with the current model [14:27] cjwatson: OK. That makes sense. [14:27] Mine in any case .... [14:28] cjwatson: Also I think one should also be able to do reverse dependency expansion. [14:28] That would cover most of the cases I was considering. [14:28] __Ali__: the manual page says that it extracts it; but if it doesn't, then extract it yourself [14:28] <__Ali__> cjwatson: thanks [14:29] cjwatson: For example for the Kubuntu/KDE team, I think it'd be reasonable to describe it's area of interest of the depends of the KDE library packages and all the things that in turn depend on them. [14:30] hmm [14:30] that's interesting, although I would say that it might have unexpected results [14:30] It might. [14:30] particularly when you consider source packages that build both GNOME and KDE variants [14:31] I think it's likely to suck in much of the archive [14:31] True, but if you think of a team that 'knows how to package KDE stuff', that's what their interest would cover. [14:31] my inclination would be to give the Kubuntu/KDE team the ability to nominate stuff they're interested in, and for the archive admins to be very liberal about acknowledging basically anything with a k at the front :) [14:31] Now the ones that support both, then fall into the the multi-seeded set. [14:32] I'm using that as an example, but I think it's a general case. [14:32] it's also worth noting that germinate has absolutely no idea how to do this - it would be a complicated development project [14:32] It might be that in the overlap case you'd have to look at which way to push it. [14:32] and I'm already aware that this is a complicated project as it is and am striving for simplification [14:33] Understand. [14:33] Maybe this is a future capability then and we do manual adjustments as needed in the meantime. [14:34] cjwatson: So that's my thought. Up to you what of it you find worth taking up. [15:17] tseliot, bryce: do you know if there's anything like an ETA for nvidia/fglrx drivers which work with our X.org? [15:17] tseliot, bryce: i. e. do we have a contact to them? [15:17] pitti: I'm working on the nvidia right now [15:18] tseliot: oh, it's in the open source bits? [15:18] or upstream has a new release? [15:18] new upstream releases [15:18] pitti: but I want to make sure that other fixes are included in the new packages before an upload [15:19] tseliot: rock, thanks (just needed a quick status update for release meeting) [15:19] * pitti hugs tseliot [15:19] np [15:33] tseliot: catalyst 9.1 doesn't support the new ABI? [15:34] Amaranth: I don't know. You should ask superm1 since he's the maintainer. === mbiebl_ is now known as mbiebl [16:13] pitti, can you have a look at bug 323224? [16:13] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/323224/+text) [16:13] tkamppeter: in meeting, please subscribe me and ask your question there [16:18] mvo: ping [16:18] slangasek: pong [16:19] mvo: hi, did you happen to see my followup to bug #318442? Do you think my proposal is the right solution? [16:19] Launchpad bug 318442 in command-not-found "openjdk-6-jdk should be the default/priority for javac" [Undecided,Confirmed] https://launchpad.net/bugs/318442 [16:20] slangasek: I looked at your changes in bzr [16:21] slangasek: I agree with your reasoning [16:21] ok [16:21] slangasek: adding it to the database should be fine [16:22] cool; I'll try to come up with some code for that in my copious free time then :-) [16:23] Amaranth, as far as i'm aware it doesn't still. [16:23] slangasek: nice, thanks. we can do a bit of work on this on the sprint if you want [16:23] sounds good === dholbach_ is now known as dholbach [16:32] slangasek: fix for bug 314263 uploaded, FYI (the "apport opens file:///" one) [16:32] Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Triaged] https://launchpad.net/bugs/314263 [16:32] pitti: sweet \o/ [16:40] superm1: coolbhavi has updated firmware-tools to 2.1.5 in bug 321866 for jaunty - is that alright? [16:40] Launchpad bug 321866 in firmware-tools "Please update firmware-tools to the latest version 2.1.5" [Undecided,Confirmed] https://launchpad.net/bugs/321866 [16:41] dholbach, yeah should be fine [16:41] rock on [16:41] I'll sponsor it in a bit then [16:41] dholbach, that reminds me i need to double check on libsmbios to see if debian pulled in the new version too [16:41] thanks dholbach [16:50] <__Ali__> isn't dpkg-source supposed to create the .dsc file? [16:51] <__Ali__> it does not generate it for me [16:51] __Ali__: debuild -S will do it [16:52] <__Ali__> tseliot: debuild? [16:54] __Ali__: yes, install the "devscripts" package, then enter the directory with the source and type debuild -S [16:54] __Ali__: for further information: https://wiki.ubuntu.com/PackagingGuide/Complete [16:54] <__Ali__> tseliot: does debuild call dpkg-source or do i have to call debuild after dpkg-source? [16:55] <__Ali__> ok thanks [16:56] __Ali__: just use debuild [16:58] <__Ali__> tseliot: i dont want to build the package, i just want to create orig.tar.gz and diff.tar.gz and .dsc to upload them to opensuse build service [16:58] <__Ali__> i just need to package the source and create the required files, not actually compiling [16:58] debuild -S does what you ask [16:58] as tseliot already told you [16:59] <__Ali__> cjwatson: so it doesnt actually build? [16:59] alternatively dpkg-buildpackage [16:59] no. read the documentation [16:59] __Ali__: if you read where it says "Building the Source Package" in that guide you will see why I suggested to use debuild -S [16:59] ogra: just one option I think, to avoid confusion [16:59] <__Ali__> ok ok [17:01] is there a known problem with sasldb2? it makes sendmail-mta crash so no SMTP AUTH is possible (jaunty) [17:02] hm, sasldblistusers crashes too [17:22] PID USER PR NI VIRT RES SHR S PU %MEM TIME+ COMMAND [17:22] 30779 root 20 0 2296m 2.2g 4756 R 98 59.5 7:12.21 rsvg-convert [17:22] as soon as I get logged in, I hit 100% usage OF 4 GIGS OF RAM [17:22] oh, my fault. It's boot chart throwing a fit. [17:24] Hrm. screen-profiles has tweaked my .screenrc without informing me what it was doing. I find that a little intrusive [17:26] how long is this supposed to take? bootchart is still eating several gigs of RAM generating a chart of boot o_O [17:26] wait, it just flatlined at only 1 gig of RAM and 100% CPU,ok. [17:27] <_< finished in almost 13 minutes of full-utilization CPU time [17:32] pitti: what is dhcp3 upstream's position on interface-mtu? [17:33] kees: oh, hang on; I just checked again, and it seems that upstream's default is actually to not request it [17:33] kees: it was done in debian bug 372689 [17:33] bdmurray: ^ [17:33] kees: seems I don't quite remember any more then [17:33] Debian bug 372689 in dhcp3-client "default dhclient.conf does not request interface-mtu" [Wishlist,Closed] http://bugs.debian.org/372689 [17:34] I found some discussion about it - https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024845.html [17:34] okay, so we'll follow suit and stop requesting it? [17:35] kees: as I said, fine for me [17:36] cool [17:38] err. on my network I *have* to use interface-mtu or things randomly break. [17:38] why are we dropping it? [17:38] I can't be the only one, I'm sure [17:38] hah [17:39] I know that there are some silly MTUs advertised (as I mentioned in that post), but surely we could just tweak the "insane" range [17:39] that's what I meant with "damned if you do, damned if you don't" :( [17:39] cjwatson: that's the problem, 576 isn't "insane" at all [17:39] (I think) [17:39] the lowest legal one is 68 [17:39] no - although it is the absolute minimum allowed [17:39] is it? [17:40] which of course is unrealistic for today's systems [17:40] cjwatson: just parroting the manpage (dhclient.conf) [17:40] dhcp-options, I mean [17:40] from the point of view of somebody who actually needs an MTU of 576, there is no difference between us not requesting the MTU at all and ignoring MTUs less than (randomly) 1000 [17:41] cjwatson: which one do you need for your system? [17:41] 1380 [17:41] err, I think [17:41] it seems there are a large number of people for which requesting interface-mtu breaks their network. given this, I'd advocate following upstream, which also matches what Ubuntu has always done (excepting intrepid) [17:41] any X developer around? I raised priority of bug 322155 as it is nasty regression... [17:41] Launchpad bug 322155 in xserver-xorg-input-synaptics "laptop touchpad button shows unreliable behaviour after package upgrade in Jaunty" [High,Confirmed] https://launchpad.net/bugs/322155 [17:41] kees: what MTUs are these people getting? [17:42] 576. [17:42] cjwatson: I've gotten 576 [17:42] on comcast [17:42] kees: honestly, I think there are plenty in the other direction too, who obviously aren't speaking up right now because their network works [17:42] kees: is that consistent? if so, s/576/577/ in dhcp3 and people will be happy [17:42] mvo: hey [17:42] cjwatson: i.e. ignore 576 as a response? [17:42]