| === gouki_ is now known as gouki | ||
| Kano | hi, why is it impossible to change settings with the preinstalled cups-pdf printer? | 01:33 |
|---|---|---|
| Kano | when i remove it and add it again i could do | 01:33 |
| pwnguin | does iwl not support wpa? | 01:40 |
| RAOF_ | pwnguin: Works for me. | 02:26 |
| pwnguin | ive never used wpa before | 02:27 |
| pwnguin | mostly because the DS doesn't support it | 02:27 |
| pwnguin | but ive now got two wrt54g's | 02:28 |
| pwnguin | and an ethernet cable running to my desktop, so i can set up a mini net for just the DS | 02:30 |
| pwnguin | ah, wpa does work with wl | 02:39 |
| pwnguin | iwl | 02:39 |
| pwnguin | must have used the wrong password yesterday | 02:39 |
| === LaserJock is now known as LaserRock | ||
| thegodfather | morning | 04:49 |
| Hobbsee | morning thegodfather | 04:49 |
| thegodfather | hi Hobbsee | 04:49 |
| TheMuso | ~/c | 04:53 |
| TheMuso | ugh | 04:55 |
| === RAOF_ is now known as RAOF | ||
| lamont | morning Hobbsee | 05:02 |
| Hobbsee | hiya lamont! | 05:03 |
| lamont | 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:05 |
| lamont | when does seb128 show up usually, I wonder | 05:10 |
| Hobbsee | couple of hours? | 05:11 |
| * thegodfather should really reinstall his box | 05:11 | |
| lamont | thegodfather: won't that turn you back into a mere mortal? | 05:12 |
| thegodfather | lamont: i got to the point with dpkg dies as Z and still have no idea why | 05:12 |
| lamont | "dies as Z"? | 05:13 |
| thegodfather | (during normal operations like apt-get dist-upgrade) | 05:13 |
| thegodfather | becomes a Zombie | 05:13 |
| lamont | ah | 05:13 |
| lamont | how, um, neat. | 05:13 |
| lamont | time to apply the paddles and flatline the sucker | 05:13 |
| lamont | thegodfather: any chance you know how the xlock (well, gnome lock) interacts with pam? | 05:13 |
| lamont | wow. engrish. maybe I should sleep | 05:14 |
| thegodfather | lamont: nope :( | 05:14 |
| thegodfather | does it even use pam directly or interact with some hidden gnome layer? | 05:14 |
| lamont | no worries... I'll pester seb128 the next time we're both up. :-) | 05:14 |
| lamont | dunno... I'm trying to figure out why it insists on talking to ldap, and uses the ldap password to unlock the screen... | 05:14 |
| lamont | since I want things to work when it's _not_ on the network... | 05:15 |
| thegodfather | /etc/pam.d/gdm* ? | 05:15 |
| thegodfather | so yeah it uses pam directly... | 05:16 |
| thegodfather | you probably want to fiddle with the @include common* | 05:16 |
| thegodfather | perhaps that's where it sucks in the ldap settings | 05:16 |
| lamont | yeah - only all those already DTRT, AFAIK | 05:19 |
| lamont | anyway, off with me | 05:21 |
| thegodfather | lamont: night | 05:21 |
| thegodfather | oh neat.. they just upgraded my adsl.. | 05:21 |
| thegodfather | 2Mb outgoing! | 05:21 |
| thegodfather | wowowo | 05:22 |
| Seq | Is there a list of patches that are applied to the Ubuntu kernel? | 05:22 |
| === doko__ is now known as doko | ||
| === Igorots is now known as Knightlust | ||
| pitti | Good morning | 06:23 |
| StevenK | Morning pitti | 06:24 |
| StevenK | pitti: Did my mail make sense? | 06:24 |
| LaserRock | morning pitti | 06:24 |
| StevenK | LaserRock: Ponies! | 06:24 |
| pitti | hey StevenK, LaserRock | 06:25 |
| pitti | StevenK: wrt. the patch enabling in the merge? yes | 06:25 |
| StevenK | pitti: Okay, cool. | 06:25 |
| StevenK | pitti: gutenprint is in binary NEW, too ... | 06:25 |
| StevenK | 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:27 |
| pitti | StevenK: hm, depends on its general sanity, upstream maintenance, etc. | 06:31 |
| StevenK | "Note that Psiconv is no longer in active development." | 06:34 |
| StevenK | Hrm | 06:34 |
| StevenK | pitti: Given that, and that's it's a one line patch to disable Psion files, shall I just do that? | 06:35 |
| pitti | StevenK: sounds better then | 06:35 |
| === mpt__ is now known as mpt | ||
| pitti | (IMHO) | 06:35 |
| StevenK | Mine too | 06:35 |
| Hobbsee | pitti! | 06:36 |
| Burgundavia | mpt: you actually around> | 06:37 |
| Burgundavia | ? | 06:37 |
| Hobbsee | Burgundavia: no, he got eaten. | 06:37 |
| Fujitsu | pitti: Is apport retracing broken? | 06:37 |
| Burgundavia | Hobbsee: stop killing and eating all the canonical devs. It just isn't social | 06:37 |
| Hobbsee | Burgundavia: *i* didn't eat him! | 06:38 |
| * Fujitsu burps. | 06:38 | |
| mpt | Hobbsee is the slitherdegee | 06:38 |
| pitti | Fujitsu: yes, it is still broken; need to fix it today | 06:38 |
| Fujitsu | pitti: Thanks. | 06:38 |
| Hobbsee | mpt: the what now? | 06:39 |
| mpt | Burgundavia, no, I'm actually a triangular | 06:39 |
| Burgundavia | I really hate you all, I really do :) | 06:40 |
| * Fujitsu stabs Burgundavia with mpt. | 06:41 | |
| * StevenK test-builds abiword, since he is paranoid. | 06:44 | |
| Fujitsu | mpt: What ate https://edge.launchpad.net/ubuntu/+source/bzflag? Why is there a head in the middle of my identity? | 06:44 |
| mpt | ☶▷⾿ | 06:44 |
| Fujitsu | I agree. | 06:44 |
| StevenK | Surely spitting bits of the debian changelog are not the best solution for that page? | 06:46 |
| Fujitsu | StevenK: It's the best solution I can see. | 06:46 |
| Fujitsu | Though it isn't a terribly good one. | 06:46 |
| mpt | Fujitsu, it's auto-linking known e-mail addresses to the equivalent Launchpad profile | 06:46 |
| StevenK | 2.0.8.20060605ubuntu4 uploaded by <head> <link William Grant> ; Published ; Published ; text of the changelog entry | 06:46 |
| Fujitsu | StevenK: Right. | 06:47 |
| dholbach | good morning | 06:47 |
| Fujitsu | mpt: I can see that, but it shouldn't stick my head in the middle of an otherwise pretty textual block. | 06:47 |
| Fujitsu | Morning dholbach. | 06:47 |
| dholbach | hey Fujitsu | 06:48 |
| mpt | hmmmm | 06:48 |
| Fujitsu | (as a side note, I note that a number of them are *still* missing the attribution lines) | 06:48 |
| mpt | The head shouldn't have a space after it, at least | 06:48 |
| Fujitsu | mpt: It's also not vertically centred in the line. | 06:48 |
| mpt | Fujitsu, but how else would we show that it was a link to a profile, and not a mailto: link? | 06:48 |
| Fujitsu | mpt: I'm not quite sure. | 06:49 |
| mpt | It's baseline-aligned, I think | 06:49 |
| mpt | modulo the bottom pixel being not quite solid | 06:49 |
| Fujitsu | It looks to be more than twice the height of the rest, and the rest is monospaced. | 06:49 |
| mpt | I see your point | 06:50 |
| mpt | I think if it was (a) smaller and (b) monochrome, it would be better | 06:50 |
| StevenK | I've never particularly liked this layout. | 06:50 |
| Fujitsu | StevenK: Has anybody? | 06:50 |
| mpt | StevenK, which layout? | 06:50 |
| mpt | The page in general? | 06:50 |
| Fujitsu | It also looks like a conversation, as mpt has pointed out. | 06:51 |
| Fujitsu | In the wrong direction. | 06:51 |
| mpt | But it's all bloggy! | 06:51 |
| Fujitsu | s/conversation/discussion in a bug/ | 06:51 |
| StevenK | And since the first <version> link in the table talks about source packages for <release>, and doesn't show build records, you have to parse down, and click the second <version> link to get the information you want. | 06:51 |
| StevenK | mpt: I don't think that's a good thing, actually. | 06:52 |
| Fujitsu | Hm, did they remove the changes file links from primary archive package pages too? | 06:53 |
| mpt | StevenK, I wasn't being serious :-) | 06:53 |
| StevenK | 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:53 |
| Fujitsu | The table entirely ceased to be in 1.1.10, which made me slightly unamused. | 06:54 |
| mpt | bug 145428 | 06:54 |
| ubotu | Launchpad bug 145428 in soyuz "Source package page looks like a discussion" [Undecided,New] https://launchpad.net/bugs/145428 | 06:54 |
| StevenK | That isn't my bug. | 06:55 |
| mpt | No, that's Fujitsu's | 06:55 |
| StevenK | 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 |
| Fujitsu | Bug #141540. | 06:55 |
| ubotu | 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:55 |
| StevenK | Yay | 06:56 |
| StevenK | 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:56 |
| Fujitsu | Bug #157064 is also relevant. | 06:57 |
| StevenK | Neat. Reported two months ago. And no comments | 06:57 |
| ubotu | Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 | 06:57 |
| Fujitsu | StevenK: They get that way. | 06:57 |
| * Hobbsee takes another drink. | 06:58 | |
| StevenK | Hobbsee: Wrong channel | 06:59 |
| Fujitsu | Hobbsee: Haha. | 06:59 |
| Hobbsee | StevenK: you know, i'm not surprised that ubuntu people are permanenty sozzled, now. | 06:59 |
| Hobbsee | nevertheless, that's a very odd decision on hwo to change the pages. | 07:00 |
| StevenK | Hah | 07:00 |
| mpt | StevenK, and this is something you want to do often? | 07:00 |
| mpt | Find out which component a package is in, I mean | 07:01 |
| Hobbsee | mpt: of course | 07:01 |
| Fujitsu | mpt: Very often! | 07:01 |
| Hobbsee | mpt: although there are easier ways to do it than LP, thank goodness. | 07:01 |
| Fujitsu | It controls whether we can upload it or not (well, not for Hobbsee or StevenK) | 07:01 |
| Hobbsee | (faster) | 07:01 |
| mpt | ok | 07:01 |
| Fujitsu | Hobbsee: There are faster ways to do most things on LP when you're in .au. | 07:01 |
| StevenK | Fujitsu: Now now | 07:02 |
| Hobbsee | 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 |
| Hobbsee | Fujitsu: another drink, methinks. | 07:02 |
| Hobbsee | Fujitsu: but yes. | 07:02 |
| Fujitsu | That wasn't entirely a stab at LP. | 07:02 |
| Hobbsee | oh, right, so only half a drink | 07:02 |
| Fujitsu | Though it does manage to perform particularly badly, somehow. | 07:02 |
| Hobbsee | the other half was against the state of au internet. | 07:02 |
| mpt | One day, Hobbsee, one day | 07:03 |
| Hobbsee | mpt: one day wheN? :) | 07:04 |
| mpt | Meanwhile, I've set 141540 to High | 07:04 |
| * Fujitsu grumbles about the listed sourcepackagepublishings on that page being misleading (bug #144190) | 07:04 | |
| ubotu | Launchpad bug 144190 in soyuz "New distrosourcepackage page has misleading dates in version history" [Undecided,New] https://launchpad.net/bugs/144190 | 07:04 |
| pitti | Hobbsee: oh, I think you are happy to see the fix for bug 152400 rolled out? | 07:05 |
| ubotu | 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 |
| Hobbsee | pitti: yup :D | 07:05 |
| mpt | huh | 07:09 |
| mpt | Why is "Source package publishing history" a separate page at all? | 07:09 |
| Fujitsu | mpt: Because it used to be the original table. | 07:10 |
| Fujitsu | Then it got eaten. | 07:10 |
| mpt | Oh, it shows a bit more detail | 07:10 |
| Fujitsu | The old table was nice and tabular and readable. | 07:10 |
| Fujitsu | mpt: Right, and it used to be in a nicer format. | 07:10 |
| mpt | Separate boxes for each distribution series | 07:10 |
| mpt | whereas the source package page is one box per version, with distribution series shown together | 07:11 |
| Fujitsu | mpt: Each SourcePackagePublishing, I believe. | 07:11 |
| mpt | We could probably merge that somehow | 07:11 |
| lamont | mpt: it was too usable in the old format... so it _had_ to change. :( | 07:11 |
| * lamont still wants a +source/foo/+latest | 07:12 | |
| mpt | hmmm | 07:12 |
| mpt | You reported a bug about that, right lamont? | 07:12 |
| mpt | I don't remember what it was asking for specifically | 07:12 |
| lamont | I think it's there | 07:12 |
| lamont | short cut link to +source/pkg/$latest-version-in-the-archive | 07:13 |
| StevenK | That'd be nice | 07:13 |
| * Fujitsu notes that that combined with bug #130158 would be nice. | 07:13 | |
| ubotu | Launchpad bug 130158 in soyuz "Launchpad should provide dgettable URLs" [Medium,Confirmed] https://launchpad.net/bugs/130158 | 07:13 |
| === pitti is now known as pitti_laptop | ||
| mpt | So, I'll see if I can find out why the page was changed | 07:15 |
| mpt | (I'm sure "it was too usable" isn't the reason:-) | 07:16 |
| StevenK | Haha. Are you sure? :-P | 07:16 |
| mpt | ... and see if there's a way we can achieve whatever it was, while still having the component etc on the main page. | 07:17 |
| StevenK | pitti: New abiword uploading | 07:18 |
| StevenK | Gah, just after the publisher run, too | 07:18 |
| Fujitsu | StevenK: It's not so bad now that only binaries have to go through Accepted. | 07:18 |
| StevenK | Fujitsu: Unless they're NEW? | 07:19 |
| Fujitsu | StevenK: I presume so. | 07:19 |
| Fujitsu | Though the flow isn't documented anywhere public, as far as I know... | 07:19 |
| === doko_ is now known as doko | ||
| pitti | StevenK: gimp-gutenprint NEWed | 07:29 |
| * lamont wonders if someone maybe retried/rescored ebug-http (iz b0rken) | 07:31 | |
| lamont | it loops on the buildd trying to access CPAN to fetch missing bits... | 07:31 |
| lamont | so please don't retry it, whoever. | 07:31 |
| Fujitsu | lamont: Eww. | 07:31 |
| lamont | 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 | |
| Hobbsee | and yay, b0rken! | 07:32 |
| * lamont decides that maybe it's bed time | 07:35 | |
| Fujitsu | Night lamont. | 07:36 |
| * Hobbsee gives lamont back, to see if he is awake this time. | 07:38 | |
| === stu1 is now known as stub | ||
| StevenK | pitti: Thanks! | 07:59 |
| === \sh_away is now known as \sh | ||
| \sh | moins | 08:39 |
| \sh | is anybody working on including the mulberry email client into debian/ubuntu? | 08:42 |
| dholbach | \sh: https://bugs.launchpad.net/ubuntu/+bug/136356 - no, doesn't look like it | 08:43 |
| ubotu | Launchpad bug 136356 in ubuntu "[needs-packaging] mulberry mail" [Wishlist,Triaged] | 08:43 |
| MacSlow | Greetings everybody! | 08:45 |
| * pitti hugs MacSlow | 08:57 | |
| * MacSlow gives pitti ^5 | 08:57 | |
| \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 |
| ubotu | 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:00 |
| \sh | doko, you find a fix for gutsy version (which is the same as in hardy) in bug #163845 | 09:01 |
| ubotu | 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:01 |
| slangasek | mvo: morning | 09:20 |
| doko | \sh: seen it, thanks | 09:20 |
| mvo | good morning slangasek | 09:20 |
| \sh | doko, I added some lines to your rules file...it took my life to understand all this ;) cool work :) | 09:21 |
| slangasek | mvo: did you get my mail, or did I screw up the destination? :) | 09:21 |
| mvo | slangasek: thanks, I got the mail. I will answer when I finished my tea :) | 09:22 |
| slangasek | sounds good | 09:22 |
| pitti | hey mvo | 09:28 |
| pitti | Compiling /usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeCache.py ... | 09:28 |
| StevenK | seb128: I uploaded a new gnome-screenserver for a NBSism | 09:28 |
| pitti | File "/usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeCache.py", line 452 | 09:28 |
| pitti | finally: | 09:28 |
| pitti | ^ | 09:28 |
| pitti | SyntaxError: invalid syntax | 09:28 |
| pitti | mvo: are you aware of this update-manager bug? | 09:29 |
| seb128 | StevenK: I've noticed, thanks | 09:29 |
| pitti | mvo: try:/except:/finally: doesn't work with at least 2.4 (I think they introduced it into 2.5) | 09:29 |
| StevenK | seb128: No problem :-) | 09:29 |
| pwnguin | what's the right way to request a sync (new package eally) of thinkfinger from debian into ubuntu? | 09:29 |
| pwnguin | note: thinkfinger is in experimental | 09:29 |
| pitti | pwnguin: file a sync request bug with requestsync | 09:30 |
| seb128 | pwnguin: open a sync bug on launchpad | 09:30 |
| pwnguin | ok | 09:30 |
| pitti | pwnguin: I second this, I'm using the packages on my notebook | 09:30 |
| pwnguin | heh | 09:30 |
| pwnguin | excellent | 09:30 |
| pwnguin | testers | 09:30 |
| pwnguin | ive been putting it in my ppa | 09:30 |
| pwnguin | and patching a few things | 09:30 |
| pwnguin | ie i fixed gksudo | 09:30 |
| dholbach | http://wiki.ubuntu.com/SyncRequestProcess | 09:31 |
| pwnguin | i assume new packages of uncertain quality should land go to universe? | 09:31 |
| dholbach | all packages (with suitable licenses) 'start' in universe | 09:33 |
| dholbach | it needs to fulfill https://wiki.ubuntu.com/UbuntuMainInclusionRequirements to get into main | 09:33 |
| pwnguin | im pretty sure it's fine | 09:33 |
| pwnguin | im not sure why its in experimental in the first place, perhaps because integration isn't there yet | 09:34 |
| dholbach | it needs to be discussed and everything to get into the default set of packages | 09:34 |
| pwnguin | ok | 09:34 |
| mvo | pitti: hrm, thanks. | 09:38 |
| mvo | pitti: where did you see it? do you run 2.4 by default? | 09:40 |
| Fujitsu | mvo: It's on all systems where python2.4 is installed. | 09:40 |
| Keybuk | mvo: #164947 | 09:41 |
| pitti | mvo: just apt-get dist-upgrade | 09:41 |
| pitti | 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 |
| pitti | Python-Version: 2.4, 2.5 | 09:42 |
| pitti | that should just be 'current' in the source package, right? | 09:42 |
| mvo | oh, yeah. fixing it now | 09:42 |
| pwnguin | pitti: bug #165138 | 09:42 |
| ubotu | Launchpad bug 165138 in ubuntu "Sync Thinkfinger from Debian experimental" [Undecided,New] https://launchpad.net/bugs/165138 | 09:42 |
| mjg59 | Better to skip thinkfinger, I suspect | 09:43 |
| mjg59 | fprint is looking like a much better option | 09:43 |
| pitti | pwnguin: I acked the sync request | 09:43 |
| pwnguin | is it working? | 09:43 |
| sladen | thinkfinger v0.3 changelog: "avoid fingerprint device from heating up "... | 09:43 |
| mjg59 | fprint? Does for me, though I'm using an aes2510 rather than a upek | 09:44 |
| Fujitsu | ... sounds special. | 09:44 |
| pwnguin | it's worked fine for me at least | 09:44 |
| mjg59 | If we're doing any sort of distribution-wide integration, fprint is certainly the way to go | 09:44 |
| mjg59 | It has the significant advantage of not being hardware specific | 09:45 |
| pwnguin | there's people currently talking about moving towards fprint | 09:45 |
| sladen | integration is more of a policy issue than a technical one | 09:45 |
| pwnguin | but thinkfinger is saying one more bugfix release then a lull while work on a new system is done | 09:46 |
| sladen | "should we automatically enable this binary, black box, hash-providing proprietary hardware as a core authenication mechanism" | 09:46 |
| mjg59 | There's no benefit in us doing anything more with thinkfinger | 09:46 |
| mjg59 | It can't be integrated nicely | 09:46 |
| pwnguin | sladen: which country do you live in? | 09:46 |
| pitti | mjg59: does fprint have a sensible GUI/integration for registering fingerprints? | 09:47 |
| sladen | 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 |
| mjg59 | pitti: Yes | 09:47 |
| sladen | pwnguin: I live in HEL! | 09:47 |
| mjg59 | pitti: Well, I'd quibble over sensible. But it exists and works. | 09:47 |
| pitti | mjg59: ah, great; that's what I was missing in tf | 09:47 |
| mjg59 | pitti: Needs some UI love | 09:47 |
| pitti | better than TF, which needs an UI in the first place :) | 09:47 |
| mjg59 | Needs packaging, but it's pretty trivial | 09:48 |
| pitti | mjg59: fprint is not yet in Debian AFAICS? | 09:48 |
| mjg59 | Only issue is the lack of ABI guarantees on the library | 09:48 |
| mjg59 | So it'd need some shlibdeps magic | 09:48 |
| pwnguin | pitti: if it is, FingerForce isn't talking about it | 09:48 |
| mjg59 | 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 |
| mjg59 | The scanner is just a scanner, there's no intelligence in it | 09:49 |
| pwnguin | ironically my hardware controls it in hardware | 09:49 |
| mjg59 | Yes, so it wouldn't be a problem for you | 09:49 |
| pwnguin | apparently its easier to export control hardware than source code / software | 09:49 |
| mdz | Burgundavia: they are "normal people" oriented, who get confused by having the same milestone called a different thing in each release | 09:50 |
| pwnguin | note: its not clear how US export laws intersect with fingerprinting | 09:50 |
| pitti | pwnguin: well, it's still software, I guess, in a µC? | 09:50 |
| pwnguin | pitti: something like that. but naturally heavily tied to the hardware it runs in | 09:51 |
| mjg59 | That's fine, we don't export anything from the US | 09:51 |
| pwnguin | "we" dont | 09:51 |
| pwnguin | but i happen to live there =( | 09:51 |
| mjg59 | 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 |
| pwnguin | well, these things are statistical in nature | 09:54 |
| pwnguin | they're going to have false positives and negatives | 09:54 |
| pwnguin | there was even an article on c't about fooling these things | 09:56 |
| pwnguin | mjg59: you might wanna deliver some of your sense to the people tinkering on this bioAPI blueprint in lp/wiki | 10:03 |
| mjg59 | Yeah, bioAPI may not be the way forward | 10:05 |
| Chipzz | mjg59: giving fprint the middle finger, uh? ;) | 10:05 |
| mjg59 | I'm not really going to have time to do anything until the new year | 10:05 |
| mjg59 | One more chapter and some conclusions to write | 10:06 |
| === cprov-away is now known as cprov | ||
| === pedro is now known as pedro_ | ||
| seb128 | 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:28 |
| StevenK | I didn't, actually | 11:29 |
| seb128 | ok | 11:29 |
| seb128 | StevenK: you might want to use submittodebian which does that for you | 11:30 |
| StevenK | Oh, in u-d-t? | 11:30 |
| soren | yes | 11:31 |
| soren | It does quite a bit more than that, too. | 11:31 |
| Hobbsee | seb128: but that requires actually reading ubuntu-devel.... | 11:33 |
| seb128 | Hobbsee: what? knowing about usertagging? | 11:35 |
| Hobbsee | seb128: about how to use it, yes | 11:36 |
| seb128 | or having somebody on IRC showing you the wikipage ;-) | 11:38 |
| === dholbach_ is now known as dholbach | ||
| Mez | pitti, around? | 11:58 |
| pitti | Mez: yes | 11:59 |
| Mez | pitti, may I /msg you (security issue) | 11:59 |
| pitti | Mez: mailing security@ubuntu.com is better with those issues, but sure, you can always /msg me :) | 11:59 |
| ciphergoth | 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 |
| persia | ciphergoth: Please. This achieves two goals: | 12:15 |
| persia | 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 |
| ciphergoth | ok | 12:16 |
| persia | 2) It means that the software can be included in other distributions more easily, making all Linux environments better. | 12:19 |
| persia | 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 |
| ciphergoth | that's slightly tricky in general - eg defaulting to "sensible-editor" rather than to "vi" or whatever | 12:19 |
| ciphergoth | not that that issue affects us | 12:20 |
| persia | 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 |
| cjwatson | 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:21 |
| ciphergoth | 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 |
| persia | cjwatson: You'd prefer that upstreams who also maintain software keep distribution patches in diff.gz? | 12:22 |
| cjwatson | persia: sometimes it's the right answer | 12:22 |
| * persia notes that this isn't a debian/patches vs. diff.gz discussion | 12:22 | |
| cjwatson | oh, I see. but nevertheless :-) | 12:22 |
| cjwatson | I have a couple of small patches to man-db in the packaging, despite also being upstream | 12:22 |
| persia | cjwatson: I suppose. I still think it's better for other distributions to adopt the patches in most cases. | 12:22 |
| cjwatson | and I don't think it's unreasonable | 12:22 |
| cjwatson | it depends whether the patches are distro customisation or bug-fixes | 12:23 |
| cjwatson | in the latter case, I agree with you | 12:23 |
| persia | True. In the former case, I agree with you. | 12:23 |
| cjwatson | excellent :-) | 12:23 |
| cjwatson | the man-db case is a patch to the upstream default configuration file | 12:24 |
| ciphergoth | 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 |
| persia | 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 |
| cjwatson | ciphergoth: right, that's how the debian/patches/ scheme works | 12:24 |
| cjwatson | persia: the latter is definitely evil | 12:24 |
| cjwatson | as is patching debian/ itself in debian/patches/ | 12:24 |
| persia | ciphergoth: That's about it. Some people prefer that, but many don't. Best to choose a scheme that works best for you. | 12:24 |
| ciphergoth | .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 |
| persia | cjwatson: Yes. That's really unfortunate as well. | 12:25 |
| ciphergoth | a script has the freedom to move things around, for example, or to unpack any kind of archive | 12:25 |
| persia | ciphergoth: Maybe, but I prefer to get content and use trusted tools to manipulate it, rather than calling random scripts. | 12:25 |
| cjwatson | 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:25 |
| cjwatson | ciphergoth: while people like debian/patches/ for other reasons such as separating out one change from another | 12:26 |
| cjwatson | there are various very very slow-moving projects to try to unify these | 12:26 |
| ciphergoth | well, there's no point raking over decade-old design decisions that can't be changed now anyway | 12:26 |
| cjwatson | oh, they can | 12:26 |
| persia | Which makes it really easy to track down issues in the code (e.g. hunting backtraces) | 12:26 |
| cjwatson | it just takes ages | 12:26 |
| cjwatson | and needs lots of buy-in | 12:26 |
| Mithrandir | ciphergoth: if you're interested in how they change, look for "dpkg wig and pen" on your favourite search engine. | 12:27 |
| ciphergoth | The Right Thing would have been for the .tar.gz to have been *exactly* what upstream ship, always | 12:27 |
| persia | 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:27 |
| Mithrandir | 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:28 | |
| Mithrandir | 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 |
| persia | Mithrandir: Excellent :) | 12:29 |
| persia | Mithrandir: On a completely unrelated note, what do you think about sticking uqm-music and uqm-voices in multiverse? | 12:30 |
| ciphergoth | 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 |
| Mithrandir | persia: they're quite large, iirc? | 12:30 |
| persia | Mithrandir: Incredibly huge | 12:30 |
| Mithrandir | persia: I don't think we have a policy on it per se.. mail -archive and ask? | 12:31 |
| persia | (the alternative is pulling them from raw.no) | 12:31 |
| ciphergoth | 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 |
| Mithrandir | persia: I should get people to update that url to err.no instead.. | 12:31 |
| persia | Mithrandir: OK. I just figured you might have an opinion based on their current hosting. | 12:31 |
| Mithrandir | persia: I haven't had complaints about excessive bandwidth usage, but if distros want to take them, that's fine with me. | 12:32 |
| broonie | ciphergoth: No, it should be the other way round. | 12:32 |
| persia | 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 |
| cjwatson | ciphergoth: you're certainly welcome to back that up, but that hadn't been my observation either | 12:33 |
| ciphergoth | persia, cjwatson: that perception could be totally wrong. You always notice the exceptions more after all. | 12:33 |
| cjwatson | (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 |
| cjwatson | are basically the cases | 12:34 |
| ciphergoth | OK | 12:34 |
| broonie | There are quite a few core packages affected, which makes it more visible too. | 12:34 |
| ciphergoth | Anyway, putting all that aside | 12:35 |
| ciphergoth | Those of you who maintain both upstream and the Debian/Ubuntu package - what do you do in your source control? | 12:35 |
| persia | ciphergoth: You might want to ask that question in #ubuntu-motu : I believe there are more people who meet that criterion there. | 12:39 |
| seb128 | 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:43 |
| soren | Will the alpha release on Thursday have 2.4.22 kernels? | 12:52 |
| seb128 | soren: 2.4.n? not likely no | 12:53 |
| soren | *headdesk* | 12:53 |
| seb128 | ;-) | 12:53 |
| soren | It didn't look right to me either, but I couldn't spot the error :) | 12:53 |
| soren | Will the alpha release on Thursday have 2.6.22 kernels? | 12:53 |
| seb128 | dunno about the kernel team plans | 12:53 |
| seb128 | but that starts being late to get a new version now | 12:53 |
| soren | It sure does. | 12:53 |
| persia | Hard to get everything built and at least install tested by Thursday, no? | 12:54 |
| soren | I've got a few bugs I'd like to report against a new kernel, too, but I just have to wait, I guess. | 12:54 |
| === ogra1 is now known as ogra | ||
| === ScottK2 is now known as ScottK | ||
| lamont | Hobbsee: heh | 13:22 |
| === cprov is now known as cprov-lunch | ||
| lamont | seb128: you aroudn? | 13:22 |
| seb128 | lamont: yes | 13:23 |
| === ember_ is now known as ember | ||
| * lamont -> work | 13:42 | |
| calc | pitti: responded to 153132 about the issues with the SRU | 13:44 |
| pitti | calc: ah, thanks | 13:45 |
| pitti | calc: good morning | 13:45 |
| calc | pitti: good morning :) | 13:46 |
| calc | pitti: i will be leaving here in a few minutes to take my wife to the doctor | 13:46 |
| pitti | calc: hm, I thought I did check for the Conflict, and it's not there | 13:52 |
| pitti | calc: besides, it shuold also have a replaces:, so that apt gets less confused | 13:52 |
| calc | pitti: OOo is setup to always conflict with all old version of the packages that are installed apparently | 13:54 |
| calc | pitti: it has a << source-version conflict | 13:54 |
| calc | which was why it didn't show up in the debdiff | 13:54 |
| pitti | ah, seems I forgot about this | 13:55 |
| pitti | erm, overlooked | 13:55 |
| pitti | calc: ok, then let me unreject the oo.o upload; sorry | 13:56 |
| calc | pitti: no problem.. i should have made it clear that it wasn't needed since in 99.9% cases it really is :) | 13:57 |
| calc | OOo apparently moves files around often enough that someone added those conflicts long ago | 13:57 |
| gaspa | pitti: bug #152952. Should I mark it as Confirmed? | 13:58 |
| ubotu | Launchpad bug 152952 in usplash "input command with timeout parameter" [Undecided,Incomplete] https://launchpad.net/bugs/152952 | 13:58 |
| * calc bbl | 13:58 | |
| Bubulle | hello, I'd lie to discuss ubuntu-devel mailing list last List-ID buggy changes, anyone? | 14:01 |
| pitti | gaspa: yes, please do | 14:01 |
| Bubulle | lie | 14:01 |
| Bubulle | k | 14:01 |
| Bubulle | Friday, List-Id: Ubuntu Developer Discussion <ubuntu-devel.lists.ubuntu.com> changed to List-Id: "Ubuntu Development \(developers\)" <ubuntu-devel.lists.ubuntu.com> | 14:02 |
| cjwatson | calc: for future reference, could you please include more detail when closing a bug in a changelog than just the patch name? (in the bits that close 132583 and 131526) | 14:02 |
| cjwatson | Bubulle: what's wrong with that? | 14:02 |
| gaspa | pitti: ok. ;) | 14:02 |
| cjwatson | Bubulle: you should only be using the bits within <> for filtering anyway | 14:02 |
| Bubulle | No discussion was shown about this change. Backslashes before parenthesis enclosing developers look like some | 14:03 |
| Bubulle | buggy string. Anyone relying on mail sorting routing according to the List-Id is | 14:03 |
| Bubulle | left in the wild guessing why it stopped working alltogather without | 14:03 |
| Bubulle | warnings. | 14:03 |
| cjwatson | I'm afraid anyone relying on the comment part of the list-id for filtering has buggy filters | 14:03 |
| cjwatson | mailman is being excessively enthusiastic by backslash-escaping the parentheses there, I think, but it's not broken as such | 14:04 |
| Bubulle | cjwatson, List-Id is what identify the List itself, I rely on this to put incoming list message in dedicated Imap folters uppon delivery with mailfilter | 14:04 |
| Ng | ubuntu-devel.lists.ubuntu.com is the string to match | 14:04 |
| cjwatson | Bubulle: the part within <> identifies the list | 14:04 |
| cjwatson | Bubulle: the part outside <> is a comment that may change at any time | 14:05 |
| Bubulle | oh, oki | 14:05 |
| Bubulle | I have it liek this: # Ubuntu Developer Discussion <ubuntu-devel@lists.ubuntu.com> | 14:06 |
| Bubulle | if (/^List-Id: Ubuntu Developer Discussion/) | 14:06 |
| Bubulle | to 'Maildir/.Listes.Ubuntu.Devel' | 14:06 |
| cjwatson | I'm sorry the change broke your filters, but take it as an encouragement to fix them :-) | 14:07 |
| cjwatson | that's totally wrong | 14:07 |
| cjwatson | /^List-Id:.*<ubuntu-devel\.lists\.ubuntu\.com>/ | 14:07 |
| cjwatson | /^List-Id:.*<ubuntu-devel\.lists\.ubuntu\.com>/ | 14:07 |
| ogra | seb128, do you still have a plan for ephiphany with webkit ? | 14:07 |
| cjwatson | you should absolutely not match on the human-readable portion | 14:07 |
| Bubulle | thanks cjwatson | 14:07 |
| seb128 | ogra: I'm going to mail ubuntu-devel about it today, I've the merge from debian locally available | 14:07 |
| ogra | cool, i'd love to try it on the classmate | 14:07 |
| seb128 | ogra: option are: move epiphany to universe, don't build webkit variant, get webkit promoted | 14:08 |
| seb128 | ogra: I'm happy with none of those | 14:08 |
| * ogra would prefer the latter | 14:08 | |
| ogra | what about konqueror ? | 14:08 |
| seb128 | that's a shame that a main package can't Build-Depends on an universe one | 14:08 |
| ogra | i'd assume it needs it in its latest release | 14:08 |
| seb128 | ogra: did they switch from khtml to webkit? | 14:09 |
| ogra | no idea, but that sounds like it would be the most sane thing | 14:09 |
| seb128 | is webkit better than khtml? | 14:09 |
| ogra | Riddell, ?? ^^^ | 14:09 |
| seb128 | I don't know enough about those to have an opinion | 14:09 |
| ogra | no idea either :) i heard its extremely faster but lack the software to prove :) | 14:10 |
| Keybuk | *sigh* | 14:33 |
| Keybuk | Et tu, trackerd? | 14:33 |
| Riddell | seb128: webkitkde is waiting for you New approval :) | 14:36 |
| elmo | TheMuso: ping | 14:36 |
| seb128 | Riddell: is that going to be used in kubuntu? like MIRed this cycle? | 14:37 |
| Riddell | seb128: it'll stay in universe this cycle, in main next I'd expect | 14:37 |
| seb128 | hum, k; doesn't solve the question for webkit to main or universe this cycle | 14:37 |
| \sh | keescook, jdstrand_ : bug #163833 ready for review | 14:38 |
| ubotu | Launchpad bug 163833 in tikiwiki "[tikiwiki] Multiple vulnerabilities possibly resulting in the remote execution of arbitrary code" [Undecided,In progress] https://launchpad.net/bugs/163833 | 14:38 |
| seb128 | cjwatson: can gobuntu use universe packages or not? | 14:39 |
| cjwatson | seb128: in the same way that Ubuntu can | 14:40 |
| seb128 | ok, which means epiphany needs to stay in main then? | 14:40 |
| cjwatson | if you mean for epiphany, it would be possible to switch to building Gobuntu from universe, although not preferable | 14:40 |
| seb128 | ok | 14:41 |
| seb128 | the easier way is to get webkit promoted | 14:41 |
| seb128 | not sure pitti will like that though | 14:41 |
| cjwatson | the option you missed out of your summary above would be a separate copy of the epiphany source package that builds the webkit variant | 14:41 |
| cjwatson | I imagine you aren't terribly fond of that either :) | 14:42 |
| pitti | well, it's not about me personally | 14:42 |
| cjwatson | but it would be a possibility | 14:42 |
| pitti | I'm just the gatekeeper of crack, the maintenance is a burden for all of us | 14:42 |
| pitti | if we truly need webkit, so be it, but I'm saying is that we should not pile up numbers and numbers of HTML rendering libraries without ever dropping any | 14:42 |
| seb128 | cjwatson: I was thinking about that but source code duplication is ugly and I don't want to update the package twice if possible | 14:43 |
| seb128 | pitti: we don't need it, I wish we could build main packages with universe build-deps and move the corresponding binaries to universe | 14:43 |
| pitti | seb128: the discussion is not (IMHO) about how to build gobuntu's epiphany with webkit | 14:43 |
| seb128 | it would make possible to move things like webkit or beagle to universe | 14:44 |
| pitti | if gobuntu needs webkit, we promote it and avoid duplication of source packags, etc. | 14:44 |
| seb128 | pitti: no, I was considering moving epiphany-browser to universe | 14:44 |
| pitti | the question is really whether gobuntu needs webkit in the first place | 14:44 |
| seb128 | pitti: I've no idea if they want to use webkit or xulrunner | 14:44 |
| pitti | ah | 14:44 |
| seb128 | epiphany-browser has a webkit variant now | 14:45 |
| pitti | but what does that actually buy us? | 14:45 |
| seb128 | so either we promote webkit or demote epiphany-browser | 14:45 |
| seb128 | nothing | 14:45 |
| pitti | compared to gecko'ed epiphany? | 14:45 |
| seb128 | out of the making users which are asking for it happy | 14:45 |
| pitti | seb128: what are they asking for actually? some features that webkit provides? | 14:45 |
| cjwatson | we can't necessarily keep everyone happy, of course | 14:45 |
| Mithrandir | pitti: "speed" | 14:46 |
| Mithrandir | (no, not the sister drug of crack) | 14:46 |
| seb128 | pitti: it's lighter than gecko | 14:46 |
| seb128 | and faster | 14:46 |
| seb128 | the webkit backend is far to be as functional than the gecko one for now though | 14:46 |
| pitti | so if it dominates gecko in all regards (compatibility with plugins, speed, etc.), then wouldn't it make more sense to use it for all derivatives? | 14:47 |
| pitti | and if it lacks some gecko features, we should discuss which one we prefer | 14:47 |
| seb128 | it's not ready yet to replace the gecko one | 14:47 |
| seb128 | will not be for hardy | 14:47 |
| pitti | alright; seems it's not appropriate (yet?) for main then? | 14:48 |
| seb128 | things like plugins, etc are not working for example | 14:48 |
| seb128 | well, webkit might be | 14:48 |
| seb128 | epiphany-webkit is not | 14:48 |
| seb128 | I would put the binary package to universe anyway | 14:48 |
| pitti | ah, so webkit itself supports the plugin, but the epy embedding doesn't | 14:48 |
| seb128 | not sure, I didn't look into webkit details | 14:49 |
| pitti | so if someone from the community wants to provide that, he would take the epiphanyu source, configure it for webkit, and put it into a PPA, right? | 14:49 |
| seb128 | right | 14:50 |
| pitti | that would avoid imposing the maintenance work on the distro team | 14:50 |
| jcastro | there is a epi-webkit ppa already, heh | 14:50 |
| pitti | DONE! :) | 14:50 |
| seb128 | debian has both variants built already | 14:50 |
| seb128 | and installable together | 14:50 |
| \sh | pitti, for removal reports, I'll subscribe archive admins to the report? | 14:57 |
| pitti | \sh: right | 14:57 |
| \sh | pitti, thx | 14:57 |
| persia | \sh: You might want to subscribe the sponsors, as it usually is good to get confirmation from a member of ~ubuntu-dev | 14:58 |
| \sh | persia, well, I think a debian decision should be enough , or? | 14:58 |
| \sh | persia, but uus subscribed too :) | 14:59 |
| persia | \sh: Usually, but not always. Plus, you're likely special :) | 14:59 |
| \sh | persia, no..I'm not special :) | 14:59 |
| \sh | persia, but it's sad, after I fixed the vulnerabilities | 15:00 |
| persia | \sh: Well, if you want to keep it in... (but the fixes are still good for dapper, edgy, feisty, and gutsy) | 15:01 |
| \sh | persia, only feisty and gutsy...and yes, they should go in our security-queue | 15:02 |
| jdong | pitti: is there something required on bug 158400 before security team can prepare an update? It's a fairly exploitable pidgin DoS that's been reported and unpatched for ~1month now | 15:03 |
| ubotu | Launchpad bug 158400 in pidgin "[CVE-2007-4999] pidgin HTML Processing Denial of Service" [Undecided,Confirmed] https://launchpad.net/bugs/158400 | 15:03 |
| \sh | jdong, because there is no patch attached? | 15:05 |
| pitti | jdong: I can only guess, but recently they worked on some high-impact bugs; this one doesn't seem to be overly critical (they'll get to it, of course) | 15:05 |
| \sh | jdong, provide a debdiff with the patch for all versions downto dappe | 15:05 |
| jdong | pitti: that sounds quite reasonable :) | 15:06 |
| jdong | and yeah, if I have some time I'll definitely contribute the patch/debdiff | 15:06 |
| pitti | well, yeah, I still remember digging out the gaim patches from their CVS; quite painful :) | 15:06 |
| pitti | but doable | 15:06 |
| pitti | keescook, jdstrand_: ^ just to confirm that you saw above issue? | 15:06 |
| \sh | pitti, why don't they add a rev diff to their reports...I wonder...wireshark is quite good at it in the moment | 15:08 |
| pitti | one of these upstreams which say "upgrade to the latest release" | 15:09 |
| jdong | pitti: heh I know the type of VCS quite too well ;-), I just wanted to make sure it wasn't forgotten and was on the to-be-fixed queue :) | 15:09 |
| pitti | jdong: yeah, should; it got a CVE, so it will appear in the security team's work queue | 15:09 |
| jdong | fantastic, thanks :) | 15:10 |
| === Shely is now known as iExaile | ||
| bddebian | Heya | 15:13 |
| \sh | pitti, hmmm...this was easy ,-) | 15:15 |
| \sh | http://developer.pidgin.im/viewmtn/revision/diff/0810c68ce97a8213a5edbf5ffe7c1418915d3dfe/with/aff089bc73ecc6fe8ebbeac670db8be13511fcf4 there is the diff for the CVE... | 15:16 |
| \sh | well, I'll prepare some diffs for it | 15:16 |
| jdong | \sh: whoo | 15:19 |
| === ryu2 is now known as ryu | ||
| jdstrand_ | pitti, jdong: bug #158400 is on our radar, however it is a lower priority than some other security issues we are working on atm. We will get to it, but as \sh mentioned, if debdiffs are provided, we will get the update out sooner. | 15:20 |
| ubotu | Launchpad bug 158400 in pidgin "[CVE-2007-4999] pidgin HTML Processing Denial of Service" [Undecided,In progress] https://launchpad.net/bugs/158400 | 15:20 |
| pitti | jdstrand_: ah, what I figured; thanks! | 15:20 |
| \sh | jdstrand_, you'll get some :) | 15:20 |
| jdong | jdstrand_: thanks for all your hard work :) | 15:20 |
| \sh | jdstrand_, there are more ,-) | 15:20 |
| \sh | my list of assigned bugs is increasing from day to day.../me needs some holidays | 15:21 |
| jdstrand_ | jdong: thank you, and thanks for making sure ubuntu is up on its updates. :) | 15:22 |
| jdstrand_ | \sh: yes, thanks for your hard work. tikiwiki bug is noted as well | 15:23 |
| === cprov-lunch is now known as cprov | ||
| \sh | jdstrand_, there is still this openldap stuff, the patches for those two cves are in a different bugreport... | 15:30 |
| pitti | seb128: I guess rebuilding devscripts against current libs will unbreak it? shall I just do it? | 15:32 |
| jdstrand_ | \sh: ok | 15:32 |
| seb128 | pitti: devscripts? fix what? | 15:32 |
| seb128 | pitti: ELACKCONTEXT | 15:32 |
| pitti | well, 'it' | 15:32 |
| pitti | seb128: I mean 'devhelp', of course | 15:32 |
| pitti | devhelp: error while loading shared libraries: libgtkembedmoz.so: cannot open shared object file: No such file or directory | 15:32 |
| seb128 | ah | 15:32 |
| seb128 | I've that on my TODO, not sure what is wrong there | 15:33 |
| seb128 | why a rebuild would fix it? | 15:33 |
| pitti | I don't know, that was my q | 15:33 |
| seb128 | not likely to be fixed with a rebuild no, but I'll look to it today | 15:33 |
| seb128 | pitti: you are welcome to have a look if you want though ;-) | 15:33 |
| seb128 | pitti: debian does that, " chrpath -d `pwd`/debian/libdevhelp-1-0/usr/lib/libdevhelp-1.so.0.0.0" | 15:34 |
| seb128 | pitti: dunno if that can create the issue, my guess is "try without this line and see if it works" | 15:35 |
| \sh | jdong, pidgin was not in feisty, right? is the bug also reproducable in gaim on feisty downto dapper? | 15:35 |
| seb128 | they use xulrunner and not firefox | 15:35 |
| jdong | \sh: pidgin was not in feisty, correct. I'm unsure if the bug also affected gaim but I'd have a hunch that is a yes. | 15:35 |
| pitti | $ chrpath -l /usr/lib/libdevhelp-1.so.0.0.0 | 15:36 |
| pitti | /usr/lib/libdevhelp-1.so.0.0.0: no rpath or runpath tag found. | 15:36 |
| pitti | seb128: ^ | 15:36 |
| pitti | ah, so the trick is to add it | 15:36 |
| pitti | seb128: trying | 15:36 |
| seb128 | pitti: well, the line comes from the debian/rules, maybe try a build with it commented? | 15:36 |
| pitti | seb128: right, my thinking was too slow; in progress... | 15:37 |
| \sh | jdong, can you try to reproduce the crash with gaim please on feisty somehow? so we are sure, that the bug is not there, or it's reproducable, and we somehow produce a different fix for it? | 15:37 |
| jdong | hmm I don't have a feisty handy right now :-/ | 15:37 |
| * norsetto passes a feisty to jdong | 15:38 | |
| jdong | I will have one tomorrow in lab... | 15:38 |
| pitti | seb128: that's it: it works with "LD_LIBRARY_PATH=/usr/lib/firefox/ devhelp" | 15:38 |
| jdong | is the POC easy to execute? | 15:38 |
| seb128 | pitti: good ;-) | 15:39 |
| seb128 | pitti: thanks for looking to it | 15:39 |
| pitti | seb128: ok, I'll upload the fix then, unless you want to | 15:40 |
| \sh | jdong, hmm...I have to go through some bugtraq mails... | 15:40 |
| seb128 | pitti: go for it, thanks | 15:40 |
| \sh | jdong, if there is a POC | 15:40 |
| \sh | jdong, oh..much better | 15:41 |
| \sh | jdong, on http://developer.pidgin.im/ticket/3436 there is a description how to reproduce it... | 15:41 |
| jdong | \sh: ok, nice, I'll see if I can reproduce that in Feisty | 15:42 |
| \sh | jdong, enable html logging, and try something like <a bla> because it expects (in libpurple) a "href" tag after the opening <a ... if it's not there the string is NULL | 15:42 |
| jdong | \sh: yeah, that's what I was thinking | 15:42 |
| pitti | seb128: bah, it coredumps now | 15:43 |
| seb128 | :( | 15:43 |
| \sh | jdong, the fun part behind is, the NULL gestring is freed when the next <a href is coming ,-) | 15:43 |
| \sh | jdong, applied debdiff to your pidgin bug for gutsy | 16:12 |
| \sh | ok..and going home...cu later | 16:13 |
| === \sh is now known as \sh_away | ||
| nxvl_work | i need some give-backs, does someone can help me? | 16:48 |
| === cassidy_ is now known as cassidy | ||
| Mithrandir | nxvl_work: please just ask what you want given back. | 16:50 |
| === cassidy_ is now known as cassidy | ||
| nxvl_work | i need advi (on i386, amd64, sparc and powerpc) and boo on i386 | 16:51 |
| Mithrandir | nxvl_work: why do you think the boo build is going to work this time around? | 16:54 |
| nxvl_work | cause i donwload it, build it using pbuider and i have a .deb of boo | 16:55 |
| Mithrandir | let's see if it builds now, then | 16:56 |
| Mithrandir | (aka, all given back) | 16:56 |
| Keybuk | so, I have an svg presentation | 17:07 |
| Keybuk | how do I view that? | 17:07 |
| Chipzz | Keybuk: firefox? | 17:09 |
| Keybuk | Chipzz: doesn't seem to like svg at all | 17:09 |
| Keybuk | offers me to save it | 17:09 |
| Chipzz | Keybuk: hrrrm I recently saw some demo's of svg in firefox; maybe you need to wrap it in some xhtml though | 17:10 |
| jcastro | eog handles svg | 17:11 |
| Chipzz | jcastro: but probably only static svgs | 17:11 |
| === asac_ is now known as asac | ||
| nxvl_work | Mithrandir: car also need a give-back | 17:17 |
| seb128 | Riddell: kdebindings wants to bring gtk1.2 to main, is that a mistake? | 17:21 |
| seb128 | Riddell: gtk1.2 should stay to universe ;-) | 17:22 |
| Mithrandir | nxvl_work: given-back | 17:22 |
| nxvl_work | Mithrandir: thnx | 17:23 |
| * nxvl_work *HUGS* Mithrandir | 17:23 | |
| Riddell | seb128: sorry that's something I've been meaning to fix, it's a mistake | 17:23 |
| seb128 | Riddell: ok, no problem, I was just looking at the component mismatch list and was wondering about this one | 17:24 |
| === cjwatson_ is now known as cjwatson | ||
| pitti | BenC: is there something instead of 'modinfo' which I can use in teh installer busybox? such as poking stuff out of /sys? | 17:45 |
| BenC | pitti: not really, modinfo gives me the output of stuff from the actual .ko file, like it's deps and such | 17:46 |
| === mthaddon changed the topic of #ubuntu-devel to: LP going down for maintenance 18:00 UTC - 18:05 UTC - Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
| pitti | BenC: hm, but I cannot install the system with the current driver to get working modinfo; chicken-egg FTW | 17:47 |
| BenC | pitti: modprobe --show-depends might work as well | 17:47 |
| BenC | pitti: can't even get to a livecd session? | 17:47 |
| BenC | oh, only alternate/server for dapper.2, forgot | 17:47 |
| pitti | BenC: right; --show-depends seems to work, though (if you only need the dependencies) | 17:48 |
| pitti | BenC: will it help at all if I tar up /sys? | 17:48 |
| BenC | pitti: not likely | 17:48 |
| pitti | BenC: (BTW, it happens in standard vmware, so maybe it's easier if you just reproduce it there) | 17:48 |
| BenC | pitti: my main concern is that all the right modules might not be in place | 17:49 |
| BenC | pitti: I could check that later today | 17:49 |
| pitti | BenC: ok, I'll attach the rest of the outputs in the meantime | 17:49 |
| pitti | BenC: thanks | 17:49 |
| pitti | BenC: done | 17:54 |
| BenC | pitti: thanks | 17:55 |
| === mthaddon changed the topic of #ubuntu-devel to: Archive: OPEN | Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
| === pedro is now known as pedro_ | ||
| === LaserRock is now known as LaserJock | ||
| mathiaz | I'm seeing some changelog entries about removing stop script symlinks from rc0 and rc6 dating back to edgy. Are they still needed for hardy ? | 19:29 |
| Mithrandir | mathiaz: yes. | 19:42 |
| Mithrandir | mathiaz: they make shutdown faster. | 19:42 |
| slangasek | without also making it unclean, I guess? | 19:42 |
| mathiaz | Mithrandir: is this a due to the upstart transition in edgy ? | 19:43 |
| Mithrandir | mathiaz: no | 19:43 |
| mathiaz | Mithrandir: ok. Thanks. | 19:43 |
| Mithrandir | slangasek: yes, so we don't remove the stop script for, say, databases, but we do for, say bind or ifupdown | 19:44 |
| Nafallo | Mithrandir: just say; where it makes sense :-) | 19:57 |
| === pedro__ is now known as pedro_ | ||
| calc | ugh | 20:23 |
| calc | the new OOo build failed on lpia | 20:23 |
| calc | apparently due to missing lib | 20:23 |
| === nixternal_ is now known as nixternal | ||
| calc | now i get to download the packages for every arch and unpack and see which archs it should exist for | 20:24 |
| jdong | how powerful are lpia's? I always thought they were like extremely lightweight chips | 20:28 |
| slangasek | they support the full x86 instruction set, the architecture difference is just an optimization change for power consumption benefits | 20:29 |
| slangasek | OOo isn't altogether out of the question, AFAIK | 20:29 |
| Mithrandir | jdong: my development system is a measly 1GHz 1GB memory system. | 20:30 |
| Mithrandir | newer systems are rumoured to be slightly faster, though we're targetting less memory, at least for the low end of the market. | 20:30 |
| calc | ugh i should have done -mv foo instead of mv | 20:30 |
| jdong | slangasek: interesting. So is lpia x86 binary compatible or not? | 20:33 |
| Mithrandir | jdong: it's binary compatible, yes. | 20:33 |
| calc | iirc lpia binaries could run on x86 but not necessarily the other way around | 20:33 |
| jdong | interesting | 20:34 |
| Mithrandir | calc: that's wrong. | 20:34 |
| calc | or is it just in-order scheduling changes (istr hearing something about that) | 20:34 |
| calc | Mithrandir: oh ok | 20:34 |
| Mithrandir | the CPU is slightly different built, but it's completely compatible. | 20:34 |
| jdong | are there any production systems with lpia chips? or is it still an in-development architecture? | 20:35 |
| mjg59 | You can't currently buy any lpia hardware | 20:35 |
| Mithrandir | jdong: you might want to look around for "menlow", but it's not on the market yet. | 20:36 |
| calc | grr sun encodes the architecture via a letter in the library soname | 20:42 |
| * calc kicks them | 20:42 | |
| calc | after unpacking the packages from all the architectures the filenames are different on each arch by one letter in the filename | 20:43 |
| TheMuso | Thats crazy. | 20:43 |
| calc | eg libdba680lx.so on amd64 and libdba680li.so on i386 | 20:44 |
| calc | and so on | 20:44 |
| TheMuso | So, probably something like libdba680lp.so for PowerPC. :p | 20:44 |
| calc | yea | 20:44 |
| calc | and s.so for sparc | 20:44 |
| TheMuso | Yep. | 20:44 |
| calc | i'm guessing it is probably i.so for lpia which was where it first failed | 20:45 |
| * calc bbiab | 20:46 | |
| toilet_paper | HELLO. I AM LOOKING FOR AN ASS TO WIPE. CAN SOMEONE HELP ME? | 21:16 |
| IntuitiveNipple | Andrex 1 - Others 0 | 21:19 |
| pochu | Mithrandir: same on -desktop... | 21:22 |
| Mithrandir | I don't have @ on -desktop ; sorry. | 21:22 |
| pochu | Amaranth just did it. No worries btw. | 21:23 |
| === seb128_ is now known as seb128 | ||
| === cprov is now known as cprov-out | ||
| coastGNU | oem-config, are the uuids changing when a partition is copied with partimage? Or are the uuid's the same? | 21:56 |
| === cassidy__ is now known as cassidy | ||
| geser | Mithrandir: Hi, a large list of packages FTBFS because one of the build-depends wasn't build at that time. Is there a better way as to give the build-admins a list of packages for give-back? | 22:19 |
| wasabi | This sillyness that I keep getting repeated regarding nvidia and the kernel makes me wonder if the nvidia user space utilities should hard depend on a specific kernel module package version in some fashion. | 22:24 |
| wasabi | Oh, they do. | 22:25 |
| wasabi | Blah. Sillyness! | 22:26 |
| wasabi | Next line of questioning: is there any way to cause a source package to want to be rebuilt when a related package is rebuilt? That would be nice. :0 | 22:27 |
| persia | wasabi: There is tracking, but in many cases it needs manual adjustment of the dependent package, so it sometimes takes a while to catch up. There are pushes to clear the outstanding queue of rebuilds needed for each alpha/beta/rc/public release | 22:28 |
| wasabi | Well, my biggest desire is to have the nvidia/ati stuff pulled out of this giant monolithic package. It is more than a small effort to download 141MB to rebuild nvidia-glx-new | 22:29 |
| wasabi | And I hear it's there because of the effort to force a rebuild of all import module packages when the kernel updates. | 22:30 |
| wasabi | s/import/important/ | 22:30 |
| jdong | wasabi: I've cried about modular l-r-m for a while now | 22:32 |
| persia | wasabi: Since everything in that package needs a rebuild for each kernel rebuild, it's much easier from a distribution management point of view to keep it monolithic. | 22:32 |
| wasabi | Yes. It's a pain in the ass from a "just want to rebuild one really small module!" pov though. :0 | 22:32 |
| persia | True :) | 22:33 |
| jdong | we need source metapackages ;-) | 22:33 |
| jdong | nested debs | 22:33 |
| wasabi | Eh. A system that would automatically force a rebuild when a specified package is rebuilt. Probably just another field in the control file, and a system that cares | 22:33 |
| jdong | metadebs sounds so cool we've got to turn it into a real feature, right? ;-) | 22:33 |
| * persia really doesn't think automatic rebuilds of affected deps is ideal: better to have transition breakage to flag the need for manual verification than to have everything update, and half of it break. | 22:34 | |
| wasabi | Eh. Good point too. | 22:35 |
| wasabi | The problem then is that the system won't actually break. | 22:35 |
| wasabi | It will upgrade the kernel, but not the dependent modules. | 22:35 |
| wasabi | And the next reboot will bring you to a system with no modules. | 22:35 |
| persia | Right. Even just for libraries, everything looks good until you reboot. | 22:36 |
| jdong | speaking of that, is there a modules-assistant command to build for the current kernelver any packages that were built for previous ones? | 22:36 |
| LaserJock | just do it all with bzr ;-) | 22:36 |
| jdong | it'd be great to be able to stick something like that in an init.d for manual graphics driver installers | 22:36 |
| wasabi | Could probably fix that with some sort of hard dependency on a rolling kernel version. nvidia-glx could hard depend on linux-image-specific-version. | 22:36 |
| * persia pointedly ignores LaserJock, noting that bzr doesn't have build features | 22:36 | |
| wasabi | That would force a kernel upgrade, before the module would upgrade. | 22:37 |
| wasabi | But not actually force the user to USE the new kernel. | 22:37 |
| wasabi | Or you could roll the kernel module packages just like you do for the kernel itself, I guess. | 22:38 |
| persia | wasabi: Now that's an idea that might be interesting to someone (but needs analysis to ensure it doesn't break anything related to the apt, aptitude, and upgrade-manager dependency models. | 22:38 |
| wasabi | Still leaves userspace up in the air. | 22:38 |
| wasabi | Course you'd totally want Nvidia to guarentee userspace/kernel space would be backwards compatible. :0 | 22:38 |
| norsetto | riddell: you don't have 5 min. by any chance? | 22:42 |
| Riddell | norsetto: hi | 22:52 |
| Riddell | what can I do? | 22:52 |
| norsetto | riddell: hi there, is about mentoring | 22:52 |
| soren | Plural of "status"? "statuses"? "stati"? | 23:10 |
| slangasek | context? (usually it's easier to use a singular) | 23:11 |
| soren | I could of course cheat and write "states"... | 23:11 |
| soren | slangasek: "Trigger support in dpkg adds to new stat{uses,i}" | 23:12 |
| slangasek | statuses, or status values | 23:12 |
| soren | I guess "states" works just fine. | 23:12 |
| slangasek | or that :) | 23:12 |
| norsetto | soren: in latin is statii (don't think this helps you much though) | 23:13 |
| soren | norsetto: Double i? | 23:13 |
| soren | Hm.. I did not know. | 23:14 |
| slangasek | I don't believe that's correct | 23:14 |
| norsetto | soren: yes (well, depending on the school of thought really) | 23:14 |
| soren | Well, actually, I probably did, but forgot :) | 23:14 |
| === tiborio__ is now known as tiborio | ||
| slangasek | http://www.englishforums.com/English/StatiPluralStatusStatusesSounds-Horrible/2/bjgpr/Post.htm | 23:15 |
| slangasek | status is a fourth-declension noun, not a first-declension noun | 23:15 |
| norsetto | slangasek: well, the problem is that ii is sometime written as long U | 23:16 |
| soren | slangasek: I'm afraid I forget what the means in terms of conjugation. | 23:17 |
| slangasek | norsetto: er, so when is it ever written "ii"? | 23:17 |
| norsetto | slangasek: in what we call "latino maccheronico":-) | 23:17 |
| soren | slangasek: If it were a first-declension noun what would it be in plural? And now that we know it's a fourth-declension one, what is its plural form? | 23:17 |
| slangasek | norsetto: ok then :) | 23:18 |
| persia | soren: first is -a, -ae. second is -us -i | 23:18 |
| soren | persia: Oh, right. That rings a bell. | 23:18 |
| * soren only had 3 latin lessons or thereabouts :) | 23:18 | |
| persia | anyway, in English, it is "statuses" | 23:19 |
| slangasek | right, sorry; so I meant that status is fourth declension rather than /second/ declension ): | 23:19 |
| slangasek | :) | 23:19 |
| slangasek | soren: fourth-declension plural is statūs | 23:20 |
| soren | ALright. "states" it is. :) | 23:20 |
| slangasek | heh | 23:20 |
| norsetto | I vote for statis :) | 23:20 |
| soren | Does "statuses" sound horrible to you as well? | 23:21 |
| slangasek | yes | 23:21 |
| * ScottK thought is was status | 23:21 | |
| soren | Ok, that's enough latin and dpkg code for one day. I'm off to bed. | 23:31 |
| soren | Good night, everyone. | 23:31 |
| * slangasek waves | 23:32 | |
| LaserJock | soren: I finally got your interview up, btw | 23:33 |
| soren | LaserJock: Yes, someone pointed it out :) | 23:34 |
| soren | LaserJock: Thanks :) | 23:34 |
| * soren wanders off to bed | 23:34 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!