[00:55] slangasek, ping [00:55] cprofitt: hi [00:55] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/281732 [00:55] Launchpad bug 281732 in linux "Mute button on thinkpad x200/x200s" [Medium,Triaged] [00:55] was wondering if there was any more information I could give you... or any guidance you have [00:57] slangasek, did you get that or suffer a netsplit? [00:58] cprofitt: fundamentally, these keys are not designed to be handled by userspace at all; I'm told the current behavior parallels the handling of these keys under Windows, and the only way we could improve on the current behavior in jaunty is by exposing the hardware mixer to ALSA. [00:59] slangasek, is it just the mute key... the up / down volume works... [00:59] "works"? [01:00] also the mute works on my T61p, T42p and Self Built machine with a Gateway keyboard [01:00] works = OSD display, mixer notification, mute / unmute (for the mute key) [01:00] you should not be getting *any* of those things with a Thinkpad under 9.04 [01:01] because the buttons are hardware buttons, not hotkeys [01:01] on my T500 the volume keys lower / raise the volume, give an OSD display and move the volume control [01:01] slangasek, the up / down volume register in xev, but the mute does not... [01:02] ooh cool, is that a hardware mute switch then? [01:02] have you modified your hotkey handling under /etc? Because those buttons don't do anything in 9.04. [01:02] "don't do anything" -> "don't do any of those things" [01:02] slangasek, no modifications at all [01:03] cprofitt: you should first of all open a new bug report, instead of following up to this one, and provide all the information from https://wiki.ubuntu.com/Hotkeys/Troubleshooting [01:04] ok [01:04] slangasek, that bug does have all that information in it... [01:05] no, it has all the information in it for *someone else's* laptop [01:06] Anyone in here hack on LVM2 support in Ubuntu? [01:07] thanks for your help slangasek I will make another bug with the same description and add the files I already added to the bug I linked you too with the additional information... [01:07] I appreciate your advice... [01:09] cprofitt: also, what are the contents of /sys/devices/platform/thinkpad_acpi/hotkey_mask on your system? [01:23] 0x038c7fff [01:23] slangasek, sorry for the delay... wife needed help getting the kids to bed [01:25] cprofitt: that does not appear to be the default value in jaunty. Have you rebooted after upgrading, and do you have all packages fully upgraded? [01:25] I did a fresh install [01:25] hmm [01:28] cprofitt: a fresh install from jaunty final, or from an earlier milestone? [01:29] * slangasek has a look at the thinkpad_acpi source [01:34] slangasek, final [01:34] hmm [01:34] downloaded and installed yesterday [01:34] ok; if you can provide info from the troubleshooting guide and point me at the bug, I may have a better idea what's going on here [01:35] I don't see anything in the thinkpad_acpi source that explains how this mask would be set by default [01:35] ok -- I have to finish helping my wife with the kids... [01:41] hello === freeflyi1g is now known as freeflying [04:22] doko: When you said "pysupport-movemodules: Catch files installed in /usr/local." in debian/changelog for python-support did you mean 'catch them and move them to the right place' or 'notice them and fail the build'? It looks (at a glance) like Debian's python-support is doing the former. === ssweeny_ is now known as ssweeny [06:43] Good morning [06:46] Does Ubuntu intend to import Debian's new archive sections (e.g. "haskell")? [06:47] we already did [06:52] OK, thanks. [06:59] geser: did the curl patch to gnupg get submitted to Debian? [07:27] good morning [07:32] * pitti hugs dholbach [07:33] * dholbach hugs pitti back [07:41] slangasek: I have to check but I guess not [07:48] slangasek: will forward it to Debian bug 502558 [07:49] Debian bug 502558 in gnupg "FTBFS: fails to build when either libcurl4-*-dev is installed" [Serious,Open] http://bugs.debian.org/502558 === fabbione-vac is now known as fabbione === fabbione is now known as fabbione-vac [07:55] geser: ok, thanks :) [07:58] I'm sometimes a little bis hesistant with forwarding patches where I'm not sure if Debian is affected (or will be affected in future) [07:59] understandable === jldugger is now known as pwnguin === tkamppeter_ is now known as tkamppeter === imbrando_ is now known as imbrandon [09:39] StevenK: hildon-fm-l10n was removed from Debian (; abandoned upstream; hildon-fm removed); should we follow suit? [09:42] pitti: Yeah, it should die -- can I kill it? :-) [09:42] StevenK: please have the honor (I skipped it in process-removals) [09:46] cjwatson, ok i believe i have sorted out this kexec-tools thing and tested it with dpkg and apt-get updates ... i presume what i need to do is prepare two debdiffs, one for karmic making ubuntu5 with the new changes, plus a second for jaunty which has both changese as an ubuntu 3.1, or should that be 3.1 and 3.2 in the same split as karmic (which is preferred) hrm [10:01] cjwatson, pitti: demotion time! please demote gcj-4.3, axis, gjdoc, libmx4j-java, wsdl4j (all source). wondering why java-gcj-compat-dev is still in component mismatches [10:04] I would like to install xorg-server source code: I try using apt-get source xorg-server but while I launch ./configure the 'X11' package is not found. Any ideas ? [10:07] Pixy: sudo apt-get build-dep xorg-server [10:07] doko: java-gcj-compat-dev is due to hppa, apparently - the removal tool sometimes isn't very helpful when some architectures are at a different version [10:08] I'll clean that up [10:08] cjwatson: are there java-gcj-compat binaries for hppa? [10:10] doko: there was an old one hanging about, version 1.0.56-0ubuntu1 [10:10] cjwatson: ohh, can we remove this? [10:10] 10:08 I'll clean that up [10:10] i.e. I just did [10:10] cjwatson: thanks [10:10] thanks [10:11] doko: done all those demotions, thanks [10:15] next target is gcc-4.3 demotion ... still to do: gtkmathview linux-ports gcc-4.3 squashfs glibc openjdk-6 [10:16] glibc doesn't matter, we could demote that [10:18] agreed, it's overrated [10:19] looking at eglibc ... [10:21] pitti, hi === freeflyi1g is now known as freeflying [10:23] seb128: could you have a look at gtkmathview? [10:24] Keybuk: in which udev version as /lib/udev/rules.d introduced? is that a packaging thing or upstream? [10:24] hi tkamppeter [10:24] asac: between intrepid and jaunty [10:24] asac: upstream change [10:25] doko: what about it? [10:25] k thanks [10:26] seb128: build with GCC-4.4 (not explicitely with 4.3), see debian #504913. I'd like to demote gcc-4.3 early [10:26] Debian bug 504913 in gtkmathview "FTBFS with GCC 4.4: missing #include" [Unknown,Open] http://bugs.debian.org/504913 [10:26] doko: ok [10:27] now for an openjdk update ... [10:28] pitti, can you have a look at bug 352472? The SpliX package of Jaunty is supposed to upgrade the PPDs of existing queues, but this requires the CUPS daemon to be running. Are there methods to update from Intrepid to Jaunty where the CUPS daemon is not running (like booting a CD into an installer and letting the installer do the update).? [10:28] Launchpad bug 352472 in splix "[Samsung ML-1610] intrepid->jaunty upgrade causes "format not supported" for existing PPDs" [Undecided,New] https://launchpad.net/bugs/352472 [10:28] * apw wonders how debdiff decides where to diff against, which version, i had been assuming it was against the previous version in the change log ... [10:30] apw: debdiff takes two packages as arguments, and diffs between them [10:30] it doesn't decide anything, it just does what it's told :) [10:31] and if you are in a directory and do it without arguments? [10:31] apw: oh, for the moment, a karmic diff should be sufficient; we can then backport it to jaunty once we're agreed [10:31] If no arguments are given, debdiff tries to compare the content of the [10:31] current source directory with the last version of the package. [10:31] oh, huh, I never knew that [10:32] cjwatson, i've actually made both and attached them to the bug, but clearly we should only condifer the jaunty one once you are happy in karmic [10:32] apw: it takes the top two entries from the changelog, apparently [10:32] ahh yes, as you'd hope. i was miss-reading the patch doh [10:32] tkamppeter: ah, splix doens't depend on cups, just on cups-client [10:32] that's a neat little piece of DWIM [10:32] tkamppeter: thus it doesn't enforce that cups is configured and running when splix gets configured [10:32] tkamppeter: thus a mere dependency change might fix that [10:33] pitti, so I simply need to add "cups" to the Depends? [10:33] tkamppeter: and remove cups-client, since the client stuff isn't needed for a driver, right? [10:34] tkamppeter: when I filed the bug I wasn't aware that splix' postinst is already trying to migrate the drivers [10:34] pitti, the client stuff is needed for the post-install script to do the PPD update/ [10:34] tkamppeter: ah, I see [10:42] in packages using cdbs can I have two doc-base.manual files somehow? (one package with both user documentation and developer documentation) the file format of doc-base seems to be limited to one document... [11:06] pitti, I have fixed bug 352472 in Karmic now and prepared an SRU for Jaunty, as it has several duplicates. [11:06] Launchpad bug 352472 in splix "[Samsung ML-1610] intrepid->jaunty upgrade does not upgrade the PPDs of the existing print queues" [Undecided,Fix released] https://launchpad.net/bugs/352472 [11:07] tkamppeter: nice, thank you [11:07] pitti, the SRU is already uploaded, you only need to approve it. [11:38] kirkland: I can't copy screen-profiles from jaunty-proposed to karmic, since karmic already has a newer version; please fix the three SRU bugs in Karmic ASAP === lucas__ is now known as lucas [12:11] map ,br :w:call system("bzr resolve " . bufname("")) [12:11] why did I never think to do this before [12:17] cjwatson: resolve on save? [12:17] the number of times I've resolved with <<<< somewhere else in the file would be a good reason not to ;) [12:19] Out-of-date BUT modified: 906 (5.96%) [12:19] Updated: 1554 (10.22%) [12:19] Ubuntu Specific: 2570 (16.90%) [12:19] * seb128 flushes karmic autosyncs now [12:20] Keybuk: no, just a key sequence to resolve so that I don't have to run 'bzr resolve' separately [12:21] ah [12:22] go seb128, break the world! [12:23] pitti: ;-) [12:23] didn't need the buildds anyway [12:23] * Keybuk tries to gingerly pick his way through lamont's util-linux-ng git madness [12:26] * cjwatson gleefully removes relatime from the installer (yay 2.6.30) [12:26] Keybuk: iz not madness... :p what's the pain? [12:27] that its git ? [12:27] ogra: just like upstream [12:27] lamont: just remembering whether master is based off origin/master or lamont/master - and whether stuff goes in master or ubuntu/master [12:27] bad enough :) [12:27] madness is using something different from upstream, unless upstream is using cvs/svn/other-crap [12:28] indeed [12:28] Keybuk: yeah - I should really rename master -> debian/master [12:28] but master is debian, and ubuntu/master is ubuntu's perma-fork [12:28] lamont: how can it be a fork? we're using the same git branch collection [12:28] if there's a debian directory, it's not $upstream/master :-) [12:29] Keybuk: giggle [12:29] and of course, as part of updating ubuntu/master, I first update master for *you* :p [12:30] Keybuk: and for that, we buy you $beverages in barcelona [12:32] lamont: I just confuse myself because I have first and second level branches in the same repo [12:32] ie. ubuntu/master is based off master, which is based off your master, which is based off karel's master [12:32] but topic/hwclock is based off karel's master [12:33] Keybuk: that just means you suck at naming branches. :-p [12:33] lamont: it doesn't help, of course, that the debian git repo has the ubuntu package in it too [12:33] cause then I could just call your remote "debian" [12:41] lamont: anyway, master has been updated to include a 2.15-rc2 release [12:41] Keybuk: but the debian repo is _my_ tree... so of course it has both... why on earth would I want to separate them? [12:41] that way lies directory-per-branch insanity [12:41] ah, thaks [12:42] I'd been planning to do that this weekend [12:42] You can have multiple remotes in one local repository. [12:44] lamont: well, if you had an ubuntu remote in your tree, you could refer to ubuntu/master ubuntu/stable/v2.14 etc. [12:44] which would be remotely in the ubuntu-published tree as just master stable/v2.14 [12:44] and I could have a debian remote in my tree, and could refer to debian/master debian/stable/v2.14 etc. [12:44] which would be master stable/v2.14 in your tree [12:44] and we could both have an origin remote referring to karel's tree [12:44] it would be less ... mad :p [12:45] then it'd be just /master -> /master -> /master [12:45] meh [12:46] but it wouldn't be /usr/local/src/util-linux/util-linux for all of it... :) [12:46] lamont: ah, but it can be that's the point [12:46] your /usr/local/src can have the remotes all added to it [12:46] and you can fetch at will [12:46] but when you push, you just push the debian bits [12:46] just like I do now [12:47] zinc doesn't republish your bits [12:47] but my local tree here has them all [12:47] man git-remote [12:47] git.debian.org wouldn't be for all of it, sure - but it probably shouldn't be === Guest52556 is now known as Zic [12:52] is there any reason why we need gftp in main? [12:54] git.debian.org is the backup for my tree, at least originally [12:54] seb128: it matches ^g, so it must be main, no? [12:54] lamont: right ;-) [12:54] we could sync it if it was in universe [12:54] the only diff we have is for language packs [12:54] lamont: maybe one way would be to have a git.debian.org pkg/util-linux or something that's just the published bits of the debian tree, rather than the backup of yours? [12:58] lamont: could I persuade you to take http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=commit;h=dc14ed886d5f47375c5dd63ca4552fc5a00ea3e0 and http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=commit;h=4e2c5d41d370392319f824e15191a9c255475e97 in Debian? [12:59] Is there any easy way for tftp server to a) not to care letter capitalisation in filenames or b) have some "translation table" for filenames? [13:00] hmh... 2 channels and I manage to post in wrong one... sorry === yofel_ is now known as yofel [13:11] Keybuk: with out reading them, my gut answer is "for you, sure" [13:12] and reading them, sure [13:12] Keybuk: could you toss me that in email and I'll pick them tonight and upload to debian [13:14] * Keybuk hugs git format-patch [13:39] * Keybuk starts sacrificing random animals to make dpkg-source stop issuing random errors about the diff [13:39] I need a dpkg-source --look-its-from-revision-control-theres-bound-to-be-differences-you-dont-like-lets-just-play-nice-ok [13:57] Keybuk: I'm curious, what kind of diffs? [13:58] i. e. anything that -i doesn't filter out? [13:58] pitti: config.sub in the tarball being a file, but automake putting a symlink there [13:58] .gmo changes [13:58] new binary files (OH NOES!) [13:59] that rather sounds like make distclean being broken, no? [13:59] not really [13:59] auto-* generated files [13:59] for example [13:59] they're going to be different in your working tree because you ran autoreconf/autogen.sh differently to what was in the upstream makefile [14:00] ah [14:00] those really get on my nerves as well [14:00] which is why I previously used cdbs tarball.mk, and now love to use bzr-buildpackage [14:01] so that distclean/autoreconf can be as broken as it wants to [14:01] how does that help? [14:01] at the end of the day, if the stuff in the source tree and in the tarball differ, dpkg-source will throw a wobbly [14:01] I don't use bzr-buildpackage because of that [14:01] Keybuk: you never build from your development tree, it always uses ../build-area/ [14:01] (and because this tree is git ) [14:02] Keybuk: right, of course it doesn't help with debian/ having binary files [14:02] pitti: but that doesn't help you any [14:02] this just protects you from changes which are done during build [14:02] pitti: then you end up with an out-of-date configure in the source package [14:02] because it gets copied from the tarball [14:02] like orig.tar.gz shipping .gmo, and build regenerating them (ugh) [14:02] when it needs to be updating [14:02] or calling autoreconf during build [14:03] Keybuk: yeah, one of my favourite reasons to hate autotools :) [14:03] anyway, let's not warm up this [14:03] Keybuk: my personal practical solution is debian/patches/99autoreconf.patch [14:04] it's evil and ugly, but the most stable hack that I found [14:04] autoreconf patches and autoreconf-in-rules both suck [14:04] the common suck factor being autofoo, of course ;) [14:04] pitti: debian/patches in revision control ARGH [14:04] directhex: the former has huge and hard to maintain patches, the latter breaks every other build, so I prefer the former [14:04] pitti: they're already fixed in karmic ;-) [14:04] kirkland: ah, please close the bugs then (apparently the changelog didn't) [14:05] the whole *point* of packaging in revision control is that I can go [14:05] autoreconf [14:05] bzr commit -m "autoreconf" [14:05] ?? [14:05] you certainly don't want to maintain generated files in bzr? [14:05] like configure or Makefile.in? [14:05] pitti: they're in the tarball [14:05] so they get put into the bzr imports [14:05] anyway, if you do, bzr will get along [14:05] autom4te.cache! [14:06] I've argued about this non-stop [14:06] and even filed bugs on bzr suggesting how to make it work [14:06] but to no avail [14:06] Keybuk: so, about that particular point I don't have an idea either; it's a hard to solve combination of dpkg source format limitations and autoconf being a tramp [14:06] * directhex prepares more of karmic's mono stack [14:06] pitti: I will admit to, once, making the diff.gz myself and uploading it [14:06] heh [14:07] * pitti pats Keybuk and sheds a tear with him [14:07] bzr tag --build FTW! [14:07] pitti: done! [14:07] Keybuk: NoMoreSourcePackages FTW! [14:07] Keybuk: (I guess you meant the same) === emgent_ is now known as emgent [14:08] pitti: right [14:08] Keybuk: I think notify-osd and apport are in a similar situation [14:08] Keybuk: I keep the full source in bzr, and use bzr-bd's merge mode to blend in the orig.tar.gz [14:09] and of course as soon as I add an icon to the ubuntu branch, it falls over [14:09] (should be pretty much the same problem, AFAIUI) [14:10] yeah [14:10] I'm surprised any of this works, tbh :p [14:10] I have packages entirely maintained in git (upstream, debian and ubuntu) [14:11] packages where the upstream is in git, and I patch in git, but then import to bzr to add the debian/ directory [14:11] packages where the upstream is in bzr, and the packaging added (without tarball files) [14:11] that one's Debian packaging is, ironically, in git === LucidFox is now known as lucidfox [14:19] Keybuk: FYI, I uploaded new g-p-m with dk-power support an hour ago [14:19] MIRs are filed [14:19] * pitti goes to package dk-disks now, yay new crack === lucidfox is now known as LucidFox [14:38] Riddell: could we get a transitional kubuntu-kde4-desktop package (for #368459) [14:48] Riddell: hm, nevermind, I think I found a better solution [15:07] Keybuk: roll on the v3 source package format [15:08] Keybuk: at which point the delta to upstream is in a .tar.gz not a .diff.gz and all those annoying restrictions stop being a problem [15:08] cjwatson: I'd settle for no source packages at all [15:08] (entirely independent of all the auto-quilt stuff in v3 which I haven't quite got my head around yet) [15:08] I do think we need source packages if only as an export format. I wouldn't mind not working with them day-to-day [15:09] what do we need an export format for? :) [15:09] it'd piss me off if I had to use some other distribution's magic tools to find out what was in their source [15:09] so I'd rather not do that to other people [15:09] you already do, no? [15:09] anyway, it won't be a big deal once the v3 format is in place [15:09] Debian you need to know how to extract tarballs, diffs and which file to chmod [15:10] RedHat-a-like you need to turn the src.rpm into a cpio and extract it (or install rpm) [15:10] sure, but there's a document that tells you how to do it for Debian-based systems if you don't have the tools [15:10] and it's pretty damn trivial [15:10] .src.rpm is more of a hassle I agree (and that annoys me) [15:10] you could document "bzr checkout"/"git checkout" quite trivially [15:10] put it this way: I don't see a need to oppose source packages once they're not a burden [15:11] the burden is in terms of working with them as part of the development processes, not in terms of exporting them to users [15:12] I'm all for making our development processes (incrementally) easier [15:12] if I may comment for anything/nothing, I kinda like the gentoo way of "compile everything" way :) [15:13] that's rather unrelated to this discussion ... [15:13] Keybuk: dk-disks currently installs http://people.ubuntu.com/~pitti/tmp/95-devkit-disks.rules [15:13] Keybuk: it currently duplicates the by-{uuid,label,id} stuff from 60-persistent-storage.rules [15:13] I know that too :) Just had an unresistable urge to say it =) [15:13] Keybuk: do you happen to have heard about a discussion where these rules should live? [15:14] Keybuk: I'm inclined to patch dk-disks' ones to remove them [15:14] olmari: FWIW, we compile everything as well, but just once, not 10 million times :) [15:14] you're entirely welcome to compile Ubuntu for yourself too [15:14] olmari: (SCNR, too) [15:15] pitti: Well, what I like most is compile selectores, or WTF they was called as... And that compilation is optimised for any one CPU/system at the time at hand [15:16] pitti: I'm not aware of those, I'll ask davidz [15:16] pitti: but I also like ubuntus "easyness" [15:16] Keybuk: they seem useful outside of dk-disks, so from my POV it makes sense to have them in udev, but I don't have a strong opinion about it [15:16] pitti: in other areas than installation I mean [15:17] pitti: in reality there rarely is noticeable diffirence between "common" binary and optimised compile, but I kinda thriwe to be best all the time :D [15:18] pitti: and for the record, I do use Ubuntu on mine comp =) [15:21] best possible thing would be that compilation process would go unnoticeable from users point of view, as in normal apt-get does, and able to see the process would shown only if wanted to etcetc :) [15:22] But maybe this is end of the discussion... I really don't mean to be insult around here :) [15:22] it's not insulting, it's just a very very old discussion that we have long since taken a clear decision on [15:22] hehe, well I didn't know that :) [15:23] also this was just at-the-moment mindstorm [15:23] a big advantage of having the source in bzr on LP is that you have an easy web interface to browse files ... src packages need to be downloaded, unpacked etc to inspect them [15:24] sometimes that annoys me if i only want to look at a single file [15:24] then again anyone can get the source and do compile it as wanted =) [15:24] Gentoo was around when Ubuntu was created and we were aware of it. We simply felt that that approach would not meet our goals. [15:25] cjwatson: I do know what you mean actually :) [15:26] besides, ubuntu can't be that bad if I'm using it too :D [15:29] (and sorry again if this was against channel rules) :) [15:29] kirkland, StevenK, jdstrand, james_w: (looking at karmic/NEW) just making sure, that you know about new-binary-debian-universe? [15:30] pitti: I've seen it on the wiki page, haven't had an opportunity to use it yet [15:30] james_w: right, I just want to make sure that you guys don't waste hours on reviewing those manually [15:30] no chance :-) [15:30] thanks [15:31] that should help focussing on the real new Ubuntu packages like devicekit-disks (hint, hint) :) [15:32] pitti: thanks for the tip! Like james_w, I'd seen it in the wiki, but nothing else [15:33] also, during those archive days you should run sync-source -a every now and then [15:33] and also new-source [15:34] oh, new-source, I forgot that [15:34] doing now [15:35] urg [15:35] $ new-source | wc -l [15:35] 500 [15:35] cjwatson: BTW, no one have yet answered that apt bug we talked awhile back... I wan't to help on the issue like by doing installation again on this computer, assuming it still sould happend yet again as it did happend consistently few days ago... but I'd like to do it before too much stuff on this comp as I don't have any else computer to use as per "spare" [15:35] seb128: ! [15:36] pitti: indeed [15:36] cjwatson: I know the bug isn't a responsibility... just agai nwanted t oinform the situation [15:37] pitti: how much reviewing do you usually do to this list? ;-) [15:37] seb128: none, except well-formedness :) [15:37] ok, let's sync then ;-) [15:37] * pitti hears the buildds squeak [15:38] seb128: please do keep the list, though, and source-new them in bulk [15:38] pitti: right [15:38] seb128: gosh, three gazillion new perl modules [15:39] seb128: list looks quite sane to me [15:40] pitti: to me too, syncing it now [15:40] seb128: while you are at it, sync-source -a also works with -C contrib and non-free [15:40] pitti: right [15:41] but that's rather not urgent [15:41] pitti: for how long will we keep the buildds busy do you reckon? ;-) [15:41] the next couple of dist-upgrades will be a hell :) [15:41] seb128: dunno, maybe two or three weeks [15:42] * pitti blows off the dust from his rescore-sru script [16:07] mvo: could you look at olmari's apt bug? [16:11] cjwatson: sure [16:13] mvo: (it's the same hang we've seen before, but he can reproduce it every time) [16:13] cjwatson: ohhh, I missed that, that sounds perfect, finally a good lead on the issue [16:15] that's what I thought :) === beuno_ is now known as beuno [16:29] pitti: ok, new sources synced and waved through source NEW [16:36] pitti: interesting, that's a new one to me === beuno_ is now known as beuno [17:35] Keybuk: is it a known issue on _hardy_ that udevadm info with --path=/sys/class/... gives "no database record ..." (or something similar) while --name= would work fine? ... === Amaranth_ is now known as Amaranth [17:45] asac: udev always does that if there's nothing in the database [17:46] Keybuk: so in this case --path=/sys/class/tty/ttyACM0 failed like that, but --name=ttyACM0 gave valid entries [17:47] doko: I'm just going to minimize the diff from Debian in python-support to the supported versions and we can see how that works out. [18:03] * ScottK now notes slangasek beat him to it. === rbelem is now known as rbelem-lunch [19:07] kirkland: where have you reported "screen" patches? is there an active tracker for them? [19:08] * ScottK notes https://lists.dns-oarc.net/pipermail/dns-operations/2009-March/003710.html at lamont and wonders if we care about DNSSEC stuff stop working in BIND in 3 days? (I don't understand DNSSEC well enough yet to know) [19:15] cjwatson: I didn't have any UTF-8 sync requests the other day when you were asking, but I've had two today and used your fix (which works). Thank you. === janito_ is now known as joaopinto [19:32] kees: yes there is! [19:32] kees: let me grab it [19:32] kirkland: cool; I have a patch I'd like to put in so the shared-session beeping stops :) [19:32] kees: were you hearing beeping? [19:32] kees: i had that turned off, i thought [19:32] tkamppeter: is cups-pdf still used/useful? [19:33] kirkland: anyone else attached who typed at the window would generate a bell for each letter typed. [19:33] /* XXX FIXME only display !*/ [19:33] WBell(fore, visual_bell); [19:33] :) [19:33] so I switched it to a Msg() as is done for the ACL'd commands [19:34] kees: here's one i pushed upstream: http://savannah.gnu.org/bugs/?22146 [19:35] kees: very nice [19:35] kees: actually, it looks like someone opened that one on my behalf :-) [19:35] kees: commit that puppy to karmic, and push it upstream :-) [19:36] kees: and i'll add it to the screen-profiles ppa as well, where I've collected a few useful backport screen patches [19:41] kirkland: https://savannah.gnu.org/bugs/index.php?26401 === Snova_ is now known as Snova [19:59] kenvandine_wk: just read your message indicator talk! (was good btw!) had a question but couldn't make it there... [20:00] is there any way to get a notifcation to stay on screen longer? sometimes the time out is just a bit too short to read a tweet! [20:01] (or perhaps have the timeout scale when the message is longer?) and I hope this isn't an inappropriate place to ask.. too many ubuntu channels! lol === Riddelll is now known as mariamne [20:02] RyanK: #ayatana is probably a better channel. [20:03] ScottK: thanks for the heads up... will head in there [20:04] cjwatson: hm, does karmic's dch work properly for you? it acts strangely in multiple different ways for me === azeem_ is now known as azeem [20:18] ScottK: fixed in 9.5.1.dfsg.P2-1, if that helps... [20:19] lamont: It does. Thanks. [20:20] not particularly interested in trying to backport the fix, though... pretty sure my my git tree has the 9.4.3-P2 bits in it as well. [20:20] though that's still a fix-rev update+2 patches from hardy bits [20:28] hm. i hope the desktop-karmic-default-media-player-choice session doesn't suffer from too many protests === racarr_ is now known as racarr [20:40] directhex: it'll be fine [20:42] jcastro, i recognise a name on the subscribers list on the blueprint. i don't question that it'll be fine, but i doubt they're there to lend any positive sentiments [20:44] jcastro, we'll see how it goes. if it's calm & peaceful, i owe you a beer. if there's disruption, you owe me a beer. deal? :p [20:45] heh [20:45] * mterry will cause a disruption for half of directhex's spoils [20:47] is there a blueprint for said "default media player choice session" ? [20:47] LordKow, https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice [20:50] directhex: so the idea is to switch rhythmbox-> banshee ? yea that will cause a lot of commotion [20:51] i've actually never touched banshee before but from the website it does not look to shabby, very similar to rhythmbox and if it saves space... goodie. [20:53] the quick search is lacking in banshee, however :( [20:54] unless it breaks a license agreement, should be able to package rhythmbox differently such that docs, helpfiles, etc are a separate package [20:56] LordKow, gotta have docs though. that's a bonus for RB right now [20:56] well, the whole idea behind that blueprint is to save space for the isos right? [21:07] LordKow, sure. but iso's gotta be useful without internet, so gotta have a manual [21:32] <__iron> hi buddies [21:34] <__iron> any git pro is avaible ? [21:34]