=== nixternal_ is now known as nixternal [03:05] http://ubuntuforums.org/showthread.php?p=5194590#post5194590 [06:15] Good morning [06:16] Hi [06:17] pitti! [06:31] Morning pitti. [06:39] good morning === dholbach_ is now known as dholbach [06:58] zul: yay, Debian accepted all our openvpn patches; yay bug/patch forwarding, we can sync :) [06:59] Whee [07:23] hey thekorn [07:24] good morning dholbach [07:24] thekorn: with the new /+text parser bug summaries just contain one character :-) [07:25] cjwatson: Good morning [07:25] cjwatson: if you have a moment, your input in bug 220805 would be appreciated [07:25] Launchpad bug 220805 in base-installer "when selecting "only free software", I get restricted from the original CD and for -security" [Medium,Fix committed] https://launchpad.net/bugs/220805 [07:26] dholbach, oh, thanks for letting me know, will check this in a bit [07:26] thekorn: http://paste.ubuntu.com/20548/ :-) [07:27] * dholbach hugs thekorn :) === hunger_t is now known as hunger [07:28] looks like a bad start in this day [07:28] thekorn: nah... apart from that the new text connector seems to work fine :) [07:29] thekorn: as always top-notch work from you! [07:30] <\sh> moins [07:30] <\sh> thekorn: the start in this day is great..when I see our bzr commits ;) [07:30] <\sh> rainct rockt da house [07:31] dholbach, hehe, thanks for motivating me [07:31] \sh, morgen [07:31] <\sh> thekorn: guten morgen :) [07:34] <\sh> damn...I have to catch up with the gtk guys [07:35] <\sh> they did awesome work last night [07:36] \sh: You probably should wait for the LP API. [07:38] <\sh> wgrant: well...to change the backend is not a problem :) [07:38] \sh: True, true [07:38] The API will hopefully make it much faster. === tkamppeter_ is now known as tkamppeter [07:38] <\sh> the point is to get this project started...and it's awesome to see how it evolves in only 4 days :) [07:39] if the project is only read-only the text connector is the way to go [07:41] <\sh> dholbach: it won't :) whatever thekorn is giving us, we'll implement it :) [07:42] is this eventually intended to make a full out replacement LP interface from a custom GTK app? [07:42] dholbach, rev 99 fixes bug.summary and bug.reporter [07:42] thekorn: ROCK! [07:42] * dholbach hugs thekorn [07:42] * thekorn hugs dholbach [07:43] I'll be interested to see how the official LP Python lib will compare to p-lp-b. [07:43] me too [07:44] It would be nice if they released an API at some point so we could poke holes into it first. [07:44] Er, the Python API. [07:44] Before the whole thing's actually released. [08:43] pitti: Hi, can you look at the buildlog for openocd? http://launchpadlibrarian.net/15228528/buildlog_ubuntu-intrepid-amd64.openocd_0.0%2Br655-1_FAILEDTOBUILD.txt.gz [08:43] pkg-create-dbgsym fails with "objcopy: Unable to recognise the format of the input file `./usr/lib/openocd/ecos/at91eb40a.elf' [08:43] debian/openocd/usr/lib/openocd/ecos/at91eb40a.elf: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped [08:44] should pkg-create-dbgsym skip unrecognized files or do I need to add a -X at91eb40a.elf to the dh_strip call? [08:45] pitti: OK, I'll just give it a spin here [08:45] morning [08:46] geser: it uses -X invalidly [08:47] geser: -X doesn't take a glob, it takes a substring [08:49] oh, overlooked it. Thanks, will fix the package then. [08:49] geser: I wonder how that builds in Debian [08:50] foreach my $f (@{$dh{EXCLUDE}}) { [08:50] return if ($fn=~m/\Q$f\E/); [08:50] } [08:50] that doesn't work with globs either [08:52] seb128: no intrepid copy love for you in bug 230998; is that fixed upstream in 2.23 already? [08:52] Launchpad bug 230998 in evolution "evolution leaves deleted messages strike through" [Low,Fix committed] https://launchpad.net/bugs/230998 [08:53] thekorn: rev99 works NICEly :) [08:55] phew [08:56] seb128: same question for bug 211604 [08:56] Launchpad bug 211604 in gnome-applets "trash icon disappears in panel" [Low,Fix committed] https://launchpad.net/bugs/211604 [09:00] pitti: no an dno [09:00] no and no [09:01] pitti: will be fixed when next versions are available which should be today [09:01] seb128: just got some insight into bug #209520, and sent a follow-up just now [09:01] Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] https://launchpad.net/bugs/209520 [09:01] seb128: ok, great; thanks [09:01] slangasek: ah, nice ;-) [09:02] seb128: basically, any server that's security=share can only use weak password authentication, which we deliberately disabled in samba for hardy; slightly ahead of upstream, but on the grounds that upstream will do the same in samba 3.2 and it would be unfortunate to have vulnerable default settings for the life of hardy [09:02] slangasek: oh, so those are non supported configs? [09:03] well, that's /my/ position on it with my samba hat on, but I'm willing to be persuaded [09:03] I think nautilus/gvfs needs some fixing there regardless [09:03] but that's not necessarily 8.04.1 material [09:03] right [09:03] and if there's a sense that enabling the weak client auth is the lesser evil, then that's a quick fix [09:03] but seeing the number of people concerned by the issue I'm not sure what the right fix would be [09:03] out of letting them using their config ... [09:04] slangasek: any particular reason why security=share isn't then just disabled? [09:04] Mithrandir: it's a server setting; the servers are not hardy servers, AFAICS [09:04] Mithrandir: i.e., there are corresponding defaults on the server side which someone would have to override to get a hardy server in security=share mode [09:05] slangasek: oh, ok, so you're talking about the client. Ack. [09:05] yeppers [09:05] and when the client is nautilus+gvfs, the user gets no feedback about why it failed... :) === mdz_ is now known as mdz [09:13] soren: the virt-manager bugs of the hardy-updates version are still open in intrepid; can you please apply the fixes to intrepid, too, and upload? [09:13] anyway, with that bug triaged, I'm off to bed [09:14] slangasek: thanks for your work on that, good to have a clue about the issue [09:14] I'm not convinced yet that making those connection fail on purpose is a good idea though [09:14] seb128: n/p. feel free to discuss with pitti and whoever else about whether we should relax this setting for hardy [09:14] but I don't really have an idea about the number of broken configuration which are around [09:14] will do [09:14] and I'll catch up in the morning :) [09:15] * pitti <- no clue about samba :( [09:15] pitti: oh, well, most of what you need to know can be learned from scrollback + the last comments in the bug log ;) [09:16] pitti: read the current comment on https://launchpad.net/bugs/209520 and tell me what your gut feeling is about this option ;-) [09:16] pitti: the only missing piece is "how easy is it to break this password mechanism?" [09:16] Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] [09:19] seb128: my gut feeling is that there should be a dialog box which explains the issue, instead of silently failing; WDYT? [09:19] pitti: right, that's for sure [09:20] oh I agree, but I'm not sure that we get a proper feedback channel from libsmbclient for this :/ [09:20] pitti: the question is rather to know if it should fail or not by default [09:20] so AFAICS it affects servers which are either still running win98, or badly configured samba, right? [09:21] I'm not sure how many users know that those are "badly configured" [09:21] IMHO disabling LANMAN by default makes sense; if it gets explained properly, then these servers can be reconfigured [09:21] ie, how many users have a similar config on a local network which worked until now and breaks in hardy [09:21] did previous Ubuntu releases configure samba with LANMAN by default? [09:22] dunno but it was not restricting access to those [09:22] i. e. will default hardy client fail to connect to default gutsy/dapper samba server? [09:22] pitti: not all of them. Win9x "servers" aren't capable of doing anything stronger than Lanman; likewise, any ancient Unix NASen based on Samba 2.x [09:22] pitti: previous Ubuntu releases allowed lanman by default [09:23] I would argue that we should still allow those [09:23] slangasek: right, but I mean s/allowed/& only/ [09:23] we will not fix the world by confusing users who try to use broken servers [09:23] servers they can use from other distros and gutsy [09:24] pitti: uh... sorry, I think we're talking past each other, none of the lines of yours I was replying to had "allowed" in them and I'm now a little lost :) [09:24] I should probably just go to bed ;) [09:24] we just get bad press than hardy can't connect to working servers at the moment where other distro can, admitelly that would be better if nautilus was displaying a proper error but I'm still not sure it would make those users happy [09:24] especially that often users don't have control over the servers they are trying to use [09:24] slangasek: I meant: if I apt-get install samba on dapper on server A, and install hardy on client B, will B fail to connect to A? [09:24] i. e. what's the default setting in dapper? [09:25] seb128: note that agreeing to negotiate lanman auth exposes the user to a security risk, which is more of a problem than just not wanting random servers to not use weak auth... [09:25] seb128: I tend to agree (FSVO "working server" :) ) [09:25] with the current explanation, these servers are not really working flawlessly, AFAIUI? (because they are a password stealing trap) [09:26] pitti: I would have to check where in the history dapper's version of samba falls, but I believe that it should do encrypted passwords by default, and therefore work ok with hardy clients [09:26] slangasek: I would argue that it depends of the context [09:26] slangasek: people having 3 boxes on a local lan probably don't care about that, they just want their nas and server working as they used to [09:27] but in corporate environments you might want better security [09:28] pitti: encrypted passwords are enabled by default in dapper, so hardy clients are perfectly compatible [09:28] slangasek: right, that was my primary concern; i. e. does it fail OOTB, or do you need to manually (mis-)configure it to fail [09:28] seb128: well, I definitely disagree, but I recuse myself from this decision because I implemented this change in defaults myself with my maintainer hat on :) [09:29] seb128: in this case I still lean towards a better error message; people with broken ancient NASes can still change smb.conf to re-enable LANMAN again [09:30] slangasek: anyway no hurry, I'll speak with some other people about it to collect opinions, you should go to bed ;-) [09:30] and with modern Windows and supported distros it shouldn't be a problem either? [09:30] right, 'night folks :-) [09:30] slangasek: sleep well! thanks [09:30] night slangasek [09:30] and thank you for your work on the issue ;-) [09:31] pitti: right, it just means new strings and it's not clear than libsmbclient has an api which makes it easy to know that the issue is due to this [09:31] pitti: ie, might not be easy to sru in hardy [09:32] right; might be necessary to grep it out of the log, or so? [09:32] but I can't believe that it has such a poor error reporting API? [09:32] pitti: not sure, I'm not a samba guy, now that we know what the issue is I'll try to have a look though [09:33] mvo: can you please apply bug 184238 to intrepid? [09:33] Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,In progress] https://launchpad.net/bugs/184238 [09:33] pitti: sure [09:37] pitti: its already fixed, forgot to update the bug :( [09:37] mvo: I didn't see it in the changelog; thanks [09:37] my bad, it was fixed upstream [09:37] and I forgot to add that to the changelog [09:37] when I did the merge [09:38] doko_: is bug 211309 actually an issue in sun-java{5,6}? If not, can the tasks be closed? [09:38] Launchpad bug 211309 in icedtea-gcjwebplugin "[hardy] Java plugin not registered in Firefox 2" [Undecided,Fix committed] https://launchpad.net/bugs/211309 [09:54] soren: same for virtinst (bug 221746) [09:54] Launchpad bug 221746 in virtinst "Assigning storage space fails if acceleration enabled" [High,Fix committed] https://launchpad.net/bugs/221746 === elkbuntu` is now known as elkbuntu [10:05] pitti: we dont forward bugs that are incomplete :) [10:05] jcastro: ^^ [10:06] asac: sometimes they become incomplete after forwarding [10:06] (happens to me quite often, at least); i. e. upstream needs further info, etc. [10:06] pitti: well ... that discussion is usually done in upstream tracker, but the ubuntu task is mostly static after that point [10:06] e.g. the upstream task would be "incomplete", while the ubuntu one stays at whatever state it was before [10:08] makes sense or are you always changing the ubuntu task as well in-sync with the upstream status? [10:09] If upstream needs information and the person coordinating the bug doesn't have it, using the Ubuntu bug to ask for it (and setting "Incomplete") makes sense. [10:12] persia: point is that the ubuntu task is used to determine whether a bug was forwarded upstream in the +upstreamreport [10:12] persia: i dont think that using the ubuntu task is a reliable way to determine that ... better look at the upstream status (e.g. is upstream bug "incomplete", "confirmed" or whatever) [10:12] asac: better to look if there is an upstream watch available [10:13] the status is not revelant there [10:13] seb128: right. thats what i mean [10:13] seb128: yeah, but still the [10:13] +upstreamreport currently only uses Triaged ;) [10:13] everything else is forgotten about [10:13] I know, most of the GNOME stats are broken due to that [10:13] https://edge.launchpad.net/ubuntu/+upstreamreport [10:13] seb128: well ... at least you are using Triaged for forwarded bugs ... which i am not ;) [10:13] because we have lot of confirmed bugs forwarded from the time before triaged [10:13] seb128: so you are far better off atm :) [10:14] right ;-) [10:14] seb128: right. in the past mozillateam moved forwarded bugs that were on track upstream to "in progress" :) [10:15] jcastro: so read above: just use the watch count for open bugs to get the right count for forwarded bugs [10:24] hello all, i have a heavily modified system of ubuntu that i want to make bootable from a livecd. is that possible in any way? === fabio is now known as kinio [11:10] Riddell: is bug 194474 still an issue in intrepid? [11:10] Launchpad bug 194474 in kdebase "[hardy] kded in loop (100%CPU) when using 'mount automatically'" [Undecided,In progress] https://launchpad.net/bugs/194474 [11:17] pitti: no, intrepid uses kde 4 so different codebase [11:17] Riddell: thanks === chand is now known as _r1__ === _r1__ is now known as chand [11:47] tkamppeter: is bug 219999 an issue in intrepid? if 4.0 fixes it, pleaes close the task [11:48] Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix released] https://launchpad.net/bugs/219999 [11:55] asac: can you please upload epiphany-browser 2.22 to intrepid? (bug 236116); I can copy-package epy-extensions, but e-browser differs in hardy and intrepid [11:55] Launchpad bug 236116 in epiphany-browser "new upstream 2.22.2 release" [Undecided,In progress] https://launchpad.net/bugs/236116 [11:56] good morning [12:03] hey zul [12:05] pitti: ok looking === chand is now known as chand[aw] === ryu2 is now known as ryu [12:40] pitti: do you have a dhcp3 merge in progress? I need it to build d-i [12:41] cjwatson: only as far as "need to get to it RSN", if SRUs ever leave me some time :) [12:41] cjwatson: I just finished SRUs, though [12:41] so I can get to it after lunch [12:41] cjwatson: oh, we need 3.1 for d-i now? [12:42] yeah, netcfg's dhclient-script got merged into dhcp3-client-udeb so now netcfg requires the version where it was merged [12:42] cjwatson: ok, thanks for the poke; queued for the afteroon [12:42] afternoon, too [12:43] pitti: thanks, appreciated === _max_ is now known as Guest96354 [13:34] doko: It look likely that pyogg can be sync'ed now. Do you mind if I look after it (you touched it last)? [13:34] look/looks [13:35] ScottK, not at all. thanks for doing that [13:35] No problem. === persia_ is now known as persia === chand[aw] is now known as chand [13:52] asac: so in your opinion it should be counting watches, not a certain status? [13:53] Maybe count != (Invalid | Won't Fix)? [13:54] persia: that sounds reasonable to me [13:56] jcastro: what the status changes to the fact that there is an upstream bug corresponding to the launchpad one? [13:56] I don't understand your question === Tonio__ is now known as Tonio_ [13:59] jcastro: why should the status do a difference there? [13:59] jcastro: i think what matters for upstream is an absolute number. not something that measures the ratio [14:00] seb128: that's just what we started with. [14:00] I think keeping track of the watches themselves makes more sense though [14:00] ok, cool [14:00] asac: well, I think having a ratio is a good thing to track as well [14:00] asac: we know that number will never be 100% [14:01] seb128: the report is still very much alpha, which is why I want to make sure we're measuring what you guys are doing [14:01] and adjusting the report accordingly [14:02] it shouldn't be "your numbers look weird, you are doing something wrong," [14:02] it should be "your numbers look weird, are we measuring the right thing?" [14:03] jcastro: right, and the reply is that you are not, we have hundred of GNOME bugs forwarded upstream which are "confirmed" because they have been sent upstream when launchpad had no triaged for example [14:03] yep [14:04] when I try to merge fbreader from sid, I found it build-deps on a package dosen't exist in ubuntu, so what the workflow for such a case, btw, fbreader is in main [14:04] freeflying_: On which package does it depend? [14:05] jcastro: sorry. reconnect [14:05] persia: liblinebreak-dev [14:06] freeflying_: https://launchpad.net/ubuntu/+source/liblinebreak ? [14:06] asac_: http://paste2.org/p/39840 [14:07] jcastro: right [14:07] freeflying_: Alternately https://launchpad.net/ubuntu/intrepid/+package/liblinebreak-dev or https://launchpad.net/ubuntu/+source/liblinebreak/0.9.6-5 [14:07] It probably needs a MainInclusionReport for the merge [14:07] jcastro: anyway, i think the problem with the ratio is that its hard to tell for sure what bugs should be forwarded. especially since we have no real common usage of bug statusses [14:08] persia: wired, my latest intrepid chroot can't find it [14:08] stati ;) [14:08] asac_: yeah each team does it different. [14:08] asac_: that's the reason I sent you guys that mail [14:09] freeflying_: it's in universe only: things in main need to build against main, which is likely the issue you see. [14:10] persia: thanks for clarify this for me :) [14:10] jcastro: to who did you send mails? [14:11] seb128: calc and asac so far, since their packages showed up obviously wrong in the report. [14:11] jcastro: ok, just checking if I should have received a mail or not [14:12] jcastro: ok. i think the ratio watch vs. upstream task without watch could be used as something that would fit in our new bug workflow [14:12] seb128: I am planning on bugging you guys as a group during the sprint [14:12] alright [14:12] seb128: your columns are still mostly green so I'm going after the ones that look bad first. :) [14:13] jcastro: right but the numbers are far to be as good as they should :-p [14:13] seb128: right. [14:13] since half of the forwarded bugs are "confirmed" and not counted ;-) [14:13] yeah [14:13] the thing is that kiko wants confirmed to go away and is specifically measuring triaged instead [14:13] but that's a different argument, heh [14:15] jcastro: the ubuntu state makes no sense. how about what i just proposed: compare upstream task without watch with upstream task with watch? [14:15] according to launchpad "advanced search" adding an empty upstream task is similar to expressing that this needs to be forwarded [14:15] asac_: yeah I have that down here in my notes to ask kiko about it (he actually implements the report) [14:16] jcastro: ok cool [14:17] asac_: almost nobody is bothering adding empty upstream tasks for the bugs that need to be forwarded though [14:17] seb128: well. thats the official mean to express that though :) ... so if there is something you can use to measure that then its that [14:17] seb128: and i will try to make more use of that in future [14:18] I would rather like a setting the other way [14:18] because 99% of the GNOME bugs we receive are upstream one [14:18] seb128: which way? [14:18] and I would prefer to flag 1% as distro bugs rather than 99% as upstream bugs [14:19] default to "this is a bug in the software" [14:19] seb128: so you want to have an empty upstream task opened by default? [14:19] and having a way to express the bug is rather an ubuntu one [14:19] not sure if the empty upstream task is the right semantic there [14:19] but yeah, I would like to have things considered as upstream issues by default [14:19] seb128: you could do your "flag 1% as distro" by setting the empty upstream task to "invalid" [14:19] but that's what they are most of the time [14:19] right [14:20] that's an interesting way to look at it [14:21] jcastro: we are a distribution so ideally we just distribute upstream code and have no ubuntu specific issues ;-) [14:22] yep [14:22] OTOH it doesn't take so many packaging bugs forwarded upstream before we lose credibility. [14:22] well, the people forwarding the bug would be the same person who is doing it now [14:23] ScottK: why would that happen if we add an empty upstream task by default? [14:23] why would that happen more frequently ? [14:23] Just saying that we need to be thoughtful about shipping all bugs upstream. [14:23] nobody speak about doing that [14:24] OK. That's how I read "I would like to have things considered as upstream issues by default". [14:24] Nevermind then. [14:24] ScottK: he means an empty task thing on launchpad [14:24] Ah. [14:24] that would be rather a workflow change [14:25] ScottK: though, we've had brainstorming sessions on how to make it easier to file bugs in an upstream bugzilla and yes, it can be scary sounding [14:25] rather than having to open empty upstream tasks for all the bugs you would just have to reject some for bugs which are distro specific [14:25] well, we have to ensure that triagers really know that you are not supposed to forward anything that is incomplete [14:25] ^^^^ [14:26] ideally only triaged bugs should be forwarded anyway [14:26] and by the time they are triaged the upstream task should be closed if that's a distro specific bug [14:26] seb128: so we could auto create empty upstream task once a bug goes to triaged \o/ [14:26] asac_: but you said you're not using triaged [14:27] would work for me if you have a box saying "distro bug" [14:27] jcastro: thats a historical thing [14:28] jcastro: i dont want to do two things just to indicate that a bug is ready to go up [14:28] asac_: afaik confirmed is eventually going away right? [14:28] so either set to triaged, or use launchpad upstream task. i use launchpad upstream task :) [14:28] jcastro: why should it? [14:28] because thats what the advanced search page suggests imo [14:28] seb128: dunno, that's what kiko wants [14:29] he's the one who insisted to adding the extra confirmed and triaged thing in the first place no? [14:29] seb128: clearly there needs to be some kind of discussion because I haven't gotten any solid yes or no answer from anyone [14:29] alright [14:30] I'll bring it up to heno because if they are getting rid of triaged then it might make sense to do it sooner rather than later in the cycle === asac_ is now known as asac [14:31] zul: hm, the apache merge log is confusing; it doesn't list the remaining changes from Debian, but the changes in that upload [14:32] zul: do we still actually have a delta? AFAIR, infinity and Mithrandir went to great effort to synchronize the package in hardy [14:32] (gutsy and feisty, too) [14:33] pitti: no we dont, I should have synced it [14:38] who can have a look of this bug #239069 [14:38] #239069 [14:40] The bot is currently undergoing a server upgrade ;) [14:40] hi everybody [14:42] i'm a beginner here.. can someone tell me how team channel are different from support ones? [14:44] its really a security relate bug [14:46] masood: Ubuntu doesnt come together magically, these channels are here for planning, bug fixing and development discussion to go on :) === devfil_ is now known as devfil [14:46] freeflying_: how is that a security issue? [14:47] pitti: just wonder :) [14:47] pici: i figured that out a while ago, I'm just not sure in which channel should I ask my question :D [14:48] masood: Well, I'd start in #ubuntu and hope they point you in the right direction :) [14:48] LP:239069 has become a rather high profile issue in the Chinese GNU/Linux community. [14:48] Or rather, controversial issue. [14:49] BenC1, Hi! [14:49] It started here: http://bbs.chinaunix.net/viewthread.php?tid=1154718 [14:50] foka: no one can read Chinese here, besides you and me :) [14:50] A local developer (of a local Chinese distribution) began complaining that there are too many blind fans/sheep of Ubuntu === BenC1 is now known as BenC [14:51] freeflying_, Right, but just to offer some perspective. [14:51] pici: k. thanks for the help ;) [14:51] I guess there are indeed some over-zealous Chinese Ubuntu fans, which is both good and bad... [14:51] foka: lets forget the qurrel, come back to the bug itself :) [14:52] Anyhow, that certain developer (cjacker) noticed that bug as a proof to those "mindless Ubuntu fans" that Ubuntu core isn't as good as it seems, and claiming that this bug is worse than a kernel panic. [14:52] foka: hey [14:53] freeflying_, You're right, but just again, I'm offering more background info as to why it may be good PR to investigate this bug and get it fixed ASAP. [14:53] freeflying_ is right in saying "let's forget about the quarrel and focus on the bug itself" though. [14:54] pitti, I have closed bug 219999 now. Thanks for remombering me. [14:54] tkamppeter: thanks [14:55] But it is a somewhat perplexing and evasive bug, as not all people can reproduce it yet. [14:56] A small bit of information that isn't reflected in the Launchpad bug report yet: cjacker mentions it could be related to a particular version of libc6 and bash and wtmp/utmp, i.e. hinting an upstream issue. (though cjacker's main point is that Ubuntu's QA is slightly insufficient) [14:56] Launchpad bug 219999 in foomatic-filters "[Hardy SRU request] foomatic-rip does not handle enumerated-choice options with choices "True" and "False" correctly, leading to Duplex on most Ricoh printers not working" [High,Fix released] https://launchpad.net/bugs/219999 [14:56] Let me try to go through the Chinese discussion more thoroughly and try to pick out more technical info. [15:05] pitti: hey, i had another idea, wrt to ecryptfs and mounting/unmounting [15:07] hi kirkland`; oh? [15:08] pitti: another option would be to create a group for ecryptfs users (say, ecryptfs), and allow those users sudo access to mount and unmount commands? or do you think that would give too much access to those two commands? [15:09] kirkland`: we are currently trying to abolish all groups which control device/privilege access, so I don't like this at all [15:09] pitti: gotcha, okay [15:09] kirkland`: apart from this, unlimited mount == root [15:09] pitti: okay, i'll work on the custom unmount more today [15:10] kirkland`: thus, you could just as well work as root in the first place === stdin_ is now known as stdin === radio|work` is now known as brandon|work` [15:34] ogra: do you still remember dhcp3's revert-next-server.dpatch patch? what is it good for? the code changed in 3.1.1, so the patch doesn't apply any more [15:35] i can take a look [15:35] ogra: I guess it broke LTSP somehow? [15:35] it breaks old ltsp configs and is totally useless for standalone servers [15:35] ogra: I would disable it for now (for the merge), is that ok for you? [15:36] sure, i can merge it back in later [15:36] lets get that CD out :) [15:36] or, rather, develop a new patch (this time with upstream preferably) [15:36] upstream refuses to take that change [15:36] we had long discussions [15:36] its already over 2 years old [15:48] jcastro: do you rememer ColinCharlesQueue [15:48] remember [15:52] jsgotangco: yeah, he was in sydney [15:53] jcastro: yeah he's currently in Manila and meeting up with him tomorrow. I think Sun/MySQL has an event here heh, just wondering if you still remember him [15:54] jsgotangco: yeah, say hi for me please. [15:54] jsgotangco: he was one of the editors that you had to have approve your spec to get it past the Drafting stage [15:54] * jcastro remembers that not being very fun. :p [15:55] lol yeah [15:55] old skool [16:07] pitti, since you sponsored last merge, any chance to look at scons (bug #226783) ? Current version causes some FTBFS with some packages in the archives. [16:07] Launchpad bug 226783 in scons "Merge scons 0.98.5-1 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/226783 [16:09] DktrKranz: not right now, but later/tomorrow; I assigned it to me [16:10] pitti: thanks. [16:19] Hi! I will be attending an install party the 5th of July, that was organised thinking that 8.04.1 will be out by then (it was planned 3rd july on hardy release schedule). Now on intrepid schedule I see it will be at the soonest the 10th. Will there be a stable release candidate out by then? Stable enough to install it on user machines? [16:19] If not we will make our own .iso simply out of an up-to-date hardy... but I was wondering if we could not already install the 8.04.1rc... [16:22] The schedule says July 3rd [16:23] Kl4m: that's what I thought too, when someone pointed out to me that this one said july 10th... https://wiki.ubuntu.com/IntrepidReleaseSchedule [16:26] Hmm https://wiki.ubuntu.com/HardyReleaseSchedule says 3 [16:26] jupp [16:27] you see we're wondering what to do, if it will be out by july 5th or not.... [16:29] if it will, then no problem, if not, then my question is: will there be a stable rc? or do you think it is safe to use a working daily build? or just modify an iso to make it up-to-date? [16:32] I would expect that daily builds would be safe to use by then, even if 8.04.1 isn't out [16:32] it would likely be waiting for testing and certification to complete [16:33] you won't gain much by building your own, and that's more likely to create problems than not, I expect [16:39] back, sorry, the internet connection is bad here :( last phrase I got was " you won't gain much by building your own, and that's more likely to create problems than not, I expect" [16:39] thanks for the info [16:39] we already did this for a previous install party and it worked out great, but it sure would be easier to use .1 directly... === pep` is now known as pep [16:39] <_MMA_> pep: That was the last message from cwatson. [16:40] thank you! [16:42] do you think the intrepid release schedule ismore trustworthy? or rather the hardy one? because I am preparing an email to the LUG to inform them of this problem we might have.. === Mirv_ is now known as Mirv [16:52] Who must I contact or where must I ask to have the best possible opinion about the release of 8.04.1 ? [16:53] pep: preferably, don't ask every ten minutes ;-) [16:54] pep: at least the end of the intrepid release schedule is rock-solid, but early milestones are always fluid depending on what can be made to work [16:54] ah no, I'm just wondering if there is a channel dedicated to the development of hardy LTS... [16:54] you are in it [16:54] ok ;) [16:54] of course it's also dedicated to other things [16:55] then I can safely assume and tell my LUG that it will not be out by 5th July I suppose. Thank you ;) [16:55] huh? when did I say that? [16:55] oh, ok... so it's not sure... [16:55] IF it is not out by 5th July, it will likely just be waiting for testing to complete [16:56] but the current schedule has it due to release on 3rd July [16:56] Ah, ok thank you, that was what I wanted to know, which schedule to trust. [16:56] there is only one relevant schedule ... [16:57] you definitely don't want to use an early milestone of intrepid for widespread installation [16:57] ok :) [16:57] it's meant for experienced testers only at this stage [16:57] (and developers, obviously) [16:57] hehe, yes I understand [17:02] ogra: ah, ignore me; it still applies [17:15] thanks for the advice, have a nice day. [17:25] Riddell: what package has dcopidl nowdays with kde4? [17:33] asac: I have had no reply to my comment on the gnome-mplayer ITP (dbug 415381). How do you want to proceed? [17:34] norsetto: just upload ;) [17:34]