=== gouki_ is now known as gouki [01:33] hi, why is it impossible to change settings with the preinstalled cups-pdf printer? [01:33] when i remove it and add it again i could do [01:40] does iwl not support wpa? [02:26] pwnguin: Works for me. [02:27] ive never used wpa before [02:27] mostly because the DS doesn't support it [02:28] but ive now got two wrt54g's [02:30] and an ethernet cable running to my desktop, so i can set up a mini net for just the DS [02:39] ah, wpa does work with wl [02:39] iwl [02:39] must have used the wrong password yesterday === LaserJock is now known as LaserRock [04:49] morning [04:49] morning thegodfather [04:49] hi Hobbsee [04:53] ~/c [04:55] ugh === RAOF_ is now known as RAOF [05:02] morning Hobbsee [05:03] hiya lamont! [05:05] hrm... now I just need to figure out how to make the xlock password prompt come up faster when the ldap server isn't reachable [05:10] when does seb128 show up usually, I wonder [05:11] couple of hours? [05:11] * thegodfather should really reinstall his box [05:12] thegodfather: won't that turn you back into a mere mortal? [05:12] lamont: i got to the point with dpkg dies as Z and still have no idea why [05:13] "dies as Z"? [05:13] (during normal operations like apt-get dist-upgrade) [05:13] becomes a Zombie [05:13] ah [05:13] how, um, neat. [05:13] time to apply the paddles and flatline the sucker [05:13] thegodfather: any chance you know how the xlock (well, gnome lock) interacts with pam? [05:14] wow. engrish. maybe I should sleep [05:14] lamont: nope :( [05:14] does it even use pam directly or interact with some hidden gnome layer? [05:14] no worries... I'll pester seb128 the next time we're both up. :-) [05:14] dunno... I'm trying to figure out why it insists on talking to ldap, and uses the ldap password to unlock the screen... [05:15] since I want things to work when it's _not_ on the network... [05:15] /etc/pam.d/gdm* ? [05:16] so yeah it uses pam directly... [05:16] you probably want to fiddle with the @include common* [05:16] perhaps that's where it sucks in the ldap settings [05:19] yeah - only all those already DTRT, AFAIK [05:21] anyway, off with me [05:21] lamont: night [05:21] oh neat.. they just upgraded my adsl.. [05:21] 2Mb outgoing! [05:22] wowowo [05:22] Is there a list of patches that are applied to the Ubuntu kernel? === doko__ is now known as doko === Igorots is now known as Knightlust [06:23] Good morning [06:24] Morning pitti [06:24] pitti: Did my mail make sense? [06:24] morning pitti [06:24] LaserRock: Ponies! [06:25] hey StevenK, LaserRock [06:25] StevenK: wrt. the patch enabling in the merge? yes [06:25] pitti: Okay, cool. [06:25] pitti: gutenprint is in binary NEW, too ... [06:27] pitti: And I merged abiword, which Build-Depends on libpsiconv-dev. I can either file an MIR for psiconv, or disable the Psion bits of abiword. [06:31] StevenK: hm, depends on its general sanity, upstream maintenance, etc. [06:34] "Note that Psiconv is no longer in active development." [06:34] Hrm [06:35] pitti: Given that, and that's it's a one line patch to disable Psion files, shall I just do that? [06:35] StevenK: sounds better then === mpt__ is now known as mpt [06:35] (IMHO) [06:35] Mine too [06:36] pitti! [06:37] mpt: you actually around> [06:37] ? [06:37] Burgundavia: no, he got eaten. [06:37] pitti: Is apport retracing broken? [06:37] Hobbsee: stop killing and eating all the canonical devs. It just isn't social [06:38] Burgundavia: *i* didn't eat him! [06:38] * Fujitsu burps. [06:38] Hobbsee is the slitherdegee [06:38] Fujitsu: yes, it is still broken; need to fix it today [06:38] pitti: Thanks. [06:39] mpt: the what now? [06:39] Burgundavia, no, I'm actually a triangular [06:40] I really hate you all, I really do :) [06:41] * Fujitsu stabs Burgundavia with mpt. [06:44] * StevenK test-builds abiword, since he is paranoid. [06:44] mpt: What ate https://edge.launchpad.net/ubuntu/+source/bzflag? Why is there a head in the middle of my identity? [06:44] ☶▷⾿ [06:44] I agree. [06:46] Surely spitting bits of the debian changelog are not the best solution for that page? [06:46] StevenK: It's the best solution I can see. [06:46] Though it isn't a terribly good one. [06:46] Fujitsu, it's auto-linking known e-mail addresses to the equivalent Launchpad profile [06:46] 2.0.8.20060605ubuntu4 uploaded by ; Published ; Published ; text of the changelog entry [06:47] StevenK: Right. [06:47] good morning [06:47] mpt: I can see that, but it shouldn't stick my head in the middle of an otherwise pretty textual block. [06:47] Morning dholbach. [06:48] hey Fujitsu [06:48] hmmmm [06:48] (as a side note, I note that a number of them are *still* missing the attribution lines) [06:48] The head shouldn't have a space after it, at least [06:48] mpt: It's also not vertically centred in the line. [06:48] Fujitsu, but how else would we show that it was a link to a profile, and not a mailto: link? [06:49] mpt: I'm not quite sure. [06:49] It's baseline-aligned, I think [06:49] modulo the bottom pixel being not quite solid [06:49] It looks to be more than twice the height of the rest, and the rest is monospaced. [06:50] I see your point [06:50] I think if it was (a) smaller and (b) monochrome, it would be better [06:50] I've never particularly liked this layout. [06:50] StevenK: Has anybody? [06:50] StevenK, which layout? [06:50] The page in general? [06:51] It also looks like a conversation, as mpt has pointed out. [06:51] In the wrong direction. [06:51] But it's all bloggy! [06:51] s/conversation/discussion in a bug/ [06:51] And since the first link in the table talks about source packages for , and doesn't show build records, you have to parse down, and click the second link to get the information you want. [06:52] mpt: I don't think that's a good thing, actually. [06:53] Hm, did they remove the changes file links from primary archive package pages too? [06:53] StevenK, I wasn't being serious :-) [06:53] mpt: I much prefered the table, and besides in a real bug, that page doesn't show the Component for each release any more [06:54] The table entirely ceased to be in 1.1.10, which made me slightly unamused. [06:54] bug 145428 [06:54] Launchpad bug 145428 in soyuz "Source package page looks like a discussion" [Undecided,New] https://launchpad.net/bugs/145428 [06:55] That isn't my bug. [06:55] No, that's Fujitsu's [06:55] mpt: Try and determine when a source package was promoted from main to universe, you have to click on up to eight links and clicking a link and going back takes ~ 8 seconds [06:55] Bug #141540. [06:55] Launchpad bug 141540 in soyuz "New source page doesn't show in which component a package is" [Undecided,New] https://launchpad.net/bugs/141540 [06:56] Yay [06:56] That's how they fixed my bug, then. They show the component on the build page, but now don't show it on the main page. :-) [06:57] Bug #157064 is also relevant. [06:57] Neat. Reported two months ago. And no comments [06:57] Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 [06:57] StevenK: They get that way. [06:58] * Hobbsee takes another drink. [06:59] Hobbsee: Wrong channel [06:59] Hobbsee: Haha. [06:59] StevenK: you know, i'm not surprised that ubuntu people are permanenty sozzled, now. [07:00] nevertheless, that's a very odd decision on hwo to change the pages. [07:00] Hah [07:00] StevenK, and this is something you want to do often? [07:01] Find out which component a package is in, I mean [07:01] mpt: of course [07:01] mpt: Very often! [07:01] mpt: although there are easier ways to do it than LP, thank goodness. [07:01] It controls whether we can upload it or not (well, not for Hobbsee or StevenK) [07:01] (faster) [07:01] ok [07:01] Hobbsee: There are faster ways to do most things on LP when you're in .au. [07:02] Fujitsu: Now now [07:02] mpt: are there any plans to actually go around and ask devlopers what they'd find to be the most useful on those pages? [07:02] Fujitsu: another drink, methinks. [07:02] Fujitsu: but yes. [07:02] That wasn't entirely a stab at LP. [07:02] oh, right, so only half a drink [07:02] Though it does manage to perform particularly badly, somehow. [07:02] the other half was against the state of au internet. [07:03] One day, Hobbsee, one day [07:04] mpt: one day wheN? :) [07:04] Meanwhile, I've set 141540 to High [07:04] * Fujitsu grumbles about the listed sourcepackagepublishings on that page being misleading (bug #144190) [07:04] Launchpad bug 144190 in soyuz "New distrosourcepackage page has misleading dates in version history" [Undecided,New] https://launchpad.net/bugs/144190 [07:05] Hobbsee: oh, I think you are happy to see the fix for bug 152400 rolled out? [07:05] Launchpad bug 152400 in soyuz "accept from +queue UI does not send mail to announcement list" [High,Fix committed] https://launchpad.net/bugs/152400 [07:05] pitti: yup :D [07:09] huh [07:09] Why is "Source package publishing history" a separate page at all? [07:10] mpt: Because it used to be the original table. [07:10] Then it got eaten. [07:10] Oh, it shows a bit more detail [07:10] The old table was nice and tabular and readable. [07:10] mpt: Right, and it used to be in a nicer format. [07:10] Separate boxes for each distribution series [07:11] whereas the source package page is one box per version, with distribution series shown together [07:11] mpt: Each SourcePackagePublishing, I believe. [07:11] We could probably merge that somehow [07:11] mpt: it was too usable in the old format... so it _had_ to change. :( [07:12] * lamont still wants a +source/foo/+latest [07:12] hmmm [07:12] You reported a bug about that, right lamont? [07:12] I don't remember what it was asking for specifically [07:12] I think it's there [07:13] short cut link to +source/pkg/$latest-version-in-the-archive [07:13] That'd be nice [07:13] * Fujitsu notes that that combined with bug #130158 would be nice. [07:13] Launchpad bug 130158 in soyuz "Launchpad should provide dgettable URLs" [Medium,Confirmed] https://launchpad.net/bugs/130158 === pitti is now known as pitti_laptop [07:15] So, I'll see if I can find out why the page was changed [07:16] (I'm sure "it was too usable" isn't the reason:-) [07:16] Haha. Are you sure? :-P [07:17] ... and see if there's a way we can achieve whatever it was, while still having the component etc on the main page. [07:18] pitti: New abiword uploading [07:18] Gah, just after the publisher run, too [07:18] StevenK: It's not so bad now that only binaries have to go through Accepted. [07:19] Fujitsu: Unless they're NEW? [07:19] StevenK: I presume so. [07:19] Though the flow isn't documented anywhere public, as far as I know... === doko_ is now known as doko [07:29] StevenK: gimp-gutenprint NEWed [07:31] * lamont wonders if someone maybe retried/rescored ebug-http (iz b0rken) [07:31] it loops on the buildd trying to access CPAN to fetch missing bits... [07:31] so please don't retry it, whoever. [07:31] lamont: Eww. [07:32] it's not uncommon for things to _try_ to hit the net.. the DC buildds don't let them, of course. [07:32] * Hobbsee didn't. [07:32] and yay, b0rken! [07:35] * lamont decides that maybe it's bed time [07:36] Night lamont. [07:38] * Hobbsee gives lamont back, to see if he is awake this time. === stu1 is now known as stub [07:59] pitti: Thanks! === \sh_away is now known as \sh [08:39] <\sh> moins [08:42] <\sh> is anybody working on including the mulberry email client into debian/ubuntu? [08:43] \sh: https://bugs.launchpad.net/ubuntu/+bug/136356 - no, doesn't look like it [08:43] Launchpad bug 136356 in ubuntu "[needs-packaging] mulberry mail" [Wishlist,Triaged] [08:45] Greetings everybody! [08:57] * pitti hugs MacSlow [08:57] * MacSlow gives pitti ^5 [09:00] <\sh> doko, would you like to to fix CVE-2007-4965 for python2.5 in hardy, or should I push the fix to u-m-s? [09:00] Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE [09:01] <\sh> doko, you find a fix for gutsy version (which is the same as in hardy) in bug #163845 [09:01] Launchpad bug 163845 in python2.5 "[python] Multiple integer overflow vulnerabilities possibly resulting in the execution of arbitrary code or DoS" [Undecided,In progress] https://launchpad.net/bugs/163845 [09:20] mvo: morning [09:20] \sh: seen it, thanks [09:20] good morning slangasek [09:21] <\sh> doko, I added some lines to your rules file...it took my life to understand all this ;) cool work :) [09:21] mvo: did you get my mail, or did I screw up the destination? :) [09:22] slangasek: thanks, I got the mail. I will answer when I finished my tea :) [09:22] sounds good [09:28] hey mvo [09:28] Compiling /usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeCache.py ... [09:28] seb128: I uploaded a new gnome-screenserver for a NBSism [09:28] File "/usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeCache.py", line 452 [09:28] finally: [09:28] ^ [09:28] SyntaxError: invalid syntax [09:29] mvo: are you aware of this update-manager bug? [09:29] StevenK: I've noticed, thanks [09:29] mvo: try:/except:/finally: doesn't work with at least 2.4 (I think they introduced it into 2.5) [09:29] seb128: No problem :-) [09:29] what's the right way to request a sync (new package eally) of thinkfinger from debian into ubuntu? [09:29] note: thinkfinger is in experimental [09:30] pwnguin: file a sync request bug with requestsync [09:30] pwnguin: open a sync bug on launchpad [09:30] ok [09:30] pwnguin: I second this, I'm using the packages on my notebook [09:30] heh [09:30] excellent [09:30] testers [09:30] ive been putting it in my ppa [09:30] and patching a few things [09:30] ie i fixed gksudo [09:31] http://wiki.ubuntu.com/SyncRequestProcess [09:31] i assume new packages of uncertain quality should land go to universe? [09:33] all packages (with suitable licenses) 'start' in universe [09:33] it needs to fulfill https://wiki.ubuntu.com/UbuntuMainInclusionRequirements to get into main [09:33] im pretty sure it's fine [09:34] im not sure why its in experimental in the first place, perhaps because integration isn't there yet [09:34] it needs to be discussed and everything to get into the default set of packages [09:34] ok [09:38] pitti: hrm, thanks. [09:40] pitti: where did you see it? do you run 2.4 by default? [09:40] mvo: It's on all systems where python2.4 is installed. [09:41] mvo: #164947 [09:41] mvo: just apt-get dist-upgrade [09:42] mvo: preferably u-m shouldn't declare itself to be compatible with 2.4; there's no library where we need it for 2.4, right? [09:42] Python-Version: 2.4, 2.5 [09:42] that should just be 'current' in the source package, right? [09:42] oh, yeah. fixing it now [09:42] pitti: bug #165138 [09:42] Launchpad bug 165138 in ubuntu "Sync Thinkfinger from Debian experimental" [Undecided,New] https://launchpad.net/bugs/165138 [09:43] Better to skip thinkfinger, I suspect [09:43] fprint is looking like a much better option [09:43] pwnguin: I acked the sync request [09:43] is it working? [09:43] thinkfinger v0.3 changelog: "avoid fingerprint device from heating up "... [09:44] fprint? Does for me, though I'm using an aes2510 rather than a upek [09:44] ... sounds special. [09:44] it's worked fine for me at least [09:44] If we're doing any sort of distribution-wide integration, fprint is certainly the way to go [09:45] It has the significant advantage of not being hardware specific [09:45] there's people currently talking about moving towards fprint [09:45] integration is more of a policy issue than a technical one [09:46] but thinkfinger is saying one more bugfix release then a lull while work on a new system is done [09:46] "should we automatically enable this binary, black box, hash-providing proprietary hardware as a core authenication mechanism" [09:46] There's no benefit in us doing anything more with thinkfinger [09:46] It can't be integrated nicely [09:46] sladen: which country do you live in? [09:47] mjg59: does fprint have a sensible GUI/integration for registering fingerprints? [09:47] I can see a case for having it there to keep the whingers happy, until such a time as we genuinely have a "Provides:/Conflicts:" implementation depolyed [09:47] pitti: Yes [09:47] pwnguin: I live in HEL! [09:47] pitti: Well, I'd quibble over sensible. But it exists and works. [09:47] mjg59: ah, great; that's what I was missing in tf [09:47] pitti: Needs some UI love [09:47] better than TF, which needs an UI in the first place :) [09:48] Needs packaging, but it's pretty trivial [09:48] mjg59: fprint is not yet in Debian AFAICS? [09:48] Only issue is the lack of ABI guarantees on the library [09:48] So it'd need some shlibdeps magic [09:48] pitti: if it is, FingerForce isn't talking about it [09:49] It's a bit too happy about producing false negatives, but that's because my hardware requires all the comparison work to be done in software [09:49] The scanner is just a scanner, there's no intelligence in it [09:49] ironically my hardware controls it in hardware [09:49] Yes, so it wouldn't be a problem for you [09:49] apparently its easier to export control hardware than source code / software [09:50] Burgundavia: they are "normal people" oriented, who get confused by having the same milestone called a different thing in each release [09:50] note: its not clear how US export laws intersect with fingerprinting [09:50] pwnguin: well, it's still software, I guess, in a µC? [09:51] pitti: something like that. but naturally heavily tied to the hardware it runs in [09:51] That's fine, we don't export anything from the US [09:51] "we" dont [09:51] but i happen to live there =( [09:54] There's clearly a couple of algorithmic issues with fprint, given its willingness to identify my middle finger and lack of enthusiasm about my index finger [09:54] well, these things are statistical in nature [09:54] they're going to have false positives and negatives [09:56] there was even an article on c't about fooling these things [10:03] mjg59: you might wanna deliver some of your sense to the people tinkering on this bioAPI blueprint in lp/wiki [10:05] Yeah, bioAPI may not be the way forward [10:05] mjg59: giving fprint the middle finger, uh? ;) [10:05] I'm not really going to have time to do anything until the new year [10:06] One more chapter and some conclusions to write === cprov-away is now known as cprov === pedro is now known as pedro_ [11:28] StevenK: do you know about https://wiki.ubuntu.com/Bugs/Debian/Usertagging? (just pointing it in case, you didn't tag the bluez-libs shlibs bump bug apparently) [11:29] I didn't, actually [11:29] ok [11:30] StevenK: you might want to use submittodebian which does that for you [11:30] Oh, in u-d-t? [11:31] yes [11:31] It does quite a bit more than that, too. [11:33] seb128: but that requires actually reading ubuntu-devel.... [11:35] Hobbsee: what? knowing about usertagging? [11:36] seb128: about how to use it, yes [11:38] or having somebody on IRC showing you the wikipage ;-) === dholbach_ is now known as dholbach [11:58] pitti, around? [11:59] Mez: yes [11:59] pitti, may I /msg you (security issue) [11:59] Mez: mailing security@ubuntu.com is better with those issues, but sure, you can always /msg me :) [12:15] Am now reading NewPackges on the wiki. They seem to assume that there's an upstream you're going to package. Should "upstream" be maintained separately from the Debian/Ubuntu patch even if we're the developer for both? [12:15] ciphergoth: Please. This achieves two goals: [12:16] 1) It makes for a clean separation of packaging from software, which helps when tracking down various problems (e.g. you don't need to change the software to rebuild, or comply with new distro policies (usually)) [12:16] ok [12:19] 2) It means that the software can be included in other distributions more easily, making all Linux environments better. [12:19] ciphergoth: As an additional note, I'd suggest that if you are both, you don't apply any patches in your diff.gz, but just add the packaging bits. [12:19] that's slightly tricky in general - eg defaulting to "sensible-editor" rather than to "vi" or whatever [12:20] not that that issue affects us [12:21] ciphergoth: True. I'd recommend upstreams to use a configuration file to adjust those values, for ease of packaging, but if you're not affected, that's easier. [12:21] for the record, I and others disagree with persia on where to apply patches (not that I want to have the argument yet again, but it's worth noting that this is not a universal mandate) [12:22] I wonder how we should arrange it in terms of revision control? The easiest thing might be to have a single repository, and actually arrange for the tgz builder in the Makefile to delete the debian directory [12:22] cjwatson: You'd prefer that upstreams who also maintain software keep distribution patches in diff.gz? [12:22] persia: sometimes it's the right answer [12:22] * persia notes that this isn't a debian/patches vs. diff.gz discussion [12:22] oh, I see. but nevertheless :-) [12:22] I have a couple of small patches to man-db in the packaging, despite also being upstream [12:22] cjwatson: I suppose. I still think it's better for other distributions to adopt the patches in most cases. [12:22] and I don't think it's unreasonable [12:23] it depends whether the patches are distro customisation or bug-fixes [12:23] in the latter case, I agree with you [12:23] True. In the former case, I agree with you. [12:23] excellent :-) [12:24] the man-db case is a patch to the upstream default configuration file [12:24] don't know much about debian/patches actually - I'm guessing that rather than directly patching the software in the .diff.gz, the diff.gz writes the patch to debian/patches and the build process applies it? [12:24] Further, and for the record, I'm not opposed to raw patches in diff.gz, just to mixing debian/patches and raw patches. [12:24] ciphergoth: right, that's how the debian/patches/ scheme works [12:24] persia: the latter is definitely evil [12:24] as is patching debian/ itself in debian/patches/ [12:24] ciphergoth: That's about it. Some people prefer that, but many don't. Best to choose a scheme that works best for you. [12:25] .diff.gz was always a mistake IMHO - it should always have been a script which built the Debian sources given the upstream sources [12:25] cjwatson: Yes. That's really unfortunate as well. [12:25] a script has the freedom to move things around, for example, or to unpack any kind of archive [12:25] ciphergoth: Maybe, but I prefer to get content and use trusted tools to manipulate it, rather than calling random scripts. [12:25] ciphergoth: like I said, I don't especially want to hash through it again, but the property of inline patches that many people like is that dpkg-source -x gives you the source without any further messing around [12:26] ciphergoth: while people like debian/patches/ for other reasons such as separating out one change from another [12:26] there are various very very slow-moving projects to try to unify these [12:26] well, there's no point raking over decade-old design decisions that can't be changed now anyway [12:26] oh, they can [12:26] Which makes it really easy to track down issues in the code (e.g. hunting backtraces) [12:26] it just takes ages [12:26] and needs lots of buy-in [12:27] ciphergoth: if you're interested in how they change, look for "dpkg wig and pen" on your favourite search engine. [12:27] The Right Thing would have been for the .tar.gz to have been *exactly* what upstream ship, always [12:27] ciphergoth: That's the policy: the orig.tar.gz must be upstream, and if upstream doesn't ship one, there should be a provided script to generate one from upstream provided data. [12:28] ciphergoth: that doesn't work if upstream ships non-free files, for instance. [12:28] * persia notes that the wig & pen wiki pages have moved around so much that much of the content is now very difficult to find [12:29] persia: it looks like I'm taking over hosting of dpkg.org, so it should be easy to find once DNS is updated. :-) [12:29] Mithrandir: Excellent :) [12:30] Mithrandir: On a completely unrelated note, what do you think about sticking uqm-music and uqm-voices in multiverse? [12:30] Mithrandir: search hits aren't as useful as you'd like for that - found this but any better links appreaciated http://www.advogato.org/person/joey/diary.html?start=153 [12:30] persia: they're quite large, iirc? [12:30] Mithrandir: Incredibly huge [12:31] persia: I don't think we have a policy on it per se.. mail -archive and ask? [12:31] (the alternative is pulling them from raw.no) [12:31] persia: isn't it almost more common than not that the .orig.tar.gz file you find in the Debian archives is not binary-identical to the upstream one? [12:31] persia: I should get people to update that url to err.no instead.. [12:31] Mithrandir: OK. I just figured you might have an opinion based on their current hosting. [12:32] persia: I haven't had complaints about excessive bandwidth usage, but if distros want to take them, that's fine with me. [12:32] ciphergoth: No, it should be the other way round. [12:33] ciphergoth: It shouldn't be more common. If there's a case like that, and there's not a debian/rules get-orig-source: I'd consider it a bug (although there's still heaps of packages that do it with README.Debian-source) [12:33] ciphergoth: you're certainly welcome to back that up, but that hadn't been my observation either [12:33] persia, cjwatson: that perception could be totally wrong. You always notice the exceptions more after all. [12:34] (1) screwup (2) upstream ships .tar.bz2 or something else (3) upstream ships non-free files (4) current "upstream tarball" is actually a random build from a VCS [12:34] are basically the cases [12:34] OK [12:34] There are quite a few core packages affected, which makes it more visible too. [12:35] Anyway, putting all that aside [12:35] Those of you who maintain both upstream and the Debian/Ubuntu package - what do you do in your source control? [12:39] ciphergoth: You might want to ask that question in #ubuntu-motu : I believe there are more people who meet that criterion there. [12:43] TheMuso: you have a gnome-orca update listed on the desktop team TODO, there is a new version in Debian though, could you do the merge for this one rather? [12:52] Will the alpha release on Thursday have 2.4.22 kernels? [12:53] soren: 2.4.n? not likely no [12:53] *headdesk* [12:53] ;-) [12:53] It didn't look right to me either, but I couldn't spot the error :) [12:53] Will the alpha release on Thursday have 2.6.22 kernels? [12:53] dunno about the kernel team plans [12:53] but that starts being late to get a new version now [12:53] It sure does. [12:54] Hard to get everything built and at least install tested by Thursday, no? [12:54] I've got a few bugs I'd like to report against a new kernel, too, but I just have to wait, I guess. === ogra1 is now known as ogra === ScottK2 is now known as ScottK [13:22] Hobbsee: heh === cprov is now known as cprov-lunch [13:22] seb128: you aroudn? [13:23] lamont: yes === ember_ is now known as ember [13:42] * lamont -> work [13:44] pitti: responded to 153132 about the issues with the SRU [13:45] calc: ah, thanks [13:45]