[04:42] can someone help me find the code responsible for changing screen resolution? === racarr_ is now known as racarr === pace_t_zulu_ is now known as pace_t_zulu [07:09] Good morning [07:11] bryce: can we even be sure that the bug is still the same with 2.6.30 and new libdrm? [07:11] bryce: when I wanted to test the freezes I get on the 945, these new packages change behaviour completely [07:20] hi [07:25] hey asac [08:30] * pitti hugs seb128 [08:30] * seb128 hugs pitti [08:30] how are you today? [08:33] seb128: pitti: do you guys have any ideas about bug 322714 and bug 328885. There seems to be a lot of vague dpkg type bugs in avahi [08:33] Launchpad bug 322714 in avahi "package libavahi-common3 0.6.22-2ubuntu4 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/322714 [08:33] seb128: pretty good, and you? [08:33] Launchpad bug 328885 in avahi "package libavahi-qt3-1 0.6.23-2ubuntu2.1 failed to install/upgrade: package libavahi-qt3-1 is already installed and configured" [Undecided,Incomplete] https://launchpad.net/bugs/328885 [08:33] hey robert_ancell [08:33] hey robert_ancell [08:33] good morning guys [08:33] looking [08:33] pitti: pretty good thanks! [08:35] those seems bugs for mvo [08:35] robert_ancell: the first one seems a local corruption rather than a bug [08:36] seb128: what is the best thing to do with them? i.e. how should they be marked (I can't see anything avahi specific about them) [08:36] that's a very good question [08:36] I tend to close them or switch them to questions [08:36] which is not really "right" and mvo will not agree with me there [08:37] I tried to argue for getting an "upgrade issues" components [08:37] but other people didn't like the idea [08:37] I want to assign them to "dkpg" or something [08:37] other people being mvo and pitti I think ;-) [08:37] yeah, you can do that too [08:38] (but that feels like passing the buck. A bit like assigning to the great black hole of compiz) [08:38] so, do you close as "invalid"? [08:38] convert it to a question saying that's a local issue and not a software bug [08:39] that's what I do usually [08:39] or invalid [08:39] robert_ancell: I analyized a bunch of them [08:39] the one: 322714 [08:39] question let the possibility that answer tracker guys will give advices to the guy on how to sort the issue [08:39] dpkg complains that its missing a final newline, so I usually ask for the file [08:39] and typically it contains either garbage or a bit flip error [08:40] mvo: hey [08:40] * pitti wishes it was easier to see the actual problem in the plethora of logs [08:40] robert_ancell: hi [08:40] pitti: good point [08:41] robert_ancell: I'd set 322714 to incomplete, asking for an fs check and attaching the .list file in question (sounds like corrupted fs or full disk to me) [08:41] seb128: I still stand to this opinion [08:41] generating large amounts of bug spam and then directing it into a black hole where nobody looks doesn't help anyone [08:41] pitti: which one? not having an upgrade issues component? [08:42] pitti: because that one is clearly an avahi bug? *g* [08:42] either we make those reports better, or we stop collecting them [08:42] it should more be a package install/upgrade component [08:42] stop collection them [08:42] ok, but when you get the .list file back what can we do with it? [08:42] I'm that near > < of adding a piece of code which close all of those on GNOME packages [08:42] robert_ancell: see if it's obviously broken/truncated [08:43] I've enough of getting 95% of useless bugs assigned on the wrong component [08:43] seb128: I think ignoring/not collecting them is a valid option [08:43] robert_ancell: it should contain just file names, it will probably contain a bunch of garbage in between. clear sign of either filesystem correuption, memory corruption or (heaven forbit) a bug in dpkg [08:43] pitti: and if it is, all we can say is your system is corrupted, please delete and reinstall that package? [08:43] robert_ancell: I usually ask people to start the rescue system from grub and then start fsck [08:43] reinstalling the package will not solve the corruption issue [08:43] I think not collecting them is not a good option [08:44] mvo: we shouldn't ask people to file those reports if we are just going to ignore them [08:44] we already had this discussion, we will just never agree [08:44] it's raising false expectations and just leads to frustrations like "ubuntu bug reports are never looked at" [08:44] I feel if I was sending in the report a link to a "fixes for dpkg issues" wiki page would make me happy [08:44] I don't want to ignore them either, I do check a lot of them and act. half of them a bad. but the other half is not [08:45] what can we do to reduce this bad half to be less than that? [08:45] I'd like to see some more specific data collection from them, so that we can sanely auto-duplicate them [08:45] robert_ancell: there is a fsck and fix broken package option in friendly-recover (the menu in the rescue option in grub) [08:45] and then just look at the ones which have several dupes (the real ones) [08:45] pitti: it's hard to autoduplicate random corruption [08:45] seb128: right, those fall into the "ignore because of missing duplicates" part [08:45] robert_ancell has a good point, we should have a stock reply and wiki page about corruption [08:45] but if a package's postinst fails with exit status 99 for 50 people, that's something worth looking at [08:46] mvo: I haven't been in grub for a while now it seems. Is there a user-friendly wiki page about how to use it? [08:46] I'm fine with collecting them into a special category as long as we keep collecting them [08:46] robert_ancell: I don't iknow (I think its not) [08:46] pitti: when you know what status nn means, 90% of the time it's something crashing but you don't know what, though mvo probably fixed that one now [08:46] I mean, it sounds silly to me that we collect bugs that there are typos in the help widnow of synaptic, but we ignore errors that make package installation impossible at the users machine and say this is not a bug [08:46] ie we get lot of random issues being scrollkeeper-update crashing [08:47] seb128: but if it affects 50 people in our testing community, it's _still_ worth looking at it surely? (even if it is mistitled/misassigned) [08:47] it will attach the dmesg logs now [08:47] mvo: but it's not a bug, it's an installation issue [08:47] right, but it still deserves attention, no? [08:47] and often its bugs [08:47] we already had this discussion [08:47] I agree on that [08:48] I just don't think forcing me to keep those bugs on my component work [08:48] thats ok [08:48] I just close them now because you don't force things over people when that's not something they are responsive for there [08:48] no clue about 328885, this looks indeed like a weird apt/debconf issue [08:48] ie I've no clue what to do about dpkg index corruptions [08:48] so what should we do a) have a discussion (with more people) at uds again b) discuss on the ML c) just move them all to a new category? [08:48] and I don't care enough to keep those on my components [08:49] that would work for me [08:49] seb128: those aren't really the ones worth looking at indeed, which is why I'm eager to get more specific data into the bug reports [08:49] but you and pitti already expressed that you are against reassigning those to an "upgrade issue" place [08:49] yeah, 328885 is one of the useless ones :/ [08:49] which means you force them at the wrong place where it will angry the maintainer only and not being worked anyway [08:50] seb128: I didn't say _re_assigning is a bad thing (although I'd prefer "invalid") [08:50] seb128: I'm just against reporting them all against a "package failures" project initially [08:50] pitti: where do we reassign those bugs? ie the avahi one [08:50] since that will just be one honking big mess nobody ever looks at [08:50] seb128: perhaps we misunderstood each other then [08:50] and why wouldn't we have some bugsquad ressource dedicated to triage that component ? [08:51] ^ no reason not to, we just don't have it [08:51] you seem to have the illusion that people actually triage those when they are on random components [08:51] looking at desktop packages bug triagers just ignore those [08:51] because they don't know what to do [08:51] well, I triage them on my pacakges [08:52] but I don't think that everyone does, and that's fine [08:52] seb128: what are you trying to convince me about? [08:52] pitti: that letting them assigned to random component is not efficient [08:52] (and no, I don't think we can tell the community "please go triage those 20.000 bugs against "install-failures", that won't work) [08:52] and that we should have an "upgrade issue" component [08:53] seb128: as I said, I can live with _re_assigning [08:53] just not with apport reporting them all against that component initially [08:53] ok, we started wrongly [08:53] let's restate what the problem is and what we need to do [08:53] if you look at a bug, say "oh crap, NFC", and reassign, that's fine [08:54] but then you looked at it and determined that you didn't see that issue 30 times already, and it's rarian which segfaults for half of the people [08:54] - we need an easy way to move the random corruption bugs out of the way [08:54] "invalid"? [08:54] (or "wontfix") [08:54] re-assigning would make me happy as long as I could attach some sort of clue to the reporter on what they should do [08:54] reassigning to a garbage dump is not ideal, but WFM, too [08:54] ok, so course of action [08:55] - get a stock reply and wiki page for corruption cases [08:55] +1 [08:55] and use those to close those bugs [08:55] +1 [08:55] seems a good way to track them (hello o/) [08:55] - improve the information collecting process and auto-duplication [08:56] can we automatically detect and tag in a special file conflicts? [08:56] can we automatically detect and tag in a special way file conflicts? [08:56] those are usually valid and useful bugs [08:56] mvo: ^ [08:56] right, and they sound like something we should be able to detect automatically [08:56] I think we can detect it in the error message [08:57] also, I'd really like to avoid filing a package install bug if something in postinst segfaulted, since that should rather create a proper .crash file [08:57] maitnainer script failures is something we can probably detect relatively easily as well [08:57] where do we keep note of those action items? [08:57] that would mean to enable apport again for all upgrades (stable->stable too)? [08:58] ok, so let me take notes [08:58] * pitti edits Bugs/Responses [08:58] mvo, pitti, robert_ancell: you agree with closing corruption bugs are invalid? [08:58] seb128: fine for me [08:59] are -> as [08:59] I'm still not comfortable with it, those might be dpkg errors (rare ones). but yeah, its ok with me [08:59] mvo: other option is to get a "upgrade issues" component [08:59] what are "corruption" bugs? bad backtraces? [08:59] and reassign those there [08:59] seb128: yes, as long as users get some info on how to save their system (i.e. don't think we're telling them it's not a problem) [08:59] asac: no, dpkg status corrupted for example [08:59] oh. yeah [08:59] asac: or weird dpkg errors about new lines, or parsing issues [08:59] seb128: lets call it pkg failures or something, its not limited to upgrades IME [09:00] mvo: works for me [09:01] seb128: do we have webkit ephy somewhere? [09:01] (recent) [09:01] mvo: do you want a bug about the "would be nice to autotag file conflicts"? [09:02] asac: no but I think there is a ppa and the packaging is in debian pkg-gnome svn [09:02] mvo: I've been looking through the code of gnome-app-install and I have a design for how I'd like to extend it to support removing Wine applications. Mind if I run it by you? [09:02] seb128: yes please [09:02] Also good evening ;) [09:02] Or morning ;) [09:03] seb128: ok. i think i am member of the webkit team in launchpad ... let me check what those folks are doing actually [09:03] YokoZar: good evening [09:03] mvo: where should I open this bug? [09:03] mvo: apt? [09:04] seb128: yes [09:05] seb128, mvo, robert_ancell: first cut at a stock response: https://wiki.ubuntu.com/Bugs/Responses#Package%20installation%20failure [09:06] pitti: looks a good start to me thanks [09:06] pitti looks good [09:07] pitti: I've tested with both 2.6.28 and 2.6.30 and have not noticed a difference in behavior [09:08] bryce: ok, good [09:10] here's another question for everyone: Bug 361622 requests that avahi provide a firewall rule - this seems crazy to me, if anything the firewall should have a default rule for avahi. Do others agree? [09:10] Launchpad bug 361622 in avahi "Add application rules for the ufw firewall " [Undecided,New] https://launchpad.net/bugs/361622 [09:13] mvo: bug #368435 [09:13] Launchpad bug 368435 in apt "could tag file conflicts installation issues" [Undecided,New] https://launchpad.net/bugs/368435 [09:13] thanks seb128 [09:14] mvo: thank *you* and sorry for ranting again there [09:14] mvo: good that we are moving in a way where everybody is happy about the change though [09:14] seb128: yeah [09:15] robert_ancell: you can provide in application packages ufw rules, which are activated or not considering the local policy. So, it doesn't sound too crazy for me :-) [09:15] didrocks: thanks, not very familiar with ufw. Will confirm it then [09:16] robert_ancell: talk to jdstrand on IRC when he's around [09:16] robert_ancell: I think the idea is that packages are shipping their firewall rules, ie when you install avahi that's to get it used and the firewall rule to allow that would be there [09:17] seb128: exactly. I can handle it. I did for a bunch of packages when jdstrand asked some help for intrepid [09:17] cool, thanks guys [09:18] seb128: FYI, the desktop team presentation tomorrow at OpenWeek will be largely inspired by your last talk :) [09:18] didrocks: good ;-) [09:19] robert_ancell: you got a reply on this rhythmbox codec bug btw [09:21] robert_ancell: I'm looking the glade upgrade bug [09:21] robert_ancell: no need to nominate bugs for karmic that early in the cycle [09:21] seb128: ok, wasn't sure when to do that. [09:21] you also want to add a debdiff for the update to the bug [09:21] seb128: excellent, the rb response reproduces for me [09:21] gzipped if required [09:22] seb128: I couldn't remember how to make the debdiff... [09:22] it makes review easier since the diff is on the bug [09:22] debdiff *.dsc [09:22] thanks [09:22] in the dir where you have the jaunty version and your update [09:24] seb128: there now [09:24] robert_ancell: thanks [09:25] seb128: should have gzipped it as you said though... [09:25] robert_ancell: do you already have enough work for tomorrow? [09:26] seb128: I have various stuff to do. If there's something you want me to look at pass it over [09:26] robert_ancell: bug #368252 assigned to you [09:26] (I've never found nothing to do :) ) [09:26] Launchpad bug 368252 in totem "Totem firefox plugin can't launch apple HD trailers" [Low,New] https://launchpad.net/bugs/368252 [09:26] robert_ancell: that seems another totem-pl-parser issue [09:27] not a high priority issue, but in case you get bored ;-) [09:27] the user claims that was working in intrepid === andreasn_ is now known as andreasn [09:40] seb128: do you me to rename jaunty/karmic in my waiting to be sponsored bug (as karmic repos are opened now)? [09:40] didrocks: feel free to do that [09:41] didrocks: I'm still on jaunty and trying to deal with the current bug flood so those uploads will wait [09:41] seb128: oki, if I can do anything to help, do not hesitate (even if I'm quite busy now until middle of may ;)) [09:41] just in case you missed it in -devel: karmic is open, go wild! [09:42] pitti: apparently we have some crack addicts, didrocks is already on it ;-) [09:42] seb128: :-) [09:42] hehe [09:42] go didrocks! [09:42] * seb128 stills dealing with jaunty bugs [09:42] pitti: just began ^^ [09:43] please everyone remember to sub to karmic-changes@ [09:43] pitti: already done this morning :D [09:43] * pitti uploads new hal and dk-power [09:44] pitti: so you can spam our mailboxes down? [09:44] muhaha [09:44] "busted" [09:44] * didrocks is setting up a filter right now :) [09:44] I revealed your evil plan! [09:44] I have about 20 "fix committed" bugs, I want to clean my +assignedbugs list [09:45] * seb128 is always impressed by how early people switch to new crack ;-) [09:45] seb128: I wonder if you would mind if I'd upload the new gnome-power-manager with DK-power support [09:45] I must be the only of to still have a stack of jaunty bugs to get fixed [09:45] pitti: not at all, as said I'm still stucked in jaunty mode there ;-) [09:46] we have some evolution crasher issues [09:46] and lot of desktop bugs coming [09:46] seb128: please don't put too much effort into jaunty SRUs [09:46] feel free to upload anything you want to karmic [09:46] pitti: we got at least 15 people complaining about evolution calendar hanging evo since jaunty [09:46] yeah, I heared about that [09:46] that's indeed an important thing [09:46] pitti: I want to get that fixed, then I can switch to karmic [09:46] pitti: could you nag about about a sru approval for update-manager again? sorry that its such a sru intensive beast [09:47] seb128: I just don't think we should do a lot of work wrt. uploading all the point releases unless they fix something truly critical [09:47] mvo: of course [09:47] pitti: I'm almost done with srus on my list, I don't intend to spend much time on jaunty [09:47] thanks [09:47] pitti: right [09:47] * pitti hugs seb128, seems we're on the same page [09:47] pitti: karmic will be busy enough [09:47] * seb128 hugs pitti [09:48] mvo: I add a karmic task to bug #361053 too [09:48] Launchpad bug 361053 in gnome-terminal "Please, sponsor gnome-terminal 2.26.1 to jaunty" [Wishlist,In progress] https://launchpad.net/bugs/361053 [09:49] didrocks: ok [09:49] didrocks: don't [09:49] oupsss [09:49] jaunty-updates are pocket copied to karmic [09:50] oh, didn't know that :/ It's done until which milestone? [09:50] it's done when the versions are identic [09:51] in jaunty and karmic that is [09:51] it makes sense to have only one upload [09:51] yes, I regularly do that with SRUs [09:51] ok, sorry, I can't revert the release nomination. I will just put a comment, so... [09:52] didrocks: that's ok, it's a detail [09:52] mvo: here's one you might have an idea about: bug 291484 [09:52] Launchpad bug 291484 in avahi "package libavahi-common3 0.6.23-2ubuntu2 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/291484 [09:52] didrocks: just no need to create paper work where it's not required [09:52] seb128: good to know, though :) [10:09] see you all tomorrow [10:10] robert_ancell: good evening, see you tomorrow [10:59] didrocks: your gnome-terminal upload refers to LP: #572414, that doesn't exist [11:00] pitti: let me check if I just mixed with the corresponding GNOME bug [11:00] * didrocks is confused :/ [11:00] pitti: it's bug #331295 [11:00] Launchpad bug 331295 in gnome-terminal "'Close this terminal' warning labels button as 'Close Window'" [Low,Fix committed] https://launchpad.net/bugs/331295 [11:00] pitti: do you want I change it? [11:01] this doesn't really match our SRU criteria, and the session fix is quite intrusive [11:01] didrocks: please; also add a real changelog line for it which refers to the bug [11:01] the "new upstream release" one should just close the sponsoring bug [11:01] pitti: ok, I am quite unconfortable to add lines that are not on NEWS file, but I will :) [11:02] pitti: do you think the gnome-session handling goes against the SRU criteria. [11:02] I don't think bug 333603 is of any SRU concern [11:02] Launchpad bug 333603 in gnome-terminal "gnome-terminal does not honor new gnome session protocol" [Medium,Fix committed] https://launchpad.net/bugs/333603 [11:02] session saving is _terminally_ broken in current gnome [11:02] heh :-) [11:03] and changing that behaviour in an SRU is not really appropriate IMHO [11:03] I'd upload that to karmic and consider it done [11:03] pitti: ok, so, we just postpone in a regular update to karmic :) [11:03] hi gentlemen [11:03] hey james_w ;) [11:03] and crevette [11:03] sorry for not very active theses days [11:03] :) [11:03] +being [11:04] salut [11:05] didrocks: ok, thanks [11:09] ember: please prepare bugs for SRUs properly (brasero) [11:09] fixing bugs to be SRU compliant is an awful lot of work for me [11:11] pitti: done. I removed also the release tag in bzr and changed the bug title. Sorry for the extra useless work in candidating it for SRU [11:11] didrocks: n/p; just be very conservative about SRUs [11:11] pitti: understood [11:14] hello everyone ! [11:22] mvo: wow, fixing all kinds of random broken universe stuff? [11:22] * pitti wishes there was a way to make the upgrade more robust instead of forcing us to do those updates [11:24] pitti: yeah, I was going over the apport-package list and noticed those issues (some pretty simple to fix) [11:24] pitti: and yes, its anoying :/ [11:25] mvo: what concerns me is that those aren't really "simple fixes" [11:25] once you do them, you need to feed them to Debian, get them applied, fix them in karmic, etc. [11:25] those aren't just "fire and forget" updates [11:25] pitti: I have some hopes for the aufs based upgrader, but that will still mean that a broken package would prevent the upgrade (it would just be a rollback) [11:25] pitti: right [11:25] and I wouldn't like you to get even more swamped in this stuff [11:25] pitti: yeah, the cost is relatively high :( [11:26] mvo: we don't do auto-upgrade tests with universe? [11:28] pitti: we have code for this, it just takes ages. I did a ugprade with a image of ~15.000 packages installed, dpkg was 500mb real mem [11:28] and reading the file list took ages [11:28] it whole thing lastet a couple of days [11:29] but we definitely should do more for karmic (there is a spec about a ec2 based tester planned) [11:29] I thought u-m already does some tricks to continue the update if there is a single broken package, or by and large ignore file conflicts [12:03] pitti: it does ignore all file conflicts and it will continue on error, but that only help if the error is not too deep down in the dependency chain [12:05] why was the gnome-terminal jaunty-proposed upload rejected? [12:14] wrong bug attribution in changelog, and general unsuitability for SRU [12:14] (I followed up in the bug) [12:17] aha, ok [12:17] I kind of assumed gnome updates where ok, but I'm fine with that [12:18] actually we only had this exception in hardy, we just continued to practice it in intrepid [12:18] and I'm still generally fine with it, but this one was a bit too intrusive for my taste [12:18] point releases should fix bugs, not fundamentally change behaviour === nhandler is now known as Guest21024 [12:46] popey, are you on [12:59] jtholmes: hi [13:00] popey, good day i just discovered last night that you are the screencasts person, nice job btw you and your team [13:01] where unfortunately the team has been somewhat dormat for a while [13:01] needs reviving [13:01] i am having problems downloading and saving any of the screencasts and wondered what i am doing wrong [13:01] any in particular? [13:02] let me get the name [13:02] lets start with installing ubuntu part 1 [13:02] they're quite old and could do with updating :) [13:02] which is on my todo list [13:03] yes but they do server a very useful purpose [13:03] I click on the download 1280X720 vorbis... and it plays but will not download any ideas [13:03] http://static.screencasts.ubuntu.com/ [13:03] grab them from there [13:04] ah, oh let me try that [13:04] http://static.screencasts.ubuntu.com/20070909_installing_ubuntu_part_1_theora_400k_vorbis_1280x720.ogg [13:04] thats probably the one you want [13:05] good thanks, one more thing have you done a wubi sc [13:05] no [13:05] ok i will let you get back to your work, thanks [13:05] np [13:10] popey question pls [13:10] fire away [13:11] at static... it still only plays doesnt download what am i doing wrong using FF [13:11] right click, save link as [13:12] so then the link is saved but how do i then get the contents to my machine [13:12] sorry, save target as :) [13:12] ok let me try thx [13:13] np [13:15] save link as is doing it not familiar with that, interesting thanks again i have a situation where i cant go to the inet to get it must have it locally appreciate you help [13:17] no problem [13:52] hey rickspencer3 [13:52] seb128: nice to see you today [13:53] nice to see you too! [13:53] did you have a good trip back in the us? [13:53] yes [13:53] good ;-) [13:53] hey rickspencer3 [13:53] I stopped in Washington D.C. to visit my new nephew [13:53] rickspencer3: enjoyed the long weekend? [13:53] yes [13:53] excellent [13:53] I love D.C. it is a wonderful city [13:54] hah, /me runs 2.6.30rc3, -intel 2.7.0 and UXA now [13:54] let's see where this leads me to [13:54] fortunately, my sister in law clearly did not want company, so had plenty of time to sight see and such [13:54] pitti: thanks for that [13:54] I hope it works [13:54] rickspencer3: I survived the first 5 minutes ;) [13:54] rickspencer3: anyway, quick update on the 965 issue [13:54] I've seen a couple of bugs related to freezes on i945 too :( [13:55] pitti: interesting but bryce_ was trying to get the hang using a virtual setting yesterday [13:55] rickspencer3: meeting on Friday didn't yield anything significant [13:55] seb128: right [13:55] and seems to confirm that it workaround the bug [13:55] at least as said I'm using a virtual setting and never got any issue [13:55] rickspencer3: setting a virtualsize by default sounds like a promising workaround right now [13:56] hmmm [13:56] * seb128 notes that I suggested that some weeks ago [13:56] seems hacky to me without knowing the root cause [13:56] rickspencer3: disabling compiz is hacky too ... [13:56] seb128: good point [13:56] if we can do that only on the 965, it's acceptable IMHO [13:56] it's not acceptable to set it as default on all intel chips, of course [13:56] what are the drawback of that? [13:56] it allows to use multiple screen too [13:56] bryce and I had a quick discussion of that, he wanted to prepare a test package and toss that back to upstraem [13:57] seb128: we don't know what it breaks on other chipsets [13:57] are they still trying to pursue the root cause though? [13:57] I meant on 965 [13:57] rickspencer3: not really, at least not on stuff which can't be reproduced on 2.7.0/uxa [13:58] so basically exa is a lost cause in their mind, and we need to mitigate until we can get users to uxa? [13:58] right [13:58] so we'll probably end up with keeping a workaround for jaunty [13:58] like setting virtualsize or whatever we come up with [13:58] right now we have no clue _why_ it works [13:59] in a way, we've worked around it now [13:59] (or whether it works for everyone, thus creating the test package) [13:59] unfortuantely, my guess with the pipe underrun patch was wrong [13:59]