smoser | lifeless, thanks. http://bugs.squid-cache.org/show_bug.cgi?id=3949 | 00:03 |
---|---|---|
ubottu | bugs.squid-cache.org bug 3949 in other "hang in read caused by unclosed connection" [Normal,Unconfirmed] | 00:03 |
smoser | now me to bed. | 00:03 |
lifeless | smoser: gnight | 00:03 |
lifeless | smoser: thanks | 00:03 |
=== infinity_ is now known as infinity | ||
=== echevemaster_afk is now known as echevemaster | ||
=== seb128_ is now known as seb128 | ||
=== Mapley is now known as letmechangemynic | ||
=== letmechangemynic is now known as Mapley | ||
snkt | hiii | 04:43 |
slangasek | hallyn_: ovmf persistence> oh, very nice :) | 04:56 |
pitti_ | Good morning | 04:58 |
=== pitti_ is now known as pitti | ||
=== iahmad is now known as iahmad|afk | ||
=== tkamppeter__ is now known as tkamppeter | ||
=== Riddelll is now known as Riddell | ||
brainwash | pitti: uhm, someone removed almost all duplicates from the logind suspend/resume bug report | 09:00 |
pitti | erk, why's that? any comment about it? | 09:05 |
ogra_ | secret lennart conspiracy ! | 09:06 |
ogra_ | :) | 09:06 |
pitti | he'd be the first one to point bugs in our hacks :) | 09:06 |
ogra_ | yeah | 09:06 |
pitti | point "out" | 09:06 |
* ogra_ was just joking | 09:06 | |
brainwash | pitti: dunno, but I got some new info, so I replaced pm-suspend by a simple script which sleeps for a longer amount of time (10/15/30 sec, some value) | 09:09 |
brainwash | this does reproduce the issue | 09:09 |
brainwash | it still happens only occasionally I think | 09:11 |
pitti | brainwash: oh, hang on | 09:12 |
pitti | I just saw that systemd-shim times out after 10 seconds | 09:13 |
brainwash | o.o | 09:13 |
pitti | that should certainly be much longer | 09:13 |
brainwash | yeah :D | 09:13 |
pitti | brainwash: hang on, I'm finally through with what I was working on before, I'll look at the bug now | 09:13 |
pitti | brainwash: where did you put the sleep, just to be sure? | 09:14 |
pitti | brainwash: so perhaps this happens on machines where suspend/resume takes longer, due to some particular hardware, or slow machines, etc. | 09:14 |
brainwash | I simple replaced the /usr/sbin/pm-suspend in systemd-shim | 09:14 |
pitti | brainwash: developers tend to have fast boxes with SSDs and well-supported hardware where suspend is fast, perhaps that's why :) | 09:15 |
brainwash | and pointed it to a script which contains "sleep" | 09:15 |
pitti | brainwash: can you still reproduce it if you change g_timeout_add (10000, ... to g_timeout_add_seconds(600, ...) in src/systemd-shim.c ? | 09:16 |
brainwash | but 10 sec is still a lot, don't think that my laptop needs that much time (it does wake up my dedicated gpu before going to sleep) | 09:16 |
pitti | brainwash: that'll keep it alive for 10 minutes | 09:16 |
brainwash | under real conditions or simulated? | 09:17 |
brainwash | well, I try both and report back | 09:17 |
pitti | brainwash: shouldn't matter | 09:17 |
pitti | brainwash: i. e. if you have "pidof systemd-shim" being empty right after resume (e. g. after your logind d-bus call), it would explain that | 09:18 |
pitti | or "could" rather (I'm not that familiar with the shim, desrt would know much better) | 09:18 |
brainwash | systemd-shim is still there after resume, see my old log https://launchpadlibrarian.net/155226906/systemd-shim-debug.log | 09:19 |
pitti | brainwash: ok, so probably not that then :/ | 09:20 |
brainwash | oh well, the timeout might have occurred after the resume, can't tell from that log I guess | 09:21 |
=== iahmad|afk is now known as iahmad | ||
tseliot | pitti: do we still support lpia as an arch? | 09:31 |
pitti | tseliot: no, that got dropped afer lucid I believe | 09:32 |
tseliot | pitti: ok, thanks, it's probably time to clean up my nvidia packages then ;) | 09:32 |
ogra_ | lol | 09:32 |
brainwash | pitti: did some simulated runs, it seems to work, if there is a delay of 10/15/20sec, but failed twice with 30sec (logind not in prepare for sleep mode anymore, but network down) | 09:36 |
brainwash | pitti: do you intend to upload a patched systemd-shim somewhere, so more people can test it? | 09:38 |
pitti | brainwash: so your https://launchpadlibrarian.net/155226775/dbus-monitor-system.log log definitively shows the missing PrepareForSleep False; but you say it's probably not due to the shim timing out? | 09:39 |
pitti | brainwash: oh, so the longer delay fixes the PrepareForSleep False signal? | 09:40 |
pitti | brainwash: NM is supposed to pick that up | 09:40 |
pitti | brainwash: sure, I'll put that into a PPA and follow up to the bug report, let's collect some data on that | 09:40 |
brainwash | pitti: it seems, that logind didn't get stuck anymore, but I only did a small of amount of test runs | 09:41 |
pitti | merely increasing the timeout is not a final solution, but if that works I'll know what to discuss with desrt :) | 09:41 |
pitti | brainwash: uploaded, I'll wait with the bug update until binaries are available | 09:43 |
brainwash | but in my case the current 10sec timeout should be actually enough, so it's strange | 09:43 |
brainwash | pitti: were you able to reproduce the issue with the current timeout value and some delay of 10+sec? | 09:46 |
pitti | brainwash: not yet, was reading the bug report so fara | 09:47 |
brainwash | pitti: oh, just realized that the user who removed the duplicate reports is telling people to test the upstream kernel | 09:53 |
pitti | bogus, won't help | 09:54 |
brainwash | what a mess | 09:54 |
pitti | in fact, I thought I duplicated a kernel bug to the systemd-shim one this morning | 09:54 |
brainwash | ok, I have to go now and will do some more testing later, cya :) | 09:55 |
pitti | brainwash: thanks! cu (packages are building) | 09:56 |
ogra_ | http://devnull-as-a-service.com/ | 09:56 |
* ogra_ grins | 09:56 | |
pitti | lol | 09:57 |
xnox | pitti: my 32GB RAM desktop does take a while to suspend to a spinny disk. and it is flaky sometimes. | 10:01 |
pitti | brainwash: PPA is ready, followed up to the bug, and marked two handfuls of bugs as duplicates (based on a search on "resume network") | 10:07 |
ogra_ | 32G ? why do you use disks at all ? | 10:08 |
ogra_ | :) | 10:08 |
pitti | xnox: yeah, worth trying the PPA then if you can reproduce that | 10:08 |
pitti | xnox: oh wait, suspend to *disk*; that's something else then, most probably | 10:08 |
xnox | pitti: ack. | 10:08 |
pitti | ogra_: in fact I do most stuff in /tmp these days (tmpfs), as my RAM (16 GB) is bigger than my system partition :) | 10:10 |
ogra_ | yeah, same here | 10:11 |
pitti | running VMs or schroot builds is incredibly fast there, quite nice | 10:11 |
ogra_ | yup | 10:11 |
pitti | these were the main reasons I got so much ram in the first place | 10:11 |
ogra_ | even doing native arm builds in a qemu VM is faster thann doing it on real HW | 10:11 |
=== dosaboy_ is now known as dosaboy | ||
brainwash | pitti: great job, but the first comment on your patched package does not look promising :/ | 11:46 |
pitti | darn | 11:46 |
brainwash | maybe logind does not get stuck anymore, but there is still something odd about nm | 11:47 |
brainwash | time to start my tests and do some monitoring | 11:47 |
* zyga wonders how hard would it be to copy ubuntu CD image into ramdisk before really starting the installation process | 11:48 | |
zyga | (like knoppix used to do) | 11:48 |
zyga | installing from CD is really noisy | 11:48 |
pitti | wow, you actually use CDs for installation? (good that someone tests this!) | 11:48 |
brainwash | TORAM? | 11:49 |
brainwash | https://wiki.ubuntu.com/BootToRAM | 11:49 |
zyga | pitti: yes | 11:53 |
zyga | pitti: i'm reusing a very old dvd-rw that I bought years ago | 11:54 |
davmor2 | pitti: I always do :D | 11:54 |
zyga | pitti: usb creator is broken and I didn't want to dd stuff to random partitions (even though I know how to find the right one) | 11:54 |
zyga | pitti: still, is it "easy" to do something like that? | 11:55 |
zyga | pitti: I have no idea how knoppix did it | 11:55 |
zyga | pitti: or how hard that is to do with a modern kernel | 11:56 |
pitti | zyga: I suppose something like "cat /dev/cdrom > /dev/null" already should do it, and let the cache take care of the rest | 11:56 |
zyga | pitti: that doesn't stop the CD from spinning very noisily | 11:56 |
pitti | well, you need to read the data once.. | 11:56 |
zyga | pitti: but perhaps that + some way of slowing the cd speed | 11:56 |
zyga | pitti: well sure, I'm not asking for miracles | 11:56 |
zyga | pitti: it's just after thet initial process, the cd should be ejectable | 11:57 |
pitti | zyga: sudo hdparm -E 10 or so? | 11:57 |
pitti | (never tried that, though.. -ENOCDROM) | 11:57 |
zyga | pitti: do you think that's doable in trusty installer? :-) | 11:57 |
pitti | zyga: I'm not sure it actually helps | 11:57 |
pitti | especially on older machines without much RAM the 800 MB or so wouldn't even fit | 11:57 |
pitti | and I suppose we are talking about older machines here | 11:58 |
pitti | zyga: but it's worth a try whether the hdparm helps | 11:58 |
zyga | pitti: well, not really, knoppix hat some heuristic where it would do if if you had 1GB of ram | 11:58 |
zyga | pitti: (and you could really eject the cd and use it for other things then, it was a major selling point for the live CD that allowes you to use your CD) | 11:58 |
zyga | pitti: this is a core i7 with 18GB of ram, it's also 5 years old so I don't know | 11:59 |
pitti | zyga: that could be done by cat'ing to a file in tmpfs (in initramfs) and loop-mounting that instead of /dev/cdrom | 11:59 |
zyga | pitti: which source package should be hacked to get that behavior? initrfams stuff or something "after"? | 12:00 |
pitti | but that really requires >= 1.5 GB of RAM then | 12:00 |
zyga | pitti: sure, many machines have enough of memory and that could be a nice improvement | 12:00 |
pitti | zyga: my first thought would be casper | 12:00 |
pitti | I think that handles everything | 12:00 |
zyga | ok | 12:00 |
brainwash | pitti: several test runs with a 20sec delay, everything works nice, increasing the artificial delay to 30sec causes some trouble | 12:03 |
pitti | brainwash: so maybe that hits a d-bus timeout somewhere (but standard d-bus timeout is 30 s) | 12:03 |
brainwash | but 30sec.. that's an eternity | 12:04 |
pitti | yeah, you can boot 4 times in that.. | 12:06 |
brainwash | maybe due to the clock jump after resume? | 12:06 |
brainwash | this would be really odd | 12:07 |
brainwash | well, lets wait for some more test results | 12:09 |
=== MacSlow is now known as MacSlow|lunch | ||
pitti | brainwash: ooh, more promising now :) | 12:54 |
brainwash | pitti: great, so a restart is required? | 12:55 |
pitti | brainwash: not sure why that would be, the old shim ought to time out quickly | 12:55 |
brainwash | pitti: I'll test your package later, because I cannot do several suspend/resume cycles right now to verify it actually works | 13:00 |
brainwash | but it works in theory for me (fake suspend) | 13:01 |
pitti | brainwash: great; many thanks for your investigations! | 13:03 |
mlankhorst | @pilot in | 13:09 |
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst | ||
brainwash | pitti: still not fixed, see the latest comments :/ | 13:36 |
brainwash | I guess the current fix only covers a small amount of cases | 13:37 |
=== MacSlow|lunch is now known as MacSlow | ||
voldyman | is this the correct place to ask about appindicators ? | 13:55 |
voldyman | where can i find the list of icons available, the sample code uses "indicator-messages" | 13:56 |
ricotz | voldyman, maybe better in #ubuntu-unity | 13:56 |
jamespage | infinity, any chance I could persuade you to SRU the fix for bug 1187722 to quantal and raring as well? | 14:05 |
ubottu | bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Fix released] https://launchpad.net/bugs/1187722 | 14:05 |
zyga | http://packages.ubuntu.com/search?keywords=firefox&searchon=names&suite=all§ion=all | 16:02 |
zyga | why does trusty have firefox 24 while saucy got 25? | 16:02 |
cjwatson | security updates for all stables; wonder if we can copy that forward | 16:03 |
cjwatson | looks like it's possible | 16:03 |
cjwatson | chrisccoulson: want me to copy firefox from saucy-updates to trusty-proposed? | 16:03 |
cjwatson | or are you already working on an independent update? | 16:04 |
chrisccoulson | cjwatson, feel free to copy it across | 16:04 |
cjwatson | chrisccoulson: done | 16:06 |
chrisccoulson | cjwatson, thanks | 16:06 |
tsdgeos | guys, trusty won't update anymore in my laptop http://paste.ubuntu.com/6330740/ | 16:10 |
tsdgeos | who to i tell? | 16:10 |
Laney | http://paste.ubuntu.com/6330818/ | 16:25 |
Laney | zul: are you working on openstack uploads for trusty or can we copy those? | 16:26 |
zul | Laney: feel free to copy over | 16:27 |
Laney | ta | 16:27 |
Laney | Riddell: kubuntu-docs too | 16:27 |
cjwatson | tsdgeos: Do you know what version of that package last worked? Should be possible to find it from /var/log/dpkg.log | 16:29 |
Riddell | Laney: what about it? | 16:31 |
Riddell | Laney: oh right, yeah please copy | 16:31 |
tsdgeos | cjwatson: 1.34 worked | 16:31 |
cjwatson | the only change to the i2kmon init script appears to be that it's now enabled by default | 16:33 |
cjwatson | do you actually have the hardware that this package drives? | 16:33 |
Laney | Riddell: rockin' | 16:33 |
cjwatson | oh no, there's s/--exec/--startas/ too, but still | 16:34 |
cjwatson | tsdgeos: I think your best bet is to disable it in /etc/default/i2kmon and file a bug; I'm not familiar enough with the implementation language here to debug why it's exiting non-zero | 16:37 |
tsdgeos | cjwatson: no clue to be honest | 16:38 |
tsdgeos | it just came out as a dependency from somehwere | 16:38 |
=== jono is now known as Guest50058 | ||
=== mwhudson- is now known as mwhudson | ||
infinity | jamespage: Could do, I was under the impression when it was brought up that we only care about the LTS and current devel. | 17:16 |
infinity | jamespage: Is there actually a concern for (nearly EOL) releases here, or just people who want to build all releases in a PPA for no good reason except "because they can"? | 17:17 |
=== LordOfTime is now known as TheLordOfTime | ||
TheMuso | xnox: Do you want me to go ahead and drop libasound2-plugins-extra now, or are you on it already? | 17:59 |
xnox | TheMuso: I'm on it already. | 17:59 |
TheMuso | xnox: Ok thanks. | 17:59 |
xnox | TheMuso: just planning my moves. | 17:59 |
TheMuso | np | 17:59 |
TheMuso | Gotta love patent encumbered codecs. | 18:00 |
mterry | didrocks, I added a new wiki section that I think you'll like: https://wiki.ubuntu.com/MIRTeam#Making_Life_Easier_for_Archive_Team_Members :) | 18:01 |
=== kyleN is now known as kyleN-afk | ||
TheMuso | xnox: Oh I didn't expect you to split things out. I was only going to follow through given the demand... | 18:25 |
=== kyleN-afk is now known as kyleN | ||
=== jono is now known as Guest21711 | ||
=== Nisstyre-laptop is now known as nisstyre | ||
roaksoax | hi all! I was wondering what to do with packages that come from debian that use systemd | 19:46 |
dobey | sarnold: hi! i requested a review from you for https://code.launchpad.net/~dobey/tarmac/add-apparmor/+merge/193323 if you could take a few minutes to review it please. :) | 19:46 |
roaksoax | like: --with=systemd | 19:46 |
xnox | roaksoax: nothing. | 19:48 |
roaksoax | xnox: cool! | 19:48 |
xnox | roaksoax: it should be able to build correctly. | 19:48 |
roaksoax | zul: 6^ | 19:48 |
roaksoax | zul: ^^ | 19:48 |
roaksoax | xnox: yeah it does, I was just wondering if we should be dropping it or just not care | 19:48 |
zul | cool | 19:48 |
roaksoax | xnox: zul's fault :P | 19:48 |
xnox | zul: roaksoax: be careful though, sometimes together with systemd "enablement" dh_installinit calls are dropped, which may affect and not install upstart jobs. | 19:49 |
roaksoax | xnox: ok cool thanks! | 19:52 |
=== JanC_ is now known as JanC | ||
bkerensa | http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html | 20:20 |
bkerensa | getting epic big | 20:20 |
bkerensa | 89 items | 20:20 |
bkerensa | :D | 20:20 |
=== ChrisTownsend1 is now known as ChrisTownsend | ||
=== ryukafalz_ is now known as ryukafalz | ||
brainwash | xnox: can you build a working ubuntu package for bug 1183580 please? I lack the knowledge to properly build it myself :/ | 20:47 |
ubottu | bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580 | 20:47 |
brainwash | if no, which developer(s) should I notify instead? | 20:48 |
xnox | brainwash: $ sudo apt-get install build-essential fakeroot dpkg-dev | 20:50 |
xnox | brainwash: $ sudo apt-get build-dep librcc | 20:50 |
xnox | brainwash: $ apt-get source -b librcc | 20:50 |
xnox | should produce recompiled packages | 20:50 |
xnox | which you will be able to install with $ dpkg -i *.deb | 20:51 |
xnox | brainwash: please let me know if that fixes the problem for you. | 20:51 |
brainwash | xnox: the package in the repository is broken, would rebuilding it without any change help at all? | 20:52 |
xnox | brainwash: in weird cases, it can. | 20:53 |
xnox | brainwash: if you can do above and verify that recompiled _one over_ package resolves the problem, then all is good and it will be a quick SRU. If it doesn't, then the bug in question is harder. | 20:53 |
xnox | brainwash: it usually helps resolve crasher bugs, due to un-noticed ABI breakage. | 20:54 |
brainwash | xnox: sure, I can try it, will report back later | 20:54 |
brainwash | thanks :) | 20:54 |
brainwash | xnox: no luck, my locally built package still segfaults :( | 21:13 |
xnox | brainwash: then debian binaries might be tainted, as debian accepts binary uploads from maintainer =( | 21:14 |
xnox | (or not-matching source) | 21:15 |
xnox | or there is something odd about our toolchain.... =( | 21:15 |
sarnold | dobey: looks great! thanks :D | 21:16 |
brainwash | xnox: it just feels like this problem is not going to be fixed in saucy, the workaround isn't complicated (install debian library), but it feels wrong | 21:17 |
hallyn_ | mterry: so fwiw, I've bristled from the start at, in bug 1126513, a non-server-team-member saying that server team would maintain it :) | 21:20 |
ubottu | bug 1126513 in usbredir (Ubuntu) "[MIR] usbredir-0.6-1" [Undecided,Incomplete] https://launchpad.net/bugs/1126513 | 21:20 |
dobey | sarnold: thanks! | 21:20 |
hallyn_ | but all right. fine. i'll subscribe to the bugs | 21:21 |
dobey | sarnold: about the /**/tarmac though; i was hoping to make it also work for people who are installing it from source in /usr/local, or who are running it directly from within the source tree, as well | 21:21 |
mterry | hallyn_, well | 21:21 |
mterry | hallyn_, that's why only a team member can subscribe a team | 21:22 |
mterry | hallyn_, so if you guys don't want to maintain it, that's fine. We either find a team that does or we don't have it in main | 21:22 |
hallyn_ | mterry: yeah, i just mean that in the boilerplate in the Description, he put down "server team will maintain" | 21:22 |
mterry | hallyn_, yeah :) Sorry, I didn't look into his team memberships, I just assumed he knew of what he spoke :) | 21:22 |
hallyn_ | I dunno. I have no love for the spice-originated source. but it's only for qemu, so we should. | 21:22 |
hallyn_ | mterry: hah, actually he's so fed up he's stopped using ubuntu. | 21:23 |
dobey | sarnold: is there any good way to do that? as otherwise, running from source (which is common), would be unconfined still | 21:23 |
hallyn_ | he's upset that spice didn't get into main until raring. | 21:23 |
mterry | hallyn_, ah yes, I saw that comment | 21:23 |
mterry | hallyn_, normal rage-quit material :) | 21:23 |
hallyn_ | all right - so i've subscribed, will comment to that effect, and let the MIR-completion magic happen | 21:23 |
mterry | hallyn_, I mean, do we want this feature? | 21:24 |
mterry | hallyn_, original requester rage-quit. Do other people want it? | 21:24 |
mterry | Apparently users will benefit, I'm just curious if we have someone driving this change | 21:24 |
hallyn_ | it's not a server feature. we don't hook usb crap up to servers :) | 21:25 |
sarnold | dobey: it'd be ugly, giving multiple attachment paths. might as well leave it alone then. :) thanks | 21:25 |
hallyn_ | mterry: but the bar to enabling it is so high (build your own qemu-kvm) that it's probably worthenabling it. | 21:26 |
hallyn_ | mterry: I'm only saying this bc the changelog shows so few updates that either the code is stable enough to just have it on, or noone is using it :) | 21:26 |
mterry | hallyn_, often the latter :) | 21:26 |
sarnold | would the work to enable qemu-kvm to load it as "plugin" be too steep? | 21:27 |
hallyn_ | got me | 21:27 |
mterry | hallyn_, so do we need to change qemu to enable support? | 21:28 |
hallyn_ | mterry: just debian/control | 21:28 |
mterry | hallyn_, we prefer team bug subscribers, so if you get hit by a bus, we still have someone looking at usbredir -- after a suitable mourning period :) | 21:33 |
hallyn_ | you know we sometimes travel as a team | 21:34 |
hallyn_ | lemme see how if i can do that | 21:34 |
hallyn_ | jamespage: ^ do you know how to subscribe the server team to usbredir bugs? | 21:35 |
hallyn_ | though i'm wondering about sarnold's suggestion. | 21:35 |
Laney | it needs to be an administrator | 21:35 |
Laney | Do you mean ubuntu-server-dev? I can do that if so | 21:36 |
Laney | hallyn_: ↑ | 21:38 |
hallyn_ | Laney: yeah i think that's what i mean | 21:40 |
* hallyn_ checks | 21:40 | |
hallyn_ | yup | 21:41 |
Laney | doing | 21:44 |
Laney | done | 21:44 |
hallyn_ | Laney: thanks | 21:46 |
Laney | kein problem | 21:46 |
mterry | hallyn_: which sarnold suggestion? | 21:49 |
sarnold | modify qemu-kvm to load usbredir as a plugin if it is available, rather than require build-time linking | 21:49 |
=== txwikinger is now known as txwikinger2 | ||
=== txwikinger2 is now known as txwikinger | ||
mterry | sarnold, ah neat. That way we don't need usbredir in main indeed | 21:51 |
hallyn_ | won't be particularly easy though, near as i can tell | 21:54 |
sarnold | aww. thanks for looking into it. (I didn't particularly like the feeling that usbredir drastically decreased the value of VM-based isolation..) | 21:56 |
mterry | sarnold, hallyn_: no one seems excited about usbredir... :) | 21:57 |
sarnold | mterry: yeah. I can appreciate the desire for the feature, though. | 21:58 |
mterry | Well, if the plugin way is unlikely to get done, I guess we can promote | 21:58 |
sarnold | up to the server team if they want to maintain it :) hehe | 22:00 |
hallyn_ | i wonder whether rharper has any comments ont he feasability of making it a plugin | 22:00 |
* mterry looks at rharper | 22:01 | |
TheMuso | Oh wow, and I thought we had gotten rid of dpatch... | 22:19 |
TheMuso | At least not with universe packages... | 22:19 |
=== SWAT_ is now known as SWAT | ||
rharper | hallyn_: mterry : re plugins for qemu; it's been discussed on the list quite a lot and the maintainers always nack it; If a feature is good enough to be maintained, than it can be compiled in and supported by the distro | 23:00 |
hallyn_ | rharper: thanks. sounds like a no then :) | 23:02 |
hallyn_ | sarnold: ^ | 23:02 |
sarnold | hallyn_: bugger. the reasoning even makes some kind of sense. hehe. :) | 23:03 |
hallyn_ | sarnold: it's the inverse of our reasoning :) | 23:07 |
sarnold | hallyn_: yes! bah. :) | 23:07 |
hallyn_ | maybe i'll spend tomorow looking at libpam-mount bugs | 23:09 |
hallyn_ | for great glory | 23:09 |
hallyn_ | anyway, i'm off - gnight | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!