| RAOF | achiang: Pong | 00:07 |
|---|---|---|
| jturek_ | whoohoo thanks for fixing emacs gtk in maverick guys :) | 00:58 |
| RAOF | Well, not so much fixed as had the GTK patch that was breaking it dropped. | 01:00 |
| jturek_ | ahh | 01:00 |
| jturek_ | (catching up on the launchpad bug report now) | 01:00 |
| ajmitch | by breaking it, you mean the spam on the console? | 01:00 |
| jturek_ | ajmitch, lp bug 585196 | 01:01 |
| ubottu | Launchpad bug 585196 in emacs23 (Ubuntu Maverick) "emacs fails to start: X protocol error" [Undecided,Confirmed] https://launchpad.net/bugs/585196 | 01:01 |
| RAOF | No, the BadMatch error as soon as emacs tried to display a window. | 01:01 |
| ajmitch | ah, shame | 01:01 |
| jturek_ | not admitting i am an emacs addict or anything ;) | 01:01 |
| RAOF | The spam on the console is a theme issue. | 01:01 |
| RAOF | At least, I think it is. | 01:02 |
| ajmitch | bug 538499 is the one I was thinking of | 01:02 |
| ubottu | Launchpad bug 538499 in light-themes (Ubuntu) "warning spam on stdout: CRITICAL **: murrine_style_draw_box_gap: assertion `height >= -1' failed" [Medium,Triaged] https://launchpad.net/bugs/538499 | 01:02 |
| jturek_ | thanks ubottu ;) | 01:02 |
| m3ga | err, where is Xorg.conf in lucid? | 01:38 |
| m3ga | it should be /etc/X11/xorg.conf shouldn't it? | 01:39 |
| lifeless | /etc/X11/xorg.conf | 01:39 |
| === funkyHat is now known as funkyWhat | ||
| RAOF | If you've got one; you probably don't. | 01:40 |
| m3ga | lifeless: yea, thats what i expectedi don't | 01:41 |
| m3ga | RAOF: no it don't | 01:41 |
| m3ga | should i have? | 01:41 |
| RAOF | No. | 01:41 |
| lifeless | no | 01:41 |
| m3ga | ok, so how do i bash xorg round the head to use my mouse device? | 01:42 |
| RAOF | You can create an xorg.conf and add just a Device section. I still think that if the kernel isn't presenting it as an input device you're likely to be out of luck. | 01:42 |
| m3ga | kernel finds this : input: AVAGO TECHNOLOGIES AVAGO USB OFN Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input4 | 01:43 |
| m3ga | generic-usb 0003:192F:0000.0001: input,hiddev96,hidraw0: USB HID v1.01 Mouse [AVAGO TECHNOLOGIES AVAGO USB OFN Device] on usb-0000:00:1a.1-1/input0 | 01:44 |
| === funkyWhat is now known as funkyHat | ||
| === freeflyi1g is now known as freeflying | ||
| === Amaranth_ is now known as Amaranth | ||
| === sconklin-gone is now known as sconklin | ||
| === jdong_ is now known as jdong | ||
| === 5EXAAYM9J is now known as temugen | ||
| === sconklin is now known as sconklin-gone | ||
| nigelb | jcastro: a bit too late, but I haven't logged into this session for a while | 05:18 |
| nigelb | Don't unsubscribe reviewers team after a review is done, it helps for statistical purposes | 05:19 |
| dholbach | good morning | 07:52 |
| === hrw|gone is now known as hrw | ||
| === almaisan-away is now known as al-maisan | ||
| pitti | Good morning | 08:28 |
| ddecator | morning pitti | 08:28 |
| pitti | hello ddecator | 08:29 |
| * pitti finsihes a new-binary-debian-universe run to clean up NEW somewhat | 08:52 | |
| pitti | seb128: d-conf NEWed as well, in case you are waiting for it | 08:59 |
| pitti | and the new kernel | 08:59 |
| seb128 | pitti, oh, thanks | 09:01 |
| seb128 | pitti, I newed it but it was only built on amd64 the other day when I did I think | 09:01 |
| ricotz | pitti, hello, i want to ask about the pending docky sru in lucid-proposed | 09:09 |
| ricotz | https://bugs.edge.launchpad.net/docky/+bug/574003 | 09:10 |
| ubottu | Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed] | 09:10 |
| pitti | ricotz: it fixes 19 bugs, but none got any feedback so far | 09:10 |
| pitti | ugh, who accepted that? | 09:11 |
| ricotz | pitti, there are feedbacks on the bug reports itself | 09:11 |
| pitti | Riddell: did you accept docky into lucid-proposed? | 09:11 |
| pitti | none of them have ubuntu tasks, or are set up for SRU | 09:11 |
| pitti | ricotz: I opened a sample of 4 bugs, and none of them have an "please test the SRU" question or even a SRU request | 09:12 |
| pitti | and feedback about the lucid-proposed version | 09:12 |
| ricotz | https://bugs.edge.launchpad.net/docky/+bug/555562/comments/16 | 09:13 |
| ubottu | Launchpad bug 555562 in docky (Ubuntu Lucid) "crash accessing Gnome keyring in Lucid" [Critical,Triaged] | 09:13 |
| pitti | ricotz: ok, I marked that one as verified; 1 down, 18 to go.. | 09:14 |
| pitti | well, we probably don't need all 18, but for an update as big as this we need much more than "1" | 09:14 |
| ricotz | pitti, like i wrote in my comment on the sru bug, it is impossible to get all reports | 09:14 |
| ricotz | i have linked some comments here https://bugs.edge.launchpad.net/docky/+bug/574003/comments/9 | 09:15 |
| ubottu | Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed] | 09:15 |
| pitti | but at least the bugs should have ubuntu tasks, tell the maverick status, and ask people to check the lucid-proposed version | 09:15 |
| pitti | ricotz: ok, I'll mark those as verified | 09:16 |
| Laney | I don't know who set it up for an SRU, but when I did the previous version I made sure to open all Lucid tasks | 09:16 |
| pitti | except that they didn't actually test the ubuntu package | 09:17 |
| pitti | since by that time it wasn't even in the package | 09:17 |
| pitti | ricotz: ^ | 09:17 |
| pitti | folks apparently tried some vcs head snapshot or so? | 09:17 |
| ricotz | pitti, yes, like i wrote in my comment, we backport commits to the stable branch, if there are regressions they should prevent the inclusion while there are so many bugs fixed | 09:19 |
| ricotz | docky 2.0.2 is from the current view very broken and is not able to please peoples needs in some ways therefore they perhaps stop using it | 09:20 |
| pitti | that's why we usually ask for testing the proposed package in all the bugs | 09:21 |
| pitti | which will reach the bug reporters | 09:21 |
| pitti | I can do that with a script | 09:22 |
| pitti | but it should never have been accepted this way in the first place | 09:22 |
| ricotz | yes, but in this case most of the reporters would have switched to the ppa in the meantime | 09:22 |
| pitti | so they could switch back.. | 09:23 |
| ricotz | this is unlikely cause there were major packaging changes and new dependencies for upcoming 2.1.0 | 09:24 |
| ricotz | i understand your point to verify these bugfixes, but it also hard for us to get confirmation for more recently reported bugs | 09:25 |
| pitti | ricotz: hm, the changelog doesn't even mention bug 574003 | 09:25 |
| ubottu | Launchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed] https://launchpad.net/bugs/574003 | 09:25 |
| pitti | ricotz: oh, I'm not primarily blaming you; it's just that the current state of this SRU is so poor (how it was accepted and the bugs prepared) that it will have a very low chance of being tested | 09:26 |
| pitti | ricotz: ok, I'm sending out calls for testing to the bugs | 09:27 |
| ricotz | this bug should be in the changlog for 2.0.3 | 09:27 |
| Laney | it wasn't uploaded with -v | 09:28 |
| pitti | so it should be fixed in maverick | 09:28 |
| pitti | (there are no ubuntu tasks to keep track of the state) | 09:29 |
| pitti | so, let's see whether we'll get some responses | 09:29 |
| ricotz | yes | 09:29 |
| pitti | ricotz: I also subscribed ubuntu-sru to all the bugs | 09:29 |
| ricotz | pitti, thank you | 09:29 |
| pitti | but whoever accepted this, please don't in the future; it's causing a lot of extra work | 09:29 |
| ricotz | pitti, on the other hand, it is a bit unpleasant for upstream devs who do spend a lot of work to maintaining a stable release besides a development branch, it seems hard to get an sru for an application like docky which has no rdeps | 09:33 |
| pitti | ricotz: no, not really; it just takes some care to prepare the bugs accordingly (not necessarily by you) | 09:33 |
| ricotz | perhaps packages could be categorized to make a sru easier for universe one? | 09:33 |
| pitti | ricotz: the actual changes seem quite appropriate for an SRU | 09:33 |
| pitti | it's just that due to the way the SRU was handled, we would not get any feedback | 09:34 |
| pitti | and the SRU team didn't even know about this, since they weren't subscribed to any of those | 09:34 |
| pitti | we put new upstream microversions into LTSes all the time | 09:35 |
| ricotz | ok, but a least this one bug was subscribed to the sru team, alright | 09:35 |
| ricotz | pitti, i am trying to push this a bit, cause i am planning to release docky 2.0.5 very soon | 09:36 |
| pitti | ricotz: once we get a handful of testing on the proposed package, we can move it | 09:37 |
| ricotz | pitti, thank you, i hope the will be some responses soon | 09:38 |
| apw | with the new debian 3.0 formats available do we have a feeling on whether we are keen for existing packages to migrate to it or not ? | 09:42 |
| pitti | there's no particular hurry, I think | 09:43 |
| apw | pitti, is it recommended? | 09:43 |
| pitti | we should certainly start doing new packages that way | 09:43 |
| pitti | and once we touch a package anyway, and you feel like it, you can as well do it | 09:43 |
| pitti | but I wouldn't touch packages just for that | 09:44 |
| apw | pitti, thinking about the kernel where we are obviously touching them most of the time | 09:44 |
| pitti | apw: that sounds rather easy, given that you don't actually use orig.tar.gz's and patches for that, right? | 09:44 |
| apw | pitti, we do use origin.tar.gz's against the upstream version yes once released of course | 09:45 |
| pitti | ah | 09:45 |
| apw | i have prototyped it with the 3.0 (quilt) format which looks to work but trying to work out where it is available | 09:45 |
| pitti | apw: but then you'd need to do proper patches instead of changing inline, which is what you tried to avoid, I thought? | 09:45 |
| apw | pitti, seems that in that mode any diff from the tarball to 'here' is turned into an automatic patch for you | 09:46 |
| apw | so i think it works fine for us | 09:46 |
| pitti | ? | 09:46 |
| pitti | apw: it's the other way around | 09:46 |
| pitti | apw: debian/patches/* is automatically applied to the source on unpack | 09:46 |
| pitti | all inline modifications to the upstream source are _ignored_ when building the source package | 09:47 |
| pitti | you only have a debian.tar.gz | 09:47 |
| apw | right ... but on dbuild -S if you have an orig then it diffs everything but debian and makes a patch out of those and puts it in debian/patches, then it makes the debian tarball | 09:47 |
| pitti | apw: oh, I didn't know that | 09:47 |
| pitti | how do you do that? | 09:48 |
| apw | it just happens automatically | 09:48 |
| pitti | ah, I see | 09:49 |
| apw | as far as i can tell it applied the patches in debian/patches, then diffs the result, and adds a new patch ... something like that | 09:49 |
| pitti | I actually don't like that at all, but seems to be that way | 09:49 |
| pitti | seems you'd still get weird patches with spurious config.guess stuff etc. that way | 09:50 |
| apw | pitti, yeah seems so ... as far as i can see the only real advantage is you get stuff in debian as you intended, zero length files and permission maintained | 09:50 |
| pitti | so it still doesn't obsolete the need for separate build-tree/ | 09:51 |
| apw | pitti, no i think not | 09:51 |
| apw | pitti, actually it does say 'upstream paths' are diffed | 09:52 |
| apw | so perhaps its only the ones in the tarball not new files | 09:52 |
| apw | no that wouldn't work either | 09:52 |
| pitti | no, I guess it'll do the whole thing | 09:52 |
| pitti | with {bzr,git}-buildpackage you avoid this random clutter, so I stopped worrying about it long ago | 09:53 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === aronxu is now known as happyaron | ||
| cjwatson | apw: yeah, I don't know how useful 3.0 (quilt) is for you, unless you write something that automatically serialises the git tree into a set of quilt patches | 11:53 |
| cjwatson | which might be an interesting and useful project, but doesn't seem terribly urgent :) | 11:53 |
| cjwatson | (I think somebody may have been working on something like that for git-buildpackage, not sure) | 11:54 |
| apw | cjwatson, in its basic form it seems usable as a replacement for orig/diff format in a similar way ... with the advantage that debian/* is correclty maintained permissions etc wise ... not sure if that enough of a reason to switch tho. | 11:55 |
| cjwatson | apw: I don't think there's a great deal of point in using 3.0 (quilt) in the mode where you just have it automatically spit out a single patch | 11:55 |
| cjwatson | permissions and binaries and the like are I suppose mildly useful | 11:55 |
| apw | no unless 1.0 is going to go away | 11:55 |
| cjwatson | it's not | 11:55 |
| cjwatson | you might want to declare 1.0 in debian/source/format if you're going to stick with it though | 11:55 |
| apw | yeah at least the archive knows i chose that way | 11:56 |
| cjwatson | don't get me wrong, I think 3.0 (quilt) is fantastic and I use it for all my packages, but I think that's more the case if you actually use it for maintenance work rather than just have the package spat out that way automatically | 11:56 |
| cjwatson | well, all my packages that aren't 3.0 (native) anyway :-) | 11:57 |
| apw | yeah i can see that, if there is no advantage to switching to that mode for the archive, i suspect there is little for us | 11:57 |
| cjwatson | http://upsilon.cc/~zack/stuff/dpkg-v3/ <- graph of 3.0 format adoption in Debian | 11:58 |
| === MacSlow is now known as MacSlow|lunch | ||
| apw | cjwatson, do you have any idea why one has to specific (native)/(quilt) given older formats could work it out ... just seems to make life difficult | 12:20 |
| cjwatson | apw: it was actually often a problem that the older formats worked it out; it was quite common for people to upload native packages by accident when they'd actually just misnamed the .orig.tar.gz | 12:21 |
| cjwatson | the vast majority of packages don't intend to switch back and forward between native and non-native | 12:21 |
| apw | fair indeed | 12:22 |
| buxy | pitti: clean is supposed to remove clutter so that they don't end up in automatic patches, and now you can also stick supplementary files to ignore in debian/source/options with --extend-diff-ignore | 12:48 |
| pitti | buxy: ah, --extend-diff-ignore sounds nice | 12:48 |
| pitti | buxy: right, but some packages do really nasty stuff like updating config.guess in the clean target | 12:49 |
| pitti | unfortunately this used to be in the dh-make template | 12:49 |
| pitti | but well, I disgress.. | 12:49 |
| buxy | I know, recommendations have changed over time but many are still polluting the diff due to that | 12:50 |
| seb128 | you often have no easy way to clean | 12:50 |
| seb128 | like if you run autoreconf at build time | 12:50 |
| pitti | for those, bzr bd or git-buildpackage just DTRT | 12:51 |
| buxy | seb128: there's dh-autoreconf (for dh7/cdbs) but I'm not sure I like it | 12:52 |
| buxy | (i.e. it's somewhat overkill for the purpose) | 12:52 |
| pitti | does anyone see what I'm doing wrong here? apt-get source -o DPkg::options::="--require-valid-signature" pmount -> --require-valid-signature is never passed to dpkg-source | 12:53 |
| buxy | pitti: I think Dpkg::options:: is only for "dpkg" not dpkg-source | 12:53 |
| pitti | ah | 12:53 |
| soren | pitti: You can tweak Dir::Bin::dpkg-source instead. | 13:05 |
| soren | pitti: change it to "dpkg-source --require-valid-signature" and you should be fine. | 13:05 |
| pitti | soren: to point to a locally modified dpkg-source | 13:05 |
| pitti | ? | 13:05 |
| pitti | soren: ah, nice | 13:05 |
| soren | pitti: No, just pass the extra arguments. | 13:05 |
| soren | It's concatenated with "-x blah.dsc" and passed to system. | 13:05 |
| soren | system(3), that is. | 13:06 |
| === MacSlow|lunch is now known as MacSlow | ||
| === zyga is now known as zyga_away | ||
| apw | pitti, did i ask you about the apparent leakage of red and green out of the top of our bars on the burn-down charts for A2 ? | 13:50 |
| pitti | apw: you didn't | 14:14 |
| pitti | indeed, looks weird | 14:14 |
| pitti | apw: perhaps it's related to the bug I'm currently chasing | 14:14 |
| pitti | I've been getting tons of ZeroDivisionError exceptions from cron | 14:14 |
| pitti | but whenever ran the damn thing by hand it of course worked | 14:14 |
| pitti | so I added some extra debugging, but never got a cron mail since then :-/ | 14:15 |
| apw | hrm, thats a bit mad, does it fail if you run it via at ? | 14:15 |
| pitti | it started perhaps a week ago, so something in the data must have changed | 14:15 |
| pitti | apw: haven't tried | 14:15 |
| pitti | the other reports (a3, entire cycle) seem to look just fine | 14:16 |
| pitti | so it seems that's the one which might upset it | 14:16 |
| apw | pitti, fyi its the same in firefox and chromium so i assume its real | 14:16 |
| pitti | yes, I don't think it's an svg problem; it's somewhere in pychart | 14:17 |
| pitti | apw: I'll keep that on my radar; I take it it's not OMGblocking you? | 14:17 |
| apw | no not at all, its just an oddity | 14:17 |
| apw | pitti, one which seems familiar ... i have the feeling its been about before and gone away | 14:18 |
| pitti | apw: also, it looks alright again from June 14 on, which could be about the time when I added the debugging stuff | 14:19 |
| apw | pitti, somewhat peculiarly it seems to have sorted itself in the last 4 days results | 14:19 |
| apw | but arn't the whole report rebuilt each time | 14:19 |
| pitti | yes, it is | 14:20 |
| pitti | I removed the debugging stuff again | 14:20 |
| apw | so it must still be in the old data somehow ... hrm | 14:20 |
| pitti | let's see whether it fails again next time | 14:20 |
| apw | so one assumes the issue is collector side not reporter perhaps | 14:20 |
| pitti | apw: or if the chart data has a particular shape, like bunny ears for example | 14:22 |
| === sconklin-gone is now known as sconklin | ||
| === njpatel_ is now known as njpatel | ||
| === aronxu is now known as happyaron | ||
| apw | can anyone point me to the i686/cmov discussion so i can confirm we are in line with it | 15:26 |
| apw | cjwatson, ^^ | 15:30 |
| cjwatson | apw: foundations-m-686-compile, but it's waiting for doko to write it up | 15:32 |
| apw | cjwatson, ahh yes thanks ... so we shouldn't be reacting kernel wise as yet then | 15:33 |
| cjwatson | there's probably an audio file of the UDS session if you're desperate :-) | 15:33 |
| apw | cjwatson, heh no not desperate, just wondering if we should be doing somethign for maverick. but seening as there isn't even a uds write up for it, i suspect doing anything is pre-emptive | 15:34 |
| apw | cjwatson, there don't seem to be any work-items on that spec which is concerning given it implies a rebuild does it not? | 15:38 |
| cjwatson | apw: we're not going to rebuild everything just for that, no | 15:42 |
| doko | cjwatson: yes, still to write :-/ | 15:42 |
| zul | can someone from the foundations team review the upstart job: https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/574554 | 15:45 |
| ubottu | Launchpad bug 574554 in tgt (Ubuntu Maverick) "tgtd needs init script or upstart job" [Medium,Triaged] | 15:45 |
| apw | doko, was a definative decision made? there seems to be some feedback requests on there ... | 15:46 |
| doko | apw: about what? | 15:48 |
| apw | doko, about which options we were going to require for that blueprint | 15:49 |
| doko | apw: "options to require?" | 15:50 |
| apw | doko, did we determine the minimum required cpu features we would support going forward, under the auspecis of the blueprint: foundations-m-686-compil | 15:52 |
| === bladernr is now known as bladernr-afk | ||
| doko | apw: yes, i686. but I didn't look at the nop problem yet, if it's just a glibc local thing, or if this is seen generally) | 15:55 |
| smoser | Riddell, "ebsmount upload of the day" is ready. i ran 'licensecheck' this time. sorry for not having done that before. | 16:12 |
| Riddell | smoser: upstream did another new release? | 16:13 |
| smoser | well, sort of. | 16:15 |
| smoser | those files didn't come from upstream, but from another turnkey project. they ammended the turnkey-pylib files (which i had copied)... i mentione dthis in a mail yesterday. those files were written by debian/patches. | 16:15 |
| smoser | Riddell, ^ | 16:18 |
| Riddell | smoser: and that turnkey-pylib project has files which say they're GPL and not "all rights reserved"? | 16:19 |
| smoser | correct. the patch references the git repo and commit level | 16:20 |
| smoser | http://github.com/turnkeylinux/turnkey-pylib/tree/master/pylib/ | 16:20 |
| Riddell | smoser: lovely, accepting | 16:21 |
| smoser | thanks for your time Riddell | 16:23 |
| === bladernr-afk is now known as bladernr | ||
| === bladernr is now known as bladernr_ | ||
| kirkland | pitti: ping | 16:56 |
| pitti | hey kirkland, how are you? | 16:56 |
| kirkland | pitti: not bad :-) | 16:57 |
| kirkland | pitti: who's handling SRUs in your place now? | 16:57 |
| kirkland | pitti: i wanted to see about getting https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=qemu-kvm accepted to lucid-proposed | 16:57 |
| pitti | kirkland: it's in between cjwatson, slangasek, and me | 16:57 |
| pitti | jdong and ScottK help out as well | 16:58 |
| ScottK | (all I can do is hit the accept button on stuff jdong has approved) | 16:58 |
| kirkland | pitti: cool, thanks | 16:58 |
| jdong | *looks* | 17:00 |
| jdong | ACKed :) | 17:02 |
| ogasawara | doko: do you have an ETA for when you'll have the foundations-m-686-compile spec written up. I'm the one with the Alpha2 work item assigned and if something needs to get into the Alpha2 kernel it needs to happen by mid next week. | 17:03 |
| doko | ogasawara: ok, will try to do it today | 17:04 |
| ogasawara | doko: thanks | 17:04 |
| doko | ogasawara: I thought you already did drop the i386 variant | 17:04 |
| ogasawara | doko: we did | 17:04 |
| pitti | mr_pouit: same question for exo; it can use gio as well now, so I'd drop the build/binary hal depends | 17:09 |
| pitti | mr_pouit: I have both exo and thunar prepared now, and working great | 17:09 |
| === beuno is now known as beuno-lunch | ||
| === awolfson is now known as awolfson_lunch | ||
| === MacSlow is now known as MacSlow|capoeira | ||
| ScottK | kirkland: Accepted. | 17:21 |
| pitti | mr_pouit: I'm also uploading three packages to build against exo-1 instead of the exo-0.3, to avoid two ABIs; hope you don't mind? | 17:27 |
| mr_pouit | pitti: exo-1 isn't stable either... | 17:28 |
| pitti | mr_pouit: ah, so you prefer stuff to be built against -0.3 for now? | 17:29 |
| mr_pouit | thunar(-gio) isn't ready at all | 17:29 |
| mr_pouit | it can't remember file associations for example | 17:29 |
| mr_pouit | and no volume auotmounting | 17:29 |
| pitti | mr_pouit: I'm currently working on an automounting solution, FYI | 17:29 |
| mr_pouit | you should tell that to upstream then :) | 17:30 |
| pitti | mr_pouit: but ok; I'll delete the xfce4-terminal transition from the xubuntu-dev PPA again, sorry about that then | 17:30 |
| mr_pouit | ah in, the ppa ? | 17:30 |
| mr_pouit | fine then | 17:30 |
| mr_pouit | I thought in was for the archive | 17:30 |
| mr_pouit | *it | 17:30 |
| pitti | nah, xubuntu-dev PPA | 17:30 |
| pitti | which has the new exo | 17:30 |
| mr_pouit | yeah, so no problem | 17:30 |
| pitti | mr_pouit: I have xfce4-{settings,terminal} for exo-1 (simple patch) | 17:31 |
| mr_pouit | xfce 4.8 will probably get delayed of several months, that's why I was a bit nervous if you wanted to upload that to maverick ;> | 17:31 |
| pitti | mr_pouit: I could do it for our own project only, but from our POV it'd make more sense to work in the xubuntu-dev PPA and all work on the same stuff? | 17:31 |
| pitti | but your call, of course | 17:31 |
| mr_pouit | no no, the ppa is fine if it's easier for you | 17:32 |
| pitti | ok, great | 17:32 |
| pitti | mr_pouit: I updated https://wiki.ubuntu.com/Halsectomy a bit | 17:32 |
| pitti | great to see progress on the XFCE side :) | 17:32 |
| pitti | and saves two seconds boot time | 17:32 |
| mr_pouit | pitti: fyi, the three panel plugins (volstatus, governor, cddrive) you put on the list are (more or less) unmaintained upstream, so it's very very low priority | 17:34 |
| pitti | *nod* | 17:34 |
| pitti | mr_pouit: "governor" is for CPU clock, I suppose? | 17:34 |
| pitti | there should be little reason to fiddle with this manually these days | 17:34 |
| mr_pouit | yeah, I wanted to remove it from the archive, but some people complained ("it works, why remove it") | 17:35 |
| kirkland | ScottK: jdong: thanks | 17:36 |
| mr_pouit | pitti: I'll try to complete a bit the halsectomy page, because some programs/plugins (e.g. xfce4-places-plugin) rely on libthunarvfs for {un,}mounting partitions, whereas other only for file management. So it's not obvious to know which ones need to be halsectomied without grepping the code. | 17:44 |
| pitti | mr_pouit: libthunarvfs seems to be obsolete entirely, right? | 17:45 |
| mr_pouit | yep | 17:45 |
| mr_pouit | anyway, gtg, thanks for your work on that :) | 17:46 |
| === hrw is now known as hrw|gone | ||
| pitti | mr_pouit: thanks, enjoy | 17:47 |
| === al-maisan is now known as almaisan-away | ||
| * LucidFox wishes pbuilding GTK and Qt applications didn't involve installing half of X... | 17:55 | |
| === beuno-lunch is now known as beuno | ||
| === sconklin is now known as sconklin-lunch | ||
| cjwatson | cking: re https://wiki.canonical.com/ColinKing/EFIAndGrub2-IntelDevelopmentKit - I arranged for GRUB to read most of the kernel and initrd in one single EFI call today, and (to my surprise) it didn't actually improve the time perceptibly | 18:23 |
| cjwatson | cking: this was reading from an iso9660 filesystem, so the files were contiguous | 18:24 |
| cjwatson | cking: the only thought I have is that using the block I/O layer rather than the disk I/O layer would avoid some copies, but that requires GRUB to handle alignment itself - and I already avoided at least one full copy of the data by turning off disk caching and that didn't seem to make any difference | 18:25 |
| cjwatson | cking: this was with OVMF under emulation, though | 18:26 |
| cjwatson | cking: but it's interesting to hear that you had similar performance problems on bare metal | 18:26 |
| cjwatson | cking: if you want to try my changes, they're here: http://paste.ubuntu.com/451197/ | 18:27 |
| === deryck is now known as deryck[lunch] | ||
| === sconklin-lunch is now known as sconklin | ||
| kirkland | cjwatson: odd ... running "status ssh" on my lucid box exits 0, prints nothing; sshd is in fact running though | 18:49 |
| kirkland | cjwatson: maybe an upstart hiccup | 18:49 |
| === JanC_ is now known as JanC | ||
| === deryck[lunch] is now known as deryck | ||
| === yofel_ is now known as yofel | ||
| === echidnaman is now known as JontheEchidna | ||
| === awolfson_lunch is now known as awolfson | ||
| EtienneG | Question: is there any way we can force installation of a restricted driver at install time, through preseeding? Would invoking "jockey-text -e nvidia" as a late_command be sufficient? | 20:21 |
| superm1 | EtienneG, a little more complicated, but this solution will work http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=ubuntu-fid.git;a=blob;f=framework/scripts/chroot-scripts/fish/01-jockey-drivers.py;h=6c693af7255f0fc21b6b5695906d2be52e9752cc;hb=HEAD | 21:30 |
| superm1 | (if the rest of the env is setup right for the late command that is) | 21:31 |
| EtienneG | superm1, thanks a bunch | 21:33 |
| smoser | hey all, i have a python package that is dynamically loading modules, via __import__(modname). i'm wondering where would be the right place to put the modules in a package, and subsequently, how to look up that path in python | 21:37 |
| smoser | so far, i have found that uso far, module name 'a' is loading plugins. i'm able to load them by sys.path.insert(0,a.__path__[0] + "/handlers") | 21:38 |
| === MacSlow|capoeira is now known as MacSlow | ||
| Sarvatt | lool: go figure binutils got uploaded *right* after your oprofile upload, needs a rebuild :) | 22:03 |
| === almaisan-away is now known as al-maisan | ||
| ScottK | smoser: I'd suggest ask for assistance in #debian-python on OFTC. | 22:15 |
| === al-maisan is now known as almaisan-away | ||
| hallyn | mathiaz: kirkland: process question. It only just came to my attention that the lxc package is a straight debian package. I'd like it updated to 0.7.0. Do we (a) send email to the package maintainer requesting update, (b) create a debian bug to ask for it, (c) create our own temp 0.7.0 package, or (d) just wait patiently? | 22:33 |
| mathiaz | hallyn: (d) is the prefered solution | 22:34 |
| mathiaz | hallyn: depending on how important it is to get the new upstream version (c) is also possible | 22:35 |
| mathiaz | hallyn: is there a specific blueprint or milestone target for lxc to be updated to 0.7.0? | 22:35 |
| geser | hallyn: depending on when the new upstream got released you could contact the DD and ask if he needs/wants help with the package | 22:36 |
| hallyn | mathiaz: i'd be nice to have it for alpha2, so next week | 22:36 |
| hallyn | (it's in the blueprint, yes, and would just be nice) | 22:36 |
| hallyn | now 0.7.0 just came out today... | 22:37 |
| hallyn | so i'm certainly being unreasonable, but still was wondering whether we usually try to email the DD or not | 22:37 |
| hallyn | i'll wait a day or two, thanks | 22:37 |
| lool | Sarvatt: Tss :-) | 22:37 |
| lool | Sarvatt: uploaded | 22:38 |
| hallyn | geser: i assume you mean "if it's been a long time since the upstream release" | 22:38 |
| geser | hallyn: yes, something longer than a few hours :) | 22:39 |
| hallyn | geser: drat! | 22:40 |
| hallyn | thanks :) | 22:40 |
| mathiaz | hallyn: right - helping the DD is also welcome | 22:40 |
| mathiaz | hallyn: you could look at the debian changelog and infer how responsive the DD is | 22:41 |
| mathiaz | hallyn: you could also push a package to a PPA | 22:41 |
| mathiaz | hallyn: to get more testing done | 22:41 |
| hallyn | mathiaz: yup, i've got my own bzr branch (and package on its way to ppa) - bc man, the ubuntu lxc template works GREAT | 22:56 |
| mathiaz | hallyn: \o/ | 23:04 |
| === bjf is now known as bjf[afk] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!