| ScottL | ubuntu studio has been having some trouble getting an image built | 01:31 |
|---|---|---|
| ScottL | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/oneiric/daily-20110818.log | 01:31 |
| ScottL | can someone help me resolve this please? | 01:31 |
| ScottK | slangasek: It'd make me very happy if you could do the removals in Bug #794513. | 02:52 |
| ScottK | Turns out option 3 had already been asked for. | 02:52 |
| ScottK | slangasek: I think between what's in that bug, what's already NBS, and Bug #829149 it'll make a clean sweep of KDE3. | 02:58 |
| slangasek | ScottK: done | 03:17 |
| ScottK | slangasek: Thanks. | 03:17 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| === doko_ is now known as doko | ||
| scott-work | cjwatson: i was told to mention to you about a problem with the ubuntu studio image build which i believe is affecting other derivatives | 11:48 |
| scott-work | cjwatson: this is a typical problem: W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2 Hash Sum mismatch | 11:48 |
| cjwatson | I can't do anything about it except retry | 11:49 |
| scott-work | cjwatson: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/oneiric/daily-20110819.log | 11:49 |
| cjwatson | it's due to the archive sync being too slow | 11:49 |
| scott-work | ah, okay, that's surprising because it has been happening for at least three days :( | 11:49 |
| cjwatson | it's basically random | 11:49 |
| cjwatson | and it's not remotely a new issue | 11:49 |
| scott-work | okay, thank you for the infomration :) | 11:50 |
| cjwatson | I've kicked a retry; who knows, it might work | 11:50 |
| cjwatson | whenever we get the new hardware it should address this, I think | 11:50 |
| scott-work | thank you again for your time :) | 11:51 |
| cjwatson | scott-work: seems to have worked that time | 12:29 |
| scott-work | cjwatson: thank you every so much! :) | 13:06 |
| * lamont stuffs all the buildds on manual for a bit | 13:28 | |
| lamont | and the world is coming back | 14:33 |
| * highvoltage hides | 14:37 | |
| lamont | the ppa builders are either back on line or coming back online, and the chrootwait thing is fixed, dead and gone. | 14:39 |
| NCommander | lamont: thanks:-) | 14:50 |
| ogra_ | hrm | 14:51 |
| NCommander | ogra_: can you tell skaet I'm going to be a bit late for the release meeting? | 14:51 |
| lamont | ogra_: hrm, you say? | 14:51 |
| NCommander | (I shouldbe back in time, but just in case) | 14:51 |
| * ogra_ fights with PREINSTALLED_IMAGE_FILESYSTEM | 14:51 | |
| ogra_ | i somehow need to overrice the hardcoded default thats set in debian-cd based on a subarch search ... but i dont want to add additional code to debian-cd | 14:52 |
| ogra_ | overriding from cdimage code doesnt work since debian-cd always processes CONF.sh, which resets that var to default | 14:52 |
| === joshuahoover1 is now known as joshuahoover | ||
| === Ursinha` is now known as Ursula | ||
| === Ursula is now known as Ursinha | ||
| ScottK | tumbleweed: I do think we should generally approve things like dh_python2 changes as long as they've had a second set of eyes to verify their correctness. | 17:03 |
| tumbleweed | ScottK: so you don't require any justification beyond "it looks ok"? I've always regarded FF as the point where I should justify my changes | 17:09 |
| ScottK | tumbleweed: It depends on the change. For dh_python2 we've got an overall goal to switch so there's an inherent reason. | 17:10 |
| ScottK | IMO, YMMV, etc. | 17:10 |
| tumbleweed | ok in that case I can ack the one I marked as incomplete, although I would have preferred to see a build log | 17:11 |
| ScottK | I find the debc output it a lot more useful for dh_python2 changes. | 17:12 |
| tumbleweed | I mean a build log including debc :) | 17:13 |
| ScottK | Right. | 17:13 |
| tumbleweed | I want to see the Depends, and the contents, and I'd generally like to see what dh_python2 said when it ran | 17:13 |
| ScottK | Yep. | 17:13 |
| ScottK | You might just build it yourself, for fun. | 17:13 |
| tumbleweed | might as well, it's not like I don't have the time | 17:14 |
| * ScottK wonders why people think "I'm not paid to do this work" is part of a rationale for an FFe? | 19:19 | |
| nigelb | srsly? :| | 19:22 |
| * slangasek blinks | 19:27 | |
| ScottK | 829709 | 19:32 |
| elmo | wow, I can't believe I'm going to be defending kirkland and/or byobu, but... | 19:34 |
| elmo | ScottK: he didn't make it part of the rationale, it's pretty clearly in the 'Additional Info' section, not the 'Rationale' section | 19:34 |
| elmo | ScottK: not for nothing, but assuming a bit of good faith would, IMO, go a long way. when I read the bug, I don't think kirkland's put that in there in the expectation that it's going to change the outcome, rather genuinely as non-actionable/influencing background info | 19:38 |
| highvolt1ge | byoby and kirkland are both awesome and you shouldn't have to defend defending them! | 20:02 |
| === highvolt1ge is now known as highvoltage | ||
| === Ursinha` is now known as Ursinha | ||
| === Ursinha is now known as Guest59628 | ||
| * tumbleweed reads it mostly as an "I've been busy" rather than "I'm not paid" | 20:28 | |
| nigelb | Sort of equal to "dayjob has been kicking me in the gut?" | 20:30 |
| nigelb | :) | 20:30 |
| tumbleweed | well, a sorry I couldn't get to it before FF | 20:30 |
| tumbleweed | yeah | 20:30 |
| slangasek | does anyone know what has changed in the past bit (last year or so?) that changed who's able to see private bug reports against packages? | 20:54 |
| slangasek | we've just figured out mvo didn't see private bug reports filed against update-manager, and he ought to (also, apport shouldn't have filed the bugs as private, but that's a different bug) | 20:54 |
| slangasek | and I've been seeing similar behavior on pam and grub bugs, where they're not visible to me until the security team unchecks the 'private' flag | 20:55 |
| slangasek | now that I know that it's not me, it sounds like a significant regression | 20:55 |
| slangasek | s/not me/not just me/ | 20:55 |
| slangasek | kees, jdstrand, micahg, mdeslaur: ^^ maybe you guys have some insight into what may have changed in LP on this score? | 20:56 |
| nigelb | slangasek: *maybe* security bugs are only visible to security team? | 20:56 |
| jdstrand | sorry, I don't | 20:56 |
| * nigelb checks code | 20:56 | |
| kirkland | slangasek: funny enough, aliguori tackled me today at LinuxCon saying he hasn't been getting private bug notices against the qemu upstream project in Launchpad | 20:57 |
| mdeslaur | slangasek: security bugs are only visible to the security team | 20:57 |
| jdstrand | I think if it is both private and security, only we see it | 20:57 |
| kirkland | slangasek: he said he was "embarassed" when a guy who filed a number of CVEs asked him why he hadn't taken any action in several weeks :-o | 20:57 |
| jdstrand | but I don't know of anything that has changed recently that would alter behavior | 20:57 |
| kees | slangasek: that's certainly a regression -- the package owner should be able to see it, I thought | 20:57 |
| kees | slangasek: are those bugs marked "security"? that's the only time the package subscribers can't see it, I thought. | 20:58 |
| mdeslaur | kees: I don't remember it ever being any different | 20:58 |
| kees | mdeslaur: right, _security_ bugs. but "just" private... | 20:58 |
| slangasek | mdeslaur: a) my update-manager bugs aren't tagged security, b) I would expect trusted package owners to still be able to see them, like kees says | 20:58 |
| kees | the problem is the order of operations. | 20:58 |
| slangasek | and see above for the upstream case kirkland mentions | 20:58 |
| kees | you check 'security' at the start, no one is subscribed but us, the reporter unchecks 'security', and then it should be visible to the package owners. wait, I've just talked myself out of this. | 20:59 |
| mdeslaur | slangasek: so, basically, nobody can see it except for the reporter? what good is that? :) | 20:59 |
| slangasek | I guess this should be taken to #launchpad then | 20:59 |
| kees | there is no such thing as "package owner" | 20:59 |
| slangasek | mdeslaur: no kidding! | 20:59 |
| slangasek | kees: well, I would expect package bug subscribers who are part of some "trusted" group wrt the bug task, to be able to see them | 20:59 |
| kees | so, right, mdeslaur is right, after running through this a few times in my mind. | 21:00 |
| kees | slangasek: that would be good, but where is that defined in LP? I don't think such a thing exists. | 21:00 |
| slangasek | kees: well, it used to be defined for Ubuntu in order for people to poke at backtraces when the retracer has failed | 21:00 |
| slangasek | in fact, the retracer itself needs to get access to private reports | 21:01 |
| mdeslaur | private bugs are supposed to be visible to whoever signed up to get bugmail for a particular package, and the reporter can remove people | 21:01 |
| kees | mdeslaur: but anyone can subscribe... | 21:01 |
| mdeslaur | kees: yes, but if you subscribe, you aren't added to the bugs which are already private | 21:01 |
| mdeslaur | anyway, #launchpad probably knows more | 21:02 |
| kees | slangasek: so, it must be related to the project contacts or something | 21:02 |
| kees | mdeslaur: right | 21:02 |
| mdeslaur | huh, actually, the only person subscribed to a private bug I've opened earlier today is apport | 21:03 |
| mdeslaur | and if I look at an _old_ private bug I had opened last year, a whole slew of people are subscribed to it | 21:04 |
| jdstrand | I think it's wrong for someone to subscribe to get bugmail and then automatically get all security bugs | 21:11 |
| jdstrand | if we uncheck the security box, then yes. otherwise, we bring in who is needed | 21:12 |
| slangasek | right, subscribing to bugmail shouldn't automatically get you access to security bugs | 21:12 |
| slangasek | but if you're the owner of the project (cf. qemu-kvm above), you certainly should! | 21:13 |
| jdstrand | yes! | 21:13 |
| jdstrand | by all means :) | 21:13 |
| jdstrand | I may be lacking context, but that's ok | 21:14 |
| mdeslaur | no, owners of projects should _not_ be getting security bugs | 21:22 |
| slangasek | er, what | 21:22 |
| cjwatson | oh god. if I touch a package called "php5-ffmpeg", will I go to hell? | 21:23 |
| slangasek | the Ubuntu security team shouldn't be setting the policy for security bugs filed against upstream | 21:23 |
| jdstrand | maybe we are talking about different things | 21:23 |
| jdstrand | if we get a bug against qemu in Ubuntu, then only the security team should get the bug initially | 21:24 |
| slangasek | we're talking about an *upstream* security report - the registrant of the qemu project in launchpad should certainly be able to see bugs filed against qemu in launchpad, security or not | 21:24 |
| slangasek | cjwatson: that depends on how you touch it :P | 21:24 |
| jdstrand | if upstream qemu gets a bug, they should get the bug | 21:24 |
| mdeslaur | slangasek: what's an upstream security report? | 21:24 |
| jdstrand | cjwatson: I think the safe answer is 'yes' | 21:24 |
| slangasek | mdeslaur: there are projects other than Ubuntu that use launchpad | 21:24 |
| mdeslaur | ok, if I type "ubuntu-bug qemu" and on the webpage check "security", I expect only the security team to see it | 21:25 |
| slangasek | that's not an upstream bug report | 21:25 |
| jdstrand | mdeslaur: that's correct | 21:25 |
| slangasek | an upstream bug report is one filed against the qemu *project* in launchpad | 21:25 |
| jdstrand | but if you go to https://bugs.launchpad.net/apparmor/+filebug, that's an upstream bug | 21:25 |
| kirkland | http://bugs.launchpad.net/qemu -> Report a bug | 21:26 |
| mdeslaur | right, ok, we're all in agreement | 21:26 |
| mdeslaur | jdstrand: do we even see those? I didn't think so | 21:26 |
| jdstrand | mdeslaur: no, and we should not | 21:26 |
| slangasek | or if someone uses 'also affects project' -> qemu on a security bug filed against Ubuntu, the qemu upstream bug contact should be able to see it | 21:26 |
| kirkland | you don't, no | 21:26 |
| mdeslaur | slangasek: yes, agreed | 21:27 |
| jdstrand | https://bugs.launchpad.net/ubuntu/+source/foo/+filebug (we see). https://bugs.launchpad.net/foo/+filebug (wee should not) | 21:27 |
| kirkland | but aliguori was complaining to me just today that he didn't think he was receiving the bug mail for which he's marked as the security contact | 21:27 |
| jdstrand | s/wee/we/ | 21:27 |
| jdstrand | slangasek: I'm not as enthusiastic about 'also affects project', but I think I don't disagree | 21:28 |
| slangasek | jdstrand: well, the set of people who are in a position to *add* such a task to a bug are finite; you don't have to do it, but if you do those are the sensible semantics :) | 21:31 |
| kees | cjwatson: elmo made me audit php5-ffmpeg ! it's not so bad, actually. | 21:33 |
| elmo | hey, hang on, I rick trolled you into auditing it, I didn't expect you to fall for it! | 21:34 |
| mdeslaur | rofl | 21:35 |
| jdstrand | hehe | 21:35 |
| * cjwatson wonders what to do about mplayer - attempt to bodge it into libav 0.7 support in ways different from what was done upstream, or pull in a new snapshot from Debian experimental | 21:48 | |
| cjwatson | neither is massively appealing | 21:48 |
| micahg | slangasek: sinzui has been working on a disclosure story for LP, there was a thread on launchpad-devel about it | 22:14 |
| slangasek | micahg: oh; does the thread touch on this issue we're hitting? | 22:17 |
| micahg | slangasek: yes, who can see what was a large part of the issue discussed | 22:18 |
| * micahg looks for the thread | 22:18 | |
| micahg | slangasek: https://lists.launchpad.net/launchpad-dev/msg07445.html | 22:21 |
| slangasek | micahg: thanks for the link | 22:26 |
| micahg | slangasek: sorry, I was out before | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!