=== cinerama_ is now known as cinerama [01:18] cjohnston: Any idea why http://status.ubuntu.com/ubuntu-quantal/canonical-foundations.html hasn't updated in over a day? [04:58] Good morning [04:59] morning pitti === wzssyqa1 is now known as wzssyqa [06:28] good morning [07:01] good morning [07:41] hey pitti, so the translations in /opt problem was not a gtk problem after all? [07:42] dholbach: I didn't hear any news about this since yesterday [07:42] pitti, https://bugzilla.gnome.org/show_bug.cgi?id=676543#c4 [07:42] Gnome bug 676543 in GtkBuilder "Cannot load translations from a locale dir other than the default" [Normal,Resolved: invalid] [07:43] seems we need to document it properly, so apps authors know how to special-case shipping in /opt :-/ [07:44] ah :) [07:44] what a bad trap to fall into [07:44] I thought gettext.bindtextdomain() would actually set it in glibc [07:45] yeah, it's a bit unpleasant [09:07] When building a package, what is the approved dh_ method of installing files with an owner other than root? [09:07] (specifically in this case into /etc) [09:11] alexbligh1: call dh_fixperms with some -X options to ignore these files [09:11] pitti, thanks [09:11] alexbligh1: haven't (recently) tested that myself, but it ought to work [09:11] alexbligh1: HOWEVER [09:12] alexbligh1: this is only valid if the files you ship are owned by a static system user, i. e. uid < 100 [09:12] pitti, but how do I get them owned by non-root in the first place? [09:12] alexbligh1: for a dynamic system user (created with add_user), you need a postinst which calls chown for you [09:12] (it's www-data) [09:12] ok, www-data is a static one, that works [09:13] Currently I am doing a chown -R in my postinst, but I worry that when I next install the package, it will think the user has changed the perms, and not update the file. [09:13] alexbligh1: chown? [09:13] owner [09:13] yes === oppenguin is now known as oppenguins [09:13] pitti, ah, dh_fixperms is permissions. I need *owner* [09:14] alexbligh1: yes, what I said; your "make install" or whatever chowns them to www-data, and then you tell dh_fixperms to not change it back to root [09:14] alexbligh1: dh_fixperms sets files to root:root by default [09:15] is the chown in postinst safe? Or might it have problems as set out above in upgrading? chown seems far easier [09:16] alexbligh1: you should check dpkg-statoverride if you reapply them on upgrade [09:16] alexbligh1: but you can just call chown if [ -z "$2" ], i. e. on first install [09:17] pitti, thanks [09:49] pitti, hey ... have we manually overridden the ddeb remover? it seems that the natty release kernel ddebs are gone? [09:50] apw: yes; we again ran out of space :/ [09:50] and since the RT to add more is still pending, I needed some drastic measures :( [09:50] otherwise we would have lost quantal [09:51] so we now have lucid, oneiric, precise, and quantal [09:51] pitti: does the RT have suitable levels of priority attached to it? [09:52] pitti, should we need them does IS have them on backup somewhere ? [09:52] Like lava-hot-burning-ass ? [09:53] https://rt.admin.canonical.com/Ticket/Display.html?id=52633 [09:53] Priorität: 0/ [09:53] I guess not [10:04] apw / pitti, can't we just rebuild the package with pkg-create-dbgsym installed? [10:05] If there's a particular package we desperately need it for. [10:05] diwic, perhaps, am trying it now, but th [10:05] the old 3.x/2.6.x issue is biting me as the kernel is sooooo old [10:13] infinity, when we did --uname-2.6 stuff did schroot gain a personality type for it too ? [10:26] apw: setarch x86_64 --uname-2.6 schroot ... # ? [10:26] I guess that's less convenient than schroot knowing for itself [10:27] cjwatson, yeah, the chroot kind knows for 32bit so it seems orthoganal to have it inside but yes linux64 --uname-2.6 seems to work ok for me [10:30] I don't see support for any of the personality options in schroot, anyway [10:44] vibhav: (late response) I don't think that bug is effected by the perl version - just the memory monitor one we did for precise [11:10] apw: pitti: what's the best way / less disruptive way to mirror an archive ? [11:10] the kernel ddebs are only 120Gb, I'll make a copy somewhere [11:11] Caribou: debmirror is reasonably easy to use and quite robust, AFAIK [11:11] I had used it years ago, but not recently [11:12] pitti: ok, I'll try that, thanks [11:15] :w [11:15] err, EFOCUS [11:16] popey, wow - so you're going to maintain the unity/bamf/etc packages now? :) [11:20] thanks ☺ [11:20] (I think) [11:20] :-) [11:21] wookey_: dunno if you noticed, but libc6-dev/armhf should be happier now, thanks to Adam [11:23] http://www.gtk.org/ got a new layout with 'Avatar'-like tubes hanging of it, interesting. [11:23] just noticed.... === MacSlow is now known as MacSlow|lunch [11:53] bdmurray, is bugbot your bot? [11:53] why did it tag https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249 "lucid"? [11:53] Launchpad bug 1001249 in xorg-server (Ubuntu) "EYE for Gnome 3.4.1 installed with Ubuntu 12.04 freeze the computer when displaying jpeg pictures from my nikon camera this is not the case with my 10.04 install having EYE 2.30 'tested with same pics'" [High,New] [11:53] it's a precise user === BenC__ is now known as BenC [12:08] cjwatson: I hadn't. but yes I see a -12 now. That should come through in tomorrow's build results. (which I've just noticed say 'armle' even though they are armhf. That's rebuildd being thick (and currently hacked somewhat) I think. [12:10] could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Will check for SRU also [12:10] Launchpad bug 1000356 in freerdp (Ubuntu) "remmina/xfreerdp crashes while trying to use 'remote control'" [Undecided,In progress] [12:16] Who has the upload rights to main? [12:18] vibhav: https://launchpad.net/~ubuntu-core-dev + per-package-uploads [12:19] thanks [12:22] mvo: Does http://bugs.debian.org/674338 ring any kind of bell for you? It seems like it's probably an apt bug ... [12:22] Debian bug 674338 in src:germinate "germinate: FTBFS: test failed" [Serious,Open] [12:23] cjwatson: yes, its a recent regression with python-apt/apt in debian/unstable [12:25] mvo: Do you happen to have the bug number to hand? === _salem is now known as salem_ [12:25] That said the strace seems to suggest that the EBADFs are in dealing with a seed file ... [12:26] is the relaxed sru policy still under review, or is there hope for bugfix release sru's for precise sometime soon? [12:27] My code looks OK though, perhaps some coincidental interaction === WelshDragon is now known as Guest65315 [12:30] cjwatson: not right now, but I hope to find time to work on it today, juliank did figure out the issue already [12:31] stgraber, around ? [12:31] mvo: ok, cool, I've lobbed the bug over to python-apt as a first step [12:31] ok [12:32] cjwatson: It's a simple bug where apt passes a file descriptor to gzip, which closes it automatically, whereas the descriptor should not be closed automatically (unless requested so using an AutoClose flag in APT's FileFd) [12:33] OK [12:34] I like it when my test failures turn out not to be my fault [12:35] :) === mpt_ is now known as mpt [12:58] stgraber: rumour has it you run ubiquity from lxc container for testing is that true? [13:04] SpamapS, hey [13:16] what ever happened to deb patching anyway? [13:16] somebody changes 1 line of code in libreoffice and you have 6 packages to update and 300MB to download [13:17] Hell, somebody changes a 'recommends' to 'suggest' in LibreOffice and you have 6 packages to updated and300MB to download [13:19] mterry: ping [13:19] zul, pong [13:20] mterry: we have a couple of MIR that are blocking us, dwarves-dfsg, python-jsonschema, and python-repoze.lru can they be looked at toute suite? [13:21] its also blocking some SRUs as well [13:24] oi i need to do some MIRs [13:24] zul, OK. What's the SRU connection? [13:25] mterry: dwarves-dfsg is libvirt and python-jsonschema, python-repoze.lru (new deps for python-routes) is glance related [13:25] mterry: speaking about MIRs, are you aware that your openal-soft merge introduced quite a few new universe deps? [13:27] pitti, aw darn it. I forgot to check for that [13:28] I created some MIRs for many other universe deps after the intial debian syncs/merges, and also dropped a few dependencies [13:28] zul, sorry, am still confused. Why does an SRU for precise care which component a quantal package is in [13:29] mterry: because we need to fix glance in quantal in order to start an SRU for it and its blocked on jsonschema not being in main, and python-repoze.lru being a new build deps for python-routes [13:31] zul, OK, can start looking now [13:31] mterry: thanks [13:38] smoser: around now [13:39] xnox: yes, I run part of ubiquity in containers on my machine, though I doubt it'll work for you as I'm guessing you're working on partitioning and there isn't much we can fake from a container for that part [13:39] =( [13:39] ok [13:39] thanks [13:40] stgraber: do you get point & click interface though? =) [13:40] xnox: yes [13:41] stgraber, i think i was going ot ping about bug 993794 [13:41] Launchpad bug 993794 in network-manager (Ubuntu) "Precise can't connect to a network guarded by an authentication webserver whose address can only be looked up with one of the nameservers whose address is provided by DHCP" [Medium,Confirmed] https://launchpad.net/bugs/993794 [13:41] but i then realize its not actually a resolvconf issue, but really more network manager's issue [13:42] smoser: yeah, that has to do with the way dnsmasq balances the requests between the servers, I believe it mostly happens when the secondary servers answer faster than the primary one [13:43] well, its a generic issue. not related to speed really. [13:44] well, in theory dnsmasq will send the request to the server with the lowest latency, so if you primary server is the fastest one, you'll get the right record back [13:46] pitti: I'm trying to build ubuntu-drivers-common in my quantal chroot: http://paste.ubuntu.com/1004747/ [13:48] tseliot: hmm, thanks; I tried to build an earlier version in my PPA successfully, but that was two days ago already [13:50] tseliot: that's with latest aptdaemon, I presume? 0.43+bzr810-0ubuntu3 ? === MacSlow|lunch is now known as MacSlow [13:56] pitti: let me check [13:57] zul, for python-repoze.lru, is there a reason to not sync back up with Debian (we added delta to run tests, but added "|| true" because the tests failed on buildd) -- could we be more selective with tests that don't need network access? [13:58] we could be more selective [13:58] mterry: but im not sure how [14:00] pitti: the chroot used aptdaemon_0.43+bzr810-0ubuntu3 [14:00] tseliot: ok, thanks; I'll build a chroot here to replicate this [14:02] ok, thanks === larsu__ is now known as larsu [14:14] tseliot: so, a local dpkg-buildpackage still works fine here; I need to run out for a bit, but letting that chroot build in the meantime [14:15] pitti: ok, I'll try that [14:15] roaksoax: you appear to have dropped the dh_python2 delta in python-xattr by syncing it - this is not ok, python-support is package non grata in main. Can you please move this back to dh_python2? [14:20] slangasek: ah yes, my bad.. missed the fact that python-support was a Dep, while the package was being build with python2 from debian. :) Thanks for noticing === tsdgeos_ is now known as tsdgeos [14:21] roaksoax: the components-mismatches report makes us notice ;) thanks in advance for fixing :) [14:23] slangasek: :) is this sent over the ML? [14:23] * roaksoax needs to wake up... need more coffee [14:24] roaksoax: that's sent to the ubuntu-release ML [14:25] stgraber: cool thanks [14:25] * roaksoax needs to update his spam filters :) [14:26] and subscribe to it [14:34] pitti: building it locally inside a chroot: http://paste.ubuntu.com/1004842/ [14:40] seb128: hey back. :) Whats up? [14:42] SpamapS, is there any way you could review 2 SRU candidate for me today? [14:44] SpamapS, unity and bamf in precise (unapproved), those are overdue and I would really get them out before the w.e but not on friday in case there is any issue... [14:45] SpamapS, if you don't have time I will try with chance with slangasek or infinity next ;-) [14:45] SpamapS, hey btw, how are you? ;-) [14:46] seb128: that's bryce's bot [14:47] bdmurray, thanks [14:47] bryceh, hey, how is you bot deciding that a bug should be tagged "lucid"? it tagged a precise report "lucid" ;-) [14:47] seb128: why is friday a concern for pushing to -proposed? (not that I don't think we shouldn't get them out ASAP) [14:48] slangasek, "I'm there for too long", "french paranoia", "pick something that doesn't make sense to others" :p [14:48] slangasek, basically just me being paranoid about friday uploads [14:49] seb128: well... it's -proposed, we don't require or warrant them to be regression-free at that point :) [14:49] right, I still like to be around and to be able to deal with any issue if there would happen to be one [14:50] seb128: I'll do as many reviews as I can today. Will start in about 1 hour. [14:50] SpamapS, thanks [14:51] seb128: lots of uploads from kde update too, so the queue is getting backed up [14:51] SpamapS, well as said I would appreciate to get that unity one out, it's over due and fix some annoying bug in the default desktop on the lts [14:52] SpamapS, the other desktopish ones from me have lower priority [14:52] SpamapS, (bamf is included in the "unity update set" btw) [14:54] SpamapS, seb128: let me go ahead and queue-jump those two [14:54] slangasek, thanks! ;-) [14:54] seb128: btw, do all of the changelog-referenced bugs have test cases in the description? I'm going to be a hard-nose about that going forward :) [14:55] slangasek, yes, though the format is not strict, i.e they don't all start with TESTCASE:, but they all have steps to trigger the issue and what to test in the description [14:55] ok, sounds good [14:56] slangasek, didrocks has been strict on that, that's one of the reasons the SRU is coming a bit later in the week that planned ;-) [14:56] cool ;) [15:09] slangasek: thanks :) [15:25] tseliot: ok, I get the same errors in my pbuilder [15:25] pitti: I hope those errors make sense to you [15:26] I really don't know what's going on [15:27] tseliot: they don't make sense to me yet, looking now [15:28] hehe, ok [15:37] could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Should be SRU'ed also [15:37] Launchpad bug 1000356 in freerdp (Ubuntu) "remmina/xfreerdp crashes while trying to use 'remote control'" [Undecided,In progress] [15:38] dupondje, try asking chrisccoulson or mterry they are patch pilot today according to the schedule [15:38] doh, though chrisccoulson still didn't apply for upload rights I think [15:38] i'm meant to be patch pilot today? :/ [15:39] man, i suck ;) [15:39] come on! [15:39] :D [15:39] why do my patch pilot days always collide with firefighting? [15:39] chrisccoulson, yes you are! didn't google calendar email you? ;-) [15:39] remmina is in desktop [15:39] seb128, I will patch pilot, but I'm busy doing MIRs to unblock people now. :( [15:39] chrisccoulson, is there any day you are not firefighting? [15:39] dupondje, I will look at it later today if chrisccoulson doesn't first [15:39] mterry, no hurry ;-) [15:40] tseliot: ooh, it makes perfect sense now [15:40] pitti: what is it? [15:41] - @unittest.skipUnless(os.path.isdir('/sys'), 'no /sys dir on this system') [15:41] + @unittest.skipUnless(os.path.isdir('/sys/devices'), 'no /sys dir on this system') [15:41] tseliot: pbuilders/chroots have an empty /sys [15:41] but it tries to access /sys/devices/ [15:41] micahg: its bug in FreeRDP lib :) [15:41] pitti: ok, that would explain it [15:42] tseliot: pushed [15:42] ah, yeah, freerdp is in core [15:42] tseliot: I get some more errors in my pbuilder, but these two are the ones you got [15:42] Would like to fix some more things in Remmina/FreeRDP later on [15:42] cause there seems to be alot of complaints [15:42] pitti: can I pull the code? (in my local branch) [15:43] broken things :( [15:43] tseliot: yes, I pushed to my branch on github [15:43] tseliot: perhaps wait a bit with merging it into your official one until it's working? [15:43] pitti: yes, that's just for testing things locally [15:44] tseliot: "GError: Query type 'modalias' is not supported" means that the PackageKit plugin crashed; I'll try to get a better error message out of that [15:45] in fact, I already have some provision for that: setting APTDAEMON_LOG and APTDAEMON_DEBUG in tests/ubuntu_drivers.py [15:46] pitti: it builds here. Maybe add packagekit-backend-apt to the dependencies? [15:46] oh, that's separate now? [15:47] tseliot: hm, I'd need python-aptdaemon.pkcompat | (packagekit && packagekit-backend-apt) [15:47] I guess that expands to pkcompat || packagekit, pkcompat || p-backend-apt [15:47] (deMorgan, was it not?) [15:47] ah, now I see what's wrong with the other tests [15:48] ok [15:50] pitti: shall I just test it with jockey-text? [15:51] tseliot: shoudln't matter which jockey frontend you use === v is now known as vorian [16:00] pitti: I don't think it can be tested in a chroot as it looks for the result of "uname -r" which doesn't match the kernel in the chroot: http://paste.ubuntu.com/1004953/ [16:00] (which is 3.4) [16:01] tseliot: oh, you mean jockey, not ubuntu-drivers? [16:01] tseliot: yes, ubiquity calls it with -k [16:01] that overides uname -e [16:01] pitti: yes, which I need to test ubuntu-drivers, no? [16:01] err, -r [16:01] ah [16:02] pitti: sudo jockey-text -l --no-dbus -k 3.4.0-3-generic doesn't seem to work [16:05] slangasek: just fyi, we uploaded a software-center 5.2.2.1 for precise SRU that targets just the two issues, per our discussion yesterday [16:07] slangasek: I did most of the verifies yesterday, I'll finish the last of them for 5.2.2.1 soon [16:08] tseliot: ok, now fully builds for me as well; pushed a small fix again [16:09] pitti: good. How shall I test it now? [16:10] tseliot: would you be ok with pulling this into git, and me uploading the current trunk? [16:10] pitti: sure, feel free to make a pull request and to upload [16:12] mterry: repoze fixed now i think [16:12] zul, awesome [16:15] cjwatson: I believe its due to the cron not being turned back on after having it off for a bit for some troubleshooting.. an oversite most likely.. I have requested from IS that it be investigated.. [16:21] doko: OK with you if I sync nmap from Debian? delta no longer required (Debian have moved to dh_python2) [16:21] cjohnston: thanks [16:21] tseliot: argh, got disconnected [16:22] pitti: sure, feel free to make a pull request and to upload [16:22] cjwatson: its re-enabled [16:22] great [16:22] tseliot: ah, thanks [16:22] thanks for pointing it out [16:23] tseliot: https://github.com/martinpitt/ubuntu-drivers-common/commits/master now has the release tag as well [16:23] tseliot: pull request sent [16:23] cjohnston: How frequently does it normally run, and how long does it generally take to update? Just so I know how long to wait before reporting something in future ... [16:24] cjwatson: its now at every three hours :-( [16:24] pitti: merged, thanks [16:24] so it could be up to 6 hours from now in theory [16:24] tseliot: uploaded [16:24] tseliot: thanks for testing it! [16:24] \o/ [16:24] cjohnston: Fun [16:25] cjwatson: it should be brought up for discussion during the release meeting [16:25] it needs some love [16:25] i most likely wont be there for it, but pitti seb128 and skaet are all aware of the issue [16:27] tseliot: would it be possible for me to directly commit to the official branch? [16:28] pitti: let me check [16:28] tseliot: I can e. g. commit to packagekit, hughsie gave me access [16:29] tseliot: Admin -> Collaborators perhaps? [16:29] pitti: I've just done that. Can you see if you have access? [16:30] tseliot: yep, page grew an "ssh" checkout now; thanks! [16:30] pitti: excellent :) === Guest65315 is now known as WelshDragon [16:34] good night everyone! [16:40] zul, hiyo. In python-jsonschema, you write that it's "An(other) implementation of JSON Schema". Are there others? Presumably none in main yet? [16:41] none in main yet [17:02] zul, your patch for repoze.lru just comments out the tests, which doesn't seem like a real fix. Do we know why they are failing? [17:03] mterry: no they work fine locally but not in the buildds [17:05] zul, if they are provably bogus failures, that's one thing (and the patch should document why), but it's not clear these are completely bad tests (or at least, just need some grease to work in the buildd). [17:06] mterry: so document the patch and try to get a real fix later? [17:08] zul, I meant the patch should document why the tests are provably bogus. We don't have enough information to document it one way or the other [17:09] zul, I'd like either a real fix or a real explanation for why they are failing in buildd and why it's OK to ignore them [17:09] mterry: i dont have enough information for you why they are failing but this is blocking python-routes which is blocking glance f1 [17:11] and i dont have enough experience with repose.lru either [17:13] zul, so once you get this in main, you update glance, and then how does that work with precise? You're not moving python-repoze.lru in precise, right? [17:14] mterry: no we arent just quantal [17:14] zul, so you're selectively backporting parts of glance to precise? But you still need the version update in quantal before you backport? [17:15] mterry: yes and yes [17:15] but repoze.lru is not a requirement for precise [17:16] zul, can your team commit to fixing the test stuff before alpha 1? (I'm OK with waving my hands at the tests for now, but they shouldn't stay broken) [17:17] (and by fix, it may just mean explaining why buildd's can't reasonably run those tests) [17:18] mterry: yes i can commit to fix the test stuff before alpha1 [17:18] zul, cool. I'll file a bug for that and assign it to the server team (or you?) [17:18] mterry: preferably me :) [17:23] zul, cool, approved that one then. Just the dwarves one has problems then, I believe [17:29] mterry: yeah ill have a look after im done here [17:30] pitti: any chance of having someone looking at kernel linux-ec2: 2.6.32-345.48 ? [17:31] slangasek: regarding /dev/shm (set up by initscripts), I notice that sid has /dev/shm as a bind mount of /run/shm; precise has it as a symlink. Is that difference intended? [17:31] (it affects whether sid's initscripts postinst can be deemed broken or not) [17:31] pitti: we have the next kernel ready to upload, but we can't do it before this one is moved away from proposed [17:32] hallyn: a bind mount? surely that's only in a chroot? [17:32] nope [17:32] amazon ami [17:32] hallyn: or prior to the first reboot? [17:32] er [17:32] then I think the ami was built wrong [17:32] feh [17:33] the bind mount is supposed to be a temporary "until next reboot" measure in the upgrade handling [17:33] after which it should be replaced by a symlink on shutdown [17:34] hm. lemme look through its init [17:36] yeah maybe i need to reboot the ami [17:39] except of course it doesn't want to reboot === adrient is now known as finch [17:43] slangasek: phew, right you are. (for some reason after reboot /proc didn't get mounted, but I'll assume that's not my problem for now - instance badness) [17:43] so /dev/shm after reboot -> /run/shm. [17:43] * slangasek nods [17:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry === 16SAA9EKO is now known as robert_mac === dendro-afk is now known as dendrobates [17:52] * dholbach hugs mterry [17:52] jcastro, you got your chrome unity fix in proposed, thanks to Trevinho for the fix, popey for the packaging work and slangasek for the SRU processing ;-) [17:54] Auto-sync from unstable in progress, as agreed at UDS [18:00] seb128, it scans for mentions of 'lucid' or '10.04' in description or comments (think it may look in attachments too.) Certainly it isn't foolproof [18:02] bryceh, ok, the bug description says "it was working on 10.04 but it's not on 12.04" so I guess that's it [18:02] bryceh, you don't use the same logic to tag "precise" if 12.04 is mentioned? [18:04] seb128, yeah that type of description will get it doubletagged. [18:04] bryceh, well it got only tagged "lucid" in this case [18:04] bryceh, i.e no precise tagging [18:05] seb128, it should use the same logic for tagging precise; if it isn't then that's a bug. point me at the bug report and I'll investigate when I get a chance [18:05] bryceh, it's https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249 [18:05] Launchpad bug 1001249 in xorg-server (Ubuntu) "EYE for Gnome 3.4.1 installed with Ubuntu 12.04 freeze the computer when displaying jpeg pictures from my nikon camera this is not the case with my 10.04 install having EYE 2.30 'tested with same pics'" [High,New] [18:05] bryceh, thanks [18:06] seb128, ah, well to be honest these days I rely more on apport adding the tag when running apport-collect or ubuntu-bug [18:07] since most of the time if they've filed a report without doing that, their bug usually is not diagnosable anyway [18:07] bryceh, I don't rely on the feature, I was just curious why a precise bug got tagged "lucid" [18:07] but I'll check my script [18:08] bryceh, thanks, though it's very low priority, I was mostly curious there so don't bother much about it [18:11] seb128, hah, found it [18:11] the bot uses brad's kernel lookup table, which hasn't been updated since maverick [18:11] easy fix... === dendrobates is now known as dendro-afk [18:20] pitti, sorry to bother you again with what I was asking earlier. If I install a .deb with conffiles with owner root, then in my postinst chown www-data those files, then at some later date install an upgraded version of the package, will it treat those conffiles as changed (and thus not reinstall them) or will it leave them as it is? [18:20] s/leave them as it is/install the new versions/ [18:22] I'm reading this: "Note that a package should not modify a dpkg-handled conffile in its maintainer scripts" <- does this only apply to the contents of conffiles, or also their permissions? [18:27] alexbligh1: generally applies only to the contents [18:28] dupondje, btw, doing your bug now. Thanks for the patch! [18:28] dupondje, uploaded to quantal, working on SRU for 12.04 [18:29] slangasek, so I am safe to chown conffiles in my postinst? I'm just wondering whether I should should be doing override_dh_install and a chown there at build time... === robert_mac is now known as robertk_away === robertk_away is now known as 16SAA9EKO [18:30] alexbligh1: files are stored in the .deb by numeric uid and you can't rely on that being the same on the build system and target system (sometimes you can't rely on the user existing at all on the build system) [18:31] well... www-data is actually an exception [18:31] because it's in /usr/share/base-passwd/passwd.master :) [18:31] so actually, yes, you can chown them in the package [18:32] slangasek, may be override dh_fixperms then, and do a chown www-data:www-data $(CURDIR)/debian/$(package)/etc/foo [18:32] ? [18:33] alexbligh1: yep, that works in principle [18:33] though, I do have to ask, why is www-data supposed to be able to write to these files? [18:33] we generally try hard to *not* let web apps write their own configs [18:33] since that tends to lead to security problems rather quickly [18:36] slangasek, they aren't really configs. They're .po files for different translations. [18:37] so a) why do they need to be owned by anyone other than root? b) why do they belong in /etc/ [18:37] ? [18:40] slangasek, (a) so they can be uploaded through the webserver, (b) well, there are two ways of configuring these, the old way (which involves editing the files), and the new way which involves the pofile being uploaded, sanitised, running msgfmt on it, and putting it somewhere. I really don't want to suid the last process, hence owned by www-data. They are in /etc because we want conffile behaviour on upgrade. [18:40] (so yes they could be elsewhere but I still have the conffile interaction) === nxvl_ is now known as nxvl [18:49] alexbligh1: well, if you're going to this much trouble to enable them to be updated via the webserver, I think conffiles are the wrong mechanism; it would probably be better to ship these as templates under /usr, and copy them to /var at package install time, letting the webserver update them there [18:50] tremolux: software-center accepted into -proposed now; and apologies, I had noticed the oddness of the fix for bug #999486 being commented out when reviewing the debdiff for the last one but didn't follow up [18:50] Launchpad bug 999486 in software-center (Ubuntu Quantal) "AttributeError: 'NoneType' object has no attribute '__contains__' when clicking the All Software button" [Low,Fix released] https://launchpad.net/bugs/999486 [18:51] tremolux: oh, hold up - not accepted just yet [18:51] slangasek: oh, no worries, yeah, we overlooked that :/ [18:51] tremolux: hmm - it seems someone has already published 5.2.2 to -updates, that was unexpected [18:52] 5.2.2.1 accepted into -proposed now [18:52] slangasek: ?? really? [18:52] yes [18:52] I don't know who or why [18:52] slangasek: hmm, not all of the verifies were complete [18:52] yeah [18:52] well, it's done now [18:52] slangasek: but it should not be a problem, we have all of those fixes in trunk and test everyday [18:52] * slangasek nods [18:55] slangasek: so to get 5.2.2.1, we just need do the remaining verifies? (most of the unverified bugs from 5.2.2 were related to the regression and the disabled fix actually) [18:55] tremolux: yes [18:56] slangasek: ok, I'll look for it on here and take care of them: http://people.canonical.com/~ubuntu-archive/pending-sru.html [18:56] slangasek: thanks a lot for your help! [18:56] tremolux: no problem :) [19:08] bryceh, oh, good, thanks! [19:20] slangasek, s-c, @who; pitti (from -changes), why: I guess it's "90% of the bugs verification-done and no verification-failed or regression signaled on a long list of bugs" === pp7 is now known as malkauns [19:21] slangasek, it's sometime tricky to wait that all bugs are confirmed on such updates and if most bugs are verification-done and nobody pointed regression it's better to get moving that to stale [19:22] well === dendro-afk is now known as dendrobates [19:23] slangasek, just saying, and I might be wrong so keep the discussion for pitti if you disagree ;-) [19:23] honestly, I would rather we be prepared to kick proposed SRUs back out if we can't get full coverage [19:24] but yeah... the problem here is that tremolux had been talking with me about it, but we didn't actually mark any of the bugs verification-failed to block its promotion [19:24] right [19:25] that's one of the issues pitti raised on the list about SRU team and bug emails flood [19:25] somebody has to watch for any regression mentioned in any of the bugs and set a failed flag somewhere [19:25] I don't think it was mentioned on the bug [19:25] on any bug [19:25] slangasek, another issue with such uploads is that apport bugs often have no steps, they are like "they happen randomly to some users", so it's hard to get verification-done [19:25] we should've flagged it with the tag [19:26] i.e fixed come from guessing from the stacktrace [19:26] but it's hard to find anyone to verify the fix === dendrobates is now known as dendro-afk [19:27] we can't block the updates for ever because "obvious code fixes" didn't get verified by anyone [19:27] yes, well, errors.ubuntu.com will help with that eventually :) [19:27] it helps if we see that the issue stop being reported [19:27] but it means we need a progress tracking for specific issues which I think we don't have yet? [19:28] yep - hence, "eventually" [19:29] slangasek, seb128: for bugs that are impossible to consistently reproduce (there were a couple out of about 20 fixes in this SRU), we simply try to provide the steps that can cause it and ask the verifier to do those steps repeatedly..that sort of thing [19:29] slangasek, seb128: but we are definitely counting on errors.ubuntu.com, because that's where we prioritized them from [19:30] tremolux, right, it's not specific to you, most of the segfaults are like that [19:30] i.e we have g-s-d segfaults which apparently randomly happen at logout in a racy way [19:31] it's hard to test them out of checking that the update creates no regression and watch the reporting status [19:31]