[00:19] slangasek: WOuld it be better to have a new bug for the alsa-{lib,plugins} SRU, or should I use an existing bug, like the one you adjusted task status on yesterday? [00:22] TheMuso: better to use the same bug, I think [00:22] slangasek: Ok I thought so too, but just wanted to be sure. [00:22] w31 [00:22] oops [01:13] slangasek: SInce the alsa bits are new upstream, is it ok for them to be in a PPA, instead of a diff? Or would you prefer a diff? I will attach the changelog entry of course. [01:13] TheMuso: in practice, we don't normally review or require diffs submitted to bugs for main SRUs, we just debdiff the queue [01:14] slangasek: Ok. [01:15] So in this instance, should the version number be the same as intrepid, or should it be something like 1.0.16-2ubuntu0.1? [01:15] it can never be the same [01:15] Right. [01:16] if you use 1.0.16-2 as a base for your work, then 1.0.16-2ubuntu0.1 would be ok; but please be cautious about introducing unrelated packaging changes relative to what's in hardy [01:16] * TheMuso nods. [01:20] Well in that case, I might only update to the new upstream, and subject to finding out the usefulness of any other patches Debian has added, add them also... [01:21] yes, that's what I would recommend [01:59] slangasek: looking at the diff for openldap SRU, I've noticed that: http://paste.ubuntu.com/19764/ [02:00] slangasek: would this be a problem in terms of ABI changes ? [02:00] "static int", so no [02:02] slangasek: but that is an API change right ? [02:09] mathiaz: no, it isn't; "static" functions are local to the file they're defined in, so this isn't part of any API visible from outside this one source file [02:16] slangasek: What's the relationship between hardy-backports and 8.04.1 ? If I backport Wine 1.0 to Hardy, will that stay in -backports forever, or can it be promoted in some sense? [02:18] YokoZar: -backports and 8.04.1 (which is -updates actually) are two different repositories [02:19] mathiaz: Yeah, I suspected as such. I just wondered if it might be appropriate to push some things in -backports to -updates for 8.04.1 [02:19] not really, no [02:20] -updates is for post-release fixes of critical bugs; not for new upstream versions, except for very specific exceptions [02:21] Like Firefox and such for 8.04.1 [02:21] I guess I'm just wondering how 8.04.1 is different from a handful of SRUs. [02:23] the main difference is that there are now ISOs issued [02:23] s/now/new/ [02:29] slangasek: It seems that only bluetooth audio/alsa packages add other plugins to be used with alsa. Alsa plugins live in /usr/lib/alsa and only bluetooth-alsa and bluez-audio packages add extra shared objects in that directory. [02:29] usr/share/alsa-lib even [02:34] TheMuso: right [02:37] slangasek: I'm not sure if this diff is suitable for an SRU (http://paste.ubuntu.com/19768/) [02:38] slangasek: there seems to be some changes in the libldap_r library [02:43] mathiaz: anything that's ldap_int or ldap_pvt is actually not part of the published APIs, either; so I would still be willing to accept such changes in an SRU. But if you'd prefer, I'd also be happy to have only the select bugfixes backported and applied :) [02:45] slangasek: oh no no - if that's fine with you I'd rather go with 2.4.9 :D [02:45] slangasek: and we'll probably get 2.4.10 in hardy as well [02:46] slangasek: at a later time though [02:54] Considering that openldap-2.4.9 is already in intrepid, do I need to include openldap-2.4.9.orig.tar.gz in the upload to hardy-proposed ? [02:57] mathiaz: AFAIK it won't matter [03:01] slangasek: well - I've uploaded the orig.tar.gz file - we'll see [04:11] slangasek: I've slightly adjusted the regression potential in the bug, and attached plugins and lib upstrea mchangelogs. DO you want to look over them first, or should I upload? [04:24] TheMuso: go ahead and upload please, I won't be able to review it in real time at the moment [04:27] slangasek: Ok. [05:20] jcastro: btw i think i will go in and mark the upstream'd bugs as triaged to make it easier for the page to track status [05:21] jcastro: it seems now that we have triaged that is the preferred way to do it anyway [05:21] calc: Confirmed is going to go away soonish from LP, so don't get too used to having the two status choices. [05:22] ScottK: Is that completely confirmed? I thought there were other projects that had valid use cases to preserve confirmed, and that might also impact Ubuntu. [05:22] ScottK: What is it being replaced with? [05:23] A 'me too' button so users just click there and you get a me too count instead of a bazillion useless me too comments. [05:23] persia: Nothing in Launchpad is ever completely confirmed. Not even after it's implemented because they might take it back. [05:34] ok [05:35] well i'm moving everything that is confirmed by me to triaged since it seems that is a good use of that status [05:35] i had been using confirmed as i could reproduce it but it seems that would be better as triaged [05:36] then let users use a me too or confirmed or whatever [05:37] calc: that seems to make sense [05:37] from what I gather no one has just declared "we're using triaged now." [05:38] I've always used confirmed when I can reproduce it, and triaged when the bug report contains a sufficient information for a solution (which are not always the same thing). [05:44] jcastro: We get what LP implements and that's what they said they were planning at UDS. Plans change of course. [05:44] yeah [05:44] My concern is that not everyone knows that [05:45] I think most developers are well aware the we get whatever LP decides to implement. [05:45] heh [05:47] Good night. [05:47] gnight [06:32] good morning [06:34] hi dholbach [06:34] hi ajmitch [06:36] Good morning [06:38] Hi [06:38] jussi01: you're welcome :) [06:39] kirkland: ugh, fstab dynamically? that doesn't sound like a final solution? [06:39] pitti: i'm also going to look into capabilities [06:39] kirkland: so PAM can't be fixed to umount as root during logout? [06:40] pitti: it's ssh that would have to be fixed, i think [06:40] pitti: additionally, i'm going to look into kernel capabilities [06:41] pitti: when sshd switches execution back to pam on logout, the context is running with uid 1000 (not 0) === dholbach_ is now known as dholbach [06:41] kirkland: hm, keeping CAP_SYS_ADMIN as an user process is almost as good as root [06:41] pitti: it's more finegrained than setuid, methinks [06:42] kirkland: maybe we should reconsider a hal-based solution then [06:42] kirkland: or at least d-bus [06:42] pitti: i'm open to either [06:42] pitti: if you think they can be completed within intrepid [06:43] kirkland: if you create your own dbus service, that's relatively easy, and we do not need to touch hal [06:43] it's a much bigger cannon than using PAM admittedly, but it gives us the fine-grained privileges you need [06:44] pitti: okay.... i might need a primer at some point [06:44] pitti: which sprint are you attending? [06:44] kirkland: London [06:44] :-/ hmm [06:44] seems like the several people i need to work with are going to London [06:45] kirkland: other question: do you have a running daemon process for transparently unencrypting ~/.Private to ~/Private? [06:45] i. e. is it like FUSE? [06:45] or does the kernel handle that? [06:46] pitti: kernel [06:46] pitti: handled by mount === tkamppeter_ is now known as tkamppeter [06:47] pitti: a pam module, pam_ecryptfs takes your password on login, and unwraps an encrypted file containing a mount passphrase, and inserts it into your kernel keyring [06:47] kirkland: I wonder whether it would be more elegant to have the kernel itself umount ecryptfses once the last user process dies [06:47] pitti: i had dinner with the maintainer tonight, and discussed that to some extent [06:48] pitti: there is an ecryptfsd daemon (which we're not using at the moment for ~/Private work)... he suggested that it could be tought to do so [06:48] kirkland: what is it used for? [06:48] kirkland: couldn't that just clean up umounts? [06:48] pitti: other forms of key management besides passphrase (openssl, TPM, pkcs11) [06:49] pitti: it probably could be made to do so [06:49] ah, so it isn't really meant for managing the mounts [06:49] pitti: not currently, no.... key management more so it's currently duty [06:49] kirkland: my idea was to start a daemon in the background on login which will trigger the umount when it exits [06:50] but having a daemon for each logged in user which does nothing all the time doesn't make me too happy either [06:50] pitti: right [06:50] so if that's done by a central daemon, that would be much more useful [06:51] pitti: perhaps, but i keep asking myself if entries in /etc/fstab are really that horrible [06:51] * pitti doesn't like constantly changing configuration files [06:52] pitti: constantly? [06:52] pitti: it would only get changed on adduser [06:52] and it's subject to all sorts of race conditions, confuses backup software, etc. [06:52] pitti: well, userdel too [06:53] kirkland: oh, not on login? (dynamically creating a stanza for logout) [06:53] pitti: no no no [06:53] kirkland: if it's that static, how do you handle NIS, AD, etc.? [06:53] pitti: :-) [06:53] pitti: local users only [06:53] kirkland: but seriously, I'd rather teach umount to allow you to umount your own ecryptfses than fiddling with fstab [06:53] pitti: at this point [06:54] pitti: okay [06:54] pitti: the guys i had dinner tonight with were talking about some new "user mounts" work in the kernel [06:54] pitti: someone named Mikko? working on it, i think [06:55] pitti: not in yet, perhaps -mm? [06:55] kirkland: so if you could do "umount ~/Private" as normal user, that would basically solve it with pam-mount? [06:56] that approach is pretty much what we did with pmount in warty to breezy [06:56] pitti: i think so [06:56] pitti: i'll create a super-umount tomorrow and test it out [06:56] pitti: for testing purposes ;-) [06:56] and umount already allows users to umount stuff [06:56] pitti: if its in /etc/fstab, yeah [06:57] pitti: and is set as a "user" mount in the options [06:57] kirkland: so, ecryptfs-utils could ship wrappers "ecryptfs-mount" and "ecryptfs-umount" which do pretty much that [06:57] check that what you try to do is sane, and call mount/umount [06:58] that's not a highly elegant solution, but it's doable in intrepid with the technology that we have today [06:58] and if it's hidden in a PAM module, we can transparently change the technology to kernel user mounts later [06:59] "it" -> the call to ecryptfs-umount [06:59] kirkland: actually we won't even need e-mount, right? [06:59] pitti: that's pretty much what i've created, see .... http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-mount-confidential;hb=HEAD and http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-umount-confidential;hb=HEAD [07:00] just e-umount, and that just needs to traverse /proc/mounts and compare uid, path (owned by caller), and fstype [07:00] kirkland: right, except you need to write that in C, so that you can suid root it (and add more defensive checks) [07:01] pitti: sure, that's doable [07:01] kirkland: feel free to look at pumount.c and take the sanity checks from it [07:01] pitti: thanks for the pointer, i'll do that [07:02] pitti: so i can store the mount options as variables i store in a ~/.ecryptfsrc file or something [07:02] pitti: source that (read in C) [07:02] pitti: sanity check [07:02] pitti: and suid do the mount for the uesr [07:02] kirkland: what would be in that file? [07:03] kirkland: AFAICS, you don't need to permanently store anything else than the encrypted key, right? [07:03] pitti: cypher type, key length, key fingerprint [07:03] right, so basically the key and its metadata [07:03] pitti: yeah [07:03] kirkland: but why do you need that on umount? [07:03] pitti: and the data dir and mountpoint [07:04] pitti: in case you want it somewhere other than ~/Private (IBM uses ~/Confidential) [07:04] pitti: oh, not on umount [07:04] kirkland: no, you should get that as a command line arg, and verify it in /proc/mounts [07:04] please don't store information about mounts in ~ [07:04] pitti: sorry, i was thinking about writing both e-mount and e-umount [07:05] kirkland: ah, I see [07:05] yes, that makes more sense; so the user can choose which dirs to mount on login [07:05] pitti: as you see above, i have both in shell form now [07:06] pitti: also, i like changing the perm on the ecrypted underlying dir to 500 when not mounted [07:06] pitti: to keep from inadvertently writing something in there unencrypted [07:06] pitti: as well as the mountpoint (same reason) [07:06] pitti: but keep r-x------ for backup purposes [07:07] right [07:07] pitti: that's sort of a custom job for these sorts of mounts [07:07] pitti: and on mount, we have to bump up the perms to 700 [07:07] kirkland: I hope the mount script doesn't come from upstream, but is just a local test script of your's :) [07:07] pitti: it's evolving [07:08] (I mean because of the nice root privilege escalation) [07:08] pitti: ? [07:08] pitti: those two scripts are not currently setuid [07:09] pitti: b/c they rely on the mounts being in fstab [07:09] good evening [07:09] no, but they certainly run as root, don't they? [07:09] pitti: /bin/mount and /bin/umount are setuid [07:09] pitti: nope [07:09] pitti: they don't [07:09] kirkland: ah, I thought you'd call them from pam [07:09] hey kees [07:09] pitti: no, i call them from .bash_profile and .bash_logout [07:09] kees: highlight on "root privilege escalation"? [07:09] pitti: and .config/autostart/foo [07:09] kees: :-) howdy [07:10] pitti: hahah, no, but I should. ;) [07:10] (actually highlighted on "regression" for a while back) [07:10] I'm just up doing xorg publication [07:10] pitti: you with me now? [07:11] kirkland: yep, sure [07:11] pitti: pam as root unwraps your mount passphrase and inserts it into your kernel keyring [07:11] kirkland: so the umount script will have s/umount/ecryptfs-umount/ [07:11] pitti: okay.... [07:12] and the mount one will run from pam as root (and thus needs robustification), or do you want to create an ecryptfs-mount (which then needs to be robust)? === Mithrand1r is now known as Mithrandir [07:12] Mithrandir: good morning [07:12] pitti: hiya, how's intrepid going? [07:13] Mithrandir: I don't know much TBH; I'm still on hardy duty [07:13] pitti: i don't think i follow your last statement [07:13] ah, wrapping up all the loose bits so .1 will shiny like, uh, something shiny? [07:13] Mithrandir: exactly! *bling* [07:14] kirkland: I meant, what's your final design for the mount step on login? from pam as root, or from the user's account with a suid root ecryptfs-mount? [07:15] pitti: so if pam_mount worked as advertised, i'd use that. and by that i mean if it were able to both mount and unmount, I'd prefer using it. [07:15] pitti: if that can be solved, i'm all for it. i want to talk to cjwatson a bit more about the ssh end of it [07:16] kirkland: ok; looking forward to trying it out eventually :) [07:16] pitti: b/c it works for local user locals on the console, but not ssh [07:16] kirkland: "b/c"? [07:16] pitti: oh, b/c means that this is an ssh issue [07:16] b/c = because [07:16] Mithrandir: ah, your appearance has reminded me to post my zombie meme [07:17] kirkland: well, if the problem is only on the umount side, and solved with ecryptfs-umount, then everything using pam, including ssh, should work with it [07:17] pitti: there's one other side effect of the ssh/pam_mount bug, that might be fixed separately [07:17] pitti: pam_mount accounts the number of open sessions a user has in /var/run/pam_mount/username [07:18] pitti: increments/decrements it [07:18] kees: zombies > * [07:18] pitti: but on ssh logout, the pam_session_close running as uid 1000 doesn't have sufficient privilege to decrement [07:18] kees: I was wondering how much I should have made mine D&D-themed. [07:19] pitti: i think that can probably be solved by changing the group ownership and g+w of that file [07:19] pitti: so let me see if i can get an suid ecryptfs-umount working [07:20] pitti: is that the one you were suggesting should be in C? [07:20] kirkland: yes, to be able to suid root it [07:20] kirkland: eww @ user-writable reference counter [07:20] why does it need to be in a file in the first place? [07:21] pitti: after my 48 hours with pam_mount, i have a very low opinion of the module in general [07:21] 'who' knows about all sessions, so they must be stored *somewhere* [07:21] Mithrandir: heh. I liked it as is. I haven't been able to think of a better famous person. :) [07:21] kirkland: right, I'm not saying that you should use exactly pam_mount; yesterday I just thought that it does a very similar thing, and that it might be worth taking a look at it [07:21] kees: the archangel gabriel might work well too. [07:22] pitti: i point you back to my script .... http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=blob_plain;f=src/utils/ecryptfs-umount-confidential;hb=HEAD [07:22] pitti: note the call to `who | grep | wc ` ;-) [07:22] anyway, off to work. :-) [07:22] kirkland: right, I know; I just wonder why the heck libpam-mount does it that way [07:33] * Hobbsee_ waves [07:33] * RAOF shores [07:35] heya Hobbsee_ [07:36] kees! [07:36] how goes it? I'm up this late so rarely. :P [07:37] kees: just done the evil networkign exam. [07:37] kees: so i'm glad that's over :P [07:37] oooh, computer networking? [07:38] yeah. [07:38] would be good, if they can actually mark correctly. *shrug* [07:39] but when two people give the same answer, and one gets marked right, and one wrong, it's not exactly inspiring confidence :P [07:40] Hobbsee_: ewww [07:40] Hobbsee_: just general networking, or some specific sub-topic? [07:41] kees: general. [07:43] * Hobbsee_ heads home, hoping to aviod the traffic. [08:13] seb128: hm, seems that the SRU in bug 209662 didn't fix the problem? [08:13] Launchpad bug 209662 in deskbar-applet " processes" [Low,Fix committed] https://launchpad.net/bugs/209662 [08:13] seb128: oh, good morning! [08:14] hey pitti [08:14] pitti: right [08:14] pitti: but there is no regression either and it fixes several other issues [08:15] seb128: did you try out the .debs from -proposed? [08:15] seb128: if it generally works, I'm fine with copying and reopening the bug [08:16] pitti: yes, I'm running it on my laptop and old old desktop without issue [08:16] ok, thanks [08:16] pitti: and no bug has been opened on launchpad about it recently either [08:16] mvo: hey [08:17] hey seb128 [08:17] mvo: could you have a look to http://launchpadlibrarian.net/15239248/buildlog_ubuntu-intrepid-i386.compiz-fusion-plugins-extra_0.7.6-0ubuntu1_FAILEDTOBUILD.txt.gz today? it's making compiz not installable on intrepid [08:18] seb128: sure [08:18] thank you [08:24] whos archive-admin day is today? I filed some sync requests last week and would like to ask about those :) [08:25] o/ [08:26] pitti: I can give you a hand on archive admin tasks if you want, I've been too busy on wednesday to do a lot of those again [08:26] pitti: do you plan to check on the syncs today? its not urgent, but it would be nice to get them off the list on merges.u.c [08:26] seb128: that would be great; still working on SRUs, but I'll do archive admin later (I also need to tend to MIR, argh) [08:26] mvo: yes, definitively [08:27] seb128: what would you like to start on? [08:27] pitti: ok, doing syncs and backports now [08:27] I tihnk I should apply too, looks like we could do with some more hands [08:27] * pitti hugs seb128 [08:27] * seb128 hugs pitti [08:30] * mvo waves to davmor2 [08:31] morning mvo :) [08:31] germany finally had rain [08:32] lots of it yesterday [08:35] seb128: I'll start off with removals, archive bugs, and component-mismatches then, and go on with MIR [08:36] seb128: you'll also do a sync-source -a? === thekorn__ is now known as thekorn [08:38] pitti: yes, I've done some of those yesterday already [08:38] pitti: will do an another one now [08:38] pitti: I'll try to tacklo some of the NBS list too [08:38] oh, great, thanks! [08:42] <\sh> sladen: still in .de? [08:47] <\sh> I wonder if there is any possibilty to make urllib2 report a progress of the connection/reading/closing socket state....as urllib.urlretrieve can do via hook [08:55] * Hobbsee waves [08:56] Hobbsee: Back home? [08:57] \sh, you can read the content block-wise in a loop [08:58] <\sh> thekorn: yes...but this is not working, because for that I would have to change pylpbugs ;) [08:59] <\sh> thekorn: question is, I need to show the user a infobox while the buglist e.g. is being fetched...(which takes time)...and for this i need something like a hook inside pylpbugs which gives me a status somehow [09:01] \sh, hehe, you are right, I think it's easy to add such a hook interface to py-lp-bugs, [09:01] I think there is a bugreport open for this [09:02] \sh, btw. nice LP gui! did you publish the source somewhere? [09:03] <\sh> thekorn: yes...it's on my lp code page...brb meeting [09:04] ok, cool [09:12] Lutin: hi [09:13] Lutin: when you open sync request could you describe what the ubuntu changes are instead of writting that they are all in debian now which is expected anyway if you open a sync request [09:13] Lutin: thank you [09:40] \sh, I added a patch to bug 239684 to add such progress-hook thing to py-lp-bugs [09:40] Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684 [09:58] <\sh> thekorn: cool...I'll test it later...estimation meeting done...new infrastructure meeting now....my life is doomed now ;) [10:03] Riddell: hm, all kde-i18n-* were demoted to universe in intrepid; component-mismatches complains now (seeded in DVD); was this deliberate or a glitch? [10:04] pitti: if you do seed edition please drop workrave too ;-) [10:04] seb128: demoted [10:04] danke [10:04] I'm not currently touching seeds, though [10:09] so, NEW and hardy-proposed queues empty; nobody touch anything now! :-) [10:10] pitti: and syncs cleaned [10:11] * mvo hugs seb'sync-master'128 [10:11] * pitti hugs seb128 [10:12] seb128: you said you're going to do the backports as well? doing the other archive-admin bugs now [10:13] pitti: there is almost no backports to do in fact, will have a look later, I want to catch up on bug mails first now [10:13] right; thanks [10:13] np, feel free to do the few backports listed in the bug list [10:13] I'll do those later otherwise [10:14] * pitti does the remaining two syncs [10:14] pitti: the flushing is in progress btw [10:14] oh, ok; will wait [10:22] pitti: kde-i18n can be unseeded [10:22] replaced with kde-l10n-* [10:23] aah [10:23] Riddell: so the packages shuold actually be removed then? [10:23] pitti: the translations are still useful for some apps that don't have kde 4 versions (kdevelop, quanta) [10:23] pitti: ok, manual and autosyncs flushed now, enjoy ;-) [10:23] but nothing in main [10:23] ah, -i18n -> KDE3, l10n -> KDE4 only [10:24] pitti: exactly [10:24] Riddell: ok; I won't touch it then [10:24] thanks for the heads-up [10:28] good morning [10:28] is it possible to automatically restart the computer if an installation via pxe and preseed failed? [10:28] pitti: hey, I think kopete-plugin-thinklight 0.3-0ubuntu3.1 can be moved to -updates, see bug 221531 [10:28] Launchpad bug 221531 in kopete-plugin-thinklight "Thinklight doesn't blink because /proc/acpi/ibm/thinklight has wrong permissions" [Undecided,Fix released] https://launchpad.net/bugs/221531 [10:30] apachelogger_: hmm, no SRU task? [10:31] and the bug doesn't mention who accepted it [10:31] nor an ACK from ~motu-release [10:31] pitti: Riddell did [10:31] this is heavily non-SRU compliant [10:31] * pitti subscribes motu-sru [10:33] apachelogger_: bug updated [10:34] pitti: ok, thanks [10:34] * apachelogger_ pokes \sh and ScottK [10:36] RAOF: eyah [10:52] * \sh peeks apachelogger [10:56] \sh: bug 221531 [10:56] Launchpad bug 221531 in kopete-plugin-thinklight "Thinklight doesn't blink because /proc/acpi/ibm/thinklight has wrong permissions" [Undecided,Fix committed] https://launchpad.net/bugs/221531 [10:58] <\sh> apachelogger: yepp.after acked...next time, you'll get a kick ;) [10:59] \sh: fair enough [10:59] * apachelogger creates a knote with the SRU wiki page [11:01] <\sh> thekorn: regarding the patch in bug #239684 .. you didn't commit it, right? so I can create my own branch to test this [11:01] Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684 [11:02] \sh, right i did not commit it yet, since I had no chance to test it much [11:04] <\sh> thekorn: I'll do that now/1h/this evening...depending on my workload := [11:07] \sh, no problem, please comment on this bug if something does not work as you expected so I can work on it over the weekend [12:23] pitti, could you please reject oggconvert upload in hardy-proposed? I included wrong bug # :( [12:29] DktrKranz2: done [12:30] Hobbsee, thanks :) [12:30] you're welcome [12:30] * \sh hates perl modules with a version number of 0.01 === dashua__ is now known as dashua [12:40] heya [12:41] <\sh> uh..who updated the sync mechanism to send out accepted mails ? :) === Kopfgeldjaeger2 is now known as Kopfgeldjaeger [13:14] DktrKranz2: done [13:15] DktrKranz2: oh; seems Hobbsee already did it and you uploaded a new one? [13:15] hmmm. totem is broken === Arby__ is now known as Arby [13:30] pitti: yes. I uploaded a correct version. [13:46] \sh: they always did for manual syncs [13:47] \sh: note, it's a manual decision by the archive administrator operating the mechanism whether mails get sent out or not, so sometimes mistakes are made [13:47] do autosyncs still happen? [13:47] several packages are not up-to-date [13:47] DktrKranz2: yes [13:47] DktrKranz2: example? [13:48] cjwatson: wink [13:48] they happen for everything without ubuntuX versioning [13:49] sid has 1.5.1060-5, intrepid 1.5.1060-4 [13:49] DktrKranz2: they have to be run separately for main, contrib, and non-free, so it may be that they've only been run for main lately [13:49] I'll do a contrib/non-free pass now [13:49] cjwatson: ah... didn't know that. thanks. [13:50] (wink is non-free) [13:53] <\sh> cjwatson: I wasn't seeing that as mistakes...I was wondering, because in former times no accept mails were send out to the sync requestor [13:56] \sh: that would have been mistakes [13:56] \sh: I don't recall a time when such messages were intentionally not sent [13:58] cjwatson: does autosync take XbuildY packages and sync them automatically without developer attention? [13:58] DktrKranz2: yes; only the substring "ubuntu" suppresses syncs [13:58] ARGH [13:58] so, there could be regressions in freeradius [13:58] you'll need to reupload properly, then [13:59] this is not new - Ubuntu has behaved this way since warty [13:59] yes, I saw a package which introduced ubuntu deltas with a XbuildY version scheme during hardy [13:59] well, perhaps the hoary sync process :-) but it was certainly advertised during warty [14:00] so I guess it should be checked for regressions [14:00] DktrKranz2: sometimes that's deliberate since it's known that the change should go away [14:00] cjwatson: I'll check and eventually ping uploader. thanks. [14:01] looks like it was zul [14:01] and that the diff from 1.1.7-1build2 to 1.1.7-1build4 needs to be reapplied [14:02] DktrKranz2: I've seen Ubuntu changes introduced with XbuildY when the uploader knew they would be in Debian by the time autosync ran for Intrepid. I think that's a reasonable labor saving approach. [14:02] in this case it's a clear mistake, I'll send mail [14:03] ScottK: good point. [14:12] people, when there is string freeze for debian-installer and stuff for 8.04.1? [14:14] there shouldn't have been string changes since before 8.04 ... [14:16] ok, question then - do 8.04.1 release means that debian-installer will get newest translation for certain language? [14:18] pecisk: it has had some updates [14:18] pecisk: but we won't be going through and reuploading all udebs (installer components) - enormously labour-intensive, I'm afraid [14:18] heh [14:19] I just did a huge job to fix lv [14:19] would be sad not to see that in 8.04.1 [14:20] pecisk: the best way to fix d-i translations is to do it in d-i upstream, by far [14:20] pecisk: I'm afraid it's simply impractical to do lots of that in Ubuntu [14:20] pecisk: ubiquity and oem-config have been reuploaded, I know [14:20] (obviously you have to translate Ubuntu-specific strings in Ubuntu) [14:21] $ msgfmt -o /dev/null --statistics lv.po [14:21] 196 translated messages, 11 untranslated messages. [14:21] $ msgfmt -o /dev/null --statistics lv.po [14:21] 26 translated messages. [14:21] 35mb sucked in when trying to install devscripts [14:22] doko: yeah for recommends by default ;-) [14:22] cjwatson: hmmm, didn't know that ubquity and oem-config is seperated modules. Though it all in debian-installer [14:23] pecisk: in Launchpad translations, they're all presented in debian-installer [14:23] pecisk: but the actual packages are split out [14:27] cjwatson: ahh I see. Well, I have po still on my computer, because I have few corrections left to do. Is it still possible to upload it and it will be in 8.04.1 or it is already gone now? [14:27] pecisk: afraid it's likely to be too late [14:28] pecisk: 8.04.1 needs to undergo testing and recertification before release, which means final images need to be ready well before the release date [14:28]