[00:28] so I wonder, how do I get network-mangler to quit trashing /etc/hosts? [00:34] james_w: you remember the class? :) [00:34] nigelb: yes, thanks for the reminder :-) [00:34] nigelb: did anyone pick a topic for me yet? ;-) [00:34] james_w: nope, nothing came up :( [00:35] I think it's been 6 months since I've done a "UDD intro + Q&A", so I can do that again [00:39] yay! [00:58] doko: http://qa.ubuntuwire.com/ftbfs/ should be back in business now. === bjf[afk] is now known as bjf === jjohansen is now known as jj-afk [01:50] In case anybody tries to fix it, the firefox FTBFS on powerpc is some unknown Soyuz breakage, so don't. [02:07] james_w: At UDS, I would be very interested in sitting down with some UDD type person to review how I deal with clamav packaging to find out if UDD can help be do it better/faster or if it presents any interesting use cases UDD might want to support. [02:33] Are all translations for a package stored in the po/ directory of the package, if it exists? === hunger is now known as Guest58902 [03:52] For bugs targeted to be fixed in the development branch in time for the final release, do we use milestones (e.g. ubuntu-10.10) or release nominations? The current practice has been to use milestones and reject the nominations, but https://wiki.ubuntu.com/RCBugTargetting (which might be outdated) states otherwise. [04:03] mgunes: No, that's not outdated AFAIK. [04:03] TheMuso: Would you please look at bug 621374 and bug 619809 and comment on if you think we should update the packages or not? [04:03] Launchpad bug 621374 in onboard (Ubuntu) "Feature freeze exception request for new minor release" [Undecided,New] https://launchpad.net/bugs/621374 [04:03] Launchpad bug 619809 in virtkey (Ubuntu) "Feature freeze exception request for new minor release" [Undecided,New] https://launchpad.net/bugs/619809 [04:07] ScottK, I recall quite a few RC bugs where nominations were rejected and a milestone was used instead; bug #605577 would be one recent example. [04:07] Launchpad bug 605577 in Ubuntu Translations "Help contents title bar shows cubes with numbers instead of a proper title" [High,Triaged] https://launchpad.net/bugs/605577 [04:08] mgunes: The list that the release team reviews is those that are milestoned and targetted to the release. [04:08] That doesn't mean everyone is doing it right. [04:13] ScottK, there seem to be plenty of bugs tracked in Maverick: https://bugs.launchpad.net/ubuntu/maverick/+bugs [04:14] mgunes: You asked a question. I answered it. If you were going to argue with the answer, why bother to ask? [04:18] ScottK, I wasn't arguing; I meant to confirm your observation that everyone might not be doing it right, since both milestones and nominations seem to be used. [04:18] mgunes: Oh. OK. [04:18] Sorry about that then. [04:18] no worries. === mnepton is now known as mneptok === almaisan-away is now known as al-maisan === hrw|gone is now known as hrw [07:38] Good morning [07:38] tkamppeter: cheers === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:07] !info ubuntu-restricted-extras-java [08:07] Package ubuntu-restricted-extras-java does not exist in lucid [08:08] then where on earth is it from? [08:11] oh, it's ruddy superOS [08:12] !superos [08:12] hmmm. anyone here deal with that? [08:14] and for bonus points, they have no place to report bugs [08:16] Nice. [08:16] quite [08:16] You could possibly sick the trademark police on them. [08:16] they've already changed from super ubuntu to superos [08:17] mvo: can we instruct launchpad not to accept bugs following some pattern, and force the overwrite of that file? [08:18] Hobbsee: uh, no idea. I think that is more something for #launchpad [08:18] (sorry) [08:19] mvo: ah. no problem [08:19] * Hobbsee finds a contact address, so sticks the Long Pointy Stick on it [08:20] \o/ [08:20] * ajmitch hopes they've got good flame-resistant clothing [08:20] * ScottK cheers the return of the stick. [08:20] haha [08:20] "we don't provide support for this software"...yeah, i couldn't have guessed [08:21] Hobbsee: But if they are still naming their packages ubuntu-foo, then maybe they are still vulnerable. [08:21] ScottK: good point. I'm not sure [08:21] ScottK: to be honest, as long as I don't keep receiving bugs about their conflict, i'm happy [08:22] they can name packages however they like if they don't cause us bugs [08:22] if they cause themselves bugs, that's their own problem [08:22] Right and the odds of that would be better if the package weren't called ubuntu something [08:22] true [08:23] "How can it not be an Ubuntu bug, it's got Ubuntu right in the name?" [08:23] then i'll issue smackdown #2 to the reporter, and further dupe their bugs. This is not really aproblem [08:27] popey, ! you banned karl ?!? [08:39] pitti, hi [08:40] hello tkamppeter [08:42] pitti, what's on [08:42] erm, still digging through the ridiculous stack of overnight email [08:43] oh, and I uploaded a cups fix for the upstart migration [08:43] how are you? [08:43] fine, I have seen your solution in the BZR yesterday. [08:48] pitti, I have seen in debian/rules of CUPS that there is also firewall (ufw) profile in CUPS. Does it take into account access to LPD-based network printers? See bug 645603. [08:48] Launchpad bug 645603 in cups (Ubuntu) "cups printer was properly installed and working under 10.04 LTS. Once I upgrade it to 10.10, it is no longer working." [Undecided,Invalid] https://launchpad.net/bugs/645603 [08:49] tkamppeter: isn't lpd on port 631 as well? [08:50] pitti, no, LPD is on port 515 and I do not know whether the printer uses additional ports to answer LPD requests. [08:53] pitti, CUPS uses also SNMP and DNS-SD for discovering printers (the former also to check status). I do not know which ports these protocols use. They should also not be blocked by the firewall. [08:54] wc -l x [08:58] jdstrand: ^ the firewall (ufw) isn't active by default, or is it? i. e. will /etc/ufw/applications.d/cups preclude other ports (like from lpd) from being used? [09:03] pitti, Good morning. Could you accept re-uploads for Karmic (master, mvl-dove, ec2) and binNEW lrm Hardy? [09:04] . o O { seems it really gets time to get back to platform } [09:04] pitti, There never seemed to be someone being able to fit your shoes. :) [09:07] slangasek, cjwatson: could one of you please review my udev upload from Monday? I discussed it with Colin before, and I vouch that it's safe [09:07] mvo, hey ... just tested your fix, works fine ! [09:08] ogra: nice, thanks! [09:08] ogra: that means one final upload [09:08] mvo, kleiner lacher als dankeschoen :) http://www.youtube.com/watch?v=ei7LP99FFb4&feature=channel [09:09] mvo, i havent had the opportunity to test with a list of packages yet though (TI only has one test package in their PPA) [09:09] though if it doesnt work i can ask them to create a metapackage or so [09:11] ogra: that does make sense I think [09:11] ogra: it should work :) [09:11] smb: meh, kernel-overrides is broken; hardy NEWing will take a bit [09:16] smb: karmic accepted, and hardy -envy [09:16] fiddling with hardy lrm now [09:37] ogra: :) [09:37] :( [09:37] sniff [09:38] my best coffebreak entertainment is gone [09:38] smb: meh, and queue overriding is broken for me as well; I really need to get to something else right now, I'll have a look later (unless someone beats me to it) [09:39] pitti, please don't publish bug 525807 to lucid. It was marked verification-done but it is not. Thanks. [09:39] Launchpad bug 525807 in openoffice.org (Ubuntu Lucid) "[upstream] [3.2.1] OOo Slide Show and Fullscreen modes - not full screen under compiz" [Medium,Fix committed] https://launchpad.net/bugs/525807 [09:39] jibel: can you please set it to "failed"? [09:39] pitti, Doh! Well I guess I'll have some more tea then. ;-) [09:39] pitti, done. [09:39] ah, seems queue override needs a full package name now [09:39] argh pain argh [09:40] * smb hands pitti a stress ball [09:40] ogra: lol [09:44] smb: ok, lrm/hardy done [09:44] * pitti raises his shields to full power and finally goes to do something he's supposed to [09:44] pitti: can you approve fglrx in maverick, please? [09:44] pitti, Thanks, and good luck [09:45] oops [09:45] shields down to 20% captain [09:45] later :) [09:46] TheMuso: Thanks. Approved. I'd appreciate it if you'd keep an eye on getting them uploaded sooner rather than later. [09:47] ScottK: sure [10:15] pitti: Mind if I bother you for a sync to maverick? FFE and rationale in LP #645200l systemtap 1.3-1 from Debian experimental [10:15] Launchpad bug 645200 in systemtap (Ubuntu) "FFe: please sync systemtap 1.3-1 from experimental to maverick" [Undecided,Confirmed] https://launchpad.net/bugs/645200 === spike_ is now known as spikeWRK [10:43] didrocks: I think your approach of disabling all tests for libcairo-perl due to a few corner cases failing is probably overbroad, particularly this late in the release cycle. Fortunately persia has worked out a more focused solution that only disables the tests currently failing. I'm going to reject your pending upload. Would you please have a look at what persia has prepared and consider sponsoring it if you think it's suitable? [10:43] * persia is build-testing that, and will push a patch to the bug when it completes [10:44] ScottK: sure, I've done that after talking to slomo, and almost nothing is using libcairo-perl in any case, so if persia has a better solution, please go ahead and upload it :) [10:44] didrocks: I'm just about to be away for several hours, so I'd appreciate it if you would have a look after persia puts the debdiff in the bug. [10:44] ScottK: sure [10:44] didrocks, I can't, so I'll hope for your signature on it in a few minutes :) [10:45] persia: ok, I'll look at it :) just ping me! === ogra_ac2 is now known as ogra_ac [11:01] tseliot: done; can you please update jockey as well? and thanks a lot for getting this in! === zyga is now known as zyga-airport [11:02] pitti: sure, I'm also looking at another issue in jockey when updating initramfs (which maybe we should do for the current kernel instead of the newest kernel). What do you think? (this is in the handlers) [11:03] tseliot: hm, why is it doing that for fglrx? [11:03] tseliot: or do you mean for the wl blacklisting? [11:03] pitti: here's the use case. I boot into an older kernel and decide to install the driver for that kernel but then initramfs is updated only for the newest kernel [11:03] didrocks, bug #187823 has a more targeted patch [11:03] Launchpad bug 187823 in libcairo-perl (Ubuntu Hardy) "ftbfs (1 failed test) with current cairo version" [High,Confirmed] https://launchpad.net/bugs/187823 [11:03] pitti: to blacklist the radeon KMS driver [11:04] pitti: the same applies to nvidia with nouveau [11:04] tseliot: so you want to update all? [11:04] tseliot: i. e. -k all? [11:05] pitti: maybe just the current kernel? Or the current kernel and the latest kernel [11:05] tseliot: hm, I thought -u woudl already do the current kernel [11:05] pitti: which is what dkms does by default with my template [11:06] tseliot: so, mirroring the dkms behavior makes sense to me [11:06] pitti: -u without further arguments should only update the latest kernel [11:06] pitti: ok [11:06] pitti: I'll let you know when the code is ready [11:06] tseliot: cool, thanks! === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [11:29] didrocks: is anyone from the desktop team looking at bug 642746? [11:29] Launchpad bug 642746 in libwnck (Ubuntu) "[Maverick] Workspace layout is 1x9 instead of 3x3" [Undecided,Confirmed] https://launchpad.net/bugs/642746 [11:29] I've seen a few reports of that, and I see the bug myself [11:30] cjwatson: not that I know of, but I wanted to work on it as I use metacity too :) Assigning to the team for now [11:31] it's a recent update, I didn't get that before [11:32] persia: didn't know about this SKIP testsuite (only familiar with python ones). Looks good and build fine. Sponsoring now, thanks! [11:34] didrocks, Neither did I until I saw the comments in the source file :) Thanks. === MacSlow is now known as MacSlow|lunch === amitk is now known as amitk-afk === dendrobates is now known as dendro-afk [12:08] doko: can you have a look at bug #640732? [12:08] Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged] https://launchpad.net/bugs/640732 [12:44] pitti: hi! ufw is not enabled by default. /etc/ufw/applications.d/* are what are called 'application profiles'. They provide a means for someone to do something like 'sudo ufw allow CUPS' instead of having to specify the port and protocol [12:44] pitti: they don't do anything unless the admin decides to use them. the cups application profile does not currently have an entry for lpd (515/tcp) [12:45] tkamppeter: ^ so this shouldn't cause the lpd failure you mentioned [12:45] pitti: as for snmp, there is no application profile. for dns-sd, if the firewall is enabled, multicast is allowed by default [12:46] jdstrand: ok, thanks for the heads-up; so probably cups' profile should get the lpd port added to? [12:48] pitti: possibly. ufw in Debian has some default application profiles that includes lpd already (/etc/ufw/applications.d/ufw-printserver) that we'll get in natty [12:48] jdstrand: ah, nice [12:49] pitti: I'm rethinking how we do those and will probably provide these default ones and remove the package-specific integration unless the packager wants to override the ufw defaults [12:50] but I need to think about it some more [12:50] bdrung_: hmm, do you have such an example? [12:52] new .0 release in feature freeze ... [12:55] doko: you can install audacious in maverick and follow the steps in comment #6. i haven't a stripped down version example for this bug. [12:56] doko: new .0 release of what? [12:57] cjwatson: libwnck fix pushed [12:57] bdrung_: audacious, what else. is this amd64 only? [12:59] not reproducible on i386 [12:59] doko: 2.4.0-0ubuntu1 doesn't differ much from 2.4~rc2-0ubuntu1 which doesn't differ much from 2.4~beta2-0ubuntu1. 2.4~beta1-0ubuntu1 was uploaded before feature freeze. === amitk-afk is now known as amitk [13:00] doko: i386 is probably affected too. some duplicates are filed against i386: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/633012 [13:01] Launchpad bug 633012 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init() (dup-of: 640732)" [Medium,New] [13:01] Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged] [13:01] bdrung_: is this amd64 only? [13:02] doko: according to the bug reports: no [13:03] bdrung_: and can't reproduce on amd64 either [13:03] although that's a remote system [13:03] didrocks: yay [13:03] pitti, jdstrand, is the UFW totally open (inactive), totally closed, or closed with some exceptions in a default installation? [13:04] doko: i can reproduce it. [13:04] doko: the question is what differs between our systems? i was even able to reproduce it in my VM [13:05] doko: hiding won't help. ;) [13:06] tkamppeter: the default installation is disabled (ie open) [13:06] tkamppeter: s/open/inactive/ [13:07] tkamppeter: ie, it does nothing unless someone explicitly enables it [13:08] jdstrand, pitti, if enabling it all ports get closed if no exception is defined in one of the /etc/ufw/applications.d/* files? [13:11] tkamppeter: /etc/ufw/applications.d/* are not exceptions and nothing is done with them automatically when enabling the firewall. think of /etc/ufw/applications.d/* as /etc/services on steroids: it is just a way for an admin to conveniently reference (groups of) ports and protocols by application name [13:11] tkamppeter: eg, you do something like 'sudo ufw allow Samba' rather than specifying 137/udp, 138/udp, 139/udp and 445/udp [13:12] meh [13:12] 139/tcp and 445/tcp [13:12] tkamppeter: see 'man ufw' [13:12] APPLICATION INTEGRATION [13:22] pitti: one more thing that I've noticed is that if a package is already installed and we enable it, the icons of control panels don't show up in the menu unless we do what's suggested in bug 581838 . I'd like to take care of this problem too [13:22] Launchpad bug 581838 in gnome-menus (Ubuntu) " Manually created menu item in Gnome disappears from Gnome, Ubuntu 10.04 (64 bit).after reboot" [Low,Invalid] https://launchpad.net/bugs/581838 === ivoks-afk is now known as ivoks [13:24] jdstrand, thanks. [13:25] tseliot: because it puts a desktop file into /usr/share/applications which isn't shipped in a package? [13:26] I've seen several incarnations of this report already; you either need to run the dpkg trigger, or (easier) just ship the .desktop file in the .deb [13:27] Please, please, select the latter of those options :) [13:27] *violently agree* [13:32] pitti: I do both things [13:33] pitti: however, when we switch between alternatives (and the packages are already installed), even though we call dpkg-trigger from python, it doesn't work because that's supposed to be called by a package. === ivoks is now known as ivoks-afk === MacSlow|lunch is now known as MacSlow [13:34] bdrung_: the list of segfault bugs in audacious is "impressing" ... [13:34] tseliot: [13:34] $ sudo dpkg-trigger --by-package fglrx-installer gmenucache [13:34] $ sudo dpkg --configure -a [13:35] tseliot: so you enable/disable the desktop file based on an alternative? [13:35] pitti: yes, so that we don't end up having ati's control panel when nvidia is in use [13:35] tseliot: if the trigger causes too much grief, you could also use /usr/local/share/ perhaps? [13:36] tseliot: but if you have the fglrx package isntalled, why wouldn't you show it? [13:36] I mean, it's highly unusual to have fglrx installed on an nvidia system? [13:37] pitti: I can have an image that has both fglrx and nvidia installed and I can enable the right driver according to the hardware [13:37] tseliot: ah, ok [13:38] pitti: let me check how I call dpkg-trigger in nvidia-common (in a library that jockey uses) [13:38] pitti: I do "dpkg-trigger --by-package=fakepackage gmenucache" [13:39] tseliot: you need a --configure call as well [13:39] tseliot, Rather than adding/removing the .desktop file, consider hiding it. [13:39] right, you could enable/disable NoDisplay=, too [13:39] NoDisplay is a really clean way to hide it :) [13:40] persia: we don't install .desktop files in that directory, only links to the actual desktop files. When you switch between alternatives, those links point to different desktop files [13:40] pitti: ah, so that's what I was missing === dendro-afk is now known as dendrobates [13:41] tseliot, Much of what was horridly confusing about an experience moving hard drives between machines a while back now becomes clear :) [13:41] pitti: and would it work if I did "dpkg --configure -a" after "dpkg-trigger --by-package=fakepackage gmenucache" despite the fact that fakepackage is a fake package? [13:42] tseliot: works here [13:42] persia: that's just the tip of the iceberg. Welcome to my world :P [13:42] * persia quickly withdraws to something that makes sense [13:42] pitti: good, so it'll be just a one line change in nvidia-common [13:42] hehe [13:43] tseliot: "sudo dpkg-reconfigure python-gmenu" alternatively that should work as well [13:43] not sure what is better [13:43] but using the "gmenucache" trigger hides the implementation detail which package is responsible for it [13:43] it's not unlikely to move to gnome-menus at some point [13:45] ok, thanks [13:45] * tseliot -> lunch === oSoMoN_ is now known as oSoMoN [13:54] doko__: commented bug #640732. using g++ instead of gcc fixes the crash. [13:54] Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged] https://launchpad.net/bugs/640732 [13:55] bdrung_: I love plugins ... [13:55] doko__: i will be afk for some hours - i need a new "perso" before it will be electronical and expensive. [13:56] doko__: indicates that a bug in gcc or shouldn't gcc be used for linking? === njpatel_ is now known as njpatel === ara_ is now known as ara [14:14] ev: ping to remind about merge https://code.edge.launchpad.net/~didrocks/ubiquity/take-libindicator-abi-change. the installer mode will have no indicator in the bar otherwise [14:14] didrocks: indeed, already realized that I forgot to upload it with the last version. I'll do another upload shortly. [14:15] ev: great, thanks :) === ogra_ac2 is now known as ogra_ac [14:44] pitti: I have tested my changes to jockey but I don't know if bzr hosting is up now, so here's the patch (which in bzr is split into different commits): http://pastebin.ubuntu.com/499093/ [14:44] let me know if I can upload the changes [14:44] tseliot: https://code.edge.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/ seems to work? [14:45] tseliot: ah, -k will _also_ update the current kernel? [14:45] erm, also the latest kernel, I mean? [14:45] pitti: yes, they announced a downtime for code hosting at 14 UTC [14:46] pitti: "-u -k $YOUR_KERNEL" means update this specific kernel while "-u" by itself updates the latest [14:46] tseliot: --help sounds like it would only update that particular versio then [14:46] which is why both commands are required [14:46] ah, so they are cumulative [14:46] * tseliot nods [14:46] tseliot: looks fine, thanks [14:47] tseliot: so it's one commit for reenabling fglrx, one for the initramfs, and one for dch -r/debcommit -r? [14:47] shouldnt that use triggers ? [14:47] ogra_ac: can't -- it's just changing symlinks [14:47] ah [14:49] pitti: yes, commits 431-433 [14:49] tseliot: nothing new in ~ubuntu-core-dev/jockey/ubuntu [14:49] pitti: if you agree, I'll push my changes and then upload [14:49] tseliot: please go ahead; thanks! [14:50] pitti: ok, pushed. Also, here's the debdiff for nvidia-common: http://pastebin.ubuntu.com/499148/ [14:50] just 1 line [14:50] of code that is [14:51] looks fine [14:53] pitti, superm1: I have one final change that I'd like to have in maverick. We spotted the problem in OEM when using chroots. It's a patch for DKMS which corrects the logic behind kernel selection (when building modules). I wrote the original code so I'm just correcting myself. Here's the (well tested) patch: http://pastebin.ubuntu.com/499094/ [14:56] pitti: BTW I've just uploaded both jockey and nvidia-common === dendrobates is now known as dendro-afk === ogra_ac2 is now known as ogra_ac === dendro-afk is now known as dendrobates [15:13] tseliot, I've verified bug 642518 in hardy [15:13] Launchpad bug 642518 in fglrx-installer (Ubuntu Karmic) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Fix committed] https://launchpad.net/bugs/642518 [15:13] tseliot, The module builds fine and is loaded correctly upon reboot, so that's great, but there is an error in the make.log see http://paste.ubuntu.com/499115/ [15:14] jibel: let me have a look [15:14] tseliot, I think that $srctree is not correctly set in the Makefile. [15:18] jibel: ah, so /usr/src/linux-headers-2.6.24-28-generic/include/config/compat.h exists, right? [15:18] tseliot, let me check [15:19] tseliot, yes it's there [15:19] tseliot, It might be that this is only printed on the first run [15:20] I think the makefile is called first normally, then srctree is not set, then it calls the kernel makefile and gets called from there and this time srctree would be defined === dendrobates is now known as dendro-afk [15:21] smb: ah, it could be. Shall we check $srctree in the code before doing grep? [15:23] or simply use grep -q so that the error doesn't show up [15:23] tseliot, That probably could be done (or encapsulate the grep and check into something like ifeq KERNELSRC). I guess i have the same (harmless) warning in lbm. But if people get confused and its easy to do, maybe that is a good idea [15:24] tseliot, Was that dkms package in hardy? [15:24] smb: yep [15:24] Ok, yeah. So more likely to get noticed [15:26] hey guys [15:26] not sure if you saw but even if we are not shipping a new version of gedit we do with gedit-plugins [15:27] is there any reason to not include it in maverick? [15:28] smb, jibel: I guess that simply passing "-q" to grep will remove that line from the log and it's a trivial change anyway [15:29] tseliot, If you used the line I sent you be aware that it relies on match text going to stdout. You may need to modify it a bit more [15:31] smb: yes, that's your patch. You're checking the exit status of grep, aren't you? "grep -q" will make it quiet [15:32] tseliot, No I was checking for empty or non-empty stdout output [15:32] So making the same quiet would be bad [15:33] smb: right, I've just re-read your patch [15:34] I probably should have paid more attention to the log output, but there is a bunch of that when doing lrm. So it just went under. And it worked. === shadeslayer_ is now known as shadeslayer [15:48] smb: then something like this should work: ifneq ($(shell grep -q compat_alloc_user_space /usr/src/linux-headers-2.6.35-22-generic/include/linux/compat.h && echo "found"),) [15:50] tseliot, that looks reasonable as long as you have not hard coded the path. [15:50] smb: yes, I used that only to test things locally with the makefile [15:50] jibel: let me update the patch [15:51] tseliot, the -q will only make the output quieter but since it's an error it goes to stderr [15:51] tseliot, I mean you need to redirect stderr [15:52] "Quiet; do not write anything to standard output" i.e. I can't read the man page :P [15:52] jibel: -s should work though [15:53] tseliot, why not run $(shell grep [...]) then test $$? ? [15:55] tseliot, right -s should work. Let me update the Makefile [15:55] if you test $$? outside the $(shell) then it will be in a different shell process, surely [15:55] or at least may be [15:55] * tseliot was trying to avoid $$? [16:00] tseliot, it fails silently and the module builds. I'm now trying to build it with dkms [16:01] jibel: ah, good [16:04] cjwatson: do you know if there's a way to prevent lrm-envy from ending up in NEW? Something in the version that I use perhaps? [16:04] there's 2.6.24.503-503.32 in -proposed [16:04] hardy-proposed, that is === deryck is now known as deryck[lunch] [16:08] tseliot: I doubt it [16:08] tseliot: it'll be a soyuz bug [16:08] cjwatson: I suspected that but I had to try ;) === ivoks-afk is now known as ivoks [16:10] tseliot, that's okay with dkms too. [16:11] jibel: ok, good. I'll upload a new version of lrm-envy with the updated patch [16:11] thanks for testing [16:12] tseliot, you're welcome [16:21] uploaded === amitk is now known as amitk-afk === ivoks is now known as ivoks-itc [16:41] can bug 165181 get a sponsor for its patch? [16:41] Launchpad bug 165181 in synaptic (Debian) "Order by "Supported" Column Slow" [Unknown,New] https://launchpad.net/bugs/165181 [16:46] pitti: also, please approve lrm-envy in hardy-proposed when you're back [16:47] or whenever you have the time [16:48] james_w: hey, I'm trying to do a bzr dailydeb on a package that originally used 3.0 (quilt) format. That appears broken in dailydeb. Is there something I can trivially substitude? I tried 1.0 (quilt) but got broken depend on Dpkg::Source::Package::V1::quilt [16:49] hallyn: it's just "1.0" not "1.0 (quilt)" [16:49] and it's not a trivial substitute as it doesn't have built in quilt support [16:50] james_w: anything else I can try? [16:50] there's not a great answer right now unfortunately [16:50] ok, so i'll just manually apply the patches out of debian/rules pre-build [16:50] any estimates as to when 3.0 might work? [16:51] that's the best I can offer right now [16:51] no idea, I haven't heard of a good solution yet [16:51] bug 614768 [16:51] Launchpad bug 614768 in bzr-builder "Unable to build dpkg v3 (quilt) packages" [High,Triaged] https://launchpad.net/bugs/614768 [16:51] james_w, thanks for the 'changelogs.u.c' pointer. embarrisingly never had seen that before. [16:51] james_w: thanks [16:51] smoser: np === deryck[lunch] is now known as deryck [16:59] tseliot: oh, another one? I binNEWed it this morning [17:00] pitti: yes, jibel riported a problem with an annoying message coming from grep [17:00] pitti: the new upload is just a cosmetic change [17:02] tseliot: ah, thanks; will look at it [17:03] pitti: great, thanks (together with jockey and nvidia-common) :) === jj-afk is now known as jjohansen === ogra_ac2 is now known as ogra_ac [17:29] tseliot: done, thanks === beuno is now known as beuno-lunch [17:30] pitti: thanks a lot === al-maisan is now known as almaisan-away [17:50] pitti: when do you plan review lucid-proposed for approval? [17:50] I did way too much queue review today already..; no plan yet, just "soon" :0 === beuno-lunch is now known as beuno [18:50] bdrung_: f-spot is also affected by the submodule bug (since you're in there already) [18:54] jcastro: submodule? bug number? [18:55] bug 402814 [18:55] Launchpad bug 402814 in Launchpad Bazaar Integration "Importing revisions with submodules is not supported" [Wishlist,Triaged] https://launchpad.net/bugs/402814 [18:55] jcastro: ok. added [18:56] 8 projects. i want an working import for vlc. currently i am using a workaround [19:24] kees: have you been fiddling? :-) [19:24] deathspank scott% iwconfig |& grep eth1 [19:24] eth1 IEEE 802.11 Access Point: Not-Associated [19:24] deathspank scott% sudo iwconfig |& grep eth1 [19:24] eth1 IEEE 802.11abgn ESSID:"attwifi" [19:24] Keybuk, hi, ogra just informed me upstart relies on 2.6.35, any description available of why that is? [19:25] Neko_: I don't know why ogra informed you of that, no [19:25] to be honest, I don't know why ogra does many of the things he does ;-) [19:29] so there should be no weird features in udev or upstart or anything else that basically relies on some fancy new sysfs or so feature of 2.6.35 over, say, 2.6.31, that hasn't got some workaround? [19:29] I'm hoping nobody bothered to clean it up since Karmic/Lucid [19:30] * ScottK is pretty sure he didn't say that. [19:31] Neko_: you didn't say udev [19:31] you said Upstart [19:32] udev certainly relies on whatever the *latest* kernel version was at the time that version of udev was released [19:32] which is only natural, since udev is pretty much the kernel's userspace partner [19:32] how do udev releases map to kernel releases? :/ [19:32] take an Ubuntu release [19:32] I mean say, udev 117.. how do I know which kernel that would be happy with [19:32] whatever version of udev is chipped with that release, needs whatever kernel was shipped with that release [19:34] is that an ubuntu udev thing or a www.kernel.org/udev thing? [19:35] well, you won't find it on either [19:35] but a good guide, first look at: [19:35] https://launchpad.net/ubuntu/+source/udev [19:36] 117 was shipped in Hardy, so look at: [19:36] https://edge.launchpad.net/ubuntu/+source/linux [19:36] err w/o the edge obviously [19:36] Hardy had 2.6.24 [19:36] so figure that udev 117 needs kerenl 2.6.24 [19:37] I somehow doubt 147~-6.1 is going to run on Maverick even if we try [19:37] forwards compatibility tends to be much better than backwards [19:37] usually you can update your kernel without updating your udev [19:37] Keybuk: with wifi? no... why? [19:37] for the most part, it works, occasionally you may need to update rules if you care about a particular new subsystem of that new kernel [19:38] kees: see the paste - it amused me - it's the kind of thing you'd like [19:38] kees: you can only see what AP you're associated to if you're root ;-) [19:38] Neko_: indeed, it's this slight focus on making sure that forwards compatibility works that means backwards compatibility doesn;t [19:39] Keybuk: oh, I missed the sudo. weird. [19:39] Keybuk: it's probably all the same query call that includes the key too [19:40] I'd guess iwconfig is making a kind of "give me everything" query [19:40] Keybuk: s'okay, until current kernels, I could read the kernel memory that held that info directly. ;) [19:40] kees: *grumpy* [19:40] I want /dev/kmem back, damnit [19:40] of course, in Ubuntu, you can just ask NM for the same info - which happily sends it over D-Bus ;-) [19:40] yup :) [19:41] nothing stops you from compiling and running a kernel with /dev/kmem. :) [19:49] Keybuk, i said that things like upstart and udev sometimes rely on kernel features, in some releases more in some less [19:52] Keybuk, and that if you roll an ubuntu image of maverick with your own kernel you should have a 2.6.35 [19:52] pitti: what do you think of a 30 min default? I don't want gnome-keyring to remember forever as a default... [19:55] ogra_cmpc: right, that's good advice [19:55] if you roll your own images of any ubuntu version, only *update* software [19:55] never downgrade [19:56] kernel 2.6.36, 37, 38, ... should be fine too [19:56] Keybuk, especially if you try to revive an arch we dropped :) [19:56] kees: yes, but you'd stop me uploading that to the archive as the default :p [19:56] and see weird bugs nobody can explain [19:56] there are reasons it's a dropped arch :p [19:57] yes :) [19:58] Keybuk: indeed, since only you need kmem :) [19:59] kees: no, everybody needs kmem! [19:59] because otherwise there's no way to get the string arguments to functions out of the kernel while tracing ;-) [19:59] the tracing infrastructure simply returns the address of the string, not the string :p [19:59] (as you well know) [19:59] Keybuk: key part of your sentence "while tracing" [19:59]