| sistpoty | lamont, Laney: I've just given back haskell-src-exts on armel. (build appeared to have been terminated). Hope there's not a good reason to terminate the build | 00:33 |
|---|---|---|
| lamont | sistpoty: all the pegatron buildds are gone - I was waiting for the queue to flush before doing a mass armel giveback | 00:35 |
| sistpoty | lamont: ah, ok :)... just hoped that I wouldn't cause a problem like eglibc for sparc ;) | 00:36 |
| sistpoty | *glibc* even | 00:36 |
| Laney | sistpoty: I don't think it will work — check the Debian status | 00:38 |
| Laney | same for pandoc | 00:39 |
| lamont | sistpoty: glib2.0 | 00:39 |
| sistpoty | or that :) | 00:40 |
| lamont | mass armel giveback done | 00:41 |
| lamont | well, running | 00:42 |
| lamont | meh. 1033 builds givenback | 00:42 |
| sistpoty | Laney: hm? don't see anything particular? | 00:43 |
| sistpoty | lamont: thanks a lot! | 00:43 |
| Laney | sistpoty: you don't see all of the ftbfsen? | 00:44 |
| Laney | particularly a timeout on armel | 00:44 |
| sistpoty | Laney: oh, didn't look at build status, only at bugs | 00:45 |
| sistpoty | lamont: is the estimation of ten days on https://launchpad.net/builders/ more or less correct? | 00:46 |
| sistpoty | lamont: that would mean we're very close to the border (or even after it) where we need to close the archives for publishing afaict | 00:47 |
| lamont | well, lots of them should ftbfs quickly, no? | 00:51 |
| lamont | estimation is kinda waggy, but if folks are fixing things, we may want to keep a list of what to bump up | 00:51 |
| ScottK | lamont: Your mass giveback should all score at 0, right? | 00:53 |
| ScottK | If so, it won't interfere with any uploads. | 00:53 |
| lamont | either zero or they get rescored - I can't remember which | 00:53 |
| Laney | i'd appreciate the haskell stuff being rescored | 00:54 |
| lamont | they're all 0 now, but wouldn't hurt to check back later. IIRC, the job that would rescore them isn't running these days | 00:54 |
| ScottK | Ah. | 00:55 |
| ScottK | That's why rebuilds haven't been jumping back up. | 00:55 |
| lamont | something like that | 00:55 |
| * lamont is a bit fuzzy on the details | 00:56 | |
| wgrant | lamont: you're correct. queue-builder is no longer running, so retries will stick at 0 until someone pokes them manually. | 00:58 |
| persia | Is it a problem that they are zero? most of my requested rebuilds have been running (albeit at low priority) | 00:58 |
| wgrant | It probably isn't much of a problem, no. Even ia64 is almost OK now. | 01:01 |
| ScottK | I don't think it's a problem, it's just a change. | 01:01 |
| lamont | wgrant: if it did its sql queries a bit more granularly, we might let it run more | 01:09 |
| wgrant | lamont: The only useful thing it does, though is... nothing? | 01:10 |
| wgrant | 1) Bumps score by a few points based on time in the queue. Useless. | 01:10 |
| wgrant | 2) Rescores retries. Worse than useless. | 01:10 |
| lamont | wgrant: well, it rescores builds so non-buildd-admins can get their builds bumped back up after they retry them... so all in all, I'm not sure I care to do that | 01:10 |
| lamont | yeah - 2) is a big -555 from me | 01:10 |
| wgrant | 3) Locks thousands of buildqueue rows for aaaages and breaks the world. | 01:11 |
| persia | Just out of curiosity, why the mass-giveback? | 01:11 |
| lamont | persia: because I stabbed all of haskell after we got ghc6 to build | 01:12 |
| lamont | installing ghc6-doc on a pegatron was a great way to generate an infinite loop outside of the timeouts | 01:13 |
| persia | Ah. This makes sense. | 01:13 |
| lamont | so rather than find the 100ish packages affected, I just went all 5-blades on the problem | 01:13 |
| persia | Makes sense, although I'm expecting a good ~200 of those to ftbfs as they just failed yesterday from a not-quite-so-massive-mass-giveback :) | 01:14 |
| lamont | heh. yeah | 01:15 |
| persia | I'm also a bit surprised at the number: we only had ~150 showing on the FTBFS page. From where come the other ~800? Is it worth a similar mass-giveback of missing binaries for other architectures? | 01:15 |
| Laney | I thought haskell was almost done | 01:15 |
| * persia too | 01:15 | |
| * Laney is eyeing agda with suspicion | 01:18 | |
| wgrant | I'm not sure that buildd-mass-retry.py excludes superseded builds. | 01:18 |
| wgrant | So the numbers may be artificially high. | 01:19 |
| persia | By 800? | 01:19 |
| persia | But anyway, if the point is to throw stuff at the wall and see if it sticks because the builders are bored, it makes sense to me to do other architectures as well. | 01:20 |
| persia | (although maybe not ia64, as that likely needs considerable build-dep order unwiding to make sense) | 01:21 |
| sistpoty | persia: the idea for haskell is to throw things at the wall to get the next bits of packages back in a buildable state (since the dependency graph is quite complex) | 01:22 |
| Laney | Is that how it was done? | 01:22 |
| persia | sistpoty: I thought that's why we had http://orangesquash.org.uk/~laney/haskell-installability/armel.png | 01:22 |
| Laney | I thought we had just been giving them back individually | 01:22 |
| Laney | that's what I've been doing anyway | 01:22 |
| * persia specifically excluded haskell from the not-quite-so-massive-mass-giveback beacause of the understanding that they were being done in order | 01:23 | |
| sistpoty | persia: yep, but there are some false positivis | 01:23 |
| wgrant | lamont, persia: Yeah, buildd-mass-retry.py gives back even superseded builds, which explains the vast number. | 01:23 |
| Laney | packages which have never built will show up as installable on that graph indeed | 01:23 |
| wgrant | When buildd-manager goes to dispatch most of them, it will notice and throw them away. | 01:24 |
| persia | wgrant: So the queue should actually process fairly quickly then? | 01:24 |
| sistpoty | Laney: up to a certain point, I did, yes. then things became complex since a few buildds failed to install a -doc package (segfaulted there), probably depending on the kernel version | 01:24 |
| Laney | sistpoty: I saw that, but I'm not sure why it would happen... ghc6-doc isn't anything special is it? | 01:24 |
| Laney | is it some haddock problem? | 01:25 |
| persia | It seemed to segfault the old buildds though. | 01:25 |
| Laney | or just subarch skew | 01:25 |
| wgrant | persia: Indeed. | 01:25 |
| persia | I think it was bad silicon. The old buildds were a collection of experimental boards. | 01:25 |
| sistpoty | Laney: no idea, just that it worked in a later rebuild | 01:25 |
| Laney | fair | 01:25 |
| persia | The new buildds are semi-production development boards from what I understand. | 01:25 |
| Laney | you should me-too 527245 | 01:26 |
| Laney | would have helped us here ;) | 01:26 |
| wgrant | Yes, but that's not really easy. | 01:27 |
| persia | Needs coding thogh, and wgrant seems to be faily busy doing other incredibly useful stuff :) | 01:27 |
| Laney | I never said it was | 01:27 |
| wgrant | OK, then "Yes, but that's not really easy, and it's probably not going to be scheduled in the next decade or three." | 01:28 |
| persia | heh. | 01:28 |
| persia | Anyway, it only takes a couple hours to run thorough all the failed builds and retry the ones that fail for that reason after testing installability. | 01:29 |
| persia | Probably less if I could be bothered to script it. | 01:29 |
| lamont | Laney: I want to say unimplented instr trap or some such | 01:29 |
| lamont | frankly didn't pay much attention to it | 01:29 |
| Laney | seems like those machines were on the way out anyway | 01:30 |
| persia | lamont: On another porting note: did you get a chance to try doko's fpc debs? | 01:31 |
| lamont | not yet, will do | 01:33 |
| wgrant | lamont: You used buildd-mass-retry.py for this, right? | 01:36 |
| lamont | yep | 01:37 |
| * wgrant fixes it. | 01:37 | |
| lamont | oh, yay | 01:37 |
| lamont | fix == ?? | 01:37 |
| wgrant | lamont: It retries every failed build, even those that are long-superseded. | 01:38 |
| lamont | oh, thanks | 01:38 |
| wgrant | So the build queue looks huge, but in reality most of those builds will never hit a builder. | 01:38 |
| lamont | persia: for future bootstrap requests, note that the standard is to build debs using $whatever, then use those debs to build a chroot to statisfy build-deps, and let LP do its thing with that - so there's always a double-build | 01:55 |
| persia | lamont: Right. Unfortunately, LP doesn't have an edit feature, so I can't ever change that request, but I'll fail to mention it again when we get the next new architecture. | 01:56 |
| lamont | heh | 01:57 |
| lamont | no worries | 01:57 |
| lamont | armel build running | 01:58 |
| persia | Cool, thanks. | 02:00 |
| persia | With luck, we'll have fpc before the set of stuff that build-depends on it attempts rebuild again :) | 02:00 |
| ScottK | Speaking of boot strapping... | 02:01 |
| ScottK | lamont: Any thoughts about dealing with eigenbase-farrago and eigenbase-resgen? | 02:01 |
| ScottK | At least it's arch all, so it only needs doing once. | 02:02 |
| lamont | dunno | 02:02 |
| lamont | fire something at rt.ubuntu.com? | 02:03 |
| lamont | most notably, wiht instructions that work | 02:04 |
| ScottK | Nevermind then. Whining on IRC is about the most caring I can muster. | 02:05 |
| lamont | heh | 02:06 |
| lamont | well, throw your whine at rt.u.c and we'll make that the testcase for my docs, then | 02:06 |
| ScottK | OK. | 02:07 |
| lamont | I'll throw in the extra instr that might be needed. and yeah, bootstrapping is something that at least needs an RT request | 02:08 |
| ScottK | lamont: RT 10582 | 02:10 |
| lamont | ta | 02:10 |
| lamont | thanks, even | 02:10 |
| slangasek | ArneGoetje: ttf-kacst-one has a conflict with the version of ttf-kacst we have in the archive; this will make DVDs unbuildable | 04:15 |
| ArneGoetje | slangasek: ok, will update ttf-kacst | 06:13 |
| slangasek | ArneGoetje: thanks (btw, ttf-kacst-one also had a Recommends: ttf-kacst, which I've gotten rid of) | 07:08 |
| Keybuk | the idea of recommends on fonts amuses me | 07:12 |
| Keybuk | that's like ttf-arial recommends ttf-times-new-roman just because they're usually used together | 07:12 |
| slangasek | "users who like these wingdings also enjoyed..." | 07:13 |
| Keybuk | heh | 07:17 |
| micahg | thanks for dojo slangasek | 07:17 |
| Keybuk | ttf-ms-comic-sans Recommends euthanasia | 07:17 |
| slangasek | micahg: thanks to ScottK - I just pushed the button :) | 07:18 |
| slangasek | mdke: hi, do you have an ETA for final uploads of ubuntu-docs and gnome-user-docs for 10.04? | 07:28 |
| tjaalton | slangasek: am i pushing too far, or should we get the final round of changes from debian xserver & input drivers? :) (xorg.conf.d moved to /usr/share/X11, and allows admins to have stuff in /etc/X11/xorg.conf.d) | 07:49 |
| tjaalton | slangasek: the xserver is also an rc for 1.7.7, though we already had most of the relevant bugfixes as separate patches | 07:50 |
| ArneGoetje | slangasek: https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst/ttf-kacst-lucid/+merge/23625 and https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-kacst-one/ttf-kacst-one-lucid/+merge/23624 | 07:53 |
| hunger | Anyone else getting somany "Do not show this message again" buttons in the connect/disconnect notifications that the network connected to is no longer visible since the left side of the notice is pushed off screen? | 08:22 |
| hunger | This is in lucid. | 08:23 |
| peteris | mdke, here? | 08:39 |
| === Lutin_ is now known as Lutin | ||
| === lool- is now known as lool | ||
| mdke | peteris: hi | 09:39 |
| mdke | peteris: yesterday at about 14:30 | 09:40 |
| peteris | allright, mixed up days :) | 09:43 |
| peteris | nevermind | 09:43 |
| mdke | peteris: you can send me a po file if it's important | 09:44 |
| peteris | well, it's more like 5 ot 6 po files :) | 09:45 |
| peteris | and they are in LP | 09:45 |
| peteris | mdke, nevermind then, I'm more interested if I could get them in the future 10.04.1 release | 09:47 |
| mdke | peteris: we'll certainly do an update this time | 09:48 |
| peteris | mdke, you mean on .1 release? | 09:49 |
| baptistemm | hello | 09:49 |
| mdke | peteris: yes, before that | 09:51 |
| peteris | cool | 09:52 |
| peteris | mdke, .1 will be propably in the end of Juny, right? | 09:59 |
| slangasek | ArneGoetje: you can't delete a file from the upstream source in a package: dpkg-source: warning: ignoring deletion of file KacstOne.ttf | 10:05 |
| slangasek | tjaalton: it's pretty late, but I would consider the xorg.conf.d change as time permits if you upload it | 10:07 |
| mdke | slangasek: today is the aim | 10:09 |
| slangasek | mdke: ok, cool | 10:10 |
| === \vish is now known as vish | ||
| === lucas_ is now known as lucas | ||
| joaopinto | slangasek, we have found the issue with that dell upgrade, about 48 h later :P | 10:58 |
| joaopinto | "none /proc/bus/usb usbfs devgid=127,devmode=664 0 0" on /etc/fstab caused an error on mountall which somehow leads to upstart hanging | 10:59 |
| slangasek | ah, that bug | 11:02 |
| tjaalton | slangasek: yep, the server has Breaks and bumps serverminver to minimize any damage | 11:03 |
| slangasek | joaopinto: well, that should be assigned to the mountall package, then; I thought there was an open bug report about it, but I don't see it now | 11:03 |
| joaopinto | well, it will affect all users which have followed https://help.ubuntu.com/community/VirtualBox/USB | 11:03 |
| joaopinto | ok, will do | 11:04 |
| slangasek | er, well, that documentation should be fixed then, because /proc/bus/usb doesn't work in 10.04, period | 11:05 |
| joaopinto | slangasek, right, but having a system hanging without any clue after an upgrade can't be blamed to that doc | 11:07 |
| joaopinto | :P | 11:08 |
| slangasek | yes, that part is a mountall bug | 11:12 |
| joaopinto | at least now I know how to step by step uptart tasks :) | 11:14 |
| joaopinto | I have updated bug 565109 description | 11:18 |
| ubottu | Launchpad bug 565109 in ubuntu "Upgrading from 9.10 to 10.04 on Dell Inspiron 6400 makes the system unbootable" [Undecided,New] https://launchpad.net/bugs/565109 | 11:18 |
| joaopinto | hum, cache ? | 11:18 |
| joaopinto | ubottu, refresh | 11:18 |
| ubottu | Remember that every time you hit refresh, Canonical is wasting money, bandwidth, and CPU time serving your request instead of doing useful things like uploading the image or paying for ShipIt disks. Please do so sparingly. | 11:18 |
| joaopinto | lol | 11:18 |
| tormod | joaopinto, will you paste those step-by-step instructions to a wiki page, please? | 11:27 |
| joaopinto | tormod, yes. I am just thinking that it migh worth a different page, that page we have describes the boot process, while this new one would be troubleshoot oriented | 11:27 |
| joaopinto | a single page would probably get too long | 11:28 |
| tormod | sure, make a new page | 11:28 |
| tormod | maybe it eventually should go to the upstream upstart wiki | 11:29 |
| tormod | but having such instructions somewhere in any form would be a huge improvement | 11:30 |
| joaopinto | hum, is there a good reason for the recovery option to start mountall ? | 11:40 |
| joaopinto | it's chain of events is likely to bring problems from which you want to recover from | 11:45 |
| slangasek | NCommander, ccheney: OOo FTBFs on armel with a debian/rules bug | 11:48 |
| slangasek | dh_gencontrol -popenoffice.org-pdfimport -- \ | 11:48 |
| slangasek | -v1.0+OOo`echo 1:3.2.0-7ubuntu1 | cut -d: -f2` | 11:48 |
| slangasek | dpkg-gencontrol: error: current host architecture 'armel' does not appear in pac | 11:48 |
| slangasek | kage's architecture list (i386 m68k mips mipsel powerpc s390 alpha amd64 hppa ia | 11:48 |
| slangasek | 64 ppc64 s390x sparc) | 11:48 |
| slangasek | ccheney: the OOo source package doesn't seem to be in sync with the bzr branch | 12:13 |
| slangasek | ccheney, NCommander: I've uploaded what I believe should be a correct fix for the OOo FTBFS - no conceivable way for me to build-test it, but it looks like the new armel buildds can fail to build OOo in < 2 days now... | 12:20 |
| sladen | mvo: https://bugs.launchpad.net/bugs/516727 appears still to be an upgrade breaker, even with the update-manager tweaks | 12:29 |
| ubottu | Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Fix released] | 12:29 |
| wgrant | Odd. My Lucid laptop has been thrashing sometimes lately (no swap), and I just watched it OOM kill several things with well over 2GiB of the 4GiB of RAM apparently used as disk cache. | 12:54 |
| wgrant | drop_caches does not reduce that volume :( | 12:55 |
| james_w | wgrant: ogra is having similar sounding issues in bug 563879 | 12:58 |
| ubottu | Launchpad bug 563879 in evolution-data-server "evolution-data-server consumes massive amounts of memory, invokes OOM killer" [Undecided,Confirmed] https://launchpad.net/bugs/563879 | 12:58 |
| wgrant | Hmm. | 12:59 |
| wgrant | wgrant@magrathea:~/launchpad/lp-branches/bug-565739-dont-retry-superseded-builds$ cat /proc/dri/0/gem_objects | grep object\ bytes | 12:59 |
| wgrant | That cannot be normal. | 12:59 |
| wgrant | -1296973824 object bytes | 12:59 |
| wgrant | It also looks like almost 3GB when interpreted unsigned. | 13:00 |
| james_w | certainly sounds suspicious | 13:00 |
| tormod | wgrant, sarvatt also saw this gem_object wrapping negative | 13:11 |
| hyperair | wgrant: that sounds like an ancient i915 bug. | 13:12 |
| hyperair | i used to see that. | 13:12 |
| tormod | and vish in bug 563400 has more > 1gb gem (on ATI) | 13:12 |
| ubottu | Launchpad bug 563400 in xserver-xorg-video-ati "[RV515] Playing flash video causes memory hogging" [Undecided,New] https://launchpad.net/bugs/563400 | 13:12 |
| hyperair | wgrant: try using a newer kernel and see if that happens | 13:13 |
| hyperair | wgrant: also, restarting X should clear this gem_object madness | 13:13 |
| tormod | hmm ogra is also using chromium, like vish was | 13:14 |
| wgrant | hyperair: It has cleared it, yes. | 13:15 |
| wgrant | I had a similar thing around the GEM switch. | 13:15 |
| wgrant | But not significantly since. | 13:15 |
| wgrant | I don't use Chromium much, but I did use it at one point during that session. | 13:16 |
| hyperair | wgrant: so did i. and ever since the bug was fixed upstream, i've used a custom kernel, and have never had this problem again | 13:16 |
| hyperair | wgrant: i found that it needed somewhere around one X restart a day, during the time of that problem | 13:16 |
| hyperair | wgrant: we're shipping an old DRM stack aren't we? | 13:17 |
| wgrant | hyperair: I had to restart X multiple times a day. | 13:17 |
| wgrant | But it hasn't been that bad since -- maybe once a week? | 13:17 |
| tormod | hyperair, we're shipping a .33.2 drm stack | 13:17 |
| hyperair | tormod: weird, i could have sworn .33 had it all fixed.. | 13:18 |
| wgrant | (this is a GM45, btw) | 13:18 |
| hyperair | and mine a 965GM | 13:18 |
| hyperair | regression perhaps? | 13:18 |
| hyperair | wgrant: there's an option in driconf about buffer object reuse | 13:18 |
| hyperair | perhaps that is related? | 13:18 |
| wgrant | I guess I should get something to monitor the GEM memory usage and scream if it jumps suddenly. | 13:19 |
| wgrant | Although I guess it's more likely to be a cumulative problem. | 13:19 |
| hyperair | wgrant: from my experiences during that time, it never jumped suddenly. | 13:20 |
| hyperair | something like a terminal open with watch cat /proc/dri/0/gem_objects would do | 13:20 |
| wgrant | That is exactly what I've been doing, yeah. | 13:21 |
| tormod | the gem objects are allocated all the time, that is normal, but it seems they are not all deallocated | 13:27 |
| wgrant | Right. | 13:27 |
| tormod | every time I open a youtube fan in firefox and close it again, firefox has grown 2MB, gem count as well. after closing firefox, I got only 1MB back there | 13:33 |
| tormod | for t in `seq 1 10`; do firefox ; grep "object bytes" /sys/kernel/debug/dri/0/gem_objects; done # and press ctrl-Q's | 13:38 |
| tormod | I can use e.g. eog /usr/share/backgrounds/ instead of firefox | 13:42 |
| joaopinto | slangasek, I am still playing with the mountall issue, it seems to be related to bug 553290 | 13:45 |
| ubottu | Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Fix committed] https://launchpad.net/bugs/553290 | 13:45 |
| wgrant | tormod: So it looks like a general thing -- just Flash is really good at it? | 13:45 |
| joaopinto | ops, wait, maybe not, this is a side effect of starting the mountall manually, I am hitting this bug | 13:46 |
| tormod | wgrant, yes even "xterm" does the job | 13:46 |
| tormod | and X does not grow | 13:46 |
| joaopinto | I get both a failed mount, and skipping mount | 13:46 |
| joaopinto | looping | 13:46 |
| wgrant | tormod: Hmm, indeed. That grew the GEM object size by 100MB, and it has not decreased. | 13:47 |
| wgrant | At least we can easily reproduce it now... | 13:47 |
| wgrant | This really reminds me of the early days. | 13:48 |
| wgrant | But I cannot remember exactly when it started happening again. | 13:48 |
| === steffan_ is now known as steffan | ||
| tormod | the early days when we had flies amid the vacuum tubes? | 13:49 |
| wgrant | tormod: Heh, not going *quite* that far back. | 13:50 |
| tormod | you can also track it here: awk '/name/{ i++; s+= $4 } END{print i " " s}' /sys/kernel/debug/dri/0/gem_names | 13:55 |
| === |sistpoty| is now known as sistpoty | ||
| wgrant | Which are we treating as the One True Bug? | 13:57 |
| tormod | none I think , they are all blaming different things. the "-ati" bug even got "fixed" by an ati release, then reopened | 13:58 |
| wgrant | Yeah, I saw that... | 13:59 |
| wgrant | Anyway, I'm sort of glad that I'm not alone and/or crazy. | 13:59 |
| === _silentAssassin is now known as mrigesh | ||
| === mrigesh is now known as _silentAssassin | ||
| === azeem_ is now known as azeem | ||
| vish | yay ,I'm not alone.. :p | 15:08 |
| vish | wgrant: so the bug is actually in which package? Bug 563400 is not -ati? | 15:09 |
| ubottu | Launchpad bug 563400 in xserver-xorg-video-ati "[RV515] Playing flash video causes memory hogging" [Undecided,New] https://launchpad.net/bugs/563400 | 15:09 |
| juliank | Why don't I have the permission to access bug 538253? | 15:15 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/538253) | 15:15 |
| azeem | juliank: could be an security issue, some of them are private AFAIK | 15:18 |
| vish | juliank: seems no one other than the reporter are subscribed | 15:18 |
| vish | or maybe what azeem said .. | 15:19 |
| === elleuca is now known as elleuca_ | ||
| juliank | azeem, vish - "There was a changelog entry: - make sure to record the maintainer script that requested the reboot in /var/run/reboot-required.pkgs (LP: #538253)" , and now I don't know the reason for it. | 15:20 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/538253) | 15:20 |
| === elleuca_ is now known as elleuca | ||
| juliank | that's bad. | 15:20 |
| tormod | wgrant, vish, I thought I would make a master bug 565981, although I do not know if this gem count really pinpoints the issue | 15:23 |
| ubottu | Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981 | 15:23 |
| vish | wfm :) | 15:24 |
| strange | is this the place to discuss bugs? | 15:36 |
| tormod | strange, in most cases not, try #ubuntu or (#ubuntu+1 for lucid) | 15:37 |
| strange | i've tried #ubuntu thats a no go heh | 15:37 |
| SwedeMike | strange: if you have registered a bug on launchpad, going to #ubuntu-bugs might help. | 15:38 |
| strange | ok thank you | 15:39 |
| joaopinto | slangasek, isn't bug 543251 a duplicate from bug 507881 ? | 16:18 |
| ubottu | Launchpad bug 543251 in mountall "mountall causes boot-up to hang on unknown fstab entry" [Medium,Incomplete] https://launchpad.net/bugs/543251 | 16:18 |
| ubottu | Launchpad bug 507881 in mountall "Lucid alpha 2 fails to start up unless you remove /proc/bus/usb from the fstab" [Medium,Confirmed] https://launchpad.net/bugs/507881 | 16:18 |
| ArneGoetje | slangasek: I have new language-packs ready... do you want them? | 17:08 |
| nhandler | ScottK: Bug #564070 has a debdiff | 17:22 |
| ubottu | Launchpad bug 564070 in libgtk2-perl "Please sync libgtk2-perl from Debian (fixes FTBFS)" [Wishlist,In progress] https://launchpad.net/bugs/564070 | 17:22 |
| joaopinto | mountall/plymouth is seriously broken :( | 17:22 |
| Keybuk | joaopinto: WFM | 17:29 |
| joaopinto | Keybuk, it means I have been playing with it the last couple of hours and is not reliable :P | 17:29 |
| joaopinto | my last experiment was with some invalid entry on /etc/fstab, wrong filesystem type, missing mount poing, .. tested several reboots, and it just hang on the splash screen | 17:31 |
| joaopinto | on my last reboot it did show the failure prompt (as expected) | 17:31 |
| Keybuk | joaopinto: it's worked for me reliably every time | 17:32 |
| joaopinto | Keybuk, being reliable for you that dot make it reliable in general :) | 17:32 |
| Keybuk | being unreliable for you doesn't make it unreliable in general | 17:32 |
| Keybuk | joaopinto: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html | 17:32 |
| joaopinto | Keybuk, I am not alone, anyway this comes from debugging the virtualbox proc usb issue | 17:33 |
| joaopinto | which is affecting >20 people :P | 17:33 |
| Keybuk | I'm sorry, but my INBOX disagrees with you | 17:33 |
| persia | So, let's not argue about this. | 17:34 |
| Keybuk | the only know triaged bug with mountall is with NFS root filesystems | 17:34 |
| persia | joaopinto: Please file detailed bugs. | 17:34 |
| joaopinto | Keybuk, it's hard for your INBOX to get mails from unskilled people which can't boot a system ;) | 17:34 |
| joaopinto | persia, I am just commenting, the bugs are filled, I am not complaining, I am just expressing myself | 17:34 |
| persia | Keybuk: Please acknowledge that mountall is very fast, but not necessarily careful at protecting users from shooting themselves in the foot with the right configuration. | 17:34 |
| Keybuk | joaopinto: do you have --debug output from a boot? | 17:34 |
| Keybuk | persia: I do not acknowledge that, I spent a very long time making mountall *careful* | 17:35 |
| joaopinto | Keybuk, I tried --debug, I got the debug on the console after hitting "ESC", which got me in text mode, but /var/log/boot.log was empty | 17:36 |
| Keybuk | joaopinto: bug #507881 ? | 17:36 |
| ubottu | Launchpad bug 507881 in mountall "Lucid alpha 2 fails to start up unless you remove /proc/bus/usb from the fstab" [Medium,Incomplete] https://launchpad.net/bugs/507881 | 17:36 |
| joaopinto | Keybuk, bug 507881 is reproducible on a virtualbox system | 17:36 |
| joaopinto | yup, that was I have spent more time with | 17:36 |
| Airells | hi , i have created simple app using qtcreator ( gui app ) what is the simplest way to create .deb now ? dh-make ? | 17:37 |
| Keybuk | I just commented on that asking for more information | 17:37 |
| joaopinto | then I decided to play with random errors on fstab, with random results | 17:37 |
| * Keybuk doesn't have virtualbox | 17:37 | |
| joaopinto | Keybuk, I am reinstalling my vbox with a daily cd, I played too much with my /etc/init :P | 17:38 |
| persia | Airells: Depending on your taste, either that, or manual generation of the 4 packaging files: the folks in #ubuntu-packaging would be glad to help you through it. | 17:38 |
| Airells | pecisk thx | 17:38 |
| Airells | persia thx | 17:38 |
| joaopinto | Keybuk, but I have tried "/something /somewhere somefs defaults 0 0" on my real hw :P | 17:39 |
| Keybuk | hmm | 17:41 |
| Keybuk | when it hangs, where does it hang? | 17:41 |
| joaopinto | Keybuk, wouldn't be safer for the recovery mode to not trigger mountall ? | 17:41 |
| joaopinto | Keybuk, mountall | 17:41 |
| Keybuk | not really, cause then you wouldn't get any mounted filesystems ;) | 17:42 |
| Keybuk | no, I mean where in the boot process? | 17:42 |
| Keybuk | what do you see on screen? | 17:42 |
| joaopinto | Keybuk, at that time you do have the root filesystem, mounted from the jernel, that's "recovery" ;) | 17:42 |
| joaopinto | ah, splash screen | 17:42 |
| joaopinto | always moving | 17:42 |
| Keybuk | so you do see the splash screen? | 17:42 |
| joaopinto | yes | 17:42 |
| joaopinto | btw, ATI fglrx | 17:42 |
| Keybuk | that's kooky then | 17:42 |
| joaopinto | Keybuk, recovery would be safer without mountall, because as you know it triggers several services, making optional (the personc could issue the start for it) would make it usable on more cases | 17:46 |
| joaopinto | the mountall could even be an option on the recovery menu | 17:47 |
| Keybuk | joaopinto: we're kinda getting rid of the "current" recovery mode | 17:47 |
| Keybuk | since mountall does a large part of it already | 17:48 |
| Keybuk | e.g. when filesystems fail, mountall lets you run fsck -y, or skip them, etc. | 17:48 |
| * persia is impressed by the detailed set of special-casing in mountall, and clearly ought check fresher code before making accusations based on hearsay. | 17:48 | |
| Keybuk | persia: that's why I get frustrated at people; mountall is about a thousand times *better* than the crappy shell scripts we had before | 17:48 |
| Keybuk | sure, there might be bugs, but it's not a crap piece of code - it's a very carefully planned and written piece of code :p | 17:49 |
| persia | Indeed. I always agreed it was better. I just didn't think it was perfect yet. | 17:49 |
| Keybuk | well, no code is ever perfect | 17:49 |
| Keybuk | the only perfect code is the code you've removed | 17:49 |
| joaopinto | Keybuk, so there will be another option to boot with minimal services ? as I see it recovery is not mainly for fs recovery, it has a large use for services related recovery | 17:49 |
| persia | heh | 17:49 |
| Keybuk | joaopinto: I think we'll have something like | 17:49 |
| Keybuk | Start apache [y/n/d/?] | 17:49 |
| Keybuk | Received starting apache event, Start tomcat? [y/n/d/?] | 17:50 |
| Keybuk | et.c | 17:50 |
| joaopinto | ah, that would be great | 17:50 |
| joaopinto | brb, installing the vbox, will try to get that log | 17:50 |
| Keybuk | joaopinto: http://launchpadlibrarian.net/44707171/2010-04-18%2009.46.53.jpg | 17:52 |
| Keybuk | that's what you're supposed to see | 17:52 |
| ion | My plymouth doesn’t show the shirt. :-( | 17:53 |
| Keybuk | ion: you have to buy that separately | 17:53 |
| nigelb | Keybuk, :) | 17:55 |
| Keybuk | Processed 265456 of 577332 files (12h 45m 58s remaining). | 17:57 |
| Keybuk | whew.... | 17:57 |
| ScottK | nhandler: I've got no keys for several hours, so please subscribe ubuntu-sponsors and I'll look at it when I get back to my keys if no one else does. | 18:00 |
| ion | keybuk: What’s that? | 18:01 |
| Keybuk | ion: importing my e-mail into notmuch | 18:01 |
| Keybuk | then going to run some experiments as to just how fast it is | 18:02 |
| ion | Ah | 18:02 |
| Keybuk | and if it's as awesomely fast as I hope, stick webkit on the front and write a GUI | 18:02 |
| Keybuk | I did some experiments on Friday | 18:05 |
| Keybuk | it suggested "all unread emails from Launchpad on bugs that I'm assigned to, and include the rest of the threads" would be of the order of a quarter of a second to run | 18:06 |
| joaopinto | Keybuk, pristine install on a vbox after adding the proc usb line: http://www.ubuntu-pics.de/bild/52848/screenshot_003_3Ouok9.png | 18:09 |
| Keybuk | ah | 18:10 |
| joaopinto | Keybuk, and just to be clear, I am testing on a virtualbox environment, but the original reportees where using real systems | 18:10 |
| Keybuk | now that's more like what I'd expect | 18:10 |
| Keybuk | when you said you saw the splash screen, that confused me | 18:10 |
| joaopinto | Keybuk, that is another case, the invalid entry | 18:10 |
| joaopinto | one bug at a time :) | 18:11 |
| Keybuk | can you give an example of "invalid entry" ? | 18:11 |
| joaopinto | let me try it on virtualbox now | 18:11 |
| Keybuk | also what kind of invalid entry are you putting in? | 18:11 |
| joaopinto | /something /somewhere somefs defaults 0 0 | 18:11 |
| Keybuk | hmm | 18:12 |
| joaopinto | assume it to be a major typo ;) | 18:12 |
| Keybuk | and that one you see a blank splash screen? | 18:12 |
| Keybuk | with little animated dots? | 18:12 |
| joaopinto | on that I see the blash screen with the animated dots | 18:12 |
| Keybuk | right | 18:12 |
| Keybuk | now | 18:12 |
| Keybuk | can you do this: | 18:12 |
| Keybuk | echo FRAMEBUFFER=y >> /etc/initramfs-tools/conf.d/splash | 18:12 |
| Keybuk | update-initramfs -u | 18:12 |
| Keybuk | (as root obv.) | 18:12 |
| Keybuk | then try both the usbfs and somefs cases | 18:13 |
| === yofel_ is now known as yofel | ||
| joaopinto | Keybuk, nothing changed for the usbfs case | 18:23 |
| Keybuk | joaopinto: you don't see any splash screen?! | 18:25 |
| joaopinto | usbfs case, no , still hanging on the initial text mode | 18:26 |
| dupondje | http://paste.ubuntu.com/417152/ => what is this ? :s | 18:26 |
| joaopinto | Keybuk, both usbfs and random entry on /etc/fstab result in the text mode screen without any output | 18:30 |
| joaopinto | the splash vs no splash are related to VM/Real system | 18:30 |
| Keybuk | but there should be no initial text mode if you set that FRAMEBUFFER=y | 18:31 |
| joaopinto | Keybuk, ops, my mistake, addng the framebuffer now | 18:35 |
| Keybuk | ;) | 18:35 |
| joaopinto | Keybuk, it would be nice to have an option to provide a different tasks config location, like, --initdir=/etc/init.custom | 18:37 |
| joaopinto | it would be a simple way to use different profiles | 18:37 |
| Keybuk | well, different profiles there's a proposal for | 18:37 |
| Keybuk | but that's not a bad idea for testing | 18:37 |
| joaopinto | I had a bad time moving all the confs out of the regular tree and moving them back for testing :\ | 18:38 |
| Keybuk | yeh | 18:39 |
| Keybuk | can you file a wishlist bug on that http://launchpad.net/upstart | 18:39 |
| joaopinto | Keybuk, I get the splsh and the error prompt now | 18:39 |
| joaopinto | splash | 18:39 |
| Keybuk | do you get it for both usbfs and somefs? | 18:39 |
| joaopinto | yes | 18:41 |
| Keybuk | sweet | 18:41 |
| Keybuk | then I know what causes both of these | 18:41 |
| Keybuk | they're technically different bugs | 18:41 |
| joaopinto | great :) | 18:44 |
| Keybuk | the somefs one is simply a race | 18:44 |
| Keybuk | mountall sends the messages, but plymouth isn't running | 18:44 |
| Keybuk | so they never get there | 18:44 |
| Keybuk | and when plymouth starts, it doesn't resend | 18:44 |
| Keybuk | but the usbfs one is more tricky | 18:45 |
| joaopinto | ok, that explains while I got a random prompt once booting from my real system | 18:45 |
| Keybuk | because usbfs is a nodev filesystem, it holds up the "virtual-filesystems" event | 18:45 |
| Keybuk | which is what causes drivers to be loaded | 18:45 |
| joaopinto | I checked the code, TAG_VIRTUAL, the wait rule applies :) | 18:45 |
| Keybuk | which means if it's holding up the boot, then the graphics drivers never get loaded | 18:45 |
| Keybuk | so plymouth is never shown | 18:45 |
| joaopinto | can't an exception be added, like there is one for fuse ? | 18:46 |
| joaopinto | I mean, for the usbfs case, assuming it can be ignored | 18:46 |
| Keybuk | well, it'd be an exception for a filesystem that we don't recognise anymore | 18:46 |
| Keybuk | that might be a workaround | 18:46 |
| Keybuk | also the FRAMEBUFFER=y thing | 18:46 |
| Keybuk | I'll talk to slangasek when he's up | 18:46 |
| Keybuk | since this becomes an RM decision at this point in the release | 18:46 |
| joaopinto | someone else was suggesting to strip usbfs's on the upgrade process, that's an option | 18:47 |
| joaopinto | people adding usbfs to a new system will most likely understand that caused the hang | 18:48 |
| joaopinto | or maybe not :) | 18:48 |
| Keybuk | right | 18:48 |
| Keybuk | though other mistakes can cause this too :-/ | 18:48 |
| joaopinto | the main issue for "end users" is that there is no message to understand the cause | 18:51 |
| Keybuk | sure | 18:51 |
| Keybuk | but that's the bug | 18:51 |
| Keybuk | it's not that there's no message | 18:51 |
| Keybuk | the bug is that the message isn't getting on the screen ;-) | 18:51 |
| joaopinto | it's a chicken and egg problem | 18:55 |
| === frikinz_ is now known as frikinz | ||
| === radoe_ is now known as radoe | ||
| Damascene | hello, there is a problem with ogv in ubuntu recordmydesktop at least | 19:13 |
| Damascene | http://www.google.pl/support/forum/p/youtube/thread?tid=7b9148c46c6b6f90&hl=en&safe=active | 19:13 |
| persia | Damascene: Are you sure that's a bug in Ubuntu? Looks like a bug in YouTube to me. | 19:18 |
| Damascene | you can try it your self persia | 19:18 |
| Damascene | ffmpeg -i video.ogv video.avi | 19:19 |
| Damascene | see if it works | 19:19 |
| persia | Well, if it doesn't, file a bug. | 19:20 |
| Damascene | I tried it doesn't you should try now | 19:21 |
| Damascene | I need confirmation | 19:21 |
| Damascene | maybe it's in recordmydesktop | 19:21 |
| Damascene | persia, any luck? | 19:28 |
| tjaalton | slangasek: ok, here you go (didn't upload straight to the archive) https://launchpad.net/~tjaalton/+archive/test/+packages | 19:29 |
| persia | No. I don't have a source video, and I'm working on something else. The best way to get the confirmation you want is to file a bug, as I said. | 19:29 |
| Damascene | np. I just though you are trying to reproduce | 19:30 |
| popey | Damascene: i can help you reproduce this | 19:41 |
| Damascene | thanks | 19:41 |
| popey | looks like a bug in ffmpeg or gstreamer to me | 19:42 |
| Damascene | and youtube is using them? | 19:43 |
| popey | Damascene: i just recorded a video with gtk-recordmydesktop and it plays fine in mplayer | 19:43 |
| Damascene | yeah it plays fine in totem to | 19:43 |
| popey | Damascene: i then used ffmpeg to convert to avi as you just suggested, and tried playing that in mplayer and it looked bad | 19:43 |
| Damascene | *too | 19:43 |
| Damascene | same here | 19:43 |
| popey | right, so my guess is ffmpeg or gstreamer or some libavcodec bit, not gtk-recordmydesktop | 19:44 |
| Damascene | how to make sure? | 19:45 |
| popey | well the fact that the video which gtk-recordmydesktop plays fine, and only corrupts after ffmpeg touches it is a clue | 19:45 |
| popey | I'd file a bug in ffmpeg if I were you | 19:45 |
| Damascene | and youtube is using ffmpeg? | 19:47 |
| popey | i dont know | 19:49 |
| popey | Damascene: I tend to upload to blip.tv and have them send the video to youtube and that works okay | 19:54 |
| Damascene | by the way do you know any open source video hosting? | 19:55 |
| popey | blip.tv hosts ogv | 19:55 |
| Damascene | or only technical stuff | 19:55 |
| popey | http://ubuntuscreencasts.blip.tv <- those videos are ogv which I uploaded to blip.tv | 19:55 |
| Damascene | was that your sound? | 20:03 |
| popey | was what my sound? | 20:04 |
| YokoZar | Did human-theme disappear off the CD? | 20:05 |
| Damascene | yes | 20:06 |
| Damascene | popey, | 20:07 |
| popey | Damascene: can you please explain, your short sentences are hard to parse | 20:07 |
| Damascene | I'm just asking if that is your sound in the video | 20:08 |
| popey | which video? :) there are lots | 20:08 |
| popey | I'm the one talking in the releases one | 20:08 |
| Damascene | that was really good | 20:10 |
| popey | thanks. i didnt make the video, i just did the audio | 20:10 |
| popey | YokoZar: just booted a live cd in testdrive and yes, human is not there | 20:13 |
| Damascene | that was the thing I'm talking about | 20:13 |
| YokoZar | popey: That's bad, it was one of our best themes (honestly I'm still using it due to window buttons) | 20:14 |
| * popey quite likes radiance | 20:14 | |
| popey | ar | 20:15 |
| popey | no, the other one | 20:15 |
| popey | :) | 20:15 |
| popey | I think they're named the wrong way round "radiance" makes me think dark for some reason. | 20:15 |
| spy6 | hi there | 20:28 |
| spy6 | how is the procedure to sync a package from unstabe to lucid? | 20:29 |
| spy6 | (cause https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781) | 20:29 |
| ubottu | Launchpad bug 565781 in ipplan "ipplan incompatible with php 5.3" [Undecided,Confirmed] | 20:29 |
| persia | !sync | 20:30 |
| ubottu | Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess | 20:30 |
| spy6 | persia: i did read this | 20:30 |
| persia | OK. What part is confusing? | 20:31 |
| spy6 | but its not very usefull, cause luvid is in freeze | 20:31 |
| spy6 | lucid | 20:31 |
| spy6 | there is no "resync from new debian version" documented | 20:31 |
| persia | Oh, just get a freeze exception, which tends to be easy for stuff that's completely broken. | 20:32 |
| spy6 | in case of freeze | 20:32 |
| persia | !ffe | 20:32 |
| ubottu | Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process. | 20:32 |
| persia | Mind you, if there's lots of *other* changes, it may need a cherrypick rather than a sync. | 20:32 |
| spy6 | persia: there just minor changes beside the fix | 20:32 |
| persia | Well, get input fom the release team. Sometimes they want a sync, and sometimes they want cherrypick. | 20:33 |
| spy6 | persia: sorry, i don't have a clue about ubtunu stuff, i'm just the debian maintainer | 20:34 |
| persia | spy6: OK. So, we have two options: I'm happy to explain how to do this, or I can do it for you. Which would you prefer? | 20:35 |
| spy6 | persia: dunno, i'm open for new stuff ... but the proble is just, lucid is not far ;) | 20:35 |
| persia | OK. So the way we usually get input from the release team is to file a bug with "FFE" in the title (or edit a bug title), and subscribe "ubuntu-release". | 20:36 |
| persia | The release team with ack it, reject it, or ask for more input (usually within 24 hours). | 20:37 |
| persia | If you get an ACK, then subscribe ubuntu-sponsors, and someone will push it to the archive admins to get it synced. | 20:37 |
| spy6 | okay ... so i add heading "FFE" into the title? | 20:37 |
| persia | Yep | 20:37 |
| persia | (and if you get stuck, or you think the process is stuck, come back here, and we can fix it) | 20:38 |
| spy6 | hmm ... what about the sponsor list? just looking if someone is pushing it? | 20:38 |
| persia | So first you want to subscribe "ubuntu-release" to get feedback from the release team. | 20:42 |
| persia | Once you have approval, then subscribe "ubuntu-sponsors" to ask someone to upload. | 20:42 |
| persia | (both using the "Subscribe someone else" button) | 20:42 |
| spy6 | persia: which button? I'm on the mailman interface of lists.u.c | 20:45 |
| persia | spy6: At https://bugs.launchpad.net/ubuntu/+source/ipplan/+bug/565781 | 20:45 |
| ubottu | Launchpad bug 565781 in ipplan "FFE: ipplan incompatible with php 5.3" [Undecided,Confirmed] | 20:45 |
| persia | You want to subscribe the team to the bug in launchpad. Whether you want to subscribe to the team mailing list is entirely unrelated :) | 20:46 |
| spy6 | ah ... i contacts add to the bugreport | 20:46 |
| spy6 | i though i should subscribe to a mailinglist ;) | 20:47 |
| persia | Sorry for the confusion. You may also subscribe the the maillinglist if you like, but that's up to you and unrelated to getting approval. | 20:47 |
| spy6 | damn, i just have to revert from the subscription ;) | 20:47 |
| spy6 | okay ... i got it | 20:48 |
| spy6 | persia: many thanks | 20:48 |
| persia | spy6: Looks right from here. Come ask again if you don7t get feedback in the bug in a reasonable time. | 20:49 |
| spy6 | great :) | 20:50 |
| * _silentAssassin is away: I'm busy | 20:53 | |
| persia | !away > _silentAssassin | 20:55 |
| ubottu | _silentAssassin, please see my private message | 20:55 |
| * _silentAssassin is away: sleeping | 20:56 | |
| Damascene | hi again. I used the ffmpeg from svn with x264 and the problem have gone | 21:08 |
| Damascene | popey, | 21:08 |
| matumba | Damascene, could this be related to bug 305286 ? if so, let them know, because I can confirm that the patch mentioned in the report doesn't fix it (ffplay fails to play the ogv) | 21:11 |
| ubottu | Launchpad bug 305286 in ffmpeg "fails to playback ogv produced by recordmydesktop" [Medium,Confirmed] https://launchpad.net/bugs/305286 | 21:11 |
| Keybuk | Processed 281161 of 577332 files (15h 37m 5s remaining). | 21:55 |
| Keybuk | that remaining time is going *up* | 21:55 |
| ion | Yet another piece of software that doesn’t bother to violate causality. | 21:55 |
| slangasek | joaopinto: 507881> ah, that's the one; wonder how I failed to see that in the list | 22:01 |
| slangasek | ArneGoetje: what's in the new langpacks? The deadline isn't until next week, and a full langpack upload right now wouldn't give them time to build before we need to start ISO mastering | 22:02 |
| slangasek | (for RC) | 22:02 |
| slangasek | Keybuk: if /proc/bus/usb is already supposed to be handled with the generic "An error occurred" message, that's partially bug #563621 in plymouth | 22:07 |
| ubottu | Launchpad bug 563621 in plymouth "[script splash] 'plymouth message' before 'plymouth show-splash' doesn't render" [Medium,Triaged] https://launchpad.net/bugs/563621 | 22:07 |
| Keybuk | slangasek: no it's worse than tha tone | 22:08 |
| Keybuk | /proc/bus/usb ends up being tagged virtual | 22:08 |
| Keybuk | since it's a kernel filesystem | 22:08 |
| slangasek | Keybuk: should misc filesystems listed in /etc/fstab that aren't part of mountall's known list *ever* hold up virtual-filesystems? | 22:08 |
| Keybuk | slangasek: yes, if listed as "nodev" in /proc/filesystems | 22:09 |
| slangasek | tjaalton: hum, please upload straight to the archive instead, that's actually much more efficient at this stage of the release | 22:09 |
| slangasek | Keybuk: what's the rationale for that? Future-proofing mountall against new kernel filesystems that it doesn't know about yet? | 22:11 |
| Keybuk | slangasek: anything nodev is a virtual filesystem | 22:11 |
| slangasek | true, but tautological as far as the question of whether we want to block on it before emitting the signal :) | 22:13 |
| tjaalton | slangasek: ok, on the way. -joystick would need to be synced if accepted, and debfx is working on virtualbox-ose (vboxmouse) | 22:16 |
| slangasek | Keybuk: anyway, I'll accept a mountall change to blacklist usbfs specifically; it just seems to me that the more elegant solution is to treat nodev filesystems locally specified by the admin as something other than 'virtual-filesystems', and let them be handled by the normal error handler | 22:20 |
| tjaalton | slangasek: btw fyi; there's finally support for AES/3DES/RC4 for rpcsec_gss coming up for .35, 22 commits applied without any problem on .32 ;) (needs three patches for nfs-utils as well) | 22:21 |
| slangasek | tjaalton: that's going to have to be considered as an SRU | 22:22 |
| tjaalton | slangasek: yeah I'm hoping for it | 22:22 |
| tjaalton | will test it tomorrow | 22:22 |
| tjaalton | but according to steved it has been tested with .32/.33/.34 using cthon | 22:23 |
| tjaalton | so it should be ok | 22:23 |
| tjaalton | my problems with pam_winbind were due to getting the ticket with RC4 on top, and kinit would then replace it with an nfs compatible one.. | 22:24 |
| tjaalton | slangasek: would you like me to propose it on the kernel list? | 22:26 |
| slangasek | tjaalton: um... sure :) | 22:27 |
| slangasek | I'm not on the kernel team, so whatever method you and they agree on is fine with me :) | 22:27 |
| tjaalton | ok will do :) | 22:27 |
| persia | tjaalton: Be aware there's still some .31 trees backing lucid packages (linux-rt, linux-fsl-imx51) | 22:30 |
| tjaalton | persia: I doubt that the code has changed much, it has had DES hardcoded for a loong time | 22:30 |
| persia | (yes, we're breaking new ground, with *3* different upstream versions of the kernel in lucid) | 22:30 |
| persia | OK. You just mentioned .32/.33/.34 and as far as I know, lucid has .31/.32/.33 | 22:31 |
| tjaalton | persia: actually, here's the patch: http://users.tkk.fi/~tjaalton/foo/auth-gss-update.diff | 22:32 |
| persia | (-rt/-fsl-imx51, everything else, -ti-omap) | 22:32 |
| * persia has no idea about other changes in the area: just wants to make sure that any sensible patch with behaviour on which we want to rely works on all the different kernel trees we ship) | 22:33 | |
| tjaalton | yeah well I can't see a reason why it wouldn't work with .31 as well, though it certainly doesn't hurt to test.. | 22:33 |
| tjaalton | so -rt is .31? | 22:33 |
| persia | Yeah, -rt and -fsl-imx51 | 22:33 |
| tjaalton | I doubt the other flavors run nfs&krb5 :) | 22:33 |
| tjaalton | handhelds or such | 22:34 |
| persia | Actually, NFS is *very* common for -fsl-imx51 and -ti-omap as most devices don't ship with significant onboard storage. | 22:34 |
| ajmitch | stranger things have happened | 22:34 |
| persia | Dunno about -rt. | 22:34 |
| tjaalton | well, DES is still there | 22:34 |
| tjaalton | and if people have been using it, they've had to hardcode the configs too | 22:35 |
| persia | (but -ti-omap is *closer* to .35, so less likely to have backporting issues) | 22:35 |
| tjaalton | anyway, -rt is probably something that has to be tested | 22:35 |
| tjaalton | since i can imagine it being used on such environments | 22:36 |
| tjaalton | ok, 1 hunk failed on top of .31.13 | 22:37 |
| tjaalton | out of 22 | 22:37 |
| tjaalton | likely due to 14ace024b1e missing | 22:40 |
| tjaalton | yep | 22:41 |
| tlp | is anyone else dramatically affected by bug #131094 and perhaps #343371 in Lucid? Seems to be happening more than it used to, but I could be wrong. | 23:20 |
| ubottu | Launchpad bug 131094 in linux "Heavy Disk I/O harms desktop responsiveness" [Medium,Confirmed] https://launchpad.net/bugs/131094 | 23:20 |
| tlp | when my HDD light is solid, I can't really do anything. Sometimes I can switch over to a tty and login so I can kill whatever it is that's doing it, but many times I'll just power the box off. | 23:21 |
| === raof is now known as RAOF | ||
| spy6 | hmmmm | 23:27 |
| persia | Yes? | 23:28 |
| spy6 | persia: "sync acked" means, i don't need to subscribt ubuntu-sponsors? | 23:28 |
| persia | Right. A sponsor (ajmitch) already got to it, acked it, and passed to ubuntu-archive. Now you're just waiting for an archive-admin to publish the sync. Given that it's monday, I'd expect that sometime in the 9-12 UTC range. | 23:29 |
| spy6 | persia: ah okay ... that should be fine for lucid i guess :) | 23:30 |
| spy6 | thanks | 23:30 |
| persia | For the purposes of taxonomy "archive-admin" in Ubuntu is roughly analogous to "ftp-master" in Debian. | 23:30 |
| spy6 | i thought so | 23:31 |
| slangasek | Keybuk: re: bug #565185, bug #563878 - my first reaction was also to treat it as invalid, but on second thought, I don't think the design team was ever designing for 640x480 - I'll bet they're assuming a minimum res of 1024x768. Maybe we should consult them about shrinking those graphics down by a factor of 1.6 or so, so that VGA16fb is more consistent with the experience they've actually designed? (But not for final release, and proba | 23:32 |
| ubottu | Launchpad bug 565185 in plymouth "the xx16.png's are scaled to large" [Undecided,Won't fix] https://launchpad.net/bugs/565185 | 23:32 |
| ubottu | Launchpad bug 563878 in plymouth "Ubuntu splashscreen big and ugly after installing ATI graphics driver" [Undecided,New] https://launchpad.net/bugs/563878 | 23:32 |
| slangasek | ... candidate for SRU) | 23:32 |
| persia | slangasek: I'm sure 1024x600 is a closer approximation to expected minimum, although there have been N bug reports about stuff not working at 800x480. I don't think anyone is seriously targeting 640x480. | 23:33 |
| slangasek | persia: right - but of course 640x480 is what the VGA fb gives you | 23:33 |
| slangasek | the trouble is, none of our positioning code assumes 640x480 either, so just resizing the images is going to look weird | 23:34 |
| persia | Yep. There's been some interesting discussions in #ubuntu-installer about the side effect of various scalings at various resolutions regarding the install process. | 23:34 |
| slangasek | hmm; actually, our positioning code *might* all use the image sizes as the point of reference, and might just work | 23:34 |
| slangasek | sorry, might Just Work | 23:35 |
| joaopinto_ | it works fine for me with the (ugly) ATI fglrx resolution | 23:36 |
| persia | Most stuff seems to scale reasonably down to medium resolutions, but 640x480 gets a bit tight. | 23:36 |
| persia | Anyway, anything that depends on number of pixels for apparent size is inherently broken. | 23:36 |
| persia | There exists no relationship between screen size and pixel count, even aside from the vesafb issues. | 23:37 |
| slangasek | as it happens, I had already tweaked the positioning code in the ubuntu-logo to eat up some of the space below the logo if we didn't have room to display all our text, based on feedback in prior bugs | 23:37 |
| slangasek | so we should actually *fit* on 640x480 | 23:37 |
| slangasek | it's just not pretty | 23:37 |
| persia | I think that's fine. We can't get pretty until we can get em-aware renderers into pre-boot in a sensible way. | 23:38 |
| persia | And even then it's tricky (go ahead: just try to make things look sensible on my 0.75" 800x600 display) | 23:38 |
| slangasek | you know we use pango for the text rendering, right? :) | 23:38 |
| persia | slangasek: Doesn't help with images though. | 23:38 |
| slangasek | well, yes | 23:39 |
| persia | Plus pango uses dpi as input trying to reach target size, rather than using dpi as input to reach sensible aspect. | 23:39 |
| slangasek | but we don't want to be scaling images anyway, they're not going to look crisp if we do that | 23:40 |
| persia | Right. We need to render crisp images in realtime on the target hardware. | 23:41 |
| slangasek | heh | 23:41 |
| persia | But even that won't look crisp when we have framebuffer issues, because the display resolution won't match the native resolution. | 23:41 |
| persia | (at least for non-raster devices) | 23:41 |
| persia | Well, there's always the alternative of generating a pre-rendered image for every resolution at every size, but that gets tedious in a hurry. | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
