| stgraber | infinity: hmm, i386 is still oversized (just did a rebuild), that's odd... I was expecting amd64 to be bigger than i386. Checking that the cleanup properly happened on it. If it did, I'll spend some more time tomorrow trying to figure out what's taking the space on it | 00:06 |
|---|---|---|
| infinity | stgraber: It wasn't in the archive yet. | 00:08 |
| stgraber | infinity: it was, at least according to rmadison | 00:08 |
| infinity | stgraber: Or, nevermind. I can't read timestamps. | 00:08 |
| stgraber | anyway, /var/lib/apt/lists has been properly cleaned, so it's something else | 00:08 |
| stgraber | for some reason our i386 image is indeed taking more space than amd64... | 00:08 |
| infinity | Curious that i386 would be bigger. | 00:08 |
| infinity | Same package set? | 00:09 |
| infinity | +xserver-xorg-video-geode2.11.13-2build1 | 00:09 |
| infinity | +libstlport4.6ldbl4.6.2-7 | 00:10 |
| infinity | Oh, and i386 includes another locale (de) | 00:10 |
| infinity | Dropping de from i386 would probably fix you. | 00:10 |
| infinity | Not sure how much space each langpack set takes. | 00:10 |
| stgraber | oh, I must have been blind... I checked for extra locales and missed that one apparently | 00:11 |
| stgraber | that clearly explains it then | 00:11 |
| stgraber | IIRC from my last try, a locale is around 6-7MB compressed space | 00:11 |
| infinity | I'm curious about libstlport4.6ldbl, though... | 00:12 |
| stgraber | geode + libstlport is roughly 1MB uncompressed | 00:13 |
| infinity | It's in ubuntu-desktop on i386 only... | 00:13 |
| infinity | Oh, ure depends on it on i386. | 00:13 |
| infinity | Anyhow, dropping de is probably the right answer. Having amd64 and i386 support different languages is weird anyway. | 00:14 |
| infinity | stgraber: Seed change committed. | 00:15 |
| stgraber | ok, thanks. I guess Seb probably won't complain too much about us dropping German when it already wasn't shipped on amd64 | 00:17 |
| infinity | Actually, wait. | 00:17 |
| infinity | A seed change can't fix this, can it? | 00:18 |
| * infinity scratches his head. | 00:18 | |
| infinity | Since we install ubuntu-live as a task, via apt-get, and changing the seeds won't change the Task headers in the release pocket.. | 00:19 |
| infinity | Oh, but we have new langpacks in -updates, and they'll trump that. | 00:19 |
| stgraber | unless we magically end up pulling the old ones from the release pocket | 00:20 |
| infinity | Might need to release a package to -updates to force a regen of the Packages files, though. :P | 00:20 |
| stgraber | I can probably find one, wait a sec ;) | 00:20 |
| infinity | accountsservice looks good. | 00:20 |
| * infinity releases that. | 00:21 | |
| stgraber | sounds good, and that one is really useful as it should fix quite a few install failures | 00:22 |
| infinity | If we need another one later, unity-greeter looks like another one that's ready. | 00:23 |
| infinity | And python2.7 | 00:24 |
| stgraber | ubuntu-docs should also be fine, I just need to check that it still installs and that's about it | 00:24 |
| infinity | Why do we have one langpack sitting in proposed? | 00:26 |
| stgraber | according to rmadison, we have more than one | 00:28 |
| infinity | All I see is en... | 00:28 |
| stgraber | stgraber@castiana:~/data/code/seeds/ubuntu.precise$ rmadison language-pack-fr-base | grep precise | 00:28 |
| stgraber | language-pack-fr-base | 1:12.04+20120417 | precise | source, all | 00:28 |
| stgraber | language-pack-fr-base | 1:12.04+20120508 | precise-updates | source, all | 00:29 |
| stgraber | language-pack-fr-base | 1:12.04+20120801 | precise-proposed | source, all | 00:29 |
| stgraber | I agree that pending-sru doesn't agree with that | 00:29 |
| infinity | So, the sru report is on crack. | 00:29 |
| stgraber | # for langpack updates, only keep -en as a representative | 00:29 |
| stgraber | if (pkg.startswith('language-pack-') and | 00:29 |
| stgraber | pkg not in ('language-pack-en', 'language-pack-en-base')): | 00:29 |
| stgraber | continue | 00:29 |
| infinity | Yeah, I just got there. ;) | 00:29 |
| stgraber | nope, it's doing what it's supposed to, it's just not telling people on the page ;) | 00:29 |
| infinity | Tempted to add a counter to that, and list "language-pack-en (and 731 others)" | 00:31 |
| infinity | Or even better, just "731 language packs", and not list -en at all. | 00:32 |
| infinity | Cause that code will fail miserably if we SRU a non-en langpack. | 00:32 |
| infinity | It'll just "disappear". | 00:32 |
| stgraber | sounds good. Wondering how much slower the script would be if it'd also extract the bugs from these and show a unique list of bugs for all the langpacks. (Assuming we might one day see a langpack fixing a bug) | 00:33 |
| slangasek | the changelogs themselves are autogenerated | 00:34 |
| slangasek | so I don't think so :) | 00:34 |
| infinity | Only a manual update would ever fix a bug. | 00:34 |
| infinity | Which we've had once or twice. | 00:34 |
| infinity | But it's pretty rare. | 00:34 |
| stgraber | anyway, disappearing for a couple of hours. If you want to kick an i386 build to test the seed change, have fun, otherwise I'll wait for cron to do that for me and check tomorrow. | 00:34 |
| infinity | I'm considering a short nap. | 00:35 |
| infinity | Which is, I agree, not as exciting as building ISOs, but it's right up there. | 00:35 |
| cyphermox | slangasek: yes, there is the possibility that another instance might have dbus already, though no package currently ships such a configuration; it could be done by a user. that would constitude a regression then | 00:48 |
| cyphermox | stgraber: ^ | 00:48 |
| cyphermox | slangasek: the reason I went with using dbus for dnsmasq rather than actually changing when NM restarts dnsmasq is that such changes have already been done upstream, but are rather very intrusive, some 14 or so commits in the upstream source repo | 00:49 |
| cyphermox | disclaimer, I'm in a coffee shop on battery right now, not my usual place either, connection may be spotty. | 00:49 |
| cyphermox | as for the routing table issue, I'm not certain it's an issue really, just different behavior on the kernel side. | 00:52 |
| cyphermox | afaict the dbus config for dnsmasq works properly. I seem to recall seeing something about dnsmasq being started as root then dropping privs, not sure if that would actually explain why the policy works. | 00:55 |
| cyphermox | supporting a different dbus name didn't look *hard* but does seem to involve some mucking around that I wasn't looking forward to doing; the code is pretty complicated; but it can be done. | 01:11 |
| cyphermox | I could also just ask upstream to look into it, though that might take a bit of time | 01:11 |
| infinity | stgraber: Hrm. There might be more magic involved in manipulating tasks in post-release pockets (or it might just plain not be doable). I think I'd rather ask Colin than try to trace it. :P | 01:22 |
| stgraber | infinity: ok, I'll try to remember to poke cjwatson about it tomorrow before our team meeting, or during the team meeting if I forget :) | 02:15 |
| stgraber | infinity: do we still have stuff requiring two publisher run to happen? I vaguely seem to remember that being the case in the past | 02:22 |
| stgraber | slangasek: hmm, the cd dist upgrader is really in pretty bad shape... update-notifier-common uses patch but doesn't depend on it (in lucid at least) and even if it was there, it'd fail to apply the patches (not sure they're actually needed). Then it fails to resolve the upgrade and fails... | 03:48 |
| stgraber | the cdromupgrade script on the cd at least doesn't have the patch bug, though resolving still fails | 03:49 |
| * micahg looks around for infinity | 04:54 | |
| micahg | infinity: nevermind, will wait until morning | 05:04 |
| slangasek | stgraber: update-notifier-common uses patch /at runtime/? | 05:29 |
| slangasek | trippy | 05:29 |
| slangasek | stgraber: does cddistupgrader run from within the package, not from the copy on the CD? | 05:30 |
| tumbleweed | infinity: me. and patches are welcome | 07:01 |
| tumbleweed | but whining at me won't do much right now. holed up in bed, sick | 07:01 |
| jamespage | morning all | 08:29 |
| jamespage | would an archive admin be able to review the walinuxagent package in the precise-proposed NEW queue please | 08:30 |
| jamespage | this package is already in quantal; its required to enable use of azure IaaS on precise | 08:30 |
| cjwatson | ScottK: your copy-package change makes sense to me. (This is an example of UI that I thought was completely broken in the Launchpad scripts, but I was starting off the client-side versions with the same UI and figuring people would fix it once they got annoyed ...) | 09:10 |
| cjwatson | stgraber,infinity: nothing runs germinate over stable series at all right now. I'm not sure how we'd go about changing tasks post-release ... | 09:13 |
| infinity | cjwatson: Well, I have a theory that if Task headers change in updates/proposed (ie: because of the combination of a seed change and a newer package version), then apt might honor that. I haven't tested this theory. | 09:23 |
| infinity | cjwatson: But yes, one would need to germinate for post-release pockets to make that work. | 09:23 |
| infinity | (And it may still not work) | 09:23 |
| cjwatson | If Task headers change, you might be right. But right now I don't think they will. | 09:24 |
| cjwatson | I guess we could fall back to installing metapackages if we have no choice ... | 09:25 |
| infinity | No, they definitely don't change right now, because there's no germinating for non-devel releases. | 09:25 |
| infinity | Installing metapackages seems like a potentially uglier hack than just removing langpack-de in a precise-only live* hack. | 09:26 |
| cjwatson | Yeah. | 09:26 |
| cjwatson | Hm, why does /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.precise.main have a recent timestamp? | 09:28 |
| cjwatson | Oh, cronscripts/publishing/cron.germinate fiddles with it for Supported overrides. | 09:28 |
| cjwatson | You could edit /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.precise.main in place when the publisher isn't running. And then cry a little and file an LP bug that you had to. | 09:28 |
| cjwatson | Probably best to do virtually anything else though ... | 09:29 |
| infinity | Hahha, yeah, I'll pass on that. | 09:29 |
| infinity | Removing the langpack by hand is less ugly. | 09:29 |
| infinity | Or, at least, more auditable. | 09:29 |
| cjwatson | Indeed. | 09:29 |
| cjwatson | Somebody trying to figure out how it all worked later might have a chance of arriving at the answer. | 09:29 |
| infinity | Speaking of overrides, have you noticed the frequency of apt-ftparchive whining about malformed overrides has gone through the roof? | 09:29 |
| cjwatson | No - where? | 09:29 |
| infinity | publisher logs. | 09:30 |
| cjwatson | Hm, what's that about then | 09:31 |
| cjwatson | Maybe a stupid line length limit? | 09:31 |
| infinity | Dunno. We always used to get a few of them here and there in older post-release pockets, but now we get a ton of 'em. | 09:31 |
| infinity | I didn't spend much time looking at it, except to look at some of the whined-about line numbers to determine that nothing looked broken. | 09:31 |
| cjwatson | char Line[500]; | 09:31 |
| cjwatson | libmng1/powerpc Task ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-active-desktop, kubuntu-active, edubuntu-desktop, edubuntu-desktop-kde, edubuntu-usb, xubuntu-desktop, mythbuntu-frontend, mythbuntu-frontend, mythbuntu-desktop, mythbuntu-backend-slave, mythbuntu-backend-slave, mythbuntu-backend-master, mythbuntu-backend-master, ubuntustudio-generation, ubuntustudio-video, ubuntustudio-audio-plugins, ... | 09:32 |
| cjwatson | ... ubuntustudio-publishing, ubuntustudio-photography, ubuntustudio-graphics, ubuntustudio-recording | 09:32 |
| cjwatson | -> 507 chars | 09:32 |
| infinity | Oh, special. | 09:32 |
| cjwatson | Note that the line numbers are off by one | 09:32 |
| cjwatson | (Well, zero-based) | 09:32 |
| cjwatson | Ahaha | 09:33 |
| cjwatson | apt-cache show libmng1 | 09:33 |
| cjwatson | Task: ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-active-desktop, kubuntu-active, edubuntu-desktop, edubuntu-desktop-kde, edubuntu-usb, xubuntu-desktop, mythbuntu-frontend, mythbuntu-frontend, mythbuntu-desktop, mythbuntu-backend-slave, mythbuntu-backend-slave, mythbuntu-backend-master, mythbuntu-backend-master, ubuntustudio-generation, ubuntustudio-video, ubuntustudio-audio-plugins, ubuntustudio-publishing, ... | 09:33 |
| cjwatson | ... ubuntustudio-photography, ubuntustudio-graphics, ubuntustudio-reco | 09:33 |
| cjwatson | Truncation is *not* IRC's fault | 09:33 |
| infinity | Oh, even more special! | 09:33 |
| infinity | So it is actually causing a real-world bug then. | 09:33 |
| infinity | Awesome. | 09:33 |
| infinity | Bumping that buffer up to 1024 seems like it wouldn't be rocket surgery. | 09:34 |
| infinity | Or some other arbitrary number. | 09:34 |
| cjwatson | Yeah. | 09:35 |
| infinity | SRU to precise (for if cocoplum ever gets upgraded), and backport to hardy-cat? Profit. | 09:36 |
| cjwatson | lucid-cat, I hope. | 09:36 |
| infinity | Err, yes. That one. | 09:36 |
| === doko_ is now known as doko | ||
| stgraber | slangasek: from what I could see, inserting the cdrom prompts the user asking whether they want to start the package manager, upgrade or cancel. If they select upgrade, then the cdromupgrade script that's in /usr/lib is called, not the one from the media. | 13:10 |
| stgraber | slangasek: and that one does runtime patching of files in the upgrader tarball and fails to do so either because of the missing patch package or because of the no longer valid patch | 13:11 |
| stgraber | slangasek: in either case, the UI starts without any of the changes being applied, so no real harm done, luckily | 13:12 |
| stgraber | then we have the problem that we are apparently missing around 400 packages on our media to make a succesful lucid to precise upgrade without internet usage | 13:12 |
| stgraber | I attached the full package list to the bug. Quite a bunch are transitional packages (as expected) and a few are binaries and libraries for stuff that we dropped | 13:12 |
| jamespage | please could walinuxagent be rejected from the precise-proposed NEW queue - I need to put a target architecture restriction on it... | 14:20 |
| bjf | skaet: the precise kernel has passed all testing | 14:24 |
| skaet | thanks bjf! :) | 14:26 |
| slangasek | stgraber: well, removing some of those old packages is also an acceptable outcome for an upgrade... it doesn't have to actually upgrade each of them | 14:40 |
| xnox | slangasek: stgraber: from Ubiquity design doc. If there is no network the upgrade option is presented as "Upgrade Ubuntu to 11.04 [maps to reuse] | 14:43 |
| xnox | Documents, music, and other personal files will be kept. System-wide settings will be cleared. Warning: Some installed software may be removed unless you connect to the Internet before continuing." | 14:43 |
| slangasek | xnox: this is the alternate CD, not the desktop CD | 14:44 |
| xnox | sure. I hope it still does give a ~ similar warning though? | 14:44 |
| stgraber | xnox: yeah, it shows a warning | 14:45 |
| cjwatson | It's more like the update-manager UI | 14:51 |
| === mmrazik is now known as mmrazik|on_the_p | ||
| === mmrazik|on_the_p is now known as mmrazik|otp | ||
| stgraber | can someone from the SRU team review mythtv in the queue please? it's targeted for 12.04.1 and has an MRE | 16:01 |
| slangasek | looking | 16:03 |
| * stgraber pokes queuebot | 16:11 | |
| stgraber | oh, stuck in LP authentication for some reason... | 16:11 |
| micahg | infinity: was your overwrite of platform.quantal intentional (seems to have all the changes)? | 16:41 |
| micahg | infinity: oh, sorry, not you | 16:41 |
| micahg | zul: ^^ | 16:41 |
| zul | micahg: ? | 16:42 |
| micahg | zul: your update removed 3 revisions and pushed one that seems to include all the changes | 16:42 |
| cjwatson | Please use bound branches for the seeds | 16:42 |
| zul | micahg: no it wasnt | 16:42 |
| cjwatson | That way you won't find yourself having to merge | 16:42 |
| * micahg just does a bzr pull before modifying anything | 16:43 | |
| cjwatson | You can convert your existing branch to a bound branch (aka checkout) using 'bzr bind :parent' | 16:43 |
| cjwatson | Then a commit will (a) automatically push (b) refuse to commit if you're out of date | 16:43 |
| game2 | xnox / micahg, can you look at bug 1016438 ? I was asking if it would make 12.04.1. | 16:46 |
| ubot2 | Launchpad bug 1016438 in precise-backports "Please backport btrfs-tools 0.19+20120328-3 (main) from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1016438 | 16:46 |
| zul | cjwatson: done | 16:46 |
| micahg | game2: backports aren't tied to the point release schedule | 16:46 |
| cjwatson | ta | 16:46 |
| micahg | game2: let's move to -devel | 16:47 |
| stgraber | yay, queuebot works again (not sure why the auth token suddenly became invalid...) | 16:52 |
| slangasek | superm1: see #ubuntu-devel for mythtv review comments... looks like a FTBFS to me | 17:41 |
| slangasek | oh, superm1 is here, that's not the highlight I meant to trigger ;) | 17:41 |
| slangasek | stgraber: ^^ | 17:41 |
| stgraber | slangasek: http://paste.ubuntu.com/1136656 | 18:25 |
| stgraber | slangasek: the added Breaks in launchpad-lib indeed fixed that part of the issue, though there seems to be a pretty big mess around network-manager, gnome-bluetooth, gnome-settings-daemon and some icon themes (just looking at the last few lines) | 18:26 |
| slangasek | stgraber: libnspr4 is at the root of it | 18:35 |
| stgraber | slangasek: they don't seem to have direct conflicting contents, though they certainly provide the same library (libnspr4 has been multi-arched), should I try to downgrade that Conflicts to a Breaks? | 18:42 |
| slangasek | stgraber: libnspr4-0d is a transitional package demoted to universe; libnspr4 in precise conflicts with the old one; evolution-data-server still wants libnspr4 apparently | 18:42 |
| slangasek | Breaks would still mean "cannot configure", which would result in a similar failure to calculate the upgrade | 18:42 |
| slangasek | ah, it's the old version of e-d-s... so it goes back even farther | 18:44 |
| slangasek | libcamel-1.2-29 | 18:44 |
| slangasek | er, no, I'm getting tangled | 18:44 |
| slangasek | ah, it's evolution-plugins | 18:48 |
| slangasek | stgraber: please try the same trick here: have libnspr4 Breaks: old evolution-plugins to hint it out of the way | 18:54 |
| stgraber | slangasek: ok, will try. I have the next batch of breaks if you want to have a look (tried by simply adding libnspr4-0d to my local archive to bypass that problem) | 18:55 |
| slangasek | stgraber: Breaks: evolution-plugins (<< 3.2.0-0ubuntu2) should work | 18:55 |
| slangasek | sure, hit me :) | 18:55 |
| stgraber | http://paste.ubuntu.com/1136706 | 18:56 |
| slangasek | stgraber: that one looks like it might be easier... seed libgnome2-0 into the pool? | 19:01 |
| stgraber | slangasek: "Fixing libnspr4:amd64 via remove of evolution-plugins:amd64" <- looks like that did the trick | 19:01 |
| slangasek | tada | 19:01 |
| slangasek | will you prepare uploads to these packages adding the Breaks? I can review them today | 19:02 |
| stgraber | yep, once I can get that upgrade running, I'll push the SRUs | 19:02 |
| slangasek | excellent, thanks :) | 19:02 |
| stgraber | slangasek: next batch: http://paste.ubuntu.com/1136717 | 19:05 |
| * stgraber will really need to commit that dist-uprader change to allow external repositories. Having to patch the code every time is getting annoying ;) | 19:05 | |
| slangasek | man, hardly seems like we're making any progress :P | 19:05 |
| stgraber | hehe, yeah... I'll have to check with jibel that this kind of stuff is tested by QA a bit earlier next time so we have some time to fix the mess ;) | 19:06 |
| slangasek | looks like none of the OOo transitional packages are on here | 19:08 |
| slangasek | (for the libO rename) | 19:08 |
| slangasek | so a bunch of those probably need added | 19:08 |
| slangasek | how are we on size for the alternate? | 19:08 |
| stgraber | we have around 3MB of free space, at least on the amd64 one | 19:09 |
| slangasek | openoffice.org-emailmerge, openoffice.org-core look to be the key transitional packages; both should be small of course | 19:11 |
| slangasek | you may need more of them to get an upgrade to libO instead of just a removal of OOo :P | 19:11 |
| stgraber | except that openoffice.org-core doesn't exist in precise | 19:12 |
| slangasek | really? | 19:12 |
| slangasek | huh | 19:12 |
| stgraber | yep, we have a whole bunch of transitional package but that's not one of them | 19:12 |
| slangasek | so that's possibly unhelpful | 19:12 |
| slangasek | ok; the openoffice.org package should be quick enough to SRU if we think we need it, since that's just the transitional packages | 19:13 |
| stgraber | yay for having a source just for the transitional packages | 19:15 |
| stgraber | I was kind of worried we'd need to upload libreoffice for that | 19:15 |
| stgraber | building openoffice.org-core here, will add all the binary packages from openoffice.org to my local archive, see if that does the trick | 19:18 |
| stgraber | slangasek: http://paste.ubuntu.com/1136755 | 19:28 |
| stgraber | I hope we won't need a lot of the openoffice transitional package because at 120K a package that's 21MB if we need the whole lot... | 19:28 |
| slangasek | 120k? eep | 19:32 |
| slangasek | how is it 120k? OOo-writer is only 4k | 19:32 |
| infinity | slangasek: build-essential uploaded for bug #1034568 ... I'll let you and stgraber decide if it should be targetted to .1 or not (though I see no harm in letting it through) | 19:33 |
| ubot2 | Launchpad bug 1034568 in build-essential "build-essential shouldn't be Multi-Arch: foreign" [Undecided,Fix released] https://launchpad.net/bugs/1034568 | 19:33 |
| slangasek | infinity: cheers | 19:33 |
| infinity | slangasek: Other than the bug closure in the changelog (and the version number), it's identical to the quantal version. | 19:33 |
| infinity | stgraber: 120k? I'm assuming that's a local build without a truncated changelog, or any other binarymangling magic? | 19:34 |
| slangasek | ah right, that would do it | 19:34 |
| slangasek | stgraber: yeah, the real packages are only one-inode-big after changelog truncation :) | 19:34 |
| stgraber | oh, indeed I don't appear to have pkgbinarymangler installed, that'd explain it | 19:37 |
| * infinity is strangely proud that his "mangler" namespace has survived all these years without someone insisting on renaming it to something more "professional". :P | 19:38 | |
| slangasek | stgraber: ok, this one's tricky. vinagre was a dep of ubuntu-desktop in lucid; in precise it's been replaced by remmina. But vinagre is still in the archive (in universe) so we can't just make it a transitional package | 19:38 |
| slangasek | the ideal upgrade path here is to remove libvte9 and vinagre on upgrade | 19:38 |
| seb128 | slangasek, hey, what do you think it's the limit to take a decision on whoopsie on,off for LTS .1? | 19:38 |
| seb128 | slangasek, and do you have an opinion on who,how we will decide? | 19:39 |
| slangasek | seb128: I think that's a decision that could be made up to the final freeze for .1. However, I would much rather see the pain points addressed (which ev is working on) so that we can keep it enabled | 19:41 |
| slangasek | seb128: from your perspective, what's the threshold we should be meeting to keep it enabled? | 19:42 |
| stgraber | slangasek: do you know how to force the removal of libvte9 and vinagre in the dist-upgrader? I added both to the ForcedObsoletes list but that one seems to be used at a later point, so the initial resolving still fails | 19:43 |
| slangasek | stgraber: I indeed do not have a good (clean) way to force their removal | 19:44 |
| slangasek | I said that was the ideal... but I don't think the ideal is reachable here :) | 19:44 |
| slangasek | an alternative is to bring libvte9 (the gtk2 version) into the pool | 19:44 |
| slangasek | well, wait | 19:44 |
| slangasek | the end of that log shows vinagre being removde | 19:45 |
| slangasek | which is correct | 19:45 |
| seb128 | slangasek, sorry I got distracted by other thing ... threshold, it's difficult to say, we don't have enough number | 19:53 |
| seb128 | the discussions are mostly based on direct feedback, online comments, online article and personal experiences | 19:54 |
| seb128 | those brings info but we have no way to know if they are an accurate reflect of the majority's opinion | 19:55 |
| seb128 | slangasek, my gut feeling is that we still have way too many prompts for valid or buggy reasons and that this move is detrimental to Ubuntu's image rather than beneficial for the LTS | 19:57 |
| seb128 | this move = keeping whoopsie running | 19:57 |
| seb128 | users just hate being prompted about random issues | 19:58 |
| slangasek | seb128: I don't think this is something that can reasonably be decided by gut feeling. There will always be some number of users who are annoyed at seeing the prompts, and those are going to be the most vocal *about* the prompts | 20:10 |
| seb128 | slangasek, who would be in the project best placed to fix a target for an acceptable error prompt rate? the TB? | 20:11 |
| slangasek | ultimately they would decide, if we can't agree ourselves :) | 20:11 |
| seb128 | what do you suggest is the best way forward to get to an agreement? | 20:11 |
| seb128 | it's a shame nobody cared to try to step up to do those whoopsie improvements earlier | 20:12 |
| seb128 | one week before .1 is very late to get any result | 20:12 |
| slangasek | you didn't raise the issue until now | 20:12 |
| seb128 | (and I did discuss those issues with ev in private and raised them at .1 weekly meeting over a month ago) | 20:12 |
| slangasek | ah | 20:12 |
| seb128 | slangasek, that's not true | 20:13 |
| seb128 | nobody picked them up | 20:13 |
| seb128 | I think I mentioned it in some of the release team summary email sent on friday for desktop as well | 20:13 |
| seb128 | it's just that until somebody does a fuss about it everybody is so busy that they get ignored | 20:13 |
| seb128 | well anyway it's late to argue on that, but I can show meeting logs where I raised it, and at several instance | 20:14 |
| seb128 | it just happens that nobody in the .1 meeting had an opinion | 20:15 |
| slangasek | so let's pick a number that we think is acceptable for an "average" user interaction with whoopsie | 20:15 |
| slangasek | and then we can figure out what it takes to achieve that | 20:15 |
| seb128 | works for me | 20:15 |
| slangasek | is an average of 1 crash a week acceptable? | 20:15 |
| infinity | I must be using my computer wrong, cause I haven't seen a whoopsie prompt in months. :/ | 20:16 |
| slangasek | I see them regularly | 20:16 |
| seb128 | infinity, ls /var/crash ... empty? | 20:16 |
| infinity | seb128: Aye. | 20:16 |
| slangasek | but I also am running quantal, and *want* to see them when things go wrong | 20:16 |
| seb128 | slangasek, 1 a week would be great, I would settle for around 3 to 5 a week | 20:16 |
| infinity | seb128: 3 to 5 per week is likely where we're already at. | 20:16 |
| slangasek | (and for several releases I haven't seen any problems with software crashing on session shutdown) | 20:17 |
| seb128 | infinity, we said average is 1.45/day | 20:17 |
| seb128 | no? | 20:17 |
| infinity | (That previous assumption of 10 per week was based on reaaaaaly bad math) | 20:17 |
| seb128 | which is 10 a week | 20:17 |
| slangasek | seb128: no, the average is 1.45/day /among users who report them/ | 20:17 |
| slangasek | on that given day | 20:17 |
| seb128 | slangasek, take in mind that apport cut out reports after 3 reports | 20:17 |
| slangasek | the graph is misleading, as I said on the list; ev is working on getting is better data | 20:17 |
| infinity | Yes, but it's per day, per-reporting-user. | 20:17 |
| seb128 | so that bias the stats a lot | 20:17 |
| infinity | So, any user who has a day where the same thing crashes twice, boom. | 20:18 |
| infinity | That's not 10 per week. | 20:18 |
| slangasek | seb128: we don't know that it biases the stats a lot, we only know that it /could/ bias the stats a lot :) | 20:18 |
| infinity | That's what we call someone who needs to take a statistics course. ;) | 20:18 |
| seb128 | slangasek, that's part of the issue, we have too much unknown s | 20:18 |
| seb128 | like how many report are dismissed | 20:19 |
| seb128 | how many are invalid and not sent | 20:19 |
| seb128 | how many are cut by outdated depends | 20:19 |
| slangasek | we could also explicitly look at how many of the crashes are a user reporting the same crash three times | 20:19 |
| slangasek | outdated depends should only affect launchpad bug reporting, not crashdb | 20:19 |
| slangasek | the crashdb is meant to collect everything it can | 20:20 |
| slangasek | precisely so that we have as much data as possible for the analysis | 20:20 |
| seb128 | ok | 20:20 |
| seb128 | so do we have an idea how many report the average user receive atm in the end? | 20:21 |
| slangasek | so the only ones that won't show up are 1) crashes that have shown more than 3 times, 2) crashes the user has explicitly chosen not to submit | 20:21 |
| slangasek | seb128: sorry, not sure what you're asking | 20:21 |
| seb128 | slangasek, you said "<slangasek> is an average of 1 crash a week acceptable?" | 20:22 |
| seb128 | slangasek, what's this number atm? | 20:22 |
| seb128 | i.e from where do we start? | 20:22 |
| slangasek | we don't know, ev is generating another index across the database so we can answer this | 20:22 |
| seb128 | ok | 20:23 |
| seb128 | so I think we need to wait on that number to decide on an acceptable target | 20:23 |
| slangasek | (s/index/mapping/, technically) | 20:23 |
| slangasek | why do we wait? | 20:23 |
| seb128 | but yeah, 1 a week would be fine for me | 20:23 |
| seb128 | because we don't know where we stand | 20:23 |
| seb128 | maybe we are under 1 a week? | 20:23 |
| slangasek | I think the target should be judged on its own right according to what we think is a reasonable experience | 20:23 |
| seb128 | I would say 3 a week is fine | 20:24 |
| seb128 | 1 is better | 20:24 |
| slangasek | the only reason to wait is if we're starting from the assumption that the current rate is too high even though we don't know what it actually is ;) | 20:24 |
| seb128 | if we are over 3 we need to do something | 20:24 |
| seb128 | my guess is that we are >> 3 | 20:24 |
| seb128 | (I'm not a normal user, bug I can't start a guest session here without having one for example) | 20:25 |
| slangasek | my guess is very different :-) but for my part, I'm happy to agree that 3/week/user is a reasonable limit for the average | 20:25 |
| seb128 | ok, let's agree on 3 then | 20:25 |
| seb128 | what's next? ;-) | 20:26 |
| slangasek | next is to get the results of ev's query | 20:26 |
| slangasek | and see where we are vs. that limit | 20:26 |
| seb128 | ok | 20:26 |
| slangasek | and discuss ways to reach it | 20:26 |
| seb128 | any ETA for that? | 20:26 |
| slangasek | ev: ^^ do you know when we can expect the new mapping to be done? | 20:26 |
| slangasek | seb128: my shot-in-the-dark ETA is "this week" | 20:27 |
| seb128 | which still work for the "take a decision on time for .1" | 20:27 |
| seb128 | the hard freeze is end of next week | 20:27 |
| * slangasek nods | 20:29 | |
| slangasek | btw, how does apport even know the same crash has been seen 3 times? | 20:29 |
| slangasek | since /var/crash itself is periodically emptied | 20:30 |
| seb128 | what is the period? | 20:30 |
| slangasek | weekly | 20:30 |
| seb128 | it has a counter in the .crash | 20:30 |
| seb128 | it's to avoid having the same issue nagging you every 10 minutes until end of time | 20:30 |
| seb128 | so it's 3 times by week :p | 20:30 |
| slangasek | right | 20:30 |
| slangasek | so in fact, if we're taking an average over 90 days, the apport limit is probably not a factor | 20:31 |
| seb128 | well, ev is talking about removing it because he considers it a bug | 20:32 |
| seb128 | it could make some issues pop a lot more | 20:32 |
| seb128 | like you could go from 3 prompt a week to 25 because of 1 bug | 20:33 |
| slangasek | right... I think there would be push-back against making that change in an SRU | 20:33 |
| seb128 | yeah | 20:34 |
| seb128 | hum, need to get online, be back in a few minutes | 20:34 |
| seb128 | re | 20:52 |
| stgraber | slangasek: hmm, can't figure out what's going on with vinagre, so looking at the hpijs/libhpmud0 one for now... | 20:57 |
| slangasek | yes, I think the vinagre part may be a red herring entirely | 20:58 |
| slangasek | actually, I'm not sure either of those should be fatal for the upgrade calculation | 20:59 |
| stgraber | oh, actually the log is telling me why | 21:01 |
| stgraber | "The package 'screen-resolution-extra' is marked for removal but it is in the removal blacklist." | 21:01 |
| stgraber | though that error is just plain weird... the package isn't part of a default install on precise, so I'm not sure why it's part of the blacklist | 21:03 |
| stgraber | "blacklist expr 'screen' matches 'screen-resolution-extra'" <- that'd be why... | 21:03 |
| stgraber | changed to ^screen$, retrying with that | 21:04 |
| stgraber | slangasek: success! | 21:05 |
| slangasek | sweet :) | 21:05 |
| stgraber | well, it's failing because my local archive isn't signed, but I'm taking that as a sign that the resolution part worked | 21:05 |
| stgraber | ok, so we "just" need an SRU of launchpadlib-integration, nspr, seeding libgnome2, adding openoffice.org-core to openoffice.org + seed some of these and update update-manager | 21:06 |
| stgraber | sounds trivial ;) | 21:06 |
| slangasek | yep! :) | 21:06 |
| * stgraber adds bug tasks | 21:06 | |
| slangasek | all in a day's work | 21:06 |
| slangasek | for the launchpadlib-integration and nspr SRUs in particular, I think the regression-test should include a full run of jenkins upgrade testing | 21:07 |
| slangasek | both o->p and l->p | 21:07 |
| stgraber | sounds good | 21:07 |
| stgraber | I'll also add a depends on patch to the upgrader as it's clearly using it (the fact that it fails just happens to be another bug) | 21:09 |
| * slangasek nods | 21:15 | |
| scott-work | skaet: for 12.04.1, do we need to report test results on iso.qa website? | 21:23 |
| skaet | scott-work, yes please. | 21:23 |
| skaet | please report under precise-daily | 21:23 |
| scott-work | if so, are the daily images (and therefore the test cases) changing daily as well? | 21:23 |
| skaet | scott-work, images are changing daily, but we can look at it historically and see over date range. | 21:24 |
| scott-work | skaet: copy that, thank you | 21:24 |
| bkerensa | =/ | 21:48 |
| bkerensa | The requested URL /ubuntu/dists/quantal/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html was not found on this server. | 21:48 |
| bkerensa | ? | 21:48 |
| slangasek | bdmurray: ^^ anything to do with your meta-release changes today? | 21:49 |
| slangasek | bkerensa: what were you doing when you saw this message? | 21:49 |
| infinity | slangasek: No, it has to do with the last upload of the dist-upgrade being broken. | 21:49 |
| slangasek | ah | 21:49 |
| bkerensa | slangasek: why I was upgrading a system to 12.10 of course | 21:50 |
| bkerensa | :D | 21:50 |
| infinity | Someone didn't run pre-build.sh (or it failed to do what it's meant to). | 21:50 |
| bkerensa | ahh I better not upgrade then | 21:50 |
| bkerensa | =/ | 21:50 |
| stgraber | infinity: I'm about to do a dist-upgrader upload to quantal | 21:50 |
| stgraber | (for another bug) | 21:50 |
| infinity | stgraber: Great, make sure pre-build.sh DTRT, then. :P | 21:50 |
| infinity | And the above bug will be solved at the same time, and everyone can rejoice. | 21:50 |
| bdmurray | slangasek: no and I'm fixing it now | 21:50 |
| bkerensa | can someone ping me when dist-upgrade is working :) it would be much appreciated | 21:51 |
| slangasek | ok :) | 21:51 |
| * bkerensa should just subscribe to quantal-changes | 21:51 | |
| slangasek | bkerensa: that error only pertains to the release notes, which should certainly not impact the upgrade unless there are other bugs | 21:51 |
| infinity | bdmurray: You and stgraber both seem to be fixing it. :P | 21:51 |
| bkerensa | <infinity> slangasek: No, it has to do with the last upload of the dist-upgrade being broken. | 21:51 |
| bkerensa | <slangasek> ah | 21:51 |
| bkerensa | ^ | 21:51 |
| bkerensa | so its just release notes? | 21:51 |
| infinity | bkerensa: Yeah. As in, the source package didn't contain the html files. | 21:52 |
| bkerensa | ah | 21:52 |
| bkerensa | kk | 21:52 |
| bdmurray | infinity: I'll stop then | 21:52 |
| cjwatson | ScottK: Hm. A thought about your copy-package change. How is one now supposed to copy from a PPA into the primary archive? | 22:06 |
| cjwatson | ScottK: See e.g. https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA (which I was about to update to drop the .py until I noticed this problem). | 22:08 |
| ScottK | Give me just a minute and I'll look. | 22:08 |
| cjwatson | I wonder if we need a --to-primary switch or something. | 22:11 |
| cjwatson | Also, --to-partner should probably suppress the default propagation of --ppa to --to-ppa, and vice versa. | 22:12 |
| * stgraber wonders if he'll ever get one of mvo's pre-build.sh to run fine the first time around | 22:12 | |
| ScottK | cjwatson: I was considering that if --to-ppa-name was missing, one could assume it was to the primary archive, but I like --to-primary better as I think it's good to be explicit about that. | 22:14 |
| ScottK | I can implement that and the partner changes, probably tonight. | 22:15 |
| cjwatson | Excellent, vociferous agreement. Thanks. | 22:17 |
| cjwatson | I just removed copy-package.py from LP, so I was checking for leftovers ... | 22:17 |
| cjwatson | http://people.canonical.com/~cjwatson/tmp/loc-cum.png attempting to leave a decent-sized mark in the LP codebase size | 22:18 |
| cjwatson | Hmm. scripts/ftpmaster-tools/obsolete-distroseries.py seems like the sort of thing perhaps best not exposed over the API. | 22:21 |
| cjwatson | Then again, derived distros, maybe. But I don't think I've ever run that on Ubuntu ... | 22:21 |
| ScottK | Right, so if there isn't a commit from me tomorrow morning, please re-ping me. I'm about to go out for dinner and should be able to have a look after. | 22:21 |
| cjwatson | OK. Thanks again. | 22:21 |
| stgraber | infinity, bdmurray: debdiff between what I'm uploading to quantal now and the previous version is quite big, but comparing to the one before that, it looks reasonable, so I "think" I did the right thing and we're back to a working source package :) | 22:22 |
| stgraber | now to try to achieve the same thing with the precise one... | 22:22 |
| stgraber | gah... wth did someone thing it was a good idea to check that the update-manager test suite is a child of a process called "init"? | 22:26 |
| stgraber | running in arkose, pid 1 isn't called init! | 22:27 |
| infinity | stgraber: That's a bizarre check... | 22:27 |
| stgraber | yeah... anyway, bind mounting a file on /proc/1/cmdline should do the trick for now | 22:29 |
| stgraber | oh nice ... the release upgrader in quantal FTBFSed ... | 22:37 |
| stgraber | (obviously it's building fine on my machine, wouldn't be fun otherwise) | 22:39 |
| stgraber | ah, caused by the LANG=C on the builder | 22:40 |
| stgraber | oh, I know what the bug is ;) apparently you're not allowed to have unicode in your name... | 22:41 |
| * stgraber changes name quickly to test an easy workaround | 22:41 | |
| bkerensa | anyone by chance know which package dist-upgrade is? | 22:43 |
| cjwatson | ubuntu-release-upgrader, in quantal | 22:43 |
| cjwatson | it used to be in update-manager | 22:43 |
| bkerensa | kk | 22:43 |
| stgraber | cjwatson: any idea on how to quickly fix ubuntu-release-upgrader's setup.py to not explode when parsing my name? | 22:44 |
| stgraber | (or I'll just drop the accent and upload, I don't really care that much) | 22:44 |
| cjwatson | Can you show me how to reproduce the explosion? | 22:45 |
| bkerensa | cjwatson: any idea how to file bugs against it? When I ubuntu-bug ubuntu-release-upgrade it says package does not exist | 22:45 |
| cjwatson | Spell it correctly. | 22:45 |
| cjwatson | (missing "r") | 22:45 |
| bkerensa | same problem | 22:46 |
| bkerensa | Package ubuntu-release-upgrader does not exist | 22:46 |
| cjwatson | Maybe it needs a binary package. Try ubuntu-release-upgrader-core. | 22:46 |
| bkerensa | k | 22:46 |
| bkerensa | bingo | 22:47 |
| stgraber | cjwatson: have some utf-8 (like my é) in debian/changelog, run python3 setup.py with LANG=C | 22:49 |
| stgraber | cjwatson: setup.py calls "dpkg-parsechangelog --format rfc822" which returns my name in the Maintainer field and crashes the python script | 22:50 |
| infinity | stgraber: Get a less French name. | 22:50 |
| bkerensa | :D | 22:51 |
| knome | stgraber, é <3 | 22:51 |
| cjwatson | Odd; I wonder why universal_newlines=True isn't sufficient there. | 22:51 |
| bkerensa | stgraber: we could just call you Stephan Graber ;) | 22:51 |
| Laney | Grubby Steven | 22:52 |
| cjwatson | Oh, universal_newlines decodes using locale.getpreferredencoding() and there's no way to override that in subprocess. Sigh. | 22:53 |
| cjwatson | stgraber: Er, for now, try using LANG=C.UTF-8 instead? | 22:53 |
| cjwatson | That's guaranteed to exist and should avoid this. | 22:53 |
| stgraber | cjwatson: tell that to the buildd ;) | 22:53 |
| cjwatson | You can do that in debian/rules ... | 22:53 |
| stgraber | I guess I can override in debian/rules | 22:53 |
| cjwatson | That's a grotty awkwardness with python3 subprocess, though. | 22:54 |
| stgraber | bdmurray: hmm, looks like you forgot to commit your precise-proposed upload to the bzr branch... | 23:04 |
| stgraber | (for update-manager) | 23:04 |
| bdmurray | stgraber: oh, let me look | 23:06 |
| stgraber | bdmurray: well, I'll fix the branch for you as I already commited a bunch of changes | 23:06 |
| bdmurray | stgraber: thanks, sorry about that! | 23:06 |
| stgraber | gah ... apparently not only are the builders setting LANG=C but also LC_ALL=C ... will need one more upload to fix that mess then (I only exported and tested LANG) | 23:20 |
| stgraber | can someone please reject that upload ^ I'm going to send a new one with the right -v as there's already an upload in the queue | 23:22 |
| infinity | stgraber: Sure. | 23:23 |
| stgraber | and re-uploaded | 23:28 |
| stgraber | slangasek: that's all the packages for bug 1029531 uploaded to precise and quantal (when applicable). If you're still planning to review today, everything's ready. | 23:31 |
| ubot2 | Launchpad bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,In progress] https://launchpad.net/bugs/1029531 | 23:31 |
| stgraber | I'm going out for a while but should be back around in a couple of hours. | 23:31 |
| stgraber | yay, ubuntu-release-upgrader actually built this time around! | 23:34 |
| * stgraber -> out | 23:34 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
