| TheMuso | 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:19 |
|---|---|---|
| slangasek | TheMuso: better to use the same bug, I think | 00:22 |
| TheMuso | slangasek: Ok I thought so too, but just wanted to be sure. | 00:22 |
| azeem | w31 | 00:22 |
| azeem | oops | 00:22 |
| TheMuso | 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 |
| slangasek | TheMuso: in practice, we don't normally review or require diffs submitted to bugs for main SRUs, we just debdiff the queue | 01:13 |
| TheMuso | slangasek: Ok. | 01:14 |
| TheMuso | 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 |
| slangasek | it can never be the same | 01:15 |
| TheMuso | Right. | 01:15 |
| slangasek | 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:16 | |
| TheMuso | 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:20 |
| slangasek | yes, that's what I would recommend | 01:21 |
| mathiaz | slangasek: looking at the diff for openldap SRU, I've noticed that: http://paste.ubuntu.com/19764/ | 01:59 |
| mathiaz | slangasek: would this be a problem in terms of ABI changes ? | 02:00 |
| slangasek | "static int", so no | 02:00 |
| mathiaz | slangasek: but that is an API change right ? | 02:02 |
| slangasek | 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:09 |
| YokoZar | 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:16 |
| mathiaz | YokoZar: -backports and 8.04.1 (which is -updates actually) are two different repositories | 02:18 |
| YokoZar | 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 |
| slangasek | not really, no | 02:19 |
| slangasek | -updates is for post-release fixes of critical bugs; not for new upstream versions, except for very specific exceptions | 02:20 |
| YokoZar | Like Firefox and such for 8.04.1 | 02:21 |
| YokoZar | I guess I'm just wondering how 8.04.1 is different from a handful of SRUs. | 02:21 |
| slangasek | the main difference is that there are now ISOs issued | 02:23 |
| slangasek | s/now/new/ | 02:23 |
| TheMuso | 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 |
| TheMuso | usr/share/alsa-lib even | 02:29 |
| slangasek | TheMuso: right | 02:34 |
| mathiaz | slangasek: I'm not sure if this diff is suitable for an SRU (http://paste.ubuntu.com/19768/) | 02:37 |
| mathiaz | slangasek: there seems to be some changes in the libldap_r library | 02:38 |
| slangasek | 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:43 |
| mathiaz | slangasek: oh no no - if that's fine with you I'd rather go with 2.4.9 :D | 02:45 |
| mathiaz | slangasek: and we'll probably get 2.4.10 in hardy as well | 02:45 |
| mathiaz | slangasek: at a later time though | 02:46 |
| mathiaz | 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:54 |
| slangasek | mathiaz: AFAIK it won't matter | 02:57 |
| mathiaz | slangasek: well - I've uploaded the orig.tar.gz file - we'll see | 03:01 |
| TheMuso | 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:11 |
| slangasek | TheMuso: go ahead and upload please, I won't be able to review it in real time at the moment | 04:24 |
| TheMuso | slangasek: Ok. | 04:27 |
| calc | 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:20 |
| calc | jcastro: it seems now that we have triaged that is the preferred way to do it anyway | 05:21 |
| ScottK | calc: Confirmed is going to go away soonish from LP, so don't get too used to having the two status choices. | 05:21 |
| persia | 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 |
| TheMuso | ScottK: What is it being replaced with? | 05:22 |
| ScottK | 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 |
| ScottK | persia: Nothing in Launchpad is ever completely confirmed. Not even after it's implemented because they might take it back. | 05:23 |
| calc | ok | 05:34 |
| calc | 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 |
| calc | i had been using confirmed as i could reproduce it but it seems that would be better as triaged | 05:35 |
| calc | then let users use a me too or confirmed or whatever | 05:36 |
| jcastro | calc: that seems to make sense | 05:37 |
| jcastro | from what I gather no one has just declared "we're using triaged now." | 05:37 |
| persia | 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:38 |
| ScottK | jcastro: We get what LP implements and that's what they said they were planning at UDS. Plans change of course. | 05:44 |
| jcastro | yeah | 05:44 |
| jcastro | My concern is that not everyone knows that | 05:44 |
| ScottK | I think most developers are well aware the we get whatever LP decides to implement. | 05:45 |
| jcastro | heh | 05:45 |
| ScottK | Good night. | 05:47 |
| lifeless | gnight | 05:47 |
| dholbach | good morning | 06:32 |
| ajmitch | hi dholbach | 06:34 |
| dholbach | hi ajmitch | 06:34 |
| pitti | Good morning | 06:36 |
| ion_ | Hi | 06:38 |
| pitti | jussi01: you're welcome :) | 06:38 |
| pitti | kirkland: ugh, fstab dynamically? that doesn't sound like a final solution? | 06:39 |
| kirkland | pitti: i'm also going to look into capabilities | 06:39 |
| pitti | kirkland: so PAM can't be fixed to umount as root during logout? | 06:39 |
| kirkland | pitti: it's ssh that would have to be fixed, i think | 06:40 |
| kirkland | pitti: additionally, i'm going to look into kernel capabilities | 06:40 |
| kirkland | pitti: when sshd switches execution back to pam on logout, the context is running with uid 1000 (not 0) | 06:41 |
| === dholbach_ is now known as dholbach | ||
| pitti | kirkland: hm, keeping CAP_SYS_ADMIN as an user process is almost as good as root | 06:41 |
| kirkland | pitti: it's more finegrained than setuid, methinks | 06:41 |
| pitti | kirkland: maybe we should reconsider a hal-based solution then | 06:42 |
| pitti | kirkland: or at least d-bus | 06:42 |
| kirkland | pitti: i'm open to either | 06:42 |
| kirkland | pitti: if you think they can be completed within intrepid | 06:42 |
| pitti | kirkland: if you create your own dbus service, that's relatively easy, and we do not need to touch hal | 06:43 |
| pitti | it's a much bigger cannon than using PAM admittedly, but it gives us the fine-grained privileges you need | 06:43 |
| kirkland | pitti: okay.... i might need a primer at some point | 06:44 |
| kirkland | pitti: which sprint are you attending? | 06:44 |
| pitti | kirkland: London | 06:44 |
| kirkland | :-/ hmm | 06:44 |
| kirkland | seems like the several people i need to work with are going to London | 06:44 |
| pitti | kirkland: other question: do you have a running daemon process for transparently unencrypting ~/.Private to ~/Private? | 06:45 |
| pitti | i. e. is it like FUSE? | 06:45 |
| pitti | or does the kernel handle that? | 06:45 |
| kirkland | pitti: kernel | 06:46 |
| kirkland | pitti: handled by mount | 06:46 |
| === tkamppeter_ is now known as tkamppeter | ||
| kirkland | 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 |
| pitti | kirkland: I wonder whether it would be more elegant to have the kernel itself umount ecryptfses once the last user process dies | 06:47 |
| kirkland | pitti: i had dinner with the maintainer tonight, and discussed that to some extent | 06:47 |
| kirkland | 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 |
| pitti | kirkland: what is it used for? | 06:48 |
| pitti | kirkland: couldn't that just clean up umounts? | 06:48 |
| kirkland | pitti: other forms of key management besides passphrase (openssl, TPM, pkcs11) | 06:48 |
| kirkland | pitti: it probably could be made to do so | 06:49 |
| pitti | ah, so it isn't really meant for managing the mounts | 06:49 |
| kirkland | pitti: not currently, no.... key management more so it's currently duty | 06:49 |
| pitti | kirkland: my idea was to start a daemon in the background on login which will trigger the umount when it exits | 06:49 |
| pitti | but having a daemon for each logged in user which does nothing all the time doesn't make me too happy either | 06:50 |
| kirkland | pitti: right | 06:50 |
| pitti | so if that's done by a central daemon, that would be much more useful | 06:50 |
| kirkland | 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:51 | |
| kirkland | pitti: constantly? | 06:52 |
| kirkland | pitti: it would only get changed on adduser | 06:52 |
| pitti | and it's subject to all sorts of race conditions, confuses backup software, etc. | 06:52 |
| kirkland | pitti: well, userdel too | 06:52 |
| pitti | kirkland: oh, not on login? (dynamically creating a stanza for logout) | 06:53 |
| kirkland | pitti: no no no | 06:53 |
| pitti | kirkland: if it's that static, how do you handle NIS, AD, etc.? | 06:53 |
| kirkland | pitti: :-) | 06:53 |
| kirkland | pitti: local users only | 06:53 |
| pitti | kirkland: but seriously, I'd rather teach umount to allow you to umount your own ecryptfses than fiddling with fstab | 06:53 |
| kirkland | pitti: at this point | 06:53 |
| kirkland | pitti: okay | 06:54 |
| kirkland | pitti: the guys i had dinner tonight with were talking about some new "user mounts" work in the kernel | 06:54 |
| kirkland | pitti: someone named Mikko? working on it, i think | 06:54 |
| kirkland | pitti: not in yet, perhaps -mm? | 06:55 |
| pitti | kirkland: so if you could do "umount ~/Private" as normal user, that would basically solve it with pam-mount? | 06:55 |
| pitti | that approach is pretty much what we did with pmount in warty to breezy | 06:56 |
| kirkland | pitti: i think so | 06:56 |
| kirkland | pitti: i'll create a super-umount tomorrow and test it out | 06:56 |
| kirkland | pitti: for testing purposes ;-) | 06:56 |
| pitti | and umount already allows users to umount stuff | 06:56 |
| kirkland | pitti: if its in /etc/fstab, yeah | 06:56 |
| kirkland | pitti: and is set as a "user" mount in the options | 06:57 |
| pitti | kirkland: so, ecryptfs-utils could ship wrappers "ecryptfs-mount" and "ecryptfs-umount" which do pretty much that | 06:57 |
| pitti | check that what you try to do is sane, and call mount/umount | 06:57 |
| pitti | that's not a highly elegant solution, but it's doable in intrepid with the technology that we have today | 06:58 |
| pitti | and if it's hidden in a PAM module, we can transparently change the technology to kernel user mounts later | 06:58 |
| pitti | "it" -> the call to ecryptfs-umount | 06:59 |
| pitti | kirkland: actually we won't even need e-mount, right? | 06:59 |
| kirkland | 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 | 06:59 |
| pitti | just e-umount, and that just needs to traverse /proc/mounts and compare uid, path (owned by caller), and fstype | 07:00 |
| pitti | kirkland: right, except you need to write that in C, so that you can suid root it (and add more defensive checks) | 07:00 |
| kirkland | pitti: sure, that's doable | 07:01 |
| pitti | kirkland: feel free to look at pumount.c and take the sanity checks from it | 07:01 |
| kirkland | pitti: thanks for the pointer, i'll do that | 07:01 |
| kirkland | pitti: so i can store the mount options as variables i store in a ~/.ecryptfsrc file or something | 07:02 |
| kirkland | pitti: source that (read in C) | 07:02 |
| kirkland | pitti: sanity check | 07:02 |
| kirkland | pitti: and suid do the mount for the uesr | 07:02 |
| pitti | kirkland: what would be in that file? | 07:02 |
| pitti | kirkland: AFAICS, you don't need to permanently store anything else than the encrypted key, right? | 07:03 |
| kirkland | pitti: cypher type, key length, key fingerprint | 07:03 |
| pitti | right, so basically the key and its metadata | 07:03 |
| kirkland | pitti: yeah | 07:03 |
| pitti | kirkland: but why do you need that on umount? | 07:03 |
| kirkland | pitti: and the data dir and mountpoint | 07:03 |
| kirkland | pitti: in case you want it somewhere other than ~/Private (IBM uses ~/Confidential) | 07:04 |
| kirkland | pitti: oh, not on umount | 07:04 |
| pitti | kirkland: no, you should get that as a command line arg, and verify it in /proc/mounts | 07:04 |
| pitti | please don't store information about mounts in ~ | 07:04 |
| kirkland | pitti: sorry, i was thinking about writing both e-mount and e-umount | 07:04 |
| pitti | kirkland: ah, I see | 07:05 |
| pitti | yes, that makes more sense; so the user can choose which dirs to mount on login | 07:05 |
| kirkland | pitti: as you see above, i have both in shell form now | 07:05 |
| kirkland | pitti: also, i like changing the perm on the ecrypted underlying dir to 500 when not mounted | 07:06 |
| kirkland | pitti: to keep from inadvertently writing something in there unencrypted | 07:06 |
| kirkland | pitti: as well as the mountpoint (same reason) | 07:06 |
| kirkland | pitti: but keep r-x------ for backup purposes | 07:06 |
| pitti | right | 07:07 |
| kirkland | pitti: that's sort of a custom job for these sorts of mounts | 07:07 |
| kirkland | pitti: and on mount, we have to bump up the perms to 700 | 07:07 |
| pitti | kirkland: I hope the mount script doesn't come from upstream, but is just a local test script of your's :) | 07:07 |
| kirkland | pitti: it's evolving | 07:07 |
| pitti | (I mean because of the nice root privilege escalation) | 07:08 |
| kirkland | pitti: ? | 07:08 |
| kirkland | pitti: those two scripts are not currently setuid | 07:08 |
| kirkland | pitti: b/c they rely on the mounts being in fstab | 07:09 |
| kees | good evening | 07:09 |
| pitti | no, but they certainly run as root, don't they? | 07:09 |
| kirkland | pitti: /bin/mount and /bin/umount are setuid | 07:09 |
| kirkland | pitti: nope | 07:09 |
| kirkland | pitti: they don't | 07:09 |
| pitti | kirkland: ah, I thought you'd call them from pam | 07:09 |
| pitti | hey kees | 07:09 |
| kirkland | pitti: no, i call them from .bash_profile and .bash_logout | 07:09 |
| pitti | kees: highlight on "root privilege escalation"? | 07:09 |
| kirkland | pitti: and .config/autostart/foo | 07:09 |
| kirkland | kees: :-) howdy | 07:09 |
| kees | pitti: hahah, no, but I should. ;) | 07:10 |
| kees | (actually highlighted on "regression" for a while back) | 07:10 |
| kees | I'm just up doing xorg publication | 07:10 |
| kirkland | pitti: you with me now? | 07:10 |
| pitti | kirkland: yep, sure | 07:11 |
| kirkland | pitti: pam as root unwraps your mount passphrase and inserts it into your kernel keyring | 07:11 |
| pitti | kirkland: so the umount script will have s/umount/ecryptfs-umount/ | 07:11 |
| kirkland | pitti: okay.... | 07:11 |
| pitti | 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)? | 07:12 |
| === Mithrand1r is now known as Mithrandir | ||
| pitti | Mithrandir: good morning | 07:12 |
| Mithrandir | pitti: hiya, how's intrepid going? | 07:12 |
| pitti | Mithrandir: I don't know much TBH; I'm still on hardy duty | 07:13 |
| kirkland | pitti: i don't think i follow your last statement | 07:13 |
| Mithrandir | ah, wrapping up all the loose bits so .1 will shiny like, uh, something shiny? | 07:13 |
| pitti | Mithrandir: exactly! *bling* | 07:13 |
| pitti | 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:14 |
| kirkland | 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 |
| kirkland | 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:15 |
| pitti | kirkland: ok; looking forward to trying it out eventually :) | 07:16 |
| kirkland | pitti: b/c it works for local user locals on the console, but not ssh | 07:16 |
| pitti | kirkland: "b/c"? | 07:16 |
| kirkland | pitti: oh, b/c means that this is an ssh issue | 07:16 |
| kirkland | b/c = because | 07:16 |
| kees | Mithrandir: ah, your appearance has reminded me to post my zombie meme | 07:16 |
| pitti | 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 |
| kirkland | pitti: there's one other side effect of the ssh/pam_mount bug, that might be fixed separately | 07:17 |
| kirkland | pitti: pam_mount accounts the number of open sessions a user has in /var/run/pam_mount/username | 07:17 |
| kirkland | pitti: increments/decrements it | 07:18 |
| Mithrandir | kees: zombies > * | 07:18 |
| kirkland | pitti: but on ssh logout, the pam_session_close running as uid 1000 doesn't have sufficient privilege to decrement | 07:18 |
| Mithrandir | kees: I was wondering how much I should have made mine D&D-themed. | 07:18 |
| kirkland | pitti: i think that can probably be solved by changing the group ownership and g+w of that file | 07:19 |
| kirkland | pitti: so let me see if i can get an suid ecryptfs-umount working | 07:19 |
| kirkland | pitti: is that the one you were suggesting should be in C? | 07:20 |
| pitti | kirkland: yes, to be able to suid root it | 07:20 |
| pitti | kirkland: eww @ user-writable reference counter | 07:20 |
| pitti | why does it need to be in a file in the first place? | 07:20 |
| kirkland | pitti: after my 48 hours with pam_mount, i have a very low opinion of the module in general | 07:21 |
| pitti | 'who' knows about all sessions, so they must be stored *somewhere* | 07:21 |
| kees | Mithrandir: heh. I liked it as is. I haven't been able to think of a better famous person. :) | 07:21 |
| pitti | 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 |
| Mithrandir | kees: the archangel gabriel might work well too. | 07:21 |
| kirkland | 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 |
| kirkland | pitti: note the call to `who | grep | wc ` ;-) | 07:22 |
| Mithrandir | anyway, off to work. :-) | 07:22 |
| pitti | kirkland: right, I know; I just wonder why the heck libpam-mount does it that way | 07:22 |
| * Hobbsee_ waves | 07:33 | |
| * RAOF shores | 07:33 | |
| kees | heya Hobbsee_ | 07:35 |
| Hobbsee_ | kees! | 07:36 |
| kees | how goes it? I'm up this late so rarely. :P | 07:36 |
| Hobbsee_ | kees: just done the evil networkign exam. | 07:37 |
| Hobbsee_ | kees: so i'm glad that's over :P | 07:37 |
| kees | oooh, computer networking? | 07:37 |
| Hobbsee_ | yeah. | 07:38 |
| Hobbsee_ | would be good, if they can actually mark correctly. *shrug* | 07:38 |
| Hobbsee_ | but when two people give the same answer, and one gets marked right, and one wrong, it's not exactly inspiring confidence :P | 07:39 |
| kees | Hobbsee_: ewww | 07:40 |
| kees | Hobbsee_: just general networking, or some specific sub-topic? | 07:40 |
| Hobbsee_ | kees: general. | 07:41 |
| * Hobbsee_ heads home, hoping to aviod the traffic. | 07:43 | |
| pitti | seb128: hm, seems that the SRU in bug 209662 didn't fix the problem? | 08:13 |
| ubottu | Launchpad bug 209662 in deskbar-applet "<defunct> processes" [Low,Fix committed] https://launchpad.net/bugs/209662 | 08:13 |
| pitti | seb128: oh, good morning! | 08:13 |
| seb128 | hey pitti | 08:14 |
| seb128 | pitti: right | 08:14 |
| seb128 | pitti: but there is no regression either and it fixes several other issues | 08:14 |
| pitti | seb128: did you try out the .debs from -proposed? | 08:15 |
| pitti | seb128: if it generally works, I'm fine with copying and reopening the bug | 08:15 |
| seb128 | pitti: yes, I'm running it on my laptop and old old desktop without issue | 08:16 |
| pitti | ok, thanks | 08:16 |
| seb128 | pitti: and no bug has been opened on launchpad about it recently either | 08:16 |
| seb128 | mvo: hey | 08:16 |
| mvo | hey seb128 | 08:17 |
| seb128 | 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:17 |
| mvo | seb128: sure | 08:18 |
| seb128 | thank you | 08:18 |
| mvo | whos archive-admin day is today? I filed some sync requests last week and would like to ask about those :) | 08:24 |
| pitti | o/ | 08:25 |
| seb128 | 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 |
| mvo | 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 |
| pitti | 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 |
| pitti | mvo: yes, definitively | 08:26 |
| pitti | seb128: what would you like to start on? | 08:27 |
| seb128 | pitti: ok, doing syncs and backports now | 08:27 |
| mvo | 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:27 | |
| * mvo waves to davmor2 | 08:30 | |
| davmor2 | morning mvo :) | 08:31 |
| sladen | germany finally had rain | 08:31 |
| mvo | lots of it yesterday | 08:32 |
| pitti | seb128: I'll start off with removals, archive bugs, and component-mismatches then, and go on with MIR | 08:35 |
| pitti | seb128: you'll also do a sync-source -a? | 08:36 |
| === thekorn__ is now known as thekorn | ||
| seb128 | pitti: yes, I've done some of those yesterday already | 08:38 |
| seb128 | pitti: will do an another one now | 08:38 |
| seb128 | pitti: I'll try to tacklo some of the NBS list too | 08:38 |
| pitti | oh, great, thanks! | 08:38 |
| \sh | sladen: still in .de? | 08:42 |
| \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:47 |
| * Hobbsee waves | 08:55 | |
| RAOF | Hobbsee: Back home? | 08:56 |
| thekorn | \sh, you can read the content block-wise in a loop | 08:57 |
| \sh | thekorn: yes...but this is not working, because for that I would have to change pylpbugs ;) | 08:58 |
| \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 | 08:59 |
| thekorn | \sh, hehe, you are right, I think it's easy to add such a hook interface to py-lp-bugs, | 09:01 |
| thekorn | I think there is a bugreport open for this | 09:01 |
| thekorn | \sh, btw. nice LP gui! did you publish the source somewhere? | 09:02 |
| \sh | thekorn: yes...it's on my lp code page...brb meeting | 09:03 |
| thekorn | ok, cool | 09:04 |
| seb128 | Lutin: hi | 09:12 |
| seb128 | 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 |
| seb128 | Lutin: thank you | 09:13 |
| thekorn | \sh, I added a patch to bug 239684 to add such progress-hook thing to py-lp-bugs | 09:40 |
| ubottu | Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684 | 09:40 |
| \sh | thekorn: cool...I'll test it later...estimation meeting done...new infrastructure meeting now....my life is doomed now ;) | 09:58 |
| pitti | 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:03 |
| seb128 | pitti: if you do seed edition please drop workrave too ;-) | 10:04 |
| pitti | seb128: demoted | 10:04 |
| seb128 | danke | 10:04 |
| pitti | I'm not currently touching seeds, though | 10:04 |
| pitti | so, NEW and hardy-proposed queues empty; nobody touch anything now! :-) | 10:09 |
| seb128 | pitti: and syncs cleaned | 10:10 |
| * mvo hugs seb'sync-master'128 | 10:11 | |
| * pitti hugs seb128 | 10:11 | |
| pitti | seb128: you said you're going to do the backports as well? doing the other archive-admin bugs now | 10:12 |
| seb128 | 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 |
| pitti | right; thanks | 10:13 |
| seb128 | np, feel free to do the few backports listed in the bug list | 10:13 |
| seb128 | I'll do those later otherwise | 10:13 |
| * pitti does the remaining two syncs | 10:14 | |
| seb128 | pitti: the flushing is in progress btw | 10:14 |
| pitti | oh, ok; will wait | 10:14 |
| Riddell | pitti: kde-i18n can be unseeded | 10:22 |
| Riddell | replaced with kde-l10n-* | 10:22 |
| pitti | aah | 10:23 |
| pitti | Riddell: so the packages shuold actually be removed then? | 10:23 |
| Riddell | pitti: the translations are still useful for some apps that don't have kde 4 versions (kdevelop, quanta) | 10:23 |
| seb128 | pitti: ok, manual and autosyncs flushed now, enjoy ;-) | 10:23 |
| Riddell | but nothing in main | 10:23 |
| pitti | ah, -i18n -> KDE3, l10n -> KDE4 only | 10:23 |
| Riddell | pitti: exactly | 10:24 |
| pitti | Riddell: ok; I won't touch it then | 10:24 |
| pitti | thanks for the heads-up | 10:24 |
| psypointer | good morning | 10:28 |
| psypointer | is it possible to automatically restart the computer if an installation via pxe and preseed failed? | 10:28 |
| apachelogger_ | pitti: hey, I think kopete-plugin-thinklight 0.3-0ubuntu3.1 can be moved to -updates, see bug 221531 | 10:28 |
| ubottu | 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:28 |
| pitti | apachelogger_: hmm, no SRU task? | 10:30 |
| pitti | and the bug doesn't mention who accepted it | 10:31 |
| pitti | nor an ACK from ~motu-release | 10:31 |
| apachelogger_ | pitti: Riddell did | 10:31 |
| pitti | this is heavily non-SRU compliant | 10:31 |
| * pitti subscribes motu-sru | 10:31 | |
| pitti | apachelogger_: bug updated | 10:33 |
| apachelogger_ | pitti: ok, thanks | 10:34 |
| * apachelogger_ pokes \sh and ScottK | 10:34 | |
| Hobbsee | RAOF: eyah | 10:36 |
| * \sh peeks apachelogger | 10:52 | |
| apachelogger | \sh: bug 221531 | 10:56 |
| ubottu | 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:56 |
| \sh | apachelogger: yepp.after acked...next time, you'll get a kick ;) | 10:58 |
| apachelogger | \sh: fair enough | 10:59 |
| * apachelogger creates a knote with the SRU wiki page | 10:59 | |
| \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 |
| ubottu | Launchpad bug 239684 in python-launchpad-bugs "add progress-hook to HTTPConnection" [Undecided,New] https://launchpad.net/bugs/239684 | 11:01 |
| thekorn | \sh, right i did not commit it yet, since I had no chance to test it much | 11:02 |
| \sh | thekorn: I'll do that now/1h/this evening...depending on my workload := | 11:04 |
| thekorn | \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 | 11:07 |
| DktrKranz | pitti, could you please reject oggconvert upload in hardy-proposed? I included wrong bug # :( | 12:23 |
| Hobbsee | DktrKranz2: done | 12:29 |
| DktrKranz | Hobbsee, thanks :) | 12:30 |
| Hobbsee | you're welcome | 12:30 |
| * \sh hates perl modules with a version number of 0.01 | 12:30 | |
| === dashua__ is now known as dashua | ||
| emgent | heya | 12:40 |
| \sh | uh..who updated the sync mechanism to send out accepted mails ? :) | 12:41 |
| === Kopfgeldjaeger2 is now known as Kopfgeldjaeger | ||
| pitti | DktrKranz2: done | 13:14 |
| pitti | DktrKranz2: oh; seems Hobbsee already did it and you uploaded a new one? | 13:15 |
| Hobbsee | hmmm. totem is broken | 13:15 |
| === Arby__ is now known as Arby | ||
| DktrKranz2 | pitti: yes. I uploaded a correct version. | 13:30 |
| cjwatson | \sh: they always did for manual syncs | 13:46 |
| cjwatson | \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 |
| DktrKranz2 | do autosyncs still happen? | 13:47 |
| DktrKranz2 | several packages are not up-to-date | 13:47 |
| cjwatson | DktrKranz2: yes | 13:47 |
| cjwatson | DktrKranz2: example? | 13:47 |
| DktrKranz2 | cjwatson: wink | 13:48 |
| ogra | they happen for everything without ubuntuX versioning | 13:48 |
| DktrKranz2 | sid has 1.5.1060-5, intrepid 1.5.1060-4 | 13:49 |
| cjwatson | 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 |
| cjwatson | I'll do a contrib/non-free pass now | 13:49 |
| DktrKranz2 | cjwatson: ah... didn't know that. thanks. | 13:49 |
| cjwatson | (wink is non-free) | 13:50 |
| \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:53 |
| cjwatson | \sh: that would have been mistakes | 13:56 |
| cjwatson | \sh: I don't recall a time when such messages were intentionally not sent | 13:56 |
| DktrKranz2 | cjwatson: does autosync take XbuildY packages and sync them automatically without developer attention? | 13:58 |
| cjwatson | DktrKranz2: yes; only the substring "ubuntu" suppresses syncs | 13:58 |
| DktrKranz2 | ARGH | 13:58 |
| DktrKranz2 | so, there could be regressions in freeradius | 13:58 |
| cjwatson | you'll need to reupload properly, then | 13:58 |
| cjwatson | this is not new - Ubuntu has behaved this way since warty | 13:59 |
| DktrKranz2 | yes, I saw a package which introduced ubuntu deltas with a XbuildY version scheme during hardy | 13:59 |
| cjwatson | well, perhaps the hoary sync process :-) but it was certainly advertised during warty | 13:59 |
| DktrKranz2 | so I guess it should be checked for regressions | 14:00 |
| cjwatson | DktrKranz2: sometimes that's deliberate since it's known that the change should go away | 14:00 |
| DktrKranz2 | cjwatson: I'll check and eventually ping uploader. thanks. | 14:00 |
| cjwatson | looks like it was zul | 14:01 |
| cjwatson | and that the diff from 1.1.7-1build2 to 1.1.7-1build4 needs to be reapplied | 14:01 |
| ScottK | 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 |
| cjwatson | in this case it's a clear mistake, I'll send mail | 14:02 |
| DktrKranz2 | ScottK: good point. | 14:03 |
| pecisk | people, when there is string freeze for debian-installer and stuff for 8.04.1? | 14:12 |
| cjwatson | there shouldn't have been string changes since before 8.04 ... | 14:14 |
| pecisk | ok, question then - do 8.04.1 release means that debian-installer will get newest translation for certain language? | 14:16 |
| cjwatson | pecisk: it has had some updates | 14:18 |
| cjwatson | pecisk: but we won't be going through and reuploading all udebs (installer components) - enormously labour-intensive, I'm afraid | 14:18 |
| pecisk | heh | 14:18 |
| pecisk | I just did a huge job to fix lv | 14:19 |
| pecisk | would be sad not to see that in 8.04.1 | 14:19 |
| cjwatson | pecisk: the best way to fix d-i translations is to do it in d-i upstream, by far | 14:20 |
| cjwatson | pecisk: I'm afraid it's simply impractical to do lots of that in Ubuntu | 14:20 |
| cjwatson | pecisk: ubiquity and oem-config have been reuploaded, I know | 14:20 |
| cjwatson | (obviously you have to translate Ubuntu-specific strings in Ubuntu) | 14:20 |
| cjwatson | <cjwatson@sarantium ~/src/ubuntu/ubiquity/ubiquity/debian/po>$ msgfmt -o /dev/null --statistics lv.po | 14:21 |
| cjwatson | 196 translated messages, 11 untranslated messages. | 14:21 |
| cjwatson | <cjwatson@sarantium ~/src/ubuntu/oem-config/oem-config/debian/po>$ msgfmt -o /dev/null --statistics lv.po | 14:21 |
| cjwatson | 26 translated messages. | 14:21 |
| doko | 35mb sucked in when trying to install devscripts | 14:21 |
| seb128 | doko: yeah for recommends by default ;-) | 14:22 |
| pecisk | cjwatson: hmmm, didn't know that ubquity and oem-config is seperated modules. Though it all in debian-installer | 14:22 |
| cjwatson | pecisk: in Launchpad translations, they're all presented in debian-installer | 14:23 |
| cjwatson | pecisk: but the actual packages are split out | 14:23 |
| pecisk | 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 |
| cjwatson | pecisk: afraid it's likely to be too late | 14:27 |
| cjwatson | 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 |
| pecisk | I see | 14:28 |
| pecisk | well, nevermind | 14:28 |
| cjwatson | DktrKranz2: wink's on its way in now | 14:28 |
| pecisk | cjwatson: 8.04.2 was planned in next year somewhere yes? | 14:28 |
| cjwatson | pecisk: six months from 8.04.1, roughly | 14:29 |
| pecisk | ok, I see | 14:29 |
| pecisk | well, not such big tragedy :) | 14:29 |
| pecisk | thanks for info | 14:29 |
| DktrKranz2 | cjwatson: thanks. | 14:30 |
| pitti | DktrKranz2: ok, then I killed your 'good' one; hang on | 14:30 |
| pitti | DktrKranz2: unrejected and accepted | 14:33 |
| DktrKranz2 | pitti: thanks and sorry for the mess | 14:33 |
| pitti | DktrKranz2: not your fault, no problem | 14:34 |
| asac | where can i get the latest 8.04.1 images? | 14:37 |
| \sh | thekorn: did you read my comments? :) | 14:42 |
| thekorn | \sh, yes I'm on it | 14:43 |
| thekorn | \sh, I understand why you get a set of 7 bugs, instead of 8 | 14:44 |
| \sh | thekorn: let me guess: duplicates or "same bug number" ;) | 14:44 |
| thekorn | \sh, because you are assigned to 7 different bugs, but 8 tasks | 14:44 |
| cjwatson | asac: http://cdimage.ubuntu.com/hardy/ | 14:45 |
| \sh | thekorn: ok..that was what I was suspecting | 14:45 |
| thekorn | \sh, with BugList = ConnectBugList(all_tasks=True) you get 8 bugs | 14:45 |
| asac | cjwatson: thanks. i thought i looked there. wierd | 14:45 |
| thekorn | \sh, but the don't really understand how you made it to get a list of 6 bugs | 14:45 |
| thekorn | i can't reproduce it | 14:46 |
| doko | pitti: any opinion to promote libssh for intrepid now? | 14:46 |
| \sh | thekorn: hmm | 14:46 |
| \sh | thekorn: trying to get more numbers from inside the http_connection... | 14:50 |
| \sh | lp down? | 14:53 |
| Pici | \sh: seems that way. I though I saw an email about LP downtime, but I cant seem to find it or remember the dates/times | 14:58 |
| pitti | doko: why do we want it so badly again? | 14:58 |
| cjwatson | Pici: LP downtime is next week | 14:58 |
| doko | pitti: curl | 14:58 |
| Pici | cjwatson: Ah, thanks | 14:58 |
| doko | pitti: but I can drop it again | 14:59 |
| pitti | I'm still not happy about a second ssh implementation TBH | 15:00 |
| doko | ok | 15:02 |
| doko | then please finally reject the mir | 15:02 |
| pitti | ok | 15:02 |
| mterry | LP looks like it's back up | 15:23 |
| tkamppeter | Anyone around who can do fixes on the HPPA build server? After uploading foomatic filters I got a | 15:46 |
| tkamppeter | The following packages have unmet dependencies: | 15:46 |
| tkamppeter | cdbs: Depends: intltool but it is not going to be installed | 15:46 |
| tkamppeter | libgs-dev: Depends: libgs8 but it is not going to be installed | 15:46 |
| tkamppeter | E: Broken packages | 15:46 |
| Hobbsee | tkamppeter: likely lamont | 15:47 |
| tkamppeter | from the HPPA build server. | 15:47 |
| lamont | Hobbsee: inifinty | 15:47 |
| Hobbsee | slangasek: er, when are you going to do the point release for 8.04? | 15:47 |
| * lamont doesn't mess with the buildd chroot stuff | 15:47 | |
| Hobbsee | lamont: oh, i thought you were still the hppa guy | 15:47 |
| lamont | I am the hppa guy | 15:47 |
| pitti | tkamppeter: just ignore hppa for now; ATM it's hopelessly out of date | 15:47 |
| pitti | tkamppeter: once the basic packages get fixed, someone will do a mass build-retry anyway | 15:47 |
| lamont | now, if it's just that it's out of date, yeah... that's a "pester lamont" thing | 15:47 |
| pitti | oh, hi lamont | 15:47 |
| lamont | g'morning | 15:48 |
| tkamppeter | Thanks, lamont. | 15:48 |
| lamont | hppa usually catches up right after the freeze for an alpha. :-) | 15:48 |
| tkamppeter | And also thanks, pitti | 15:49 |
| lamont | hah. sparc is further behind than hppa. | 15:49 |
| pitti | lamont: most ftbfs I saw were due to intltool | 15:49 |
| === thekorn_ is now known as thekorn | ||
| lamont | tkamppeter: which package was that? (example, please?) | 15:50 |
| qense | ping persia | 15:55 |
| hwilde | Keybuk, how do I get udevinfo for network interfaces? | 16:01 |
| Keybuk | hwilde: what are you trying to do? | 16:02 |
| hwilde | Keybuk, I want to make net70 persistent based on vendorid instead of mac | 16:03 |
| Keybuk | udevinfo -ap /class/net/ethX ? | 16:04 |
| pitti | oh, wow, I wasn't aware that you can do "less foo.deb" and it would do something really sensible | 16:09 |
| seb128 | pitti: waouh, me neither ;-) | 16:10 |
| pitti | (dpkg -I and dpkg -c concatenated) | 16:10 |
| pitti | that eases review/MIR | 16:10 |
| dholbach | pitti: where did you find out? :) | 16:10 |
| pitti | just by accident | 16:10 |
| pitti | I would have never done it deliberately | 16:11 |
| === LucidFox is now known as Wookie | ||
| === Wookie is now known as LucidFox | ||
| mario_limonciell | woah that's neat pitti. great find | 16:18 |
| * ogra knew that .... but nobody asked :P | 16:19 | |
| hwilde | Keybuk, http://pastebin.com/m5ada7265 is it ok to use DRIVERS== for the net rules, or can I use partial MACs somehow like the first four? | 16:20 |
| sistpoty|work | ogra: other cool things you can show us? :P | 16:20 |
| ogra | sistpoty|work, if you ask for particular ones :P | 16:21 |
| sistpoty|work | ogra: heh | 16:21 |
| kirkland | cjwatson: hey, what's the name of the utility that you showed me that used apt-get to pull and extract individual manpages from debs? | 16:26 |
| Keybuk | hwilde: either | 16:28 |
| Keybuk | hwilde: you can match on anything udevinfo gives you | 16:28 |
| Keybuk | and can use wildcards | 16:29 |
| cjwatson | kirkland: debman | 16:34 |
| cjwatson | kirkland: it's in the debian-goodies package | 16:34 |
| cjwatson | kirkland: there's also debmany, which is a neat idea, though I didn't write that myself and haven't looked at it much | 16:35 |
| tkamppeter | lamont, it was foomatic-filters what I uploaded and the problems were with intltool and libgs, see http://launchpadlibrarian.net/15261599/buildlog_ubuntu-intrepid-hppa.foomatic-filters_4.0.0%7Ebzr144-0ubuntu1_FAILEDTOBUILD.txt.gz and https://launchpad.net/ubuntu/+source/foomatic-filters/4.0.0~bzr144-0ubuntu1 | 16:38 |
| === qense is now known as qense|dinner | ||
| === pgraner_ is now known as pgraner | ||
| === qense|dinner is now known as qense | ||
| qense | retry: ping persia | 17:39 |
| mathiaz | kees: I've been using mk-sbuild-lv lately to re-create my intrepid chroot and exim4 is installed by default now | 17:47 |
| tkamppeter | Anyone around who can fix things on the build servers? | 17:48 |
| kees | mathiaz: interesting -- did something change? | 17:48 |
| cjwatson | tkamppeter: is this still about intltool et al? that isn't a buildd problem, the packages are just plain uninstallable on that architecture | 17:48 |
| mathiaz | kees: well - apt installs Recommends by default now | 17:48 |
| kees | erg | 17:49 |
| mathiaz | kees: I wonder if something pulls exim4 in | 17:49 |
| kees | should I switch it to not doing that in the script? | 17:49 |
| cjwatson | tkamppeter: this is very common in the early stages of merging up a new release | 17:49 |
| cjwatson | tkamppeter: and, while it needs to be fixed, generally isn't something that people should get too worried about | 17:49 |
| tkamppeter | cjwatson, this time I got also a failure on amd64. | 17:50 |
| cjwatson | tkamppeter: link please | 17:50 |
| cjwatson | tkamppeter: anything of the form "package <blah> could not be installed" is with 99% probability not a build daemon problem | 17:50 |
| tkamppeter | I tells only about libgs8 and not about intltools: https://edge.launchpad.net/ubuntu/+source/foomatic-filters/4.0.0~bzr144-0ubuntu1 and http://launchpadlibrarian.net/15265721/buildlog_ubuntu-intrepid-amd64.foomatic-filters_4.0.0%7Ebzr144-0ubuntu1_FAILEDTOBUILD.txt.gz | 17:51 |
| cjwatson | we've had this conversation in previous release cycles, I'm certain :) | 17:51 |
| cjwatson | tkamppeter: look at http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html; note that libgs-dev is listed as uninstallable on amd64 | 17:51 |
| mathiaz | kees: according to mvo emails, it may worth using the --no-install-recommends option | 17:52 |
| mathiaz | kees: in the finish script - I'll try that | 17:52 |
| cjwatson | it may well be collateral damage from something else, considering the huge list of uninstallables | 17:52 |
| kees | yeah, that's what I was thinking. let me know if that works and I'll add it. | 17:52 |
| cjwatson | tkamppeter: the best way to find out what's going on is to bootstrap an intrepid chroot and try to install the package by hand, then sometimes you have to manually drill down by trying to install the subsequent packages it complains about | 17:53 |
| mvo | kees, mathiaz: at recommends a mail-transport-agent, that probably brought it in | 17:53 |
| mvo | same for cron | 17:54 |
| tkamppeter | Seeing the list of uninstallables nearly everything is uninstallable ... | 17:54 |
| cjwatson | tkamppeter: I imagine that libgtk2.0-0 being uninstallable isn't helping much | 17:55 |
| cjwatson | (for starters) | 17:55 |
| tkamppeter | cjwatson, what I would also like to see is why the listed packages are uninstallable. | 17:57 |
| tkamppeter | I am building a pbuilder chroot now to see whether Intrepid is really so broken. | 17:58 |
| cjwatson | tkamppeter: testing is rarely wrong, just underinformative :-) | 17:58 |
| cjwatson | testing> by which I mean the list at that URL | 17:58 |
| mathiaz | mvo: yeah - or mailx | 17:59 |
| mathiaz | kees: adding --no-install-recommends fixes the issue | 18:05 |
| cjwatson | tkamppeter: I think the problem is that libkrb53 and friends got demoted to universe for some reason | 18:05 |
| cjwatson | tkamppeter: so I'll fix that | 18:05 |
| mathiaz | kees: there are two places where you could add - the first one when gnupg and ubuntu-keyring is installed | 18:06 |
| mathiaz | kees: I don't think you need to add the --no-install-recommends there as it just brings ca-certificates in | 18:06 |
| mathiaz | kees: the second call is when you install more packages (devscripts, etc...) - that's where I'd add --no-install-recommends | 18:07 |
| kees | mathiaz: cool, thanks for testing that, I'll get it added | 18:07 |
| cjwatson | tkamppeter: given that purging that from my chroot takes out ubuntu-minimal, that ought to fix a good pile of uninstallables :) | 18:07 |
| mathiaz | kees: http://paste.ubuntu.com/19932/ | 18:08 |
| cjwatson | (it'll take about 1.5 hours for that to propagate though) | 18:08 |
| === mrpouit is now known as mr_pouit | ||
| slangasek | Hobbsee: 8.04.1 is for the beginning of July | 18:13 |
| cody-somerville | slangasek, make the Xubuntu builds stop failing :P | 18:26 |
| slangasek | cody-somerville: the powerpc ones? | 18:26 |
| cody-somerville | ;] | 18:26 |
| cody-somerville | slangasek, Were they failing last release cycle too? | 18:26 |
| cjwatson | yes, they were | 18:27 |
| cjwatson | it's an awkward corner case with ports vs. universe | 18:27 |
| cjwatson | to do with how the mirror on cdimage is arranged | 18:27 |
| cjwatson | do you have anyone who actually cares about Xubuntu on powerpc? for now, the pragmatic course might be to disable those builds | 18:28 |
| cody-somerville | I think people use it for the playstation? | 18:28 |
| cjwatson | cody-somerville: oh, ugh, true | 18:33 |
| tkamppeter | cjwatson, pbuilder is currently not able to build an Intrepid chroot on 64-bit. It says | 18:45 |
| tkamppeter | The following packages have unmet dependencies: | 18:45 |
| tkamppeter | gnupg: Depends: libkrb53 (>= 1.6.dfsg.2) but it is not installable | 18:45 |
| tkamppeter | libcurl3-gnutls: Depends: libkrb53 (>= 1.6.dfsg.2) but it is not installable | 18:45 |
| tkamppeter | E: Unmet dependencies. Try using -f. | 18:45 |
| cjwatson | tkamppeter: perhaps you missed the comments I made above? | 18:45 |
| cjwatson | 18:05 <cjwatson> tkamppeter: I think the problem is that libkrb53 and friends got demoted to universe for some reason | 18:45 |
| cjwatson | 18:05 <cjwatson> tkamppeter: so I'll fix that | 18:45 |
| cjwatson | 18:07 <cjwatson> tkamppeter: given that purging that from my chroot takes out ubuntu-minimal, that ought to fix a good pile of uninstallables :) | 18:45 |
| cjwatson | 18:08 <cjwatson> (it'll take about 1.5 hours for that to propagate though) | 18:45 |
| cjwatson | the current time is 18:45 by my clock | 18:45 |
| tkamppeter | Sorry, I left for dinner and than looked at the result of my pbuilder run. | 18:46 |
| bXi | hello | 18:56 |
| bXi | i've written a tool which i want to distribute | 18:56 |
| bXi | but i dont know if its frowned upon if i'd make the application SUID root | 18:56 |
| bXi | (its a frontend to mount basicly) | 18:57 |
| slangasek | yes, it's frowned upon :) | 18:57 |
| bXi | can you recommend something else then? | 18:58 |
| slangasek | well, sometimes it's necessary | 18:58 |
| slangasek | but there will be plenty of frowning among the security folks any time you proposed to introduce a new SUID app | 18:58 |
| bXi | i was thinking about using gksu to run it | 18:59 |
| kees | bXi: I recommend examining how PolicyKit works | 19:00 |
| bXi | policykit | 19:00 |
| bXi | roger | 19:00 |
| bXi | can i put my code up for review somewhere? | 19:00 |
| kees | bXi: basically, there are backends registered with PolicyKit to do certain actions, and those actions are requested over dbus, etc. | 19:00 |
| kees | bXi: anywhere is good, but I'd recommend possibly REVU, if it's been packaged | 19:01 |
| bXi | it hasnt been packaged into someething normal yet | 19:01 |
| cjwatson | or if you're using bzr for it, point people to the appropriate URL on bazaar.launchpad.net for code browing | 19:01 |
| cjwatson | browsing | 19:02 |
| bXi | i havent put it up anywhere yet | 19:02 |
| kees | bXi: in that case, I'd recommend getting it into a bzr branch on launchpad: https://wiki.ubuntu.com/BzrMaintainerHowto | 19:02 |
| bXi | was thinking of making a sourceforge project out of it | 19:02 |
| === Kopfgeldjaeger2 is now known as Kopfgeldjaeger | ||
| wasabi | Hmmmm.... preseeding mirror/http/proxy ain't working. =( | 19:24 |
| === emgent_ is now known as emgent | ||
| wasabi | n/m my fault. | 19:24 |
| slangasek | TheMuso: are 221673 and 191027 the only bugs expected to be closed in this SRU? I thought there were more | 19:30 |
| slangasek | TheMuso: it would have been helpful if you had mentioned all of the related bugs in the usual changelog syntax, so that they would show up automatically on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html for tracking; obviously not a change to reupload for in this case, but please bear it in mind for future SRUs :) | 19:36 |
| cjwatson | tkamppeter: intrepid uninstallables list looks a lot happier now; I suggest hitting the retry button on the builds of yours that failed | 20:01 |
| ScottK | brandonperry: All the Ubuntu clamav packages are pretty current. What is it you think needs to be packaged? | 20:10 |
| * ScottK just read you on planet. | 20:10 | |
| slangasek | cody-somerville: so I can't really see a good, quick fix for the xubuntu/ppc failures (now that I look at the error messages, I remember why this problem exists); so I can disable the builds to suppress the error mails, or we can keep getting the daily error mails as a nag-minder, your choice :) | 20:32 |
| cody-somerville | slangasek, we can do the latter if you set it to e-mail ubuntu-devel too ;] | 20:34 |
| slangasek | heh, not so much | 20:34 |
| slangasek | so you'd prefer that I disable the builds until someone can look at it? | 20:34 |
| cody-somerville | Well, maybe infinity could take a look? | 20:44 |
| slangasek | it's an issue with the cdimage setup, infinity would happily punt that problem back at me anyway :) | 20:45 |
| cjwatson | slangasek: maybe the best approach would be to have anonftpsync.ports pull universe and multiverse? I don't think we care so much if universe/multiverse leaks into Ubuntu ports CDs by accident, really | 20:46 |
| slangasek | ok | 20:47 |
| * cody-somerville cheers. | 20:47 | |
| * cjwatson makes a small change to anonftpsync to support that | 20:48 | |
| cjwatson | should be in principle possible to say RSYNC_EXCLUDE= now | 20:48 |
| slangasek | cjwatson: which of the various d-i merges, if any, are in progress on your end right now? | 20:52 |
| mathiaz | is it normal that ubuntu-standard pulls stuff from universe ? | 20:52 |
| slangasek | mathiaz: apt-get with recommends-by-default may do so | 20:53 |
| slangasek | mathiaz: since I'm sure the recommends in main aren't tested for closure | 20:53 |
| cjwatson | slangasek: base-installer and debian-installer itself; I'd also like to do localechooser | 20:54 |
| slangasek | ok | 20:54 |
| mathiaz | slangasek: right - but ubuntu-standard *shouldn't* pull anything from universe ? | 20:55 |
| cjwatson | not bothered about the rest, although I think partman-target's status was odd because it had something in trunk which I thought was supposed to be for hardy | 20:55 |
| cjwatson | mathiaz: libkrb53? should be fixed if you update | 20:55 |
| slangasek | mathiaz: I think that's a question that's been insufficiently explored to date, since the change to recommends-by-default has only just been made :) | 20:56 |
| cjwatson | evand: were you planning to do anything with bug 224446? it has a hardy task | 20:56 |
| mathiaz | cjwatson: oh no - I've just installed ubuntu-standard in an intrepid chroot - I saw a couple of packages downloaded from universe (ex apparmor-profiles) | 20:56 |
| ubottu | Launchpad bug 224446 in ubiquity "lack of installer permission validation on existing partition" [Medium,Fix committed] https://launchpad.net/bugs/224446 | 20:56 |
| cjwatson | mathiaz: at the moment, germinate doesn't follow recommends, so that sort of thing will be improperly checked | 20:56 |
| cjwatson | I am fairly certain that installing ubuntu-standard *ought* not to pull anything from universe, though as slangasek says it's early days | 20:57 |
| mathiaz | cjwatson: ok - but the goal is to have ubuntu-standard only pull things from main | 20:57 |
| cjwatson | that's correct | 20:57 |
| mathiaz | cjwatson: ok - thanks for the clarification | 20:57 |
| cjwatson | slangasek: I think localechooser and debian-installer itself are the only remaining blockers to being able to build a vaguely working installed | 20:57 |
| cjwatson | installer | 20:57 |
| slangasek | cjwatson: ok, cool | 20:57 |
| cjwatson | the other bits are outside the initrd | 20:57 |
| cjwatson | I'm most of the way through debian-installer, just figuring out what to do with the switch to syslinux' vesamenu system | 20:58 |
| tedg | kees: You know more about gcc than I do... why does this come out 0, 0, 5, 5? http://pastebin.ubuntu.com/19958/ | 20:58 |
| tedg | It seems like the pointer shouldn't even be valid to come up with a zero. | 20:58 |
| slangasek | tedg: er, is that valid to initialize myvar_pa and myvar_ca like that above the declarations of myclass_a and myclassp_a? | 21:00 |
| slangasek | tedg: I'm having a visceral reaction to the sight of this much overt C++-ism :) | 21:01 |
| evand | cjwatson: ah, definitely. | 21:01 |
| tedg | slangasek: It doesn't give a warning... and it seems like it should be with the externs in there. But it would seem to me atleast, that it should create some sort of dependency graph instead of working them in order. | 21:02 |
| cjwatson | slangasek: I think with my launchpad-integration upload and my moves of krb5 and gmime2.2 binaries back to main (they'd landed back in universe for mysterious reasons), ubuntu-desktop/intrepid should be installable again after a couple of publisher runs | 21:02 |
| slangasek | cjwatson: excellent! | 21:02 |
| tedg | slangasek: It's small example of a bigger problem I'm having, but the linking is alot crazier. | 21:02 |
| slangasek | cjwatson: how did krb5 get bumped to universe, btw? | 21:02 |
| cjwatson | slangasek: I have no idea | 21:02 |
| cjwatson | obviously it took out half of main for installability | 21:03 |
| * slangasek nods | 21:03 | |
| cjwatson | rather freaked me out to be perfectly honest | 21:04 |
| cjwatson | evand: maybe 6.06.2 at this point ... | 21:05 |
| slangasek | tedg: well, AFAIK even in C++, extern just tells the compiler that it's allowed to resolve references to this object by way of other object files; given that the part that's misbehaving is precisely the part that looks wrong to me (querying get_var() above the initialization within the source file), I suspect that the C++ standards don't allow this? :) | 21:06 |
| evand | ok | 21:06 |
| cjwatson | evand: (just a suggestion; it does feel late to be shoving it in, though, given it's an edge case) | 21:07 |
| tedg | slangasek: The problem comes to when I put these in lots of different files, it's virtually impossible to determine the initialization order. | 21:07 |
| evand | indeed, though I agree. | 21:08 |
| slangasek | tedg: that would be an argument for not putting your non-static initializers in global scope? :-) | 21:08 |
| slangasek | tedg: sorry, "and that's why C doesn't allow this" is perhaps not the kind of help you're looking for :-) | 21:09 |
| tedg | It behaves the same with statics. | 21:09 |
| slangasek | tedg: can't be; if your initializers are all static, then none of them are interdependent | 21:09 |
| tedg | No one uses C anymore, that's soooo 1980's ;) | 21:10 |
| tedg | slangasek: Oh, sorry, I thought you meant class blah { static int a; } | 21:10 |
| cjwatson | with C, you can understand why your code is failing ;-) | 21:10 |
| cr3 | is there a name to describe the top-level directory under ubuntu archives, such as "ubuntu" under archive.ubuntu.com and "ubuntu-ports" under ports.ubuntu.com? | 21:11 |
| cjwatson | not AFAIK | 21:11 |
| kees | tedg: that code is hurting my head! | 21:11 |
| * slangasek grins | 21:11 | |
| kees | tedg: why the "extern"s ? | 21:12 |
| tedg | kees, It doesn't compile otherwise ;) | 21:12 |
| tedg | I was trying to simulate the situation I had with multiple files -- which do need the externs in the headers. | 21:12 |
| kees | but... | 21:12 |
| kees | int myvar_pa = myclassp_a->get_var(); | 21:12 |
| kees | happens before | 21:12 |
| kees | test * myclassp_a = &myclass_a; | 21:12 |
| kees | you're just getting lucky or something. | 21:13 |
| tedg | I know, and gcc should fix that! | 21:13 |
| kees | "fix"? | 21:13 |
| * slangasek cackles | 21:13 | |
| kees | it can't "fix" it -- it's the order it's written in. | 21:13 |
| tedg | It shouldn't let you call a function on an object that hasn't yet been initialized. | 21:13 |
| kees | hahaha. Well, I certainly agree there. | 21:13 |
| tedg | Okay, the linker should fix it when it's in multiple files. | 21:13 |
| kees | it can't know | 21:13 |
| slangasek | right, if it's in multiple files, there's no way the linker can know | 21:13 |
| tedg | Okay, and there's no way that I can tell the linker it seems... | 21:14 |
| tedg | It doesn't seem that link order helps. | 21:14 |
| tedg | It just becomes fragile. | 21:14 |
| kees | tedg: I don't understand the problem you're trying to fix yet. :P | 21:14 |
| slangasek | nope, the linker's job is solely to fix up the references between the objects | 21:14 |
| kees | tedg: can you make two .cc files that demonstrates this? | 21:14 |
| tedg | Yes, give me a sec. | 21:14 |
| slangasek | kees: he's trying to keep using non-static initializers in global scope, while having the compiler tell him when it's not ok for him to use non-static initializers in global scope :-) | 21:15 |
| cjwatson | presumably it doesn't give a warning because the compiler can't know whether some other bit of the link has a constructor for those objects | 21:16 |
| kees | yeah. madness | 21:16 |
| cjwatson | you can't fix this without integrating the compiler and the linker | 21:17 |
| cjwatson | AFAICS | 21:17 |
| tedg | Oooo, the link order does fix it, but it's backwards! | 21:18 |
| slangasek | right, that's not a very proper fix :-) | 21:19 |
| slangasek | cjwatson: don't mention that, you'll lend credence to the KDE practice of concatenating all source files at compile time... :) | 21:20 |
| cjwatson | it actually looks to me as if the compiler *is* reordering the constructors | 21:20 |
| cjwatson | if I put this in get_var: | 21:21 |
| cjwatson | fprintf(stderr, "%p %d\n", this, var); | 21:21 |
| cjwatson | I get | 21:21 |
| cjwatson | 0x80498d8 0 | 21:21 |
| cjwatson | 0x80498d8 0 | 21:21 |
| cjwatson | 0x80498d8 5 | 21:21 |
| cjwatson | 0x80498d8 5 | 21:21 |
| tedg | build: http://pastebin.ubuntu.com/19964/ main.cpp : http://pastebin.ubuntu.com/19965/ test.cpp : http://pastebin.ubuntu.com/19966/ test.h : http://pastebin.ubuntu.com/19967/ | 21:21 |
| cjwatson | so it's all the same object and the pointer gets validly initialised in time | 21:21 |
| cjwatson | but goodness knows why and I never want to see code that relies on that | 21:21 |
| slangasek | ah, so there's an implicit constructor, haha | 21:21 |
| tedg | Hmm, so I wonder if I block the explicit constructor.... | 21:22 |
| cjwatson | for the first call, yeah, and then the second one fills the same memory slot | 21:22 |
| cjwatson | so more complicated versions of this will likely crash | 21:23 |
| cjwatson | or misbehave | 21:23 |
| tedg | That could be optimization though, in other cases it may not optimize to use the same address. | 21:24 |
| * cjwatson promotes bsd-mailx/mailx and syncs db4.6, which should fix a bit more of the world | 21:28 | |
| === emu is now known as Schaf | ||
| * cjwatson promotes ruby1.9 too, since rrdtool build-depends on it as well as ruby1.8; duplication, but I think it's OK for the time being ... | 21:47 | |
| === Schaf is now known as emu | ||
| Nafallo | who takes care of usplash those days? | 21:50 |
| Nafallo | I just saw a screenshot of a segfault | 21:50 |
| geser | any main sponsors around which has some time to sponsor bug #239857? | 21:52 |
| ubottu | Launchpad bug 239857 in db "[intrepid] libdb-dev uninstallable due to a typo in Conflicts" [Undecided,New] https://launchpad.net/bugs/239857 | 21:52 |
| cjwatson | geser: yes, one moment | 21:54 |
| === emu is now known as emu1982 | ||
| brandonperry | ScottK: it isn't anything big, but the one in the repos is 0.92.1 while current is 0.93.1 | 21:56 |
| brandonperry | I like to stay current with things like that | 21:57 |
| ScottK | brandonperry: 93.1 is already in Intrepid | 21:57 |
| brandonperry | oh, I didn't know that | 21:57 |
| calc | jcastro: up to 20% now for triaged :) | 21:57 |
| ScottK | Unfortunately they changed all the libclamav interfaces with 0.93 and so backporting is non-trivial. | 21:57 |
| cjwatson | geser: done | 21:57 |
| brandonperry | yeah | 21:58 |
| ScottK | brandonperry: We just finished getting 0.92.1 back into all supported releases and that's a pretty major thing. | 21:58 |
| brandonperry | that is fine, I just thought someone would like to know how to get 0.93.1 | 21:58 |
| geser | cjwatson: thanks | 21:58 |
| ScottK | brandonperry: What we need is help getting programs working with 0.93.1 so that we can put it in the official backports repo. | 21:59 |
| brandonperry | ok, any specific programs? I could check into that this weekend | 22:00 |
| ScottK | brandonperry: avscan has a new upstream version that needs packaging. | 22:01 |
| ScottK | let me look at my list ... | 22:01 |
| jcastro | calc: wow, you're in the green now! :) | 22:02 |
| TheMuso | slangasek: Firstly, they were the only bugs I could reliably identify as 1.0.16 helping to fix issues users were having. The LP bug syntax was purely a misshap on my part, apologies, and I'll keep an eye on that for future reference. | 22:02 |
| slangasek | TheMuso: ok, thanks :) | 22:03 |
| ScottK | brandonperry: It looks like avscan, gurlchecker, and havp. See https://wiki.ubuntu.com/MOTU/Clamav and feel free to update it if you find something out. | 22:03 |
| brandonperry | yeah, definitely | 22:03 |
| brandonperry | thanks | 22:03 |
| ScottK | brandonperry: You might also want to update your blog entry to at least suggest grabbing the source package from Intrepid and building it locally for an earlier release. | 22:04 |
| brandonperry | ok | 22:04 |
| ScottK | brandonperry: Actually, now that I think of it, I need to stick 0.93.1 in the clamav team PPA. | 22:05 |
| brandonperry | :-) | 22:05 |
| calc | jcastro: i should have somewhere around 43% triaged when i get done with the pass | 22:07 |
| calc | once i get all of my new bugs processed it will be closer to 80% :) | 22:07 |
| jcastro | calc: rocking | 22:09 |
| jcastro | calc: percentage of triaged bugs to me isn't as important the percentage of those bugs which have upstream links | 22:10 |
| jcastro | wait, let me make sure I understand what I just said | 22:10 |
| jcastro | yeah, that's what I meant. :) | 22:11 |
| calc | yea :) | 22:12 |
| calc | i don't have very many non-upstream bugs open that have been reviewed anyway | 22:12 |
| ScottK | brandonperry: https://launchpad.net/~ubuntu-clamav/+archive - 0.93.1 is uploading for Hardy right now. | 22:13 |
| calc | a few haven't been forwarded yet, but this should help me to see them easier :) | 22:13 |
| brandonperry | thanks | 22:14 |
| jcastro | calc: I suspect that once everyone uses triaged that the numbers will end up being way better than we expected before | 22:20 |
| jcastro | calc: I think we should bring up this whole triaged state thing up to QA people during the sprint or something | 22:20 |
| calc | yea | 22:20 |
| calc | maybe a post ubuntu-devel list with the page and mentioning proper use of triaged would be helpful as well | 22:21 |
| jcastro | makes it hard to measure things when everyone has different assumptions on what different states should be | 22:21 |
| jcastro | yeah | 22:21 |
| jcastro | I'll put it on my todo to ask heno about it | 22:21 |
| calc | triaged is a relatively new status, so reminding people to use instead of confirmed when a bug has all needed data might be helpful | 22:22 |
| jcastro | yeah | 22:22 |
| jdstrand | kees, kirkland: fyi bug #239864 | 22:26 |
| ubottu | Launchpad bug 239864 in launchpad "request merge should send an email" [Undecided,New] https://launchpad.net/bugs/239864 | 22:26 |
| jdstrand | it'll be embarassing if the functionality exists, but I mentioned as much in the report | 22:26 |
| kees | jdstrand: cool, I've sub'd myself | 22:26 |
| kirkland | jdstrand: I've marked "Confirmed" | 22:27 |
| jdstrand | that'll show 'em | 22:27 |
| === evalles_ is now known as effie_jayx | ||
| jcastro | tkamppeter: where do you usually file upstream system-config-printer bugs, in the RH bugzilla or the fedorahosted trac? I am trying to determine on which one to set as the bug tracker in lp | 22:35 |
| slangasek | TheMuso: hum, I find 184 exported symbols dropped between 1.0.15 and 1.0.16, including a number of these with clearly public names | 22:52 |
| TheMuso | slangasek: This is what I wasn't sure of, and why I was uneasy about doing 1.0.16. | 22:52 |
| slangasek | TheMuso: do you have information that shows these symbols are only exposed as part of the plugin API? | 22:53 |
| TheMuso | slangasek: Other than what I have read in changeogs, no. What you've brought up though really has me thinking we should just can the proposed updates before they cause more problems. | 22:54 |
| slangasek | TheMuso: well, a significant number of these are not exposed in the 1.0.15 headers, and the change is explained as "make local functions really local", with a #define to rename them so that they're excluded from the symbol table; I'm auditing the list of changed symbols now to confirm that that's all they are | 22:58 |
| TheMuso | slangasek: ok | 22:59 |
| slangasek | TheMuso: if they are, then I'm not going to second-guess upstream any further about ABI compatibility: somebody would be screaming by now if the symbols really had been exported before | 22:59 |
| * TheMuso nods. | 23:00 | |
| * cjwatson had forgotten how soul-destroying localechooser merges are | 23:01 | |
| cjwatson | actually, that's a slight lie, I hadn't really which is why I'd been putting it off ... | 23:01 |
| * slangasek grins | 23:01 | |
| TheMuso | haha | 23:01 |
| slangasek | TheMuso: ok, all the symbols with public names are accounted for under the "make local functions really local" change | 23:12 |
| TheMuso | slangasek: Right. | 23:12 |
| slangasek | TheMuso: do you have references describing why the plugin API is an issue between .15 and .16? | 23:19 |
| TheMuso | slangasek: For a start, the ioplug plugin has a new symbol, whicih the pulse plugin in alsa-plugins 1.0.16 uses. | 23:20 |
| slangasek | oh; so inter-plugin issues | 23:20 |
| slangasek | ? | 23:20 |
| slangasek | so alsa-plugins needs to have a versioned depends on libasound2, I guess | 23:21 |
| slangasek | but upgrading libasound2 doesn't break the existing alsa-plugins, right? | 23:22 |
| TheMuso | slangasek: Plugins do break if you update libasound2 as libasoudn2 seems to look for specific versioned plugins. | 23:23 |
| slangasek | hrm, ok | 23:24 |
| slangasek | how does it test for this? | 23:24 |
| TheMuso | Not sure, I just remember upgrading libasound2, trying to use a plugin, and getting errors. | 23:25 |
| TheMuso | slangasek: I can dig deeper on Monday. | 23:26 |
| slangasek | ok | 23:27 |
| slangasek | I'm trying to figure out how we'll know if we got it right for the bluez plugins :) | 23:27 |
| * TheMuso nods. | 23:28 | |
| TheMuso | Pitty I don't have a bluetooth audio device handy. | 23:28 |
| hunger | How is the debian merge into intrepid progressing? | 23:29 |
| cjwatson | it takes in excess of a month at the beginning of each release cycle to get it done, so please don't ask daily | 23:31 |
| cjwatson | you can monitor progress using merges.ubuntu.com and the intrepid-changes mailing list | 23:32 |
| slangasek | TheMuso: I do, but app integration with alsa bluetooth is awful :) | 23:32 |
| TheMuso | slangasek: heh. | 23:33 |
| bryce | hunger: if you're interested in lending a hand, we'd be happy to give some pointers | 23:33 |
| hunger | bryce: Nope, I am too busy backporting stuff from debian to my hardy setup;-) | 23:33 |
| pwnguin | hunger: there's backports team you might be interested in | 23:34 |
| * bryce nods with pwnguin | 23:34 | |
| sistpoty | bryce: anything in particular you'd like to get merged? | 23:34 |
| hunger | pwnguin: Grabbing stuff from debian unstable and running debuild on it is not really backporting:-) | 23:35 |
| hunger | sistpoty: I'd like cmake, git-core and subversion. That is what keeps me from upgrading to intrepid at this time. | 23:35 |
| bryce | sistpoty: I'm working my way through the X stuff on MoM and of course would appreciate any help there; at this point everything listed on MoM is fair game | 23:35 |
| bryce | X merge status is here - http://people.ubuntu.com/~bryce/Xorg/versions_current.html | 23:36 |
| sistpoty | bryce: ok, I guess I'll try to look at some X stuff tomorrow | 23:36 |
| pwnguin | hunger: good point | 23:36 |
| hunger | pwnguin: The good news is: git-core and cmake are very easy to get running in hardy. debuild is enough;-) | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!