| === nixternal_ is now known as nixternal | ||
| Baron1984 | http://ubuntuforums.org/showthread.php?p=5194590#post5194590 | 03:05 |
|---|---|---|
| pitti | Good morning | 06:15 |
| ion_ | Hi | 06:16 |
| Hobbsee | pitti! | 06:17 |
| TheMuso | Morning pitti. | 06:31 |
| dholbach | good morning | 06:39 |
| === dholbach_ is now known as dholbach | ||
| pitti | zul: yay, Debian accepted all our openvpn patches; yay bug/patch forwarding, we can sync :) | 06:58 |
| ion_ | Whee | 06:59 |
| dholbach | hey thekorn | 07:23 |
| thekorn | good morning dholbach | 07:24 |
| dholbach | thekorn: with the new /+text parser bug summaries just contain one character :-) | 07:24 |
| pitti | cjwatson: Good morning | 07:25 |
| pitti | cjwatson: if you have a moment, your input in bug 220805 would be appreciated | 07:25 |
| ubottu | 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:25 |
| thekorn | dholbach, oh, thanks for letting me know, will check this in a bit | 07:26 |
| dholbach | thekorn: http://paste.ubuntu.com/20548/ :-) | 07:26 |
| * dholbach hugs thekorn :) | 07:27 | |
| === hunger_t is now known as hunger | ||
| thekorn | looks like a bad start in this day | 07:28 |
| dholbach | thekorn: nah... apart from that the new text connector seems to work fine :) | 07:28 |
| dholbach | thekorn: as always top-notch work from you! | 07:29 |
| \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:30 |
| thekorn | dholbach, hehe, thanks for motivating me | 07:31 |
| thekorn | \sh, morgen | 07:31 |
| \sh | thekorn: guten morgen :) | 07:31 |
| \sh | damn...I have to catch up with the gtk guys | 07:34 |
| \sh | they did awesome work last night | 07:35 |
| wgrant | \sh: You probably should wait for the LP API. | 07:36 |
| \sh | wgrant: well...to change the backend is not a problem :) | 07:38 |
| wgrant | \sh: True, true | 07:38 |
| wgrant | The API will hopefully make it much faster. | 07:38 |
| === tkamppeter_ is now known as tkamppeter | ||
| \sh | the point is to get this project started...and it's awesome to see how it evolves in only 4 days :) | 07:38 |
| dholbach | if the project is only read-only the text connector is the way to go | 07:39 |
| \sh | dholbach: it won't :) whatever thekorn is giving us, we'll implement it :) | 07:41 |
| superm1 | is this eventually intended to make a full out replacement LP interface from a custom GTK app? | 07:42 |
| thekorn | dholbach, rev 99 fixes bug.summary and bug.reporter | 07:42 |
| dholbach | thekorn: ROCK! | 07:42 |
| * dholbach hugs thekorn | 07:42 | |
| * thekorn hugs dholbach | 07:42 | |
| wgrant | I'll be interested to see how the official LP Python lib will compare to p-lp-b. | 07:43 |
| thekorn | me too | 07:43 |
| wgrant | It would be nice if they released an API at some point so we could poke holes into it first. | 07:44 |
| wgrant | Er, the Python API. | 07:44 |
| wgrant | Before the whole thing's actually released. | 07:44 |
| geser | 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 |
| geser | pkg-create-dbgsym fails with "objcopy: Unable to recognise the format of the input file `./usr/lib/openocd/ecos/at91eb40a.elf' | 08:43 |
| geser | debian/openocd/usr/lib/openocd/ecos/at91eb40a.elf: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped | 08:43 |
| geser | should pkg-create-dbgsym skip unrecognized files or do I need to add a -X at91eb40a.elf to the dh_strip call? | 08:44 |
| cjwatson | pitti: OK, I'll just give it a spin here | 08:45 |
| stgraber | morning | 08:45 |
| pitti | geser: it uses -X invalidly | 08:46 |
| pitti | geser: -X doesn't take a glob, it takes a substring | 08:47 |
| geser | oh, overlooked it. Thanks, will fix the package then. | 08:49 |
| pitti | geser: I wonder how that builds in Debian | 08:49 |
| pitti | foreach my $f (@{$dh{EXCLUDE}}) { | 08:50 |
| pitti | return if ($fn=~m/\Q$f\E/); | 08:50 |
| pitti | } | 08:50 |
| pitti | that doesn't work with globs either | 08:50 |
| pitti | seb128: no intrepid copy love for you in bug 230998; is that fixed upstream in 2.23 already? | 08:52 |
| ubottu | Launchpad bug 230998 in evolution "evolution leaves deleted messages strike through" [Low,Fix committed] https://launchpad.net/bugs/230998 | 08:52 |
| dholbach | thekorn: rev99 works NICEly :) | 08:53 |
| thekorn | phew | 08:55 |
| pitti | seb128: same question for bug 211604 | 08:56 |
| ubottu | Launchpad bug 211604 in gnome-applets "trash icon disappears in panel" [Low,Fix committed] https://launchpad.net/bugs/211604 | 08:56 |
| seb128 | pitti: no an dno | 09:00 |
| seb128 | no and no | 09:00 |
| seb128 | pitti: will be fixed when next versions are available which should be today | 09:01 |
| slangasek | seb128: just got some insight into bug #209520, and sent a follow-up just now | 09:01 |
| ubottu | 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 |
| pitti | seb128: ok, great; thanks | 09:01 |
| seb128 | slangasek: ah, nice ;-) | 09:01 |
| slangasek | 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 |
| seb128 | slangasek: oh, so those are non supported configs? | 09:02 |
| slangasek | well, that's /my/ position on it with my samba hat on, but I'm willing to be persuaded | 09:03 |
| slangasek | I think nautilus/gvfs needs some fixing there regardless | 09:03 |
| slangasek | but that's not necessarily 8.04.1 material | 09:03 |
| seb128 | right | 09:03 |
| slangasek | and if there's a sense that enabling the weak client auth is the lesser evil, then that's a quick fix | 09:03 |
| seb128 | but seeing the number of people concerned by the issue I'm not sure what the right fix would be | 09:03 |
| seb128 | out of letting them using their config ... | 09:03 |
| Mithrandir | slangasek: any particular reason why security=share isn't then just disabled? | 09:04 |
| slangasek | Mithrandir: it's a server setting; the servers are not hardy servers, AFAICS | 09:04 |
| slangasek | 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:04 |
| Mithrandir | slangasek: oh, ok, so you're talking about the client. Ack. | 09:05 |
| slangasek | yeppers | 09:05 |
| slangasek | and when the client is nautilus+gvfs, the user gets no feedback about why it failed... :) | 09:05 |
| === mdz_ is now known as mdz | ||
| pitti | 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 |
| slangasek | anyway, with that bug triaged, I'm off to bed | 09:13 |
| seb128 | slangasek: thanks for your work on that, good to have a clue about the issue | 09:14 |
| seb128 | I'm not convinced yet that making those connection fail on purpose is a good idea though | 09:14 |
| slangasek | seb128: n/p. feel free to discuss with pitti and whoever else about whether we should relax this setting for hardy | 09:14 |
| seb128 | but I don't really have an idea about the number of broken configuration which are around | 09:14 |
| seb128 | will do | 09:14 |
| slangasek | and I'll catch up in the morning :) | 09:14 |
| * pitti <- no clue about samba :( | 09:15 | |
| slangasek | pitti: oh, well, most of what you need to know can be learned from scrollback + the last comments in the bug log ;) | 09:15 |
| seb128 | pitti: read the current comment on https://launchpad.net/bugs/209520 and tell me what your gut feeling is about this option ;-) | 09:16 |
| slangasek | pitti: the only missing piece is "how easy is it to break this password mechanism?" | 09:16 |
| ubottu | Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] | 09:16 |
| pitti | seb128: my gut feeling is that there should be a dialog box which explains the issue, instead of silently failing; WDYT? | 09:19 |
| seb128 | pitti: right, that's for sure | 09:19 |
| slangasek | oh I agree, but I'm not sure that we get a proper feedback channel from libsmbclient for this :/ | 09:20 |
| seb128 | pitti: the question is rather to know if it should fail or not by default | 09:20 |
| pitti | so AFAICS it affects servers which are either still running win98, or badly configured samba, right? | 09:20 |
| seb128 | I'm not sure how many users know that those are "badly configured" | 09:21 |
| pitti | IMHO disabling LANMAN by default makes sense; if it gets explained properly, then these servers can be reconfigured | 09:21 |
| seb128 | ie, how many users have a similar config on a local network which worked until now and breaks in hardy | 09:21 |
| pitti | did previous Ubuntu releases configure samba with LANMAN by default? | 09:21 |
| seb128 | dunno but it was not restricting access to those | 09:22 |
| pitti | i. e. will default hardy client fail to connect to default gutsy/dapper samba server? | 09:22 |
| slangasek | 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 |
| slangasek | pitti: previous Ubuntu releases allowed lanman by default | 09:22 |
| seb128 | I would argue that we should still allow those | 09:23 |
| pitti | slangasek: right, but I mean s/allowed/& only/ | 09:23 |
| seb128 | we will not fix the world by confusing users who try to use broken servers | 09:23 |
| seb128 | servers they can use from other distros and gutsy | 09:23 |
| slangasek | 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 |
| slangasek | I should probably just go to bed ;) | 09:24 |
| seb128 | 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 |
| seb128 | especially that often users don't have control over the servers they are trying to use | 09:24 |
| pitti | 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 |
| pitti | i. e. what's the default setting in dapper? | 09:24 |
| slangasek | 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 |
| pitti | seb128: I tend to agree (FSVO "working server" :) ) | 09:25 |
| pitti | with the current explanation, these servers are not really working flawlessly, AFAIUI? (because they are a password stealing trap) | 09:25 |
| slangasek | 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 |
| seb128 | slangasek: I would argue that it depends of the context | 09:26 |
| seb128 | 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:26 |
| seb128 | but in corporate environments you might want better security | 09:27 |
| slangasek | pitti: encrypted passwords are enabled by default in dapper, so hardy clients are perfectly compatible | 09:28 |
| pitti | 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 |
| slangasek | 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:28 |
| pitti | 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:29 |
| seb128 | slangasek: anyway no hurry, I'll speak with some other people about it to collect opinions, you should go to bed ;-) | 09:30 |
| pitti | and with modern Windows and supported distros it shouldn't be a problem either? | 09:30 |
| slangasek | right, 'night folks :-) | 09:30 |
| pitti | slangasek: sleep well! thanks | 09:30 |
| seb128 | night slangasek | 09:30 |
| seb128 | and thank you for your work on the issue ;-) | 09:30 |
| seb128 | 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 |
| seb128 | pitti: ie, might not be easy to sru in hardy | 09:31 |
| pitti | right; might be necessary to grep it out of the log, or so? | 09:32 |
| pitti | but I can't believe that it has such a poor error reporting API? | 09:32 |
| seb128 | 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:32 |
| pitti | mvo: can you please apply bug 184238 to intrepid? | 09:33 |
| ubottu | 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 |
| mvo | pitti: sure | 09:33 |
| mvo | pitti: its already fixed, forgot to update the bug :( | 09:37 |
| pitti | mvo: I didn't see it in the changelog; thanks | 09:37 |
| mvo | my bad, it was fixed upstream | 09:37 |
| mvo | and I forgot to add that to the changelog | 09:37 |
| mvo | when I did the merge | 09:37 |
| pitti | doko_: is bug 211309 actually an issue in sun-java{5,6}? If not, can the tasks be closed? | 09:38 |
| ubottu | Launchpad bug 211309 in icedtea-gcjwebplugin "[hardy] Java plugin not registered in Firefox 2" [Undecided,Fix committed] https://launchpad.net/bugs/211309 | 09:38 |
| pitti | soren: same for virtinst (bug 221746) | 09:54 |
| ubottu | Launchpad bug 221746 in virtinst "Assigning storage space fails if acceleration enabled" [High,Fix committed] https://launchpad.net/bugs/221746 | 09:54 |
| === elkbuntu` is now known as elkbuntu | ||
| asac | pitti: we dont forward bugs that are incomplete :) | 10:05 |
| asac | jcastro: ^^ | 10:05 |
| pitti | asac: sometimes they become incomplete after forwarding | 10:06 |
| pitti | (happens to me quite often, at least); i. e. upstream needs further info, etc. | 10:06 |
| asac | pitti: well ... that discussion is usually done in upstream tracker, but the ubuntu task is mostly static after that point | 10:06 |
| asac | e.g. the upstream task would be "incomplete", while the ubuntu one stays at whatever state it was before | 10:06 |
| asac | makes sense or are you always changing the ubuntu task as well in-sync with the upstream status? | 10:08 |
| persia | 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:09 |
| asac | persia: point is that the ubuntu task is used to determine whether a bug was forwarded upstream in the +upstreamreport | 10:12 |
| asac | 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 |
| seb128 | asac: better to look if there is an upstream watch available | 10:12 |
| seb128 | the status is not revelant there | 10:13 |
| asac | seb128: right. thats what i mean | 10:13 |
| asac | seb128: yeah, but still the | 10:13 |
| asac | +upstreamreport currently only uses Triaged ;) | 10:13 |
| asac | everything else is forgotten about | 10:13 |
| seb128 | I know, most of the GNOME stats are broken due to that | 10:13 |
| asac | https://edge.launchpad.net/ubuntu/+upstreamreport | 10:13 |
| asac | seb128: well ... at least you are using Triaged for forwarded bugs ... which i am not ;) | 10:13 |
| seb128 | because we have lot of confirmed bugs forwarded from the time before triaged | 10:13 |
| asac | seb128: so you are far better off atm :) | 10:13 |
| seb128 | right ;-) | 10:14 |
| asac | seb128: right. in the past mozillateam moved forwarded bugs that were on track upstream to "in progress" :) | 10:14 |
| asac | jcastro: so read above: just use the watch count for open bugs to get the right count for forwarded bugs | 10:15 |
| guysoft42 | 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? | 10:24 |
| === fabio is now known as kinio | ||
| pitti | Riddell: is bug 194474 still an issue in intrepid? | 11:10 |
| ubottu | Launchpad bug 194474 in kdebase "[hardy] kded in loop (100%CPU) when using 'mount automatically'" [Undecided,In progress] https://launchpad.net/bugs/194474 | 11:10 |
| Riddell | pitti: no, intrepid uses kde 4 so different codebase | 11:17 |
| pitti | Riddell: thanks | 11:17 |
| === chand is now known as _r1__ | ||
| === _r1__ is now known as chand | ||
| pitti | tkamppeter: is bug 219999 an issue in intrepid? if 4.0 fixes it, pleaes close the task | 11:47 |
| ubottu | 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:48 |
| pitti | 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 |
| ubottu | Launchpad bug 236116 in epiphany-browser "new upstream 2.22.2 release" [Undecided,In progress] https://launchpad.net/bugs/236116 | 11:55 |
| zul | good morning | 11:56 |
| pitti | hey zul | 12:03 |
| asac | pitti: ok looking | 12:05 |
| === chand is now known as chand[aw] | ||
| === ryu2 is now known as ryu | ||
| cjwatson | pitti: do you have a dhcp3 merge in progress? I need it to build d-i | 12:40 |
| pitti | cjwatson: only as far as "need to get to it RSN", if SRUs ever leave me some time :) | 12:41 |
| pitti | cjwatson: I just finished SRUs, though | 12:41 |
| pitti | so I can get to it after lunch | 12:41 |
| pitti | cjwatson: oh, we need 3.1 for d-i now? | 12:41 |
| cjwatson | yeah, netcfg's dhclient-script got merged into dhcp3-client-udeb so now netcfg requires the version where it was merged | 12:42 |
| pitti | cjwatson: ok, thanks for the poke; queued for the afteroon | 12:42 |
| pitti | afternoon, too | 12:42 |
| cjwatson | pitti: thanks, appreciated | 12:43 |
| === _max_ is now known as Guest96354 | ||
| ScottK | 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 |
| ScottK | look/looks | 13:34 |
| doko | ScottK, not at all. thanks for doing that | 13:35 |
| ScottK | No problem. | 13:35 |
| === persia_ is now known as persia | ||
| === chand[aw] is now known as chand | ||
| jcastro | asac: so in your opinion it should be counting watches, not a certain status? | 13:52 |
| persia | Maybe count != (Invalid | Won't Fix)? | 13:53 |
| jcastro | persia: that sounds reasonable to me | 13:54 |
| seb128 | jcastro: what the status changes to the fact that there is an upstream bug corresponding to the launchpad one? | 13:56 |
| jcastro | I don't understand your question | 13:56 |
| === Tonio__ is now known as Tonio_ | ||
| seb128 | jcastro: why should the status do a difference there? | 13:59 |
| asac | jcastro: i think what matters for upstream is an absolute number. not something that measures the ratio | 13:59 |
| jcastro | seb128: that's just what we started with. | 14:00 |
| jcastro | I think keeping track of the watches themselves makes more sense though | 14:00 |
| seb128 | ok, cool | 14:00 |
| jcastro | asac: well, I think having a ratio is a good thing to track as well | 14:00 |
| jcastro | asac: we know that number will never be 100% | 14:00 |
| jcastro | 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 |
| jcastro | and adjusting the report accordingly | 14:01 |
| jcastro | it shouldn't be "your numbers look weird, you are doing something wrong," | 14:02 |
| jcastro | it should be "your numbers look weird, are we measuring the right thing?" | 14:02 |
| seb128 | 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 |
| jcastro | yep | 14:03 |
| freeflying_ | 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 |
| persia | freeflying_: On which package does it depend? | 14:04 |
| asac_ | jcastro: sorry. reconnect | 14:05 |
| freeflying_ | persia: liblinebreak-dev | 14:05 |
| persia | freeflying_: https://launchpad.net/ubuntu/+source/liblinebreak ? | 14:06 |
| jcastro | asac_: http://paste2.org/p/39840 | 14:06 |
| asac_ | jcastro: right | 14:07 |
| persia | freeflying_: Alternately https://launchpad.net/ubuntu/intrepid/+package/liblinebreak-dev or https://launchpad.net/ubuntu/+source/liblinebreak/0.9.6-5 | 14:07 |
| persia | It probably needs a MainInclusionReport for the merge | 14:07 |
| asac_ | 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:07 |
| freeflying_ | persia: wired, my latest intrepid chroot can't find it | 14:08 |
| asac_ | stati ;) | 14:08 |
| jcastro | asac_: yeah each team does it different. | 14:08 |
| jcastro | asac_: that's the reason I sent you guys that mail | 14:08 |
| persia | freeflying_: it's in universe only: things in main need to build against main, which is likely the issue you see. | 14:09 |
| freeflying_ | persia: thanks for clarify this for me :) | 14:10 |
| seb128 | jcastro: to who did you send mails? | 14:10 |
| jcastro | seb128: calc and asac so far, since their packages showed up obviously wrong in the report. | 14:11 |
| seb128 | jcastro: ok, just checking if I should have received a mail or not | 14:11 |
| asac_ | 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 |
| jcastro | seb128: I am planning on bugging you guys as a group during the sprint | 14:12 |
| seb128 | alright | 14:12 |
| jcastro | seb128: your columns are still mostly green so I'm going after the ones that look bad first. :) | 14:12 |
| seb128 | jcastro: right but the numbers are far to be as good as they should :-p | 14:13 |
| jcastro | seb128: right. | 14:13 |
| seb128 | since half of the forwarded bugs are "confirmed" and not counted ;-) | 14:13 |
| jcastro | yeah | 14:13 |
| jcastro | the thing is that kiko wants confirmed to go away and is specifically measuring triaged instead | 14:13 |
| jcastro | but that's a different argument, heh | 14:13 |
| asac_ | 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 |
| asac_ | according to launchpad "advanced search" adding an empty upstream task is similar to expressing that this needs to be forwarded | 14:15 |
| jcastro | asac_: yeah I have that down here in my notes to ask kiko about it (he actually implements the report) | 14:15 |
| asac_ | jcastro: ok cool | 14:16 |
| seb128 | asac_: almost nobody is bothering adding empty upstream tasks for the bugs that need to be forwarded though | 14:17 |
| asac_ | 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 |
| asac_ | seb128: and i will try to make more use of that in future | 14:17 |
| seb128 | I would rather like a setting the other way | 14:18 |
| seb128 | because 99% of the GNOME bugs we receive are upstream one | 14:18 |
| asac_ | seb128: which way? | 14:18 |
| seb128 | and I would prefer to flag 1% as distro bugs rather than 99% as upstream bugs | 14:18 |
| seb128 | default to "this is a bug in the software" | 14:19 |
| asac_ | seb128: so you want to have an empty upstream task opened by default? | 14:19 |
| seb128 | and having a way to express the bug is rather an ubuntu one | 14:19 |
| seb128 | not sure if the empty upstream task is the right semantic there | 14:19 |
| seb128 | but yeah, I would like to have things considered as upstream issues by default | 14:19 |
| asac_ | seb128: you could do your "flag 1% as distro" by setting the empty upstream task to "invalid" | 14:19 |
| seb128 | but that's what they are most of the time | 14:19 |
| seb128 | right | 14:19 |
| jcastro | that's an interesting way to look at it | 14:20 |
| seb128 | jcastro: we are a distribution so ideally we just distribute upstream code and have no ubuntu specific issues ;-) | 14:21 |
| jcastro | yep | 14:22 |
| ScottK | OTOH it doesn't take so many packaging bugs forwarded upstream before we lose credibility. | 14:22 |
| jcastro | well, the people forwarding the bug would be the same person who is doing it now | 14:22 |
| asac_ | ScottK: why would that happen if we add an empty upstream task by default? | 14:23 |
| asac_ | why would that happen more frequently ? | 14:23 |
| ScottK | Just saying that we need to be thoughtful about shipping all bugs upstream. | 14:23 |
| seb128 | nobody speak about doing that | 14:23 |
| ScottK | OK. That's how I read "I would like to have things considered as upstream issues by default". | 14:24 |
| ScottK | Nevermind then. | 14:24 |
| jcastro | ScottK: he means an empty task thing on launchpad | 14:24 |
| ScottK | Ah. | 14:24 |
| seb128 | that would be rather a workflow change | 14:24 |
| jcastro | 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 |
| seb128 | 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 |
| asac_ | well, we have to ensure that triagers really know that you are not supposed to forward anything that is incomplete | 14:25 |
| jcastro | ^^^^ | 14:25 |
| seb128 | ideally only triaged bugs should be forwarded anyway | 14:26 |
| seb128 | and by the time they are triaged the upstream task should be closed if that's a distro specific bug | 14:26 |
| asac_ | seb128: so we could auto create empty upstream task once a bug goes to triaged \o/ | 14:26 |
| jcastro | asac_: but you said you're not using triaged | 14:26 |
| seb128 | would work for me if you have a box saying "distro bug" | 14:27 |
| asac_ | jcastro: thats a historical thing | 14:27 |
| asac_ | jcastro: i dont want to do two things just to indicate that a bug is ready to go up | 14:28 |
| jcastro | asac_: afaik confirmed is eventually going away right? | 14:28 |
| asac_ | so either set to triaged, or use launchpad upstream task. i use launchpad upstream task :) | 14:28 |
| seb128 | jcastro: why should it? | 14:28 |
| asac_ | because thats what the advanced search page suggests imo | 14:28 |
| jcastro | seb128: dunno, that's what kiko wants | 14:28 |
| seb128 | he's the one who insisted to adding the extra confirmed and triaged thing in the first place no? | 14:29 |
| jcastro | 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 |
| seb128 | alright | 14:29 |
| jcastro | 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 | 14:30 |
| === asac_ is now known as asac | ||
| pitti | zul: hm, the apache merge log is confusing; it doesn't list the remaining changes from Debian, but the changes in that upload | 14:31 |
| pitti | zul: do we still actually have a delta? AFAIR, infinity and Mithrandir went to great effort to synchronize the package in hardy | 14:32 |
| pitti | (gutsy and feisty, too) | 14:32 |
| zul | pitti: no we dont, I should have synced it | 14:33 |
| freeflying_ | who can have a look of this bug #239069 | 14:38 |
| freeflying_ | #239069 | 14:38 |
| Pici | The bot is currently undergoing a server upgrade ;) | 14:40 |
| masood | hi everybody | 14:40 |
| masood | i'm a beginner here.. can someone tell me how team channel are different from support ones? | 14:42 |
| freeflying_ | its really a security relate bug | 14:44 |
| Pici | masood: Ubuntu doesnt come together magically, these channels are here for planning, bug fixing and development discussion to go on :) | 14:46 |
| === devfil_ is now known as devfil | ||
| pitti | freeflying_: how is that a security issue? | 14:46 |
| freeflying_ | pitti: just wonder :) | 14:47 |
| masood | pici: i figured that out a while ago, I'm just not sure in which channel should I ask my question :D | 14:47 |
| Pici | masood: Well, I'd start in #ubuntu and hope they point you in the right direction :) | 14:48 |
| foka | LP:239069 has become a rather high profile issue in the Chinese GNU/Linux community. | 14:48 |
| foka | Or rather, controversial issue. | 14:48 |
| foka | BenC1, Hi! | 14:49 |
| foka | It started here: http://bbs.chinaunix.net/viewthread.php?tid=1154718 | 14:49 |
| freeflying_ | foka: no one can read Chinese here, besides you and me :) | 14:50 |
| foka | A local developer (of a local Chinese distribution) began complaining that there are too many blind fans/sheep of Ubuntu | 14:50 |
| === BenC1 is now known as BenC | ||
| foka | freeflying_, Right, but just to offer some perspective. | 14:51 |
| masood | pici: k. thanks for the help ;) | 14:51 |
| foka | I guess there are indeed some over-zealous Chinese Ubuntu fans, which is both good and bad... | 14:51 |
| freeflying_ | foka: lets forget the qurrel, come back to the bug itself :) | 14:51 |
| foka | 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 |
| BenC | foka: hey | 14:52 |
| foka | 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 |
| foka | freeflying_ is right in saying "let's forget about the quarrel and focus on the bug itself" though. | 14:53 |
| tkamppeter | pitti, I have closed bug 219999 now. Thanks for remombering me. | 14:54 |
| pitti | tkamppeter: thanks | 14:54 |
| foka | But it is a somewhat perplexing and evasive bug, as not all people can reproduce it yet. | 14:55 |
| foka | 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 |
| ubottu | 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 |
| foka | Let me try to go through the Chinese discussion more thoroughly and try to pick out more technical info. | 14:56 |
| kirkland` | pitti: hey, i had another idea, wrt to ecryptfs and mounting/unmounting | 15:05 |
| pitti | hi kirkland`; oh? | 15:07 |
| kirkland` | 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:08 |
| pitti | kirkland`: we are currently trying to abolish all groups which control device/privilege access, so I don't like this at all | 15:09 |
| kirkland` | pitti: gotcha, okay | 15:09 |
| pitti | kirkland`: apart from this, unlimited mount == root | 15:09 |
| kirkland` | pitti: okay, i'll work on the custom unmount more today | 15:09 |
| pitti | kirkland`: thus, you could just as well work as root in the first place | 15:10 |
| === stdin_ is now known as stdin | ||
| === radio|work` is now known as brandon|work` | ||
| pitti | 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:34 |
| ogra | i can take a look | 15:35 |
| pitti | ogra: I guess it broke LTSP somehow? | 15:35 |
| ogra | it breaks old ltsp configs and is totally useless for standalone servers | 15:35 |
| pitti | ogra: I would disable it for now (for the merge), is that ok for you? | 15:35 |
| ogra | sure, i can merge it back in later | 15:36 |
| ogra | lets get that CD out :) | 15:36 |
| pitti | or, rather, develop a new patch (this time with upstream preferably) | 15:36 |
| ogra | upstream refuses to take that change | 15:36 |
| ogra | we had long discussions | 15:36 |
| ogra | its already over 2 years old | 15:36 |
| jsgotangco | jcastro: do you rememer ColinCharlesQueue | 15:48 |
| jsgotangco | remember | 15:48 |
| jcastro | jsgotangco: yeah, he was in sydney | 15:52 |
| jsgotangco | 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:53 |
| jcastro | jsgotangco: yeah, say hi for me please. | 15:54 |
| jcastro | 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:54 | |
| jsgotangco | lol yeah | 15:55 |
| jsgotangco | old skool | 15:55 |
| DktrKranz | 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 |
| ubottu | Launchpad bug 226783 in scons "Merge scons 0.98.5-1 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/226783 | 16:07 |
| pitti | DktrKranz: not right now, but later/tomorrow; I assigned it to me | 16:09 |
| DktrKranz | pitti: thanks. | 16:10 |
| pep | 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 |
| pep | 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:19 |
| Kl4m | The schedule says July 3rd | 16:22 |
| pep | 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:23 |
| Kl4m | Hmm https://wiki.ubuntu.com/HardyReleaseSchedule says 3 | 16:26 |
| pep | jupp | 16:26 |
| pep | you see we're wondering what to do, if it will be out by july 5th or not.... | 16:27 |
| pep | 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:29 |
| cjwatson | I would expect that daily builds would be safe to use by then, even if 8.04.1 isn't out | 16:32 |
| cjwatson | it would likely be waiting for testing and certification to complete | 16:32 |
| cjwatson | you won't gain much by building your own, and that's more likely to create problems than not, I expect | 16:33 |
| pep` | back, sorry, the internet connection is bad here :( last phrase I got was "<cjwatson> you won't gain much by building your own, and that's more likely to create problems than not, I expect" | 16:39 |
| pep` | thanks for the info | 16:39 |
| pep` | we already did this for a previous install party and it worked out great, but it sure would be easier to use .1 directly... | 16:39 |
| === pep` is now known as pep | ||
| _MMA_ | pep: That was the last message from cwatson. | 16:39 |
| pep | thank you! | 16:40 |
| pep | 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.. | 16:42 |
| === Mirv_ is now known as Mirv | ||
| pep | Who must I contact or where must I ask to have the best possible opinion about the release of 8.04.1 ? | 16:52 |
| cjwatson | pep: preferably, don't ask every ten minutes ;-) | 16:53 |
| cjwatson | 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 |
| pep | ah no, I'm just wondering if there is a channel dedicated to the development of hardy LTS... | 16:54 |
| cjwatson | you are in it | 16:54 |
| pep | ok ;) | 16:54 |
| cjwatson | of course it's also dedicated to other things | 16:54 |
| pep | then I can safely assume and tell my LUG that it will not be out by 5th July I suppose. Thank you ;) | 16:55 |
| cjwatson | huh? when did I say that? | 16:55 |
| pep | oh, ok... so it's not sure... | 16:55 |
| cjwatson | IF it is not out by 5th July, it will likely just be waiting for testing to complete | 16:55 |
| cjwatson | but the current schedule has it due to release on 3rd July | 16:56 |
| pep | Ah, ok thank you, that was what I wanted to know, which schedule to trust. | 16:56 |
| cjwatson | there is only one relevant schedule ... | 16:56 |
| cjwatson | you definitely don't want to use an early milestone of intrepid for widespread installation | 16:57 |
| pep | ok :) | 16:57 |
| cjwatson | it's meant for experienced testers only at this stage | 16:57 |
| cjwatson | (and developers, obviously) | 16:57 |
| pep | hehe, yes I understand | 16:57 |
| pitti | ogra: ah, ignore me; it still applies | 17:02 |
| pep | thanks for the advice, have a nice day. | 17:15 |
| mvo | Riddell: what package has dcopidl nowdays with kde4? | 17:25 |
| norsetto | asac: I have had no reply to my comment on the gnome-mplayer ITP (dbug 415381). How do you want to proceed? | 17:33 |
| asac | norsetto: just upload ;) | 17:34 |
| asac | norsetto: take ownership -> upload | 17:34 |
| asac | debian bug 415381 | 17:34 |
| ubottu | Debian bug 415381 in gnome-mplayer "ITP: gnome-mplayer - a simple GUI for MPlayer" [Wishlist,Open] http://bugs.debian.org/415381 | 17:34 |
| norsetto | asac: err ... upload to where? | 17:34 |
| asac | norsetto: what email do you plan to use for debian package contact? | 17:35 |
| norsetto | asac: the usual norsetto@ubuntu.com | 17:35 |
| asac | norsetto: ok i set owner to you dropping a mail that I will upload your package if we dont get a veto in a few days | 17:37 |
| norsetto | asac: ok, thx | 17:38 |
| Riddell | mvo: kde 4 doesn't use dcpo | 17:40 |
| Riddell | dcop | 17:40 |
| mvo | Riddell: aha, thanks | 17:43 |
| Riddell | jdstrand, kees: so got those MIRs scheduled in for sometime soon? | 18:11 |
| Riddell | pitti: not able to look at qca2 MIR? | 18:11 |
| pitti | still doing the dhcp3 merge requested by Colin (gosh, taking 4 hours already) | 18:12 |
| jdstrand | Riddell: I will be looking at chmlib soon yes. kees has the other one | 18:12 |
| === pwnguin__ is now known as pwnguin | ||
| calc | anyone know of a console utility that can read info from a truetype font and output info about it? | 18:19 |
| * calc used to a have a script to usefully rename ttf fonts but can't find it | 18:19 | |
| Riddell | jdstrand: what about libzip? | 18:20 |
| jdstrand | Riddell: I just saw that today-- kees or I will pick it up | 18:20 |
| slangasek | pitti: did you and seb128 get anywhere on the question of lanman client enabling? | 18:20 |
| pitti | slangasek: I think we should keep it disabled and provide a better error message, since AFAIUI it does not affect a majority of users, and in the affected cases the server should really be updated | 18:21 |
| slangasek | well, providing a better error message is a lot harder than re-enabling it would be; does that change your opinion? | 18:22 |
| slangasek | (the libsmbclient API is intended to be POSIX-like, so no extended samba error messages are available without capturing debug logs of some kind) | 18:22 |
| pitti | cjwatson: hm, I need to leave to Taekwondo soon; I'm afraid I have to continue this dhcp3 mega-merge tomorrow morning | 18:29 |
| pitti | slangasek: hm; I'm just afraid of endlessly proliferating such setups | 18:30 |
| pitti | but that's just gut feeling; I don't know much about Samba for an objective judgement | 18:31 |
| slangasek | well, due to bug #1, I'm not sure that Ubuntu is a major factor yet in whether it's practical for sites to deploy such servers :) | 18:33 |
| ubottu | Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1 | 18:33 |
| * slangasek smirks at ubottu u | 18:33 | |
| pitti | slangasek: OTOH, when we enable it, there will be no encouragement (or even knowledge) about it, so that it will stay that way forever? | 18:38 |
| slangasek | pitti: fwiw, I found the upstream thread that discusses how these default settings have been changed on the Windows side; it sounds like Vista Enterprise is even more strict than we are currently: http://lists.samba.org/archive/samba-technical/2007-February/051421.html | 18:38 |
| slangasek | pitti: well, we could leave it disabled in intrepid maybe, and hope that time takes care of things for us? :) | 18:39 |
| pitti | slangasek: I can live with that | 18:40 |
| pitti | bye everyone | 18:41 |
| === devfil is now known as totopalma_ | ||
| slangasek | pitti: ah, I need more direction than "I can live with that" :-) Do you want me to prepare a samba SRU that reverts this change? | 18:43 |
| \sh | hmm...riddell and I are missing dl.so from python2.5 on amd64... gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I../Include build/temp.linux-i686-2.5/build/buildd/python2.5-2.5.2/Modules/dlmodule.o -o build/lib.linux-i686-2.5/dl.so is missing somehow from the amd64 build :) | 18:46 |
| SynthroidMan | http://synthroid.co.uk/ | 18:47 |
| kees | Riddell: I already looked at openbabel (bug 236051) and assigned it back to you after including the results of my audit. | 19:01 |
| ubottu | Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete] https://launchpad.net/bugs/236051 | 19:01 |
| kees | Riddell: short version: I can't recommend it for main. | 19:01 |
| Riddell | kees: saw that thanks, upstream say they're looking into your comments | 19:01 |
| kees | Riddell: okay, cool. | 19:02 |
| === fta_ is now known as fta | ||
| === kirkland` is now known as kirkland | ||
| paulproteus | I'm the Debian maintainer of the alpine package, and I see this bug in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/alpine/+bug/120735 | 20:15 |
| ubottu | Launchpad bug 120735 in alpine "Alpine 0.82+dfsg-5 seg faults when attempting to view certain messages with attachments" [Undecided,New] | 20:15 |
| paulproteus | What is the right way for me to handle it? alpine is in universe, fwiw; this bug was fixed a year ago but the bug affects Ubuntu 7.04. | 20:16 |
| paulproteus | Hmm, I'm told: " You are not the bug assignee nor the maintainer of alpine (Ubuntu), and therefore cannot edit this bug's status. " | 20:18 |
| DktrKranz | paulproteus, you may want to ask for a stable release update (see https://wiki.ubuntu.com/SRU). Also, in order to edit bug status, you need to login in Launchpad. | 20:19 |
| paulproteus | I don't think it's that critical, DktrKranz. (I'll see about logging in now.) | 20:20 |
| paulproteus | Should I just leave a note telling the reporter to upgrade and mark it as invalid? | 20:20 |
| ScottK | paulproteus: It's fixed in releases later than Feisty ? | 20:21 |
| DktrKranz | You should mark it as fix released | 20:21 |
| paulproteus | ScottK, Bingo. | 20:21 |
| ScottK | paulproteus: It's as DktrKranz says then. It should be fix released. I'll mark it. | 20:22 |
| paulproteus | I'll mark it, ScottK. | 20:22 |
| paulproteus | I need the practice. (-: | 20:22 |
| ScottK | paulproteus: I already did. Sorry. | 20:22 |
| * paulproteus shrugs, I'll find another then. (-: | 20:22 | |
| DktrKranz | paulproteus, you have tree more to practice :) | 20:24 |
| paulproteus | DktrKranz, Pending feedback from the submitter. (-: | 20:26 |
| psyke83 | hi asac, can I ask you a quick question re: Firefox? I was told you've got experience with the code. I'm working with Cory on UbuntuStudio's dark theme, and I had an idea re: Firefox, but I'm not sure if it's feasible. I was wondering if it's possible to force Firefox to use native widgets only for rendering of websites (not the actual interface of Firefox such as menus, popup windows, toolbars and options windows)? | 20:27 |
| psyke83 | asac, my idea is to force Firefox to render widgets using Human-Murrine as dark widgets simply look out of place on 95% of websites, who often make bad decisions re: colour choices in style sheets, etc. | 20:28 |
| munckfish | cjwatson: hi you got a minute? | 20:55 |
| cjwatson | munckfish: sure | 20:55 |
| munckfish | I'm still trying to get the series/milestones setup on LP for PS3 | 20:55 |
| munckfish | Tiago made me Driver | 20:56 |
| munckfish | but that still hasn't given me the "Add a series" link | 20:56 |
| munckfish | do you know what's needed? | 20:56 |
| cjwatson | munckfish: should be "Register a series", https://launchpad.net/ubuntu-ps3-port/+addseries | 21:01 |
| cjwatson | blink, why did he make specifically you driver rather than a team? | 21:02 |
| munckfish | cjwatson: we were trying to work out how to give the required perms | 21:03 |
| munckfish | the doc on help.lp.net said I had to be either driver or registrant | 21:03 |
| munckfish | but seems not | 21:03 |
| munckfish | can you fix it? | 21:03 |
| munckfish | as in make the team driver instead | 21:03 |
| cjwatson | I can't fix it | 21:03 |
| cjwatson | I don't have any kind of special launchpad god-mode permissions | 21:04 |
| munckfish | cjwatson: I am forbidden to access that page | 21:04 |
| cjwatson | give me a minute, I'm checking the code (since I can at least do that) | 21:04 |
| munckfish | cjwatson: I know but I thought you had better perms than me on the project page | 21:04 |
| munckfish | cjwatson: wow insider stuff, cewl | 21:04 |
| cjwatson | don't see how, Tiago's registrant, you're driver ... | 21:04 |
| cjwatson | munckfish: Tiago should be able to do it. I think he just missed it | 21:11 |
| cjwatson | munckfish: give him the URL I gave you | 21:11 |
| cjwatson | munckfish: or else get him to make some suitable team registrant so that you can be in the registrant group too | 21:11 |
| munckfish | cjwatson: ok I'm getting some help on #launchpad now | 21:11 |
| cjwatson | adding series to products requires either "registry experts" (a special team), the registrant, or a Launchpad admin | 21:12 |
| munckfish | cjwatson: I understand | 21:12 |
| munckfish | I think the registrant should be a team in that case | 21:12 |
| cjwatson | munckfish: that is often appropriate, yes | 21:14 |
| cjwatson | please make sure a bug's filed about the documentation saying that you need to be either driver or registrant - it doesn't match the code, so one or the other is wrong | 21:14 |
| jcole | is the latest dri "enabled" in ubuntu kernels -> http://dri.freedesktop.org/wiki/Building | 21:25 |
| jcole | or does one need to follow that guide to get the latest dri | 21:25 |
| kirkland | I'm calling the umount() system call in a C program. It seems that /proc/mounts is updated properly, but not /etc/mtab ... What needs to happen such that /etc/mtab is sync'd and sees the changes? | 21:31 |
| slangasek | you need to edit /etc/mtab in your C program... :) | 21:33 |
| kirkland | slangasek: oh, seriously? | 21:33 |
| slangasek | the functions setmntent(), getmntent(), and addmntent() will help | 21:33 |
| kirkland | slangasek: cool, thanks. | 21:33 |
| slangasek | why calling umount() directly instead of via the umount program, though? | 21:33 |
| kirkland | slangasek: I need to create a setuid program to umount as a non-root user | 21:34 |
| slangasek | presumably this is an suid helper that has already done the necessary security checks, so you could safely call /bin/umount instead of umount() | 21:34 |
| kirkland | slangasek: being written from scratch, i can go any route that is recommended | 21:35 |
| kirkland | slangasek: this is back to solving last week's problem regarding pam_mount's inability to umount a filesystem on ssh logout | 21:36 |
| slangasek | kirkland: well, my assumption is that your helper has already done the necessary security checks in your helper - this assumption needs to hold true whether you call umount() or /bin/umount :) | 21:36 |
| kirkland | slangasek: seems that umount supports such "helper" programs | 21:36 |
| kirkland | slangasek: ;-) | 21:36 |
| kirkland | slangasek: but your suggestion of calling out to /bin/umount is a good one, as that would take care of /etc/mtab for me, right? | 21:37 |
| slangasek | kirkland: so, with that assumption in place, you might as well just setuid(0) and invoke /bin/umount, yes, since that will take care of all the niceties for you | 21:38 |
| slangasek | as for as umount supporting "helper" programs, those are for per-filesystem handlers | 21:38 |
| slangasek | mount/umount already know how to handle this filesystem type, right? | 21:38 |
| kirkland | slangasek: yes | 21:39 |
| slangasek | yeah - so calling /bin/umount as root for the dirty work is better | 21:39 |
| kirkland | slangasek: and "security checks"; user owns the mountpoint, perhaps a check of open fh's on that mountpoint.... anything else? | 21:39 |
| slangasek | I don't think you need to check for open fds, /bin/mount will do that for you | 21:40 |
| kirkland | slangasek: okay, good | 21:40 |
| slangasek | is there a corresponding mount wrapper? | 21:41 |
| kees | what's the method for checking mountpoint ownership? aren't those overridden by the underlying filesystems's perms? | 21:41 |
| slangasek | I'm wondering if the mtab entry for the mount should somehow record that the user in question is the one who /did/ the mounting | 21:41 |
| slangasek | kees: exactly | 21:41 |
| kirkland | slangasek: pam_mount actually works well mounting the FS, so I was just going to "fix" the unmounting with a custom unmount setuid program | 21:42 |
| kirkland | kees: i was thinking access() | 21:43 |
| kirkland | kees: well, maybe not.... | 21:43 |
| slangasek | access() will only tell you the ownership of the root node of the filesystem, not of the mountpoint | 21:44 |
| === dashua_ is now known as dashua | ||
| slangasek | i.e., in order to determine the ownership of the mountpoint, this will have to be recorded somewhere at mount time | 21:45 |
| slangasek | (with /etc/mtab being the obvious place) | 21:46 |
| kirkland | slangasek: kees: what about checking the ownership of the device? | 21:46 |
| kirkland | slangasek: kees: what we're dealing with here is mounting /home/user/.Private onto /home/user/Private | 21:47 |
| kirkland | slangasek: kees: the intention is for user:user to own both of those, permed 700 when mounted, and 500 when not mounted | 21:47 |
| slangasek | checking the ownership of the device is also race-y | 21:47 |
| slangasek | what do you do if the user *removes* /home/user/.Private, prior to unmounting? | 21:48 |
| kirkland | slangasek: hmm, well, they've hosed their underlying encrypted data in that case | 21:49 |
| slangasek | sure | 21:49 |
| slangasek | but why should that leave them unable to unmount it? :) | 21:49 |
| slangasek | actually, as long as it's mounted, they haven't hosed it because the kernel still has a reference and they'll still be able to access it... | 21:50 |
| kirkland | slangasek: well, additionally, i'd also expect that the top node of the mounted filesystem to match ownership | 21:50 |
| slangasek | but that's not an argument in support of breaking the unmount semantics IMHO :) | 21:50 |
| kirkland | slangasek: ie, a "Private" directory should only be mounted/unmounted/read/written/listed by the user owning it | 21:51 |
| slangasek | these are all heuristics that you're trying to use to answer the question, "is the mount point specified here one that was mounted as part of the user "private data" implementation?" | 21:51 |
| slangasek | the best way to answer that question without heuristics, AFAICS, is to /tag/ the mount at the time it's done, with this info | 21:51 |
| kirkland | slangasek: okay, so this is what's currently written to mtab: | 21:52 |
| kirkland | /home/kirkland/.Private.ecryptfs /home/kirkland/Private ecryptfs rw,noexec,nosuid,nodev,ecryptfs_sig=5b25c24a4bd3ed6e,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user=kirkland 0 0 | 21:52 |
| kirkland | slangasek: the user=kirkland part is there because it's currently an entry in /etc/fstab | 21:53 |
| kirkland | slangasek: and that's what currently allows me to mount/unmount as non-root user | 21:53 |
| slangasek | kees: do you know if we have any raciness involved in reading /etc/mtab? is there a standard way to lock the mtab so that we're assured to not race against a different mount being done at the same time as the unmount on the same mount point? | 21:53 |
| slangasek | kirkland: ummm, what's the "user=kirkland"? | 21:53 |
| kirkland | slangasek: pitti has suggested that i remove the dependency on reading/writing /etc/fstab | 21:53 |
| slangasek | oh, you just answered that question | 21:53 |
| slangasek | ho-hum | 21:53 |
| slangasek | :) | 21:53 |
| * kirkland types to slow for slangasek :-) | 21:54 | |
| kirkland | slangasek: i can easily keep that user=kirkland bit as part of the custom mount setup in pam_mount | 21:54 |
| kirkland | slangasek: perhaps that gets us what we need there | 21:54 |
| kees | slangasek: hmm, I don't know of any mount "lock" routines | 21:54 |
| slangasek | well, if you do *that*, I don't think you need a custom unmount wrapper at all. :) | 21:55 |
| kirkland | slangasek: right, exactly | 21:55 |
| slangasek | kirkland: so yes, I think that's by far the simplest solution :) | 21:55 |
| kirkland | slangasek: erg... can you me and pitti sit down and have a pow-wow about this? :-) | 21:55 |
| kirkland | i'm quite literally running around in circles! | 21:55 |
| kirkland | slangasek: i've been on a week-long wild goose chase trying to *not* have a script updating /etc/fstab | 21:56 |
| kirkland | and every day that goes by, that seems like the easiest solution | 21:56 |
| slangasek | kirkland: oh, I'm not suggesting updating /etc/fstab | 21:57 |
| kirkland | kees: speaking of /etc/mtab locking, what was it that we had to do for the udev/upstart bits about nfs mounts not showing up on startup? we had some lock issues to solve there | 21:57 |
| slangasek | kirkland: but I think if you add -ouser=kirkland as a mount option when mounting, it will be echoed to /etc/mtab | 21:57 |
| kirkland | slangasek: okay, i missed something | 21:57 |
| kirkland | slangasek: yup, i agree with that.... | 21:58 |
| calc | nautilus cd burner defaults not to using burnproof if available? | 21:58 |
| kirkland | slangasek: okay, so do that on mounting | 21:58 |
| * calc is looking in gconf-editor on a fresh installed system | 21:58 | |
| kirkland | slangasek: and continue with my custom umount wrapper work? | 21:58 |
| slangasek | kirkland: if you're able to pass user=kirkland into the /etc/mtab entry, I think the unmount might work as a normal user? | 21:59 |
| slangasek | maybe not, hmm | 21:59 |
| kirkland | slangasek: nope, i tried that :-( | 21:59 |
| slangasek | ok | 21:59 |
| slangasek | then I believe you want a) to get a distinguishing option into /etc/mtab at mount time, b) a custom unmount wrapper that checks this option before doing the unmount | 22:00 |
| kirkland | slangasek: i can look at the umount source code, it might just be an arbitrary /etc/fstab check.... but it does error out with "umount: /home/kirkland/Private is not in the fstab (and you are not root)" | 22:00 |
| joaopinto | kirkland, the mount man pages tells that the user option allows to mount/unmount the fs | 22:00 |
| slangasek | kirkland: right, I half-suspected that | 22:01 |
| slangasek | joaopinto: but only if the user option appears in /etc/fstab, which we're trying to avoid writing to | 22:01 |
| kirkland | slangasek: would a "fix" to umount be in order, changing that behavior? | 22:01 |
| slangasek | kirkland: no :) | 22:01 |
| joaopinto | slangasek, not really, the man refers to mtab | 22:01 |
| kirkland | slangasek: :-p | 22:01 |
| joaopinto | quoting: "The name of the mounting user is written to mtab so that he can unmount the file system again. " | 22:02 |
| kees | kirkland: that was related to handling if mtab existed yet or not | 22:02 |
| kirkland | joaopinto: what man page is that? | 22:02 |
| kees | kirkland: to check for old entries, etc | 22:03 |
| joaopinto | kirkland, man mount, user= option | 22:03 |
| kirkland | kees: oh, right... race on creation, not mulitple simultaneous editors | 22:03 |
| slangasek | joaopinto: but the username in mtab only helps if the option is also in fstab. | 22:04 |
| kirkland | joaopinto: right, perhaps that documentation could be stated more clearly | 22:04 |
| joaopinto | slangasek, well, you can pass the option from a system call mount, it doesn't need to be on the fstab | 22:04 |
| kirkland | joaopinto: but in practice, what i'm seeing is that umount will check /etc/fstab before /etc/mtab | 22:04 |
| slangasek | um, that's not the existing security model | 22:04 |
| slangasek | which should not be changed haphazardly | 22:05 |
| kirkland | slangasek: so should I recycle the user= option, or something more custom-identifiable? | 22:05 |
| slangasek | kirkland: given that the security policy for unmounting these will be explicitly different than the one built into unmount, it should have a different option name as well | 22:06 |
| kirkland | slangasek: everything else has ecryptfs_, so ecryptfs_user=kirkland then | 22:07 |
| slangasek | is ecryptfs_ the name of the tool, or the underlying fs? | 22:07 |
| kirkland | slangasek: ecryptfs is the name of the filesystem | 22:07 |
| kirkland | slangasek: ecryptfs-utils is the userspace package | 22:08 |
| kirkland | slangasek: ecryptfs-setup-confidential is the script that I'm working on to setup up the mountpoints, keys, settings, ciphers, etc. | 22:08 |
| slangasek | then I would tend to suggest an option name that's tied specifically to the implementation of this spec, rather than eating into the namespace for options related to the filesystem itself | 22:08 |
| kirkland | slangasek: umm, something more generic like mounted_by=kirkland ? | 22:09 |
| slangasek | ubuntu_private_owner=kirkland? :) | 22:10 |
| kirkland | slangasek: ah, more like that, huh.... | 22:11 |
| kirkland | slangasek: okay, so the security check now becomes a) is an ecryptfs mount, b) has ubuntu_private_owner=kirkland option | 22:12 |
| kirkland | slangasek: and i don't look at the perms of the mountpoint or the device or anything? | 22:12 |
| kirkland | slangasek: okey doke, thanks for your awesome assistance ;-) | 22:21 |
| joaopinto | hum, umount referes to the need of using an umount helper for regular users to umount fs which are not defined on fstab, so yes, there is something wrong with the mount/umount user option description | 22:24 |
| slangasek | kirkland: yep, that should do it :) | 22:29 |
| === bureflux is now known as afflux | ||
| kirkland | pitti: could you please try syncing ecryptfs-utils from Debian again when you come online? Thanks ;-) | 22:51 |
| kirkland | pitti: I'd like to see the 48-1 version pulled from Debian into Intrepid | 22:51 |
| kirkland | slangasek: regarding ubuntu_private_owner=kirkland ... to make this upstream-palatable, could I say ecrypts_private_owner=kirkland? | 23:49 |
| kirkland | slangasek: or something along those lines? | 23:49 |
| kirkland | slangasek: all of my work has been going smoothly into ecryptfs-utils upstream git | 23:50 |
| slangasek | kirkland: oh, if you think the helper tools are going to end up integrated upstream, then yeah, that would make sense | 23:50 |
| kirkland | slangasek: yeah, all of this is going upstream, cool, thanks. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!