| blueyed_ | Apport retracing service is down? | 00:01 |
|---|---|---|
| Debian911 | can anyone confirm that the version of eglibc (2.11.1-0ubuntu4) is superior then that of Debian Expermential is using as I can see there version 2.11-0exp6 lists a fix for "Add the fallocate64() syscall. Closes: bug#568924" but cant see it listed in Ubuntus' changelog - http://changelogs.ubuntu.com/changelogs/pool/main/e/eglibc/eglibc_2.11.1-0ubuntu4/changelog and http://packages.debian.org/changelogs/pool/main/e/eglibc/e | 00:37 |
| cjwatson | $ nm -D /lib/libc.so.6 | grep fallocate64 | 00:37 |
| cjwatson | 000c5f70 T fallocate64 | 00:37 |
| Debian911 | cjwatson: 00000000000dd130 T fallocate64, 00000000000da010 T posix_fallocate64 - am I to assume we're fine and my system has fallocate? | 00:39 |
| cjwatson | that means your libc has the fallocate64 syscall stub, yes | 00:39 |
| crimsun | Debian911: since you parted +1 before I could paste the reference, see http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1f3615a1c97a030bca59f728f998947f852679b9 and walk the appropriate sources in loggerhead, e.g., http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/eglibc/lucid/annotate/head:/sysdeps/unix/sysv/linux/wordsize-64/Versions | 00:40 |
| slangasek | Keybuk: so when casper-md5check is done checking, it says "press any key to continue"... what's a better way to do that than exhaustively listing all possible keys in an argument to ply_boot_client_ask_daemon_to_watch_for_keystroke()? :) Should I tell plymouth to shutdown and stay on screen, then claim the console back? | 00:46 |
| jono | are you folks aware of a bug in Rhythmbox where the volume is set to minimum by default? | 00:49 |
| Keybuk | slangasek: you can't claim the console if you've told plymouth to shutdown | 00:50 |
| Keybuk | not unless you want to deal with raw keyboard and graphics mode | 00:50 |
| Keybuk | I guess you'd want to extend plymouth to support any key press | 00:51 |
| slangasek | Keybuk: OOI, would dealing with raw keyboard and graphics mode be so hard? Would getchar() no longer DWIM? | 00:56 |
| Keybuk | slangasek: it would very definitely not DWYM | 00:57 |
| Keybuk | that kind of thing only works in XLATE | 00:57 |
| slangasek | there'd be characters on the fd even when no key was pressed? | 00:57 |
| Keybuk | yeah, you get them for other things iirc | 00:58 |
| slangasek | huh, ok | 00:58 |
| * Keybuk isn't an expoert | 00:58 | |
| Keybuk | you can try it, of course | 00:58 |
| Keybuk | plymouth quit --retain-splash is probably what you want | 00:58 |
| Keybuk | that'll leave you in graphics mode, with the keyboard in raw | 00:58 |
| * slangasek nods | 00:59 | |
| directhex | what was i supposed to add to /etc/fstab to make my ntfs mount not hang forever? | 01:00 |
| directhex | ah, nobootwait | 01:01 |
| * lamont pounds his head on grub2's desk | 01:04 | |
| lamont | given the wonderful error messages about "terminal" and "serial" being unknown/invalid/lalala-need-to-reboot-_AGAIN_, how do I teach grub2 that the console lives on ttyS1,38400? | 01:05 |
| * \sh tells lamont to use ILO2 and runs far far away ;-) | 01:08 | |
| * lamont throws rocks at \sh | 01:09 | |
| lamont | no ilo on this beast | 01:09 |
| micahg | lamont: any chance of an updated nmap in debian? | 01:09 |
| lamont | fortunately, I was done playing with what I needed to do today, and decided to maybe put lucid on it to play | 01:09 |
| \sh | lamont: GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,9600n8" ? | 01:09 |
| lamont | micahg: I think I even have it packaged. I just need to verify it and upload. OTOH, been sick much of this week, so I'm playing catchup tomorrow | 01:10 |
| micahg | lamont: k, thanks, feel better :) | 01:10 |
| \sh | lamont: the hint came from http://linux.xvx.cz/2009/08/debian-with-grub2-and-serial-connection/#comments | 01:11 |
| lamont | \sh: and I set that where, I wonder. | 01:12 |
| * lamont goes to read | 01:12 | |
| \sh | lamont: Quote: Edit file containing configuration in Debian: /etc/default/grub | 01:12 |
| \sh | dunno if that helps you | 01:12 |
| lamont | we'll see | 01:14 |
| \sh | lamont: report back pls :) | 01:18 |
| lamont | Cannot find list of partitions! | 01:19 |
| lamont | I wonder where it expects to find that | 01:20 |
| lamont | under /sys, of course. | 01:21 |
| lamont | error: bad unit number. | 01:25 |
| lamont | error: unknown terminal 'serial' | 01:25 |
| lamont | . | 01:25 |
| lamont | error: unknown command `terminal'. | 01:25 |
| lamont | error: unknown terminal 'serial' | 01:25 |
| lamont | . | 01:25 |
| lamont | error: unknown command `terminal'. | 01:25 |
| lamont | [ 0.000000] Initializing cgroup subsys cpuset | 01:25 |
| lamont | but it does continue on into the boot | 01:25 |
| lamont | and then there's the "cute" bit where it drops to busybox because the root disk wasn't there yet, somewhere between 19 and 34 seconds into the boot. The drive showed up at 38 seconds | 01:26 |
| lamont | so typing 'exit' to busybox? win | 01:27 |
| lamont | anyway, yeah... that fixed it... now I just need to automate that bit... :-( | 01:28 |
| lamont | and afk for a few hours. | 01:28 |
| lamont | \sh: thanks much | 01:28 |
| \sh | lamont: did it work as documented? | 01:29 |
| \sh | lamont: plus "add ttyS1 to /etc/inittab" or say upstart to start up a getty for a ttyS | 01:29 |
| \sh | or simply add a RIB to your machine ;) | 01:30 |
| lamont | got a getty all by itself | 01:30 |
| psusi | I'm going over some upstart rules trying to make sure I understand everything and I notice that mountall.conf says stop on starting rcS... does that not block rcS from running until after mountall finishes? but then mountall daemonizes, which seems to negate that? | 01:32 |
| slangasek | psusi: what do you mean, "daemonizes"? upstart supervises daemons. | 01:34 |
| slangasek | and it doesn't block rcS from running until mountall /finishes/, it blocks rcS from running until mountall is /stopped/ | 01:34 |
| psusi | well, the job runs mountall --daemon, so mountall forks into the background to continue mounting and monitoring for devices to appear that still need mounting, then the initial mountall process exits, which means the mountall task is now finished doesn't it? | 01:34 |
| psusi | yes, that difference is what I'm trying to understand | 01:35 |
| slangasek | no, --daemon doesn't mean the task is finished | 01:35 |
| slangasek | the 'expect daemon' at the top tells upstart to track the grandchild process | 01:36 |
| psusi | so rcS is blocked from running until the mountall daemon finishes, even though the initial mountall process exits after forking? and that does not happen until all of the devices listed in fstab are detected and mounted? | 01:36 |
| slangasek | no, not "finishes" | 01:36 |
| slangasek | you're reading it backwards | 01:36 |
| slangasek | when rcS starts, upstart *kills* mountall if it's still running | 01:36 |
| psusi | that doesn't make sense... since it should try to start rcS immediately after starting mountall, which can take some time to finish | 01:37 |
| slangasek | no | 01:37 |
| slangasek | I think you misunderstand what the rcS job is | 01:37 |
| slangasek | rcS != /etc/rcS.d | 01:38 |
| psusi | it isn't? I thought the rcS event caused /etc/rcS to run which executes all the scripts in /etc/rcS.d? | 01:39 |
| slangasek | read /etc/init/rcS.conf for yourself | 01:39 |
| slangasek | it's only executed when booting into single user mode | 01:39 |
| psusi | ohh | 01:40 |
| psusi | why was I thinking that /etc/rcS was executed on startup? | 01:40 |
| slangasek | it is, but that's executed by /etc/init/rc-sysinit.conf | 01:40 |
| psusi | hrm... so a switch to single user runlevel kills mountall then | 01:40 |
| slangasek | yes | 01:41 |
| psusi | so if you boot into single user mode, and mountall takes some time to complete, it is terminated before it finishes mounting everything? | 01:41 |
| slangasek | rc-sysinit.conf is 'start on filesystem' - so mountall won't be killed until it's at least mounted all of the core filesystems | 01:42 |
| slangasek | because it's mountall emits 'filesystem', rc-sysinit.conf executes and calls "telinit S", which kills mountall and starts the rcS job | 01:43 |
| psusi | I see, so the mountall process directly contacts init and emits these listed events as it mounts the various filesystems, and the sysV rc system doesn't start up until after mountall has finished mounting the core filesystems? what are NON core filesystems that it could still be trying to mount? | 01:43 |
| slangasek | at this point, I think it may only be those filesystems explicitly marked 'nobootwait' in /etc/fstab | 01:47 |
| psusi | I see... ok, starting to make sense now... what is the difference between expect fork and expect daemon? the man page says something about daemon forking twice... I thought a daemon forked once, and the parent process exited leaving the child in the background? | 01:47 |
| psusi | ureadahead.conf says exec ureadahead --daemon but expect fork | 01:48 |
| slangasek | most daemons fork twice, due to esoteric requirements involving process groups | 01:49 |
| psusi | ok, so since mountall starts on startup, and ureadahead starts on starting mountall, upstart starts mountall, then without waiting for it to complete, starts ureadahead in paralell? if so why does ureadahead start on starting mountall instead of on startup? | 01:51 |
| psusi | ohh, but because of the daemon directive, it waits for mountall to perform initial startup, then background the daemon before starting ureadahead? | 01:52 |
| slangasek | no, "start on starting" blocks mountall until ureadahead is done | 01:52 |
| psusi | huh? I thought starting was the very first event auto generated by init? | 01:52 |
| slangasek | starting, not startup | 01:53 |
| slangasek | but reading the ureadahead job, I'm wrong | 01:53 |
| slangasek | "start on starting" means ureadahead has to be started before mountall starts | 01:53 |
| psusi | yea, it's mountall that is start on startup, ureadhead is start on starting mountall | 01:53 |
| slangasek | (if ureadahead were a task, mountall couldn't start until ureadahead was done) | 01:54 |
| psusi | I thought it meant ureadahead is started between the time mountall's startup job is run ( which there is none ) and mountall's main job is run | 01:54 |
| slangasek | by "startup", do you mean "pre-start"? | 01:54 |
| psusi | yea | 01:54 |
| slangasek | init(5) - "pre-start [...] This process will be run after the job's starting(7) event has finished" | 01:55 |
| slangasek | so ureadahead would be started before any pre-start script | 01:55 |
| psusi | so start on starting means this job has to be running before the other job is even pre started? | 01:56 |
| psusi | hrm... | 01:56 |
| slangasek | yes | 01:56 |
| psusi | but the other job can be started before this job is considered running? | 01:57 |
| psusi | i.e. start this job first, and if it forks or daemonizes, THEN you can start the other job? | 01:57 |
| slangasek | the processing of the "starting" signal is only done when the jobs it triggers are running | 01:58 |
| slangasek | if this job forks or daemonizes, that's what tells upstart that it *is* running | 01:58 |
| psusi | so if it does not fork or daemonize, but just keeps running... is post-start then run if it exists, then when THAT finishes, the job is considered running? | 01:59 |
| slangasek | post-start is run after upstart considers the job to be running. there are a number of different conditions you can set for upstart to wait for before considering the job to be running - the 'expect' options documented in init(5) | 02:01 |
| psusi | wait a second though... ureadahead starts on mountall startING, not started, so it should run in paralell with mountall, not before it | 02:03 |
| slangasek | once ureadahead has forked, telling upstart that it's started, mountall will run in parallel, yes | 02:05 |
| psusi | I think that is what would happen if it was on startED, but not startING | 02:05 |
| slangasek | no | 02:05 |
| slangasek | the start condition for mountall is met | 02:06 |
| slangasek | so upstart looks for other jobs that are 'start on starting mountall' or 'stop on starting mountall' | 02:06 |
| slangasek | and processes those first | 02:06 |
| slangasek | and the 'starting' signal isn't done until those other jobs that are '(start|stop) on starting mountall' are started or stopped | 02:06 |
| psusi | it seems to me that the man page is saying that the starting event for mountall is emitted before even the pre-start for mountall is run | 02:07 |
| slangasek | yes | 02:07 |
| psusi | ohh... so it processes the starting event, which means start readahead, THEN actually starts mountall? | 02:08 |
| slangasek | yes | 02:08 |
| psusi | so the starting event being emitted is processed synchronously before moving on? hrm... | 02:09 |
| Emzzzz | http://imggmi.info/DSC-1268361777.jpg/ do my tits look big? | 02:49 |
| === funkyHat is now known as funkyGit | ||
| === funkyGit is now known as funkyHat | ||
| lamont | against which package do I file the bug where boot bails out to busybox because it gives up on the root disk showing up 4-20 seconds before it does? | 04:35 |
| lamont | when the hell did netcat-openbsd become the default? | 04:39 |
| slangasek | mid-lucid-cycle | 04:40 |
| * lamont looks for a place to vomit | 04:40 | |
| lamont | I assume it had rational arguments... | 04:40 |
| slangasek | I don't recall seeing any | 04:41 |
| lamont | I wonder if it's related to us maintaining a fork of netcat-openbsd since hardy | 04:44 |
| lifeless | hmm, confused langpack.. logged in with latin, have klingon menus >< | 06:10 |
| jdong | *blinks* | 06:23 |
| jdong | http://manpages.ubuntu.com/manpages/intrepid/man3/printf.3.html | 06:23 |
| jdong | "including the trailing null byte (' <EOF>" | 06:23 |
| jdong | did what I think happen just happen there? | 06:23 |
| joefox | looks like there is something missing... | 06:25 |
| jdong | it literally attempted to interpret the NULL byte in the manpage | 06:25 |
| jdong | which signaled an end of string XD | 06:25 |
| joefox | a '\0' ? | 06:26 |
| joefox | XD | 06:26 |
| jdong | yup | 06:26 |
| RAOF | Input sanitisation is for wimps. | 06:27 |
| jdong | XD | 06:27 |
| jdong | anyone wanna submit that to thedailywtf for giggles? | 06:27 |
| jdong | or planet Ubuntu? | 06:27 |
| RAOF | Ah. Sweet, sweet SIGILL | 06:29 |
| joefox | what does SIGILL mean? | 06:30 |
| jdong | illegal opcode I'd guess | 06:30 |
| RAOF | The CPU has barfed on the illegal instruction you've sent it. | 06:30 |
| joefox | ah ok. i am new in this channel | 06:30 |
| RAOF | Well, there's a surprise. JIT breaks gjs on armel. | 06:34 |
| RAOF | And for an *actual* surprise, it also breaks gjs on i386. | 06:35 |
| RAOF | But works on amd64. Take that, IA32! | 06:36 |
| joefox | ^^ | 06:36 |
| joefox | what is armel? sorry all the questions :/ | 06:37 |
| RAOF | Arm - those swanky, tiny, processors found in phones and moving into tiny netbooks. | 06:37 |
| joefox | oh ok i know arm | 06:38 |
| RAOF | Hurray for trying to build a stable library upon mozjs. :/ | 06:44 |
| micahg | RAOF: a bug in mozjs? | 06:45 |
| RAOF | Probably not a bug so much as a changed API without a changed ABI. | 06:45 |
| RAOF | Well, except perhaps on arm, where it SIGILLS. | 06:45 |
| * micahg just got an armel failure for another uploaded xul192 port | 06:46 | |
| RAOF | But that's xulrunner-1.9.1, 'cause I can't install xul-1.9.2 on there. | 06:46 |
| RAOF | It also seems that something's changed in the mozjs API. gjs seems to be assuming that destroying a context will call the finaliser, but it's not getting called. | 06:47 |
| micahg | RAOF: can you tell me where, that's one reason we can't package it as the api changes, I can look it up for you though | 06:47 |
| RAOF | Strangely, this seems to only apply to i386; amd64 sails happily along with the previous behaviour. | 06:48 |
| micahg | RAOF: that's weird | 06:49 |
| micahg | RAOF: is it that test that failed for me? | 06:49 |
| RAOF | If it was a testsuite failure on gjs-unit /js/self on i386, then yes. | 06:49 |
| micahg | RAOF: jsapi | 06:50 |
| micahg | oh,, js/self | 06:50 |
| micahg | yes | 06:50 |
| micahg | RAOF: do you want me to look into it? | 06:50 |
| RAOF | Yeah. | 06:50 |
| RAOF | If you're likely to be able to hunt it down faster, go for it. | 06:51 |
| RAOF | I'll give you what I've got so far. | 06:51 |
| RAOF | (Once I rebuild this with -DGJS_ENABLE_LIFECYCLE) | 06:51 |
| micahg | RAOF: k | 06:52 |
| RAOF | It doesn't *actually* break the tests on i386; it just makes them leak memory, which the testsuite detects, and causes a failure. | 06:52 |
| micahg | RAOF: do you know which one specifically? | 06:53 |
| RAOF | GjsFileImporter | 06:53 |
| RAOF | In particular, initialising GjsFileImporter & then destroying the context won't result in it's finalizer being called, which the testsuite detects and bails on. | 06:54 |
| RAOF | If you disable JIT, then everything goes swimmingly | 06:54 |
| RAOF | GJS_DISABLE_JIT="aww, yeah" make check succeeds. | 06:54 |
| micahg | but is it the test or funxtions? | 06:55 |
| StevenK | RAOF: A Duffman quote? | 06:55 |
| RAOF | StevenK: It was going to be GJS_DISABLE_JIT="hells, yes". Not a Duffman quote :) | 06:56 |
| RAOF | micahg: I'm not sure what you mean. The tests themselves generate the expected output. It's in the teardown method of the testsuite which destroys the js context and then checks that everything's been properly destroyed that it fails. | 06:57 |
| micahg | RAOF: I don't see GjsFileImporter defined anywhere | 06:57 |
| RAOF | gjs/importer.c; it's the javascript name for it. | 06:58 |
| micahg | ah, k, sorry, I'm used to C++... | 06:58 |
| RAOF | As you would be, if you've been wrestling the mozilla beast. | 06:58 |
| RAOF | So, if you define GJS_VERBOSE_ENABLE_LIFECYCLE during the build, test_user_data/logs/gjs.log will contain debugging information about the initialisation & finalisation of JS IMPORT. | 07:00 |
| micahg | RAOF: do you have the output of that handy? | 07:00 |
| RAOF | http://pastebin.ca/1835094 ← successful check, with GJS_DISABLE_JIT | 07:01 |
| RAOF | http://pastebin.ca/1835095 - | 07:02 |
| RAOF | That one's failed. Note that there's no finaliser called after Destroying JS context | 07:02 |
| micahg | I'll check the finalize function... | 07:03 |
| RAOF | Line 973 of gjs/importer.c | 07:03 |
| RAOF | That function is simple enough; it's not called anywhere by the gjs code, but it's shoved in the GjsFileImporter JSClass vtable. | 07:05 |
| micahg | yes, but I'm wondeing about the functions it uses | 07:05 |
| pitti | Good morning | 07:16 |
| pitti | slangasek: oh, is that not in sendsigs/omit.d? I'll have a look | 07:17 |
| slangasek | pitti: it's an upstart job, so it looks like the handling in /etc/init.d/sendsigs is supposed to ignore it | 07:17 |
| pitti | slangasek: I'll track it down | 07:18 |
| micahg | pitti: are the retracers working? | 07:21 |
| pitti | micahg: no, they broke down a couple of days ago, I didn't yet find time to restore them | 07:21 |
| micahg | pitti: k, thanks | 07:22 |
| RAOF | micahg: Can I leave that with you? At worst, we can disable JIT on armel & i386, and everything should work. | 07:25 |
| micahg | RAOF: sure | 07:25 |
| micahg | RAOF: my guess is it's returning null where it shouldn't | 07:26 |
| micahg | but I have to see how the js functions changed | 07:26 |
| micahg | RAOF: would you be able to file a bug in LP and assign to me? | 07:26 |
| === tkamppeter_ is now known as tkamppeter | ||
| micahg | RAOF: actually, I can do it | 07:27 |
| RAOF | Ok. Thanks. | 07:27 |
| micahg | RAOF: I'll talk to asac in the morning (CST) and see if it's worth working on now or later | 07:28 |
| micahg | but I'll file the bug so we don't lose it | 07:28 |
| dholbach | good morning | 07:38 |
| thekorn | good morning dholbach :) | 07:43 |
| dholbach | hey thekorn | 07:43 |
| micahg | RAOF: is bug 537903 sufficient? | 07:50 |
| ubottu | Launchpad bug 537903 in gjs "JS tests failing in gjs on i386 and armel" [Low,Triaged] https://launchpad.net/bugs/537903 | 07:50 |
| RAOF | armel doesn't fail to call the finalizer; it SIGILLs in libmozjs. I'll add that to the bug | 07:54 |
| RAOF | micahg: There you go; backtrace, such as it is, of gjs dying on armel added to the bug. | 08:00 |
| micahg | RAOF: ah, maybe they should be two bugs then? | 08:01 |
| RAOF | Quite possibly. | 08:02 |
| siretart` | fta: I hope you don't expect to "push" that branch to lucid. what were you referring to? | 08:03 |
| micahg | RAOF: k, thanks, I'll talk to asac in the morning | 08:05 |
| micahg | RAOF: so, we only have a workaround for i386? | 08:07 |
| RAOF | micahg: Disabling JIT works on both i386 and armel. | 08:31 |
| micahg | RAOF: k | 08:32 |
| alkisg | seb128: in LP bug #401497 you asked if the gdm keyboard layout problem is still an issue in Lucid. I answered there -it is, e.g. Greek people can't write Greek with the default installation- but if you need any more info/testing, I'd be glad to help as much as I can. | 08:44 |
| ubottu | Launchpad bug 401497 in ubiquity "wrong keyboard layout after upgrade with autologin" [Low,Confirmed] https://launchpad.net/bugs/401497 | 08:44 |
| seb128 | alkisg, why can't they? it's a bit weird | 08:44 |
| alkisg | seb128: because gdm forces a [us] layout | 08:45 |
| seb128 | alkisg, I don't plan to work on this bug specifically but thanks for being responsive, I'm just looking at bugs we want to milestone for lucid | 08:45 |
| alkisg | It doesn't respect the system wide default in /etc/default/console-setup... | 08:45 |
| seb128 | alkisg, what do you have in this file? | 08:45 |
| alkisg | XKBLAYOUT="us,gr" | 08:45 |
| seb128 | console-setup that is | 08:45 |
| seb128 | ok | 08:45 |
| seb128 | I think it's a known issue with multiple values there | 08:45 |
| seb128 | I'm not sure why you don't get ="gr" | 08:46 |
| alkisg | Yes, I think so too. It's really annoying, i.e. we can't preselect greek for e.g. a school | 08:46 |
| seb128 | I think pitti was looking at that some time ago | 08:46 |
| alkisg | seb128: =gr is *not* a correct value | 08:46 |
| alkisg | I needs to be [us,gr] | 08:46 |
| seb128 | why? | 08:46 |
| seb128 | that seems to be 2 layouts? | 08:46 |
| alkisg | Yes, it is | 08:46 |
| alkisg | 2 layouts are needed in many countries | 08:46 |
| seb128 | why do you need 2 default layouts? | 08:46 |
| persia | seb128: Many keyboards *need* multilayer to handle things smoothly. | 08:47 |
| seb128 | I'm just trying to understand the issue | 08:47 |
| alkisg | Because I can't type "www.google.com" without a us layout | 08:47 |
| persia | seb128: So you can type in roman and non-roman alphabets easily. | 08:47 |
| seb128 | alkisg, persia: ok thanks, that's valuable information, I will milestone this bug | 08:47 |
| persia | seb128: For reference this affects all non-latin except CJKV | 08:48 |
| seb128 | persia, ok thanks | 08:48 |
| seb128 | it makes a good candidate for the lucid buglist I'm building for the desktop team | 08:48 |
| alkisg | seb128: as I say in the last comment in the bug report, a reasonable way to solve this is to have a "system default layout" entry in the combobox in the gdm login screen | 08:49 |
| alkisg | It's really important for many countries. Thanks for milestoning this :) | 08:49 |
| seb128 | alkisg, I don't we will do UI changes and new feature now | 08:49 |
| alkisg | seb128: no, that's not a new feature | 08:49 |
| alkisg | There's a combo box with 200 keyboard layouts there | 08:49 |
| alkisg | The default is [us] | 08:49 |
| alkisg | That's a wrong assumption | 08:49 |
| seb128 | well | 08:49 |
| alkisg | The default should be [system default] | 08:49 |
| seb128 | <alkisg> XKBLAYOUT="us,gr" | 08:49 |
| seb128 | the default is the first in that list | 08:50 |
| alkisg | Taken from console-setup... | 08:50 |
| seb128 | should it be gr,us? | 08:50 |
| alkisg | No | 08:50 |
| persia | seb128: The list needs to handle multilayer layouts | 08:50 |
| persia | (or perhaps not be a list) | 08:50 |
| alkisg | By "default" gdm means *the only* layout | 08:50 |
| seb128 | well, would it be fine if you have us and gr under GNOME | 08:50 |
| seb128 | with the notification icon to switch | 08:50 |
| seb128 | and default being set to "us" | 08:50 |
| seb128 | or would that still be buggy? | 08:51 |
| persia | seb128: Not if you use greek in your password. | 08:51 |
| alkisg | Right. So gdm is broken now. It doesn't set 2 layouts, it only sets the first one. | 08:51 |
| seb128 | you can set 2 layouts at the same time? | 08:51 |
| persia | seb128: Yes. Multilayer. | 08:51 |
| seb128 | or do you mean you need to be able to switch between those? | 08:51 |
| alkisg | To be able to switch between them | 08:51 |
| alkisg | Gdm *removes* this possibility | 08:51 |
| persia | seb128: at the same time. There's usually special keystrokes that switch between layers. | 08:51 |
| alkisg | persia: that's part of the same layout, though | 08:52 |
| seb128 | persia, right but you can only have 1 layout at time, ie you have both configured and you switch with a shortcut right? | 08:52 |
| alkisg | I.e. in Greek I can use right alt+E to type the euro sign | 08:52 |
| slangasek | seb128: morning - can you tell me who the right person is to look at bug #445621 in gtk? | 08:52 |
| ubottu | Launchpad bug 445621 in libgtk2-perl "libgtk2-perl FTBFS on all archs -- test failures" [High,Triaged] https://launchpad.net/bugs/445621 | 08:52 |
| seb128 | slangasek, I think it's a libgtk2-perl bug | 08:52 |
| slangasek | seb128: you think the second failure is, too? | 08:53 |
| persia | seb128: No. X supports up to 4 layers in a keymap. | 08:53 |
| seb128 | slangasek, I was planning to look at it but tried to finish things before you freeze lucid first :p | 08:53 |
| seb128 | slangasek, yes | 08:53 |
| slangasek | hmm, ok | 08:53 |
| seb128 | slangasek, let me get you the upstream change | 08:53 |
| persia | seb128: So depending on hardware, etc. it's potentially possible to have several simultaneously enabled. | 08:53 |
| alkisg | seb128: to make it as clear as I can, because my english isn't good enough: we're not asking for a new feature. It's a bug that wasn't there up until jaunty, and was introduced with the new gdm in karmic. We just need gdm to not mess up with the system defaults... | 08:54 |
| seb128 | alkisg, right, I don't discuss that there is a bug to fix, I'm just not sure it requires new UI rather than just settings things correctly | 08:55 |
| alkisg | The current UI is fine | 08:55 |
| alkisg | There's a combobox there with 200 different layout | 08:55 |
| alkisg | It just lacks an additional entry: "use the system default layout" | 08:55 |
| seb128 | slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=591085 | 08:55 |
| ubottu | Gnome bug 591085 in GtkBuilder "GtkBuilder object ID bounded to GtkWidget "name" property" [Normal,Resolved: fixed] | 08:55 |
| persia | Well, the combobox is defective because it can7t handle dual layouts, but that's a different issue. | 08:55 |
| alkisg | persia: ok, but I'm not asking for this | 08:55 |
| seb128 | slangasek, see comment #19 | 08:55 |
| alkisg | I'm not asking for a new UI that would enable someone to select multiple layouts | 08:56 |
| persia | alkisg: Understood. The "system default" choice is the best workaround we can expect for lucid. | 08:56 |
| alkisg | I'm just asking for an entry to respect the system defaults | 08:56 |
| alkisg | Whatever those may be. Either 1, 2, or 10 different layouts in XKBLAYOUT, gdm should use those. | 08:56 |
| seb128 | alkisg, right | 08:57 |
| seb128 | gotcha | 08:57 |
| alkisg | It shouldn't be hard - a copy from console-setup to the gconf key. | 08:57 |
| seb128 | I would just expect the gconf key in GNOME to be the XKBLAYOUT list by default | 08:57 |
| seb128 | right | 08:57 |
| slangasek | seb128: so we can expect other parts of this test suite to break in the future, because get_name() is not guaranteed to return this value? | 08:58 |
| slangasek | (the reason I thought it was a gtk bug was that it's only one object out of several that causes the error) | 08:58 |
| seb128 | slangasek, well, the semantic changed, it was buggy before and has been fixed, it should not change again no, ie once you fix the testsuite you should be good | 09:00 |
| geser | does somebody know if the python-apt 0.8 API gets into lucid? | 09:00 |
| seb128 | slangasek, but you will probably get the same issue for any get_name() used this way yes | 09:00 |
| seb128 | slangasek, I can have a look in fixing that today if you want | 09:01 |
| slangasek | seb128: no, that's my point, it's only *one* object that shows this behavior with get_name(), and the test suite tests multiple objects | 09:01 |
| persia | geser: DktrKranz and mvo were discussing an updated merge. Check the bugs. | 09:01 |
| seb128 | slangasek, hum ok, I will have to check what happens there | 09:01 |
| seb128 | slangasek, I will do that today | 09:01 |
| slangasek | seb128: ok, cheers | 09:02 |
| seb128 | np | 09:02 |
| seb128 | slangasek, http://git.gnome.org/browse/perl-Gtk2/commit/?id=d0b0e0baf7a611c307040cef13773556a4898d08 | 09:06 |
| seb128 | slangasek, ? | 09:06 |
| slangasek | seb128: aha, that's it :) | 09:06 |
| seb128 | slangasek, good ;-) | 09:06 |
| seb128 | slangasek, I like when upstream does fix bugs before we report those :p | 09:07 |
| slangasek | :) | 09:07 |
| seb128 | slangasek, the comment also explain why you get it only for that widget | 09:07 |
| * slangasek nods | 09:07 | |
| seb128 | which is good to know too ;-) | 09:07 |
| pitti | seb128: XKBLAYOUT="us,gr" -> that bug is known; it originally seems to be an installer bug, but we have to workaround it in existing installations | 09:27 |
| seb128 | pitti, do you have the bug number? I want to add it to our lucid list | 09:28 |
| seb128 | pitti, if you read backlog that seems to not be a bug in the installer | 09:28 |
| seb128 | pitti, they apparently need 2 layouts in non latin cases | 09:28 |
| seb128 | pitti, those 2 same layouts should be in gdm and GNOME | 09:28 |
| pitti | seb128: ok, that requires a more intrusive fix then (it's currently a signle layout, not a list | 09:29 |
| pitti | seb128: bug 460328 | 09:29 |
| ubottu | Launchpad bug 460328 in xserver-xorg-input-evdev "Wrong keyboard settings when console-settings has multiple layouts" [Undecided,In progress] https://launchpad.net/bugs/460328 | 09:29 |
| === slangasek changed the topic of #ubuntu-devel to: Archive: Feature Freeze + Beta Freeze | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
| cjwatson | I agree, the multiple layouts there are absolutely deliberate in the installer | 09:35 |
| * popey wonders why he's just got an "Ubuntu 9.10 beta freeze now in effect" dated 24/09/2009 from slangasek | 09:38 | |
| slangasek | oh, sigh | 09:38 |
| popey | ah, my bad, slangasek replied to that mail :) | 09:38 |
| popey | *chuckle* | 09:38 |
| * slangasek sends a better one | 09:39 | |
| pitti | cjwatson: libjpeg fix uploaded, FTR | 09:40 |
| cjwatson | thanks | 09:40 |
| persia | Just to make sure I remember correctly, with BetaFreeze, we're back to hard-freeze, where the release managers need to approve each upload, right? Do we need special bugs for tracking each approval? | 09:46 |
| YokoZar | slangasek: one of the beta freeze emails you sent said 9.10 in the subject | 09:47 |
| slangasek | YokoZar: yep, that's why there were two instead of one :) | 09:48 |
| seb128 | pitti, bug #460328, is that a g-s-d or gdm issue? | 09:48 |
| ubottu | Launchpad bug 460328 in xserver-xorg-input-evdev "Wrong keyboard settings when console-settings has multiple layouts" [Undecided,In progress] https://launchpad.net/bugs/460328 | 09:48 |
| YokoZar | slangasek: ahh ok I thought I got 2 cuz of different lists ;) | 09:48 |
| slangasek | persia: please no - upload, let it be reviewed in queue | 09:48 |
| slangasek | persia: yell on IRC if that's not working :) | 09:48 |
| persia | slangasek: That's how it used to work, and I'm glad to see we haven't added more process. Thanks. | 09:49 |
| pitti | seb128: if we need to support lists, it's both (and potentially -evdev as well, since that ships the udev rules) | 09:49 |
| seb128 | pitti, should I add gdm and g-s-d tasks there, do you think it's likely fixable for lucid now? | 09:50 |
| pitti | seb128: not for beta-1, but for beta-2 | 09:50 |
| pitti | seb128: you are welcome to add tasks, and assign it to me | 09:50 |
| seb128 | pitti, ok thanks, adding it to our lucid tasks | 09:50 |
| seb128 | pitti, danke! | 09:50 |
| seb128 | bah | 09:51 |
| seb128 | retracers crashed on "lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error" | 09:51 |
| * seb128 removes lock | 09:51 | |
| pitti | again? thanks | 09:51 |
| seb128 | np | 09:52 |
| ogra | so if i have a package using gksu, lintian screams at me to use su-to-root ... but su-to-root a) lacks functionallity and b) is only in unioverse | 09:52 |
| ogra | whats our policy on that ? | 09:52 |
| persia | Our policy is undecided. | 09:54 |
| persia | We are not planning to start installing menu by default on every installation, so the Debian policy doesn't work. | 09:54 |
| persia | Try to change your application to not need gksu because it uses policykit or something. | 09:54 |
| dholbach | can somebody moderate my mail to ubuntu-devel-announce@ | 09:59 |
| cjwatson | done | 09:59 |
| dholbach | thanks cjwatson! | 10:00 |
| === jelmer_ is now known as jelmer | ||
| Chipzz | lamont: fwiw, my opinion on https://launchpad.net/bugs/532587 is that the user/group should be removed on purge | 10:23 |
| ubottu | Launchpad bug 532587 in puppet "removal of package does not stop daemon" [Medium,Fix released] | 10:23 |
| Chipzz | I expect (and I know that it doesn't hold right now anyway, but...) apt-get install foo; dpkg -P foo to be idempotent (if foo doesn't pull in extra dependencies) | 10:24 |
| Chipzz | imo, if I debootstrap 2 environments, and run 'apt-get install foo; dpkg -P foo' in one of them, a diff should show up no differences at all | 10:26 |
| persia | Chipzz: Why? Can we be sure there are no logs or extra files that might have that user/group as owner? Are we sure that the admin wouldn't prefer to keep the same UID/GID if later reinstalled? Do we expect the admin to be running out of system UID/GIDs ? | 10:36 |
| cjwatson | persia: this is something that piuparts checks in Debian (and it certainly isn't at anywhere near 100% compliance) | 10:38 |
| cjwatson | --purge should remove the uid/gid; if the admin wants to keep configuration, they should use --remove | 10:38 |
| persia | cjwatson: Ah. We were discussing this recently, and nobody could find the relevant bits in policy. | 10:38 |
| persia | mathiaz: You may also be interested in the above comment. | 10:39 |
| cjwatson | I'm sure it's an interpretation thing, but given that uids/gids reside in /etc I would account them as configuration | 10:39 |
| persia | Plus the idempotent argument above. | 10:40 |
| cjwatson | obviously you have to be careful about existing files using those ids; I'm not claiming it's easy to comply with this | 10:40 |
| cjwatson | particularly in the case of a user shared among multiple packages | 10:40 |
| cjwatson | and there may well be cases where complying with the letter of policy is worse than not doing so. there's probably an extensive argument on this somewhere in the debian-policy list archives. :-) | 10:41 |
| persia | I've always been a fan of leaving logs on --purge for later reference, and tend to like to run daemons as non-root, writing their own logs, which is probably why I had the opinion I did. | 10:41 |
| cjwatson | Chipzz: BTW I hope you're not counting /var/log/dpkg.log. ;-) | 10:41 |
| cjwatson | persia: policy is explicit that logs should be removed on purge | 10:41 |
| cjwatson | 10.8 | 10:42 |
| persia | That defeats the last bastion of my support for my previous position. | 10:42 |
| persia | Thank you for the disabuse. | 10:42 |
| cjwatson | but of course if stuff is lying around in home directories or something ... gets complicated I'm sure | 10:42 |
| persia | Well, aside from the shared UID/GID scenario, it ought be possible to know what is being done, and (mostly) clean up in the maintainer scripts. | 10:43 |
| persia | For shared UID/GID, I thought the maintainer was supposed to request allocation of a system-wide UID. | 10:43 |
| cjwatson | depends how shared | 10:44 |
| cjwatson | if it's among a group of cooperating packages maintained by the same people, that's not necessary | 10:44 |
| cjwatson | in fact it's not really necessary in general; the only reason to require allocation of a static uid is if you actually care about the number | 10:44 |
| persia | Is that because of the "same people" or because of the "cooperating packages"? | 10:44 |
| cjwatson | otherwise in general packages should just use adduser --system | 10:45 |
| cjwatson | cooperating> actually a red herring I think, thinking on the fly :) | 10:45 |
| persia | On an unrelated note, the debian-installer powerpc FTBFS confuses me. It builds fine on a local powerpc. | 10:46 |
| cjwatson | you only really need static ids if the id is baked into binaries somehow that for some reason can't or won't use normal name lookup | 10:46 |
| cjwatson | that ftbfs is bug 537733 | 10:46 |
| ubottu | Launchpad bug 537733 in launchpad-buildd "/etc/apt/sources.list unreadable on powerpc" [Undecided,New] https://launchpad.net/bugs/537733 | 10:46 |
| persia | Aha, so really we should be striving for a minimum of static UID/GID? | 10:46 |
| cjwatson | yes - indeed my default response as base-passwd@packages.debian.org to such requests is to attempt to persuade the requestor that they can do things some other way. :) | 10:47 |
| Chipzz | persia: imo it really doesn't matter - the admin requested purge, the package should be removed as complete as possible | 10:47 |
| cjwatson | /usr/share/doc/base-passwd/README <- very few package-specific ones have been allocated | 10:47 |
| cjwatson | the global static ones (0-99) are "shared" in a stronger sense, but it takes a lot to get me to add one of those | 10:48 |
| persia | Chipzz: Yes. I now agree with you. | 10:48 |
| cjwatson | plugdev was the last one, and even that was arguably a mistake | 10:48 |
| cjwatson | and the reason that was static was that we needed to hardcode the gid in /etc/fstab from the installer | 10:49 |
| cjwatson | (at the time) | 10:49 |
| persia | So the static UID/GID registrations can be thought of as extremely low-priority bugs, in a way. | 10:49 |
| cjwatson | kind of. of course, once they've been allocated, that's final. | 10:50 |
| cjwatson | deallocating them obviously wouldn't free up the numbers | 10:51 |
| Chipzz | cjwatson: does plugdev still get used these days? | 10:51 |
| cjwatson | the *uses* of the registrations are low-priority bugs | 10:51 |
| cjwatson | Chipzz: there are probably ghosts here and there, but mostly not | 10:51 |
| Chipzz | so the number can't be deallocated even if the package stops to use them, or the package is obsoleted? | 10:52 |
| persia | Chipzz: No, because some people have very long-lived systems (my last potato system is still at my desk, although I haven't turned it on in several months, and it was running intrepid or jaunty last I looked) | 10:53 |
| siretart` | fta: in any case, can you please rename the package chromium-codecs-ffmpeg-nonfree? I guess something like 'chromium-codecs-ffmpeg-extra' would be much clearer. | 10:53 |
| Chipzz | persia: I mean in future releaese | 10:53 |
| Chipzz | obviously you can't deallocate them from a past release, duh ;P | 10:54 |
| siretart` | fta: the package description sounds like ffmpeg would contain 'nonfree' codecs, which isn't exactly true. In fact, some ffmpeg developers have expressed that they are very unhappy with that naming. | 10:55 |
| persia | Chipzz: Again, I have a machine that was first installed Debian potato at my desk, so it's been continuously upgraded for a decade or so (including HW upgrades). | 10:55 |
| Chipzz | persia: but once you upgrade that potato system, if you have packages using static uids, and those migrate to a solution where they aren't needed anymore, or obsoleted... | 10:55 |
| persia | Chipzz: The point being that we can't ever know that a given UID or GID really isn't being used on any systems. | 10:55 |
| persia | Chipzz: I still have that UID in my /etc/passwd | 10:56 |
| Chipzz | persia: uhm, yes you can? | 10:56 |
| cjwatson | Chipzz: the numbers will never, ever be deallocated. live with it. :-) | 10:56 |
| geser | is using clean-la.mk from cdbs the prefered way when "fixing" .la files? (a .la files references an other .la file without a dependency on its -dev package) | 10:56 |
| cjwatson | I don't care whether it's theoretically possible to work it out, maybe, sometimes. | 10:57 |
| persia | Chipzz: I can't because the new versions of the package that use dynamic methods to find out the UID or GID based on the name will get the old numbers and not run adduser --system | 10:57 |
| Chipzz | as a package maintainer you can fix your postinst etc scripts to migrate known files away from the static UID or GID for example | 10:57 |
| Chipzz | persia: right, they can not be removed from an UPGRADED system | 10:57 |
| Chipzz | what I meant is that they are no longer part of the standard /etc/passwd etc on NEW installs | 10:58 |
| cjwatson | the allocations in /usr/share/doc/base-passwd/README are not part of /etc/passwd unless explicitly created by a package anyway. | 10:58 |
| persia | Chipzz: Sure. You could probably do that, but you can't ever reuse a previously allocated static value. | 10:58 |
| cjwatson | indeed we have sometimes removed entries from new installations, but as you say, reuse is forbidden. | 10:59 |
| Chipzz | on a related note | 10:59 |
| Chipzz | someone should probably beat some sense into Bernstein :P | 11:00 |
| Chipzz | qmail packages are ARGH | 11:00 |
| seb128 | slangasek, still awake? are you working on the gtk-perl buildfix or should I do that? | 11:05 |
| seb128 | slangasek, I can do it now | 11:05 |
| geser | will the beta1 freeze get lifted after beta1 release? | 11:30 |
| lamont | persia: I knew there were reasons I removed uids/gids | 11:46 |
| persia | lamont: I think I preferred "tastefulness" to "well, policy says to do it that way", but yeah :) | 11:53 |
| persia | lamont: Also, do you know who can fix bug 537733 ? | 11:54 |
| ubottu | Launchpad bug 537733 in launchpad-buildd "/etc/apt/sources.list unreadable on powerpc" [Undecided,New] https://launchpad.net/bugs/537733 | 11:54 |
| lamont | persia: is it reproducible? | 11:54 |
| cjwatson | yes, happened two or three times now | 11:54 |
| persia | Yes. I just reproduced it. | 11:54 |
| lamont | because looking at builds, the file sure seems readable to me... | 11:55 |
| persia | lamont: Look at the debian-installer build | 11:55 |
| persia | https://launchpad.net/ubuntu/+source/debian-installer/20081029ubuntu90/+build/1557158 | 11:55 |
| * lamont forces the build down ross' throat to see if that changes anything | 11:59 | |
| lamont | -rw------- 1 root root 48 Mar 12 11:58 /etc/apt/sources.list | 12:01 |
| lamont | I take back what I said | 12:01 |
| lamont | WTF? | 12:01 |
| lamont | OH. &^$%)&*&^%)$^%)P TWISTED | 12:01 |
| * lamont goes to beat on the right peopld | 12:01 | |
| persia | lamont: Thank you. | 12:01 |
| lamont | persia: slapped around, fix live and testing on ross, will smack adare once its build finishes, and will be pushing code to close the bug shortly | 12:13 |
| persia | lamont: Excellent. Thank you very much. | 12:14 |
| === MacSlow is now known as MacSlow|lunch | ||
| lamont | WARNING: The data in 'translation-status' is older than 2 weeks. | 12:16 |
| lamont | Should it maybe be updated? | 12:16 |
| lamont | giggle | 12:16 |
| cjwatson | makes slightly more sense in Debian :-) | 12:16 |
| lamont | heh | 12:16 |
| cjwatson | ooh. I think I have console-setup working again | 12:17 |
| * cjwatson fine-tunes against bootchart | 12:17 | |
| lamont | 2010-03-12 12:16:57+0000 [-] Unpacking anna (from udebs/anna.udeb) ... | 12:17 |
| lamont | I think that means it's going to work | 12:17 |
| cjwatson | yep, looks good | 12:17 |
| persia | At least the failure we have been seeing isn't the issue. | 12:18 |
| lamont | so.. when my boot bails out to busybox with ZOMG-NO-ROOT-PARTITION literally < 5 seconds before the partition shows up from scsi, what package do I file that against>? | 12:26 |
| lamont | I suppose I'm magically supposed to know about rootdelay at install time so that I can fix it? | 12:27 |
| lamont | persia: and built successfully | 12:44 |
| persia | lamont: Wonderful. I have renewed confidence in beta for powerpc. Is there anything else I should add on the fpc bit? | 12:46 |
| lamont | dunno - do keep pestering me though | 12:50 |
| persia | OK. Please review the last comment in bug #67544 then, just to confirm I've added all the right bits. | 12:51 |
| ubottu | Launchpad bug 67544 in fpc "PPC build of fpc fails" [Unknown,Fix released] https://launchpad.net/bugs/67544 | 12:51 |
| persia | Also let me know if I should pester some nominated third party instead :) | 12:51 |
| lamont | persia: the last 2 paragraphs are a nice restatement of the practice we've always followed | 12:52 |
| persia | I figured, but given that the last set of instructions didn't work, I felt it wouldn't hurt to be overprecise. | 12:53 |
| lamont | true | 12:53 |
| lamont | was kind of hoping for the expanded list of exactly which versions of which debs were fetched, since that apt-get command referencing ftp.debian.org? not so functional behind the buildd firewall | 12:54 |
| persia | lamont: I'm really only pulling those 5 debs from Debian. Everything else is lucid. | 12:57 |
| lamont | awesome | 12:57 |
| persia | That's the bit about --download-only and then sed on sources.list with a new cache update before the install loop. | 12:57 |
| lamont | persia: the other bit here is that we're using this as a perfect test case for another admin to validate my "how to bootstrap a package" instructions | 12:58 |
| persia | lamont: That's why I keep volunteering to chase someone other than you about it :) | 12:59 |
| Garfeild | hi all | 13:05 |
| Garfeild | Where can I found sources of Installation manager from LiveCD? | 13:06 |
| cjwatson | the installer, you mean? apt-get source ubiquity | 13:08 |
| Garfeild | thanks | 13:08 |
| === MacSlow|lunch is now known as MacSlow | ||
| === Tonio__ is now known as Tonio_ | ||
| === `Alessio` is now known as quadrispro | ||
| === lus is now known as lu | ||
| === lu is now known as lus | ||
| === sconklin-gone is now known as sconklin | ||
| qense | statik: An idea for the Ubuntu One GSOC project idea: integrating Ubuntu One with a website, maybe something like Roundcube -- contacts -- or something else. It would be something great: data integration between the desktop and the web. | 14:25 |
| doko_ | qt4-x11 is a 160MB source? insane ... | 14:26 |
| === robbiew_ is now known as robbew | ||
| === robbew is now known as robbiew | ||
| emgent | http://www.ns.umich.edu/htdocs/releases/story.php?id=7551 | 14:36 |
| apw | cjwatson, this dpkg change to add an fsync ... when does it add the fsync? | 14:42 |
| Keybuk | apw: heh, I was just about to grab him too | 14:43 |
| Keybuk | apw: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=62668eb | 14:45 |
| Keybuk | that's the patch | 14:45 |
| apw | Keybuk, ta | 14:45 |
| cjwatson | right - there was another one upstream to do the same for status file writes | 14:46 |
| Keybuk | the one in tarobject would be the culprit I expect | 14:46 |
| cjwatson | culprit? | 14:46 |
| Keybuk | cjwatson: you've utterly killed dpkg performance from what we can tell | 14:47 |
| Keybuk | it took over an hour to unpack the linux headers deb | 14:47 |
| Keybuk | if it's doing an fsync() before every rename() for every single file in a deb ... | 14:47 |
| apw | there are 11k files in there, so we are suspecting we have 11k fsync's now | 14:47 |
| cjwatson | all I did was backport it, but possibly - I was more immediately worried about stemming the flow of correctness | 14:47 |
| cjwatson | bugs | 14:47 |
| cjwatson | but yeah, an hour is ridiculous | 14:47 |
| Keybuk | apw: which options are we mounting ext4 with by default at the moment? | 14:47 |
| apw | data=ordered i believe | 14:48 |
| cjwatson | I can take out that fsync and we can see if that helps; the bugs were more related to getting ENOEXEC on maintainer scripts | 14:49 |
| * apw checks | 14:49 | |
| cjwatson | we were getting flooded by bugs of that form | 14:49 |
| apw | cjwatson, i worry the one you need applies to all files | 14:49 |
| Keybuk | cjwatson: that would only be true if people have changed their ext4 mount options though, no? | 14:49 |
| cjwatson | apw: could you rephrase that? I don't understand | 14:49 |
| Keybuk | our defaults are sync metadata first | 14:49 |
| cjwatson | Keybuk: I have no idea, feel free to debug | 14:50 |
| apw | cjwatson, if you need the rename on the maintainer sync, i won't be supprised if its the same one we don't want for non-maintainer | 14:50 |
| cjwatson | bug 512096 is the master Ubuntu bug | 14:50 |
| ubottu | Launchpad bug 512096 in dpkg "[MASTER] Exec format error : package failed to install/remove : installation/removal script returned error exit status 2" [High,Fix released] https://launchpad.net/bugs/512096 | 14:50 |
| smb | Keybuk, apw Remember there has been the issue that the default was changed implicitely on Karmic | 14:50 |
| cjwatson | note the duplicate count | 14:51 |
| smb | Eh forget it that was ext3 I thinkg | 14:51 |
| cjwatson | apw: well, maintainer scripts are used rather more immediately | 14:51 |
| * apw does not see how an fsync could fix any of these issues unless the filesystem is well broken | 14:52 | |
| Keybuk | apw: this is the whole O_PONIES problem in a nutshell | 14:52 |
| Keybuk | Ted would describe it as "but you didn't call fsync(), so why would you expect the data you write/permissions you applied to be visible on the filesystem yet?" | 14:53 |
| Keybuk | if one process opens file, writes, set permissions, closes | 14:53 |
| Keybuk | there's no guarantee that a separate process will see that | 14:53 |
| apw | fsync only guarentees it will survive a crash | 14:53 |
| apw | as far as i know there is no ordering issue between threads | 14:53 |
| Keybuk | well, that's a different argument | 14:53 |
| Keybuk | at least the bug colin quoted explicitly says "crash" | 14:54 |
| apw | hrm | 14:54 |
| Keybuk | actually, no | 14:54 |
| apw | you'd think a sync at the end of the extract would do the trick | 14:54 |
| Keybuk | I think there *are* ordering issues between threads | 14:54 |
| * Keybuk is recalling presentations | 14:54 | |
| apw | but yeeks ... well we don't need to worry about the time it takes to compress the initramfs any more :) | 14:54 |
| Keybuk | POSIX provides no guarantees about the contents of files between threads | 14:54 |
| Keybuk | of their metadata | 14:54 |
| cjwatson | somebody did suggest a single sync() | 14:54 |
| Keybuk | or of their metadata, that should say | 14:55 |
| cjwatson | apw: as I said in the comments, we can address the performance, I wasn't particularly expecting it to stay this way for lucid | 14:55 |
| cjwatson | s/comments/changelog/ | 14:55 |
| apw | cjwatson, that seems more reasonable, but ... | 14:55 |
| Keybuk | so if one thread writes, the other isn't guaranteed to actually see the written data until fsync() | 14:55 |
| apw | Keybuk, hrm, ok ... | 14:55 |
| Keybuk | fsync() is not "guarantee data hits disk" | 14:55 |
| Keybuk | fsync() is "guarantee data is available for other processes" | 14:55 |
| Keybuk | so in fact, fsync() doesn't necessarily make you safe from crashing <g> | 14:56 |
| apw | fsync really is 'to disk' | 14:56 |
| === Pici` is now known as Pici | ||
| sistpoty|work | Keybuk: I beg to differ | 14:56 |
| apw | DESCRIPTION | 14:56 |
| apw | fsync() transfers ("flushes") all modified in-core data of (i.e., modi‐ | 14:56 |
| apw | fied buffer cache pages for) the file referred to by the file descrip‐ | 14:56 |
| apw | tor fd to the disk device (or other permanent storage device) where | 14:56 |
| Keybuk | Calling fsync() does not necessarily ensure that the entry in the | 14:56 |
| Keybuk | directory containing the file has also reached disk. For that an | 14:56 |
| Keybuk | explicit fsync() on a file descriptor for the directory is also needed. | 14:56 |
| apw | that file resides. | 14:56 |
| Keybuk | sistpoty|work: I'm reading slides presented by the ext4 filesystem maintainer here | 14:56 |
| Keybuk | if you have more authorative notes on the behaviour with fsync on ext4, please do share | 14:57 |
| sistpoty|work | Keybuk: I'm using common sense :P | 14:57 |
| cjwatson | the problem reported here was not, though, that the directory entry didn't exist | 14:57 |
| Keybuk | sistpoty|work: fsync does not guarantee the data has reached disk, because ATA and SCSI do not provide any such barrier command | 14:57 |
| apw | Keybuk, i think with ordered mode, the updates may ben ensured | 14:57 |
| Keybuk | you can send the writes to the disk, and the disk can acknowledgfe | 14:57 |
| Keybuk | but there's no guarantee the disk has done anything with them other than store the need to write in its memory | 14:58 |
| sistpoty|work | Keybuk: the disk guarantees that the data in the cache gets written | 14:58 |
| cjwatson | (FWIW, I did test an upgrade before upload, and while it was slower, I didn't see anything like that order of slowdown or I probably wouldn't have uploaded it) | 14:58 |
| Keybuk | sistpoty|work: not according to Ted | 14:58 |
| apw | Keybuk, that may be true, but the disk is lying if it says yes when its not written yet | 14:58 |
| Keybuk | cjwatson: the killer seems to be "packages with thousands of small files" | 14:58 |
| Keybuk | apw: apparently the disk is permitted to lie | 14:58 |
| Keybuk | anyway | 14:58 |
| Keybuk | that's a little sliding off topic | 14:58 |
| Keybuk | the key point is: | 14:58 |
| Keybuk | process #1 writes | 14:58 |
| Keybuk | process #2 reads | 14:58 |
| apw | Keybuk, i suspect its not allowed to, but they do | 14:58 |
| Keybuk | there's no guarantee in POSIX that process #2 can see what process #1 wrote | 14:59 |
| Keybuk | unless process #1 happened to call fsync() | 14:59 |
| Keybuk | and since dpkg uses separate processes to unpack | 14:59 |
| Keybuk | that would explain the bug | 14:59 |
| apw | that leaves us in a hole | 14:59 |
| Keybuk | dpkg unpacks the tarfile, writing maintainer scripts | 14:59 |
| sistpoty|work | Keybuk: a proper disk will write the data. if power goes out power to do the write is gained from the still rotating disc ;) | 14:59 |
| Keybuk | and calls rename() | 14:59 |
| Keybuk | at the rename() point, there's no guarantee that the metadata is sync'd | 15:00 |
| Keybuk | though fwict, ext4 data=ordered *is* supposed to guarantee that | 15:00 |
| Keybuk | sistpoty|work: again, please cite references | 15:00 |
| cjwatson | what are the guarantees on sync()? | 15:00 |
| sistpoty|work | Keybuk: please cite references that it's not the case | 15:00 |
| Keybuk | sistpoty|work: for a start, the fsync man page | 15:00 |
| Keybuk | If the underlying hard disk has write caching enabled, then the data | 15:00 |
| Keybuk | may not really be on permanent storage when fsync() / fdatasync() | 15:00 |
| Keybuk | return. | 15:00 |
| cjwatson | sistpoty|work: I would appreciate it if we could stay on the topic of this bug, and not go off onto a tangent about how it should be (which we had at great length when the whole ext4/rename/fsync saga came up last summer) | 15:00 |
| Keybuk | also see Ted Tso's presentation given at the Linux Filesystem Summit last year | 15:00 |
| apw | Keybuk, does that mean not another thread will be ok | 15:01 |
| apw | ie can we only sync the maintainer scripts | 15:01 |
| apw | ie a process which is not a thread | 15:01 |
| cjwatson | we do need to sync other things at *some* point - the maintainer scripts will use the contents of the package | 15:01 |
| Keybuk | cjwatson: I *think* sync() on a filesystem is intepreted as "fsync all files currently open" | 15:01 |
| Keybuk | but, reading my notes and Ted's notes here | 15:02 |
| Keybuk | that won't be right | 15:02 |
| Keybuk | the problem is that | 15:02 |
| apw | cjwatson, yeah that was what i was angling at too | 15:02 |
| Keybuk | open () | 15:02 |
| Keybuk | write () | 15:02 |
| cjwatson | void sync(void); # of course | 15:02 |
| Keybuk | fstat () | 15:02 |
| Keybuk | close () | 15:02 |
| Keybuk | rename () | 15:02 |
| Keybuk | there's no guarantee that the rename() actually copies the metadata | 15:02 |
| Keybuk | which is, I suspect, what you're seeing | 15:02 |
| cjwatson | Keybuk: that's the problem discussed at enormous length last year, and I was under the very strong impression that ext4 had been modified to consider rename() a barrier | 15:02 |
| Keybuk | cjwatson: only depending on mount options | 15:03 |
| cjwatson | even if Ted didn't like it, and didn't put it in his presentation ;-) | 15:03 |
| Keybuk | which is why I'm wondering if most of the reporters have changed their ext4 mount options | 15:03 |
| Keybuk | perhaps related to the whole bruaha about the fact we changed the default on them in karmic | 15:03 |
| cjwatson | 200 bugs? I suppose it's possible but this is a *lot* | 15:03 |
| Keybuk | possibly ... but otoh, I've *never* seen this issue | 15:03 |
| Keybuk | and I upgrade a *lot* | 15:03 |
| cjwatson | and I'm not sure it's an excuse for dpkg to fall over in a smelly heap anyway | 15:03 |
| Keybuk | cjwatson: right, so this was the whole O_PONIES thing | 15:04 |
| apw | we cirtinaly changed the default to be sensible now | 15:04 |
| Keybuk | the response from Ted was "use fsync() if you really want the data there ... but I'll add a data mode to provide the guarantee that ext3 did" | 15:04 |
| apw | to err on the side of safety | 15:04 |
| apw | i guess the issue is not that we have fsync'd but that we wait for it to finish before moving on to the next file | 15:05 |
| Keybuk | I think you have to wait for it to finish before you can rename() | 15:05 |
| apw | perhaps so, but none of that stops you moving on to the next file per-see | 15:06 |
| apw | as in using a thread per file in some sense and overlapping N files then each could fsync | 15:06 |
| cjwatson | is the file *permanently* truncated if you don't fsync before rename? | 15:06 |
| apw | and likely not break things | 15:06 |
| Keybuk | cjwatson: I thiiiiiink so | 15:07 |
| cjwatson | I didn't think that was the case | 15:07 |
| Keybuk | also permanently without its metadata | 15:07 |
| cjwatson | I thought it merely broke assumptions that the file was atomically in-place after rename | 15:07 |
| Keybuk | Ted sadly seems asleep right now | 15:07 |
| apw | Keybuk, now that i find hard to believe | 15:07 |
| apw | yeah i can believe there might be a window, but permenantly ... i doubt | 15:07 |
| Keybuk | it may be "shows up later" of course | 15:07 |
| apw | i would assume at least expec the next pdflush run to make it right | 15:07 |
| apw | and likelyt he window is smaller than that | 15:08 |
| cjwatson | of course, that is what dpkg is trying to achieve by its "write to .dpkg-new, rename" thing | 15:08 |
| cjwatson | it's deliberately trying to ensure that the window where you don't have full contents is *zero* | 15:08 |
| cjwatson | not just "oh, not a lot, pdflush will get to it" | 15:08 |
| apw | yeah fsync is not mad conceptually | 15:08 |
| cjwatson | because otherwise you end up with unreliable applications, etc. | 15:08 |
| apw | its that its blocking necesarily that its an issue | 15:08 |
| Keybuk | yeah, dpkg is using ian's ancient and wholly sensible that "write over there, rename to where you want it" is a very big and obvious clue about atomicity | 15:08 |
| Keybuk | and that was basically the crux of the argument against Ted | 15:09 |
| apw | i wonder how hard it would be to have multiple paralell writeres | 15:09 |
| cjwatson | it's news to me that ext4 only gained this guarantee on data=ordered, but reading git log I see that you're right | 15:09 |
| Keybuk | you have to do this rename() to provide atomicity of contents *anyway* | 15:09 |
| apw | so that each can fsync as long as they like | 15:09 |
| cjwatson | apw: in dpkg? *swallow* don't go there | 15:09 |
| apw | shame | 15:09 |
| apw | according to the sync() manual page that isn't guarenteed to wait for the sync to complete | 15:10 |
| Keybuk | apw: yes it is | 15:10 |
| apw | though it is believed to for current versions | 15:10 |
| Keybuk | apw: see BUGS | 15:10 |
| apw | thats what i just presee'd | 15:10 |
| Keybuk | Linux always waits for sync() to finish | 15:10 |
| apw | sync does here, but not everywhere where sync is | 15:10 |
| cjwatson | Keybuk: on another note, I almost hate to ask, but is the plymouth stuff likely to land in time that I can say it's done in the release meeting this afternoon? :) | 15:10 |
| apw | so its not a portable solution | 15:11 |
| Keybuk | cjwatson: we hit other bugs in testing | 15:11 |
| Keybuk | have you tested it to see whether it works for you? | 15:11 |
| cjwatson | "it" - your plymouth stuff? | 15:11 |
| Keybuk | yes | 15:11 |
| Keybuk | cjwatson: ppa:scott/ppa | 15:11 |
| cjwatson | I didn't know you'd published it :) | 15:11 |
| cjwatson | aha | 15:11 |
| sgallagh | Keybuk: Who's handling SSSD in Ubuntu these days? | 15:11 |
| Keybuk | nope, can't decode that one? | 15:12 |
| Keybuk | super secret squirrel detector? | 15:12 |
| Keybuk | SQUIRREL! | 15:12 |
| sgallagh | Keybuk: System Security Services Daemon | 15:13 |
| Keybuk | sgallagh: nope, still drawing a blank there | 15:13 |
| Keybuk | Prior to Ted Ts'o's session on fsync() and rename(), some joker filled the room with coloring-book pages depicting ponies. These pages reflected the sentiment that Ted has often expressed: application developers are asking too much of the filesystem, so they might as well request a pony while they're at it. | 15:13 |
| Keybuk | ... | 15:13 |
| Keybuk | heh | 15:13 |
| Keybuk | the "joker" was Ted! | 15:13 |
| Keybuk | http://blahg.josefsipek.net/?p=364 | 15:13 |
| sgallagh | Keybuk: I was wondering who was the Ubuntu maintainer. We (upstream) are working on releasing 1.1.0 next week, and I wanted to get them to pull down the nightlies and make sure we haven't broken anything on Ubuntu | 15:14 |
| Keybuk | sgallagh: Ubuntu doesn't have maintainers | 15:14 |
| Keybuk | (mostly) | 15:14 |
| sgallagh | ... | 15:14 |
| Keybuk | we use the time honoured tradition of "who touched it last" | 15:14 |
| sgallagh | Keybuk: Ok, so "Who touched it last"? :) | 15:14 |
| Keybuk | sgallagh: dunno, never heard of it | 15:15 |
| Keybuk | sgallagh: what does Launchpad say? | 15:15 |
| sgallagh | Keybuk: I have discussed it with you on at least three separate occasions :-/ | 15:15 |
| Keybuk | sgallagh: I have literally hundreds of discussions per day | 15:16 |
| sgallagh | Looks like Mathias Gug | 15:16 |
| Keybuk | and am right now devoting 95% of my brain to reading about ext4's issues with rename() | 15:16 |
| sgallagh | Ouch | 15:16 |
| Keybuk | now is not a good time for me to pretend to be google for you | 15:16 |
| sgallagh | Keybuk: no problem. I understand. | 15:17 |
| sgallagh | I'm not familiar with Ubuntu at all, really. A simple "It's in launchpad" would have been all the direction I needed :) | 15:17 |
| Keybuk | sgallagh: everything is in Launchpad | 15:18 |
| sgallagh | Good to know | 15:18 |
| cjwatson | sgallagh: I have a browser keyword for https://launchpad.net/ubuntu/+source/%s | 15:18 |
| cjwatson | substitute in a source package name and that gets you everything about that source package - very handy | 15:19 |
| sgallagh | cjwatson: Thanks | 15:19 |
| sgallagh | I mostly develop in Fedora, so my knowledge of other distros' build environments is... limited. | 15:19 |
| cjwatson | Keybuk: trying that out in conjunction with my console-setup work, thanks | 15:19 |
| tjaalton | sgallagh: hi, yeah mathias uploaded 1.0.2 on january, and it probably deserves an update since that version is known to be broken ;) | 15:20 |
| cjwatson | though it'll be a "works/doesn't-work for me" at best, I have too many other things to do as well | 15:20 |
| sgallagh | tjaalton: Yeah, that's rather old. | 15:21 |
| sgallagh | tjaalton: We're aiming to launch 1.1.0 sometime next week, but I'd like to know ahead of time if we're going to break the build on a non-Red Hat-based build-system. | 15:21 |
| Keybuk | cjwatson: of those 200-odd bugs, don't suppose you have a rough idea how many were "after a crash ..." and how many were "dpkg went wrong all on its own!" | 15:21 |
| cjwatson | Keybuk: do apparmor and brltty need to be migrated to udev/upstart at all for lucid? they're still on the list, but I'm wondering if they should be postponed at this point | 15:21 |
| sgallagh | tjaalton: So if you have some free time... | 15:21 |
| cjwatson | Keybuk: unfortunately not, somebody else was dealing with triaging them and I talked to that guy rather than doing most of the legwork myself | 15:21 |
| cjwatson | Keybuk: it was jibel, I believe | 15:22 |
| tjaalton | sgallagh: I managed to get winbind to work, and haven't had time to play with sssd for awhile | 15:22 |
| sgallagh | I'd like to collaborate with whomever is going to do the build, because a few things changed (of note, we're producing quite a few additional shared libraries) | 15:22 |
| Keybuk | cjwatson: I would like to, if I find the time | 15:22 |
| tjaalton | sgallagh: I can try if it builds | 15:22 |
| sgallagh | tjaalton: That would be great. | 15:22 |
| sgallagh | tjaalton: What's in our nightly right now is pretty close to the final build (unless of course we've broken it for other distros) | 15:23 |
| tjaalton | sgallagh: ok, I'll try 1.0.99 first, or is it too old to bother? | 15:24 |
| cjwatson | Keybuk: beta-2, then? | 15:24 |
| Keybuk | cjwatson: yeah | 15:24 |
| sgallagh | tjaalton: Better to use the latest nightly. | 15:24 |
| cjwatson | ok, updating metadata | 15:24 |
| Keybuk | it's one of those "they should have been done by now, but too many other things that should have been done by are taking too long" things | 15:24 |
| Keybuk | e.g. I've been saying "Plymouth will be uploaded today" all week | 15:25 |
| sgallagh | tjaalton: I made several build-system changes after 1.0.99 (not that I had originally planned to...) | 15:25 |
| tjaalton | sgallagh: where can I find the nightly build? | 15:25 |
| Keybuk | cjwatson, apw: ok, so my understanding is that after open() write() close() rename(), there is a period during which there's no guarantees what the file might actually contain | 15:25 |
| Keybuk | and that in practice, this period tends to be "up to 5s" | 15:25 |
| cjwatson | Keybuk: we should probably revisit the dpkg discussion after beta-1/ | 15:25 |
| cjwatson | ? | 15:25 |
| Keybuk | so writing out maintainer scripts, renaming them, then trying to exec() them may fail | 15:25 |
| Keybuk | because they're not executable | 15:25 |
| Keybuk | and because they don't have any data in them | 15:26 |
| sgallagh | tjaalton: git clone git://git.fedorahosted.org/sssd.git | 15:26 |
| Keybuk | I'll need to talk with Ted to make sure I'm right though | 15:26 |
| cjwatson | though I suppose it wouldn't hurt to check that d-i doesn't take unreasonably long | 15:26 |
| tjaalton | sgallagh: got it, thanks | 15:26 |
| sgallagh | tjaalton: There's an RPM repository available at http://jdennis.fedorapeople.org/ipa-devel/fedora/12/x86_64/os/ if you want to compare to the Fedora packages | 15:26 |
| tjaalton | sgallagh: is the packaging in git or svn? | 15:27 |
| sgallagh | tjaalton: I don't understand the question | 15:27 |
| tjaalton | sgallagh: the spec file etc | 15:27 |
| tjaalton | like in cvs.fp.org | 15:28 |
| sgallagh | tjaalton: We have a reference spec file in the contrib/ directory in the source | 15:28 |
| tjaalton | alright | 15:28 |
| sgallagh | That forms the basis for what goes into cvs.fp.org | 15:28 |
| sgallagh | (Right now cvs.fp.org is still building SSSD 1.0.5) | 15:28 |
| tjaalton | the spec file in contrib/ is older :) | 15:29 |
| sgallagh | tjaalton: Huh? | 15:29 |
| tjaalton | at least the version says 0.6.0 | 15:29 |
| sgallagh | That doesn't seem right. Hang on. | 15:30 |
| sgallagh | Oh, ignore the changelog | 15:30 |
| tjaalton | ok | 15:30 |
| sgallagh | We don't usually keep that up to date in that spec file | 15:30 |
| sgallagh | We should, though | 15:31 |
| sgallagh | At some point I'm going to make that autogenerated from the git commit list. | 15:31 |
| tjaalton | ok I'll give it a go and will post the result on #freeipa :) | 15:32 |
| sgallagh | tjaalton: Thanks much! | 15:33 |
| jibel | Keybuk, cjwatson, hi, to answer your question above. nearly 90% are due to a system crash. | 15:42 |
| gnumdk | Hello | 15:43 |
| gnumdk | Is there any firefox packager in the place? | 15:43 |
| jibel | Keybuk, I reviewed a large part of them http://paste.ubuntu.com/394082/ | 15:43 |
| Keybuk | jibel: that's good to know | 15:45 |
| Keybuk | it's a shame we don't know which ext3/4 mount options they're using | 15:45 |
| Keybuk | or if they're using XFS, etc. | 15:45 |
| tjaalton | mathiaz: hey, sgallagh asked to test-build the upcoming sssd 1.1.0. I did that, seemed to build fine, though it probably needs some packaging changes | 15:47 |
| mathiaz | tjaalton: hi - good to know | 15:47 |
| tjaalton | had to comment out the patches, and the final packaging phase fails, but upstream-wise it builds fine | 15:47 |
| mpt | mvo, bug 538129 | 15:48 |
| ubottu | Launchpad bug 538129 in software-center "UI freeze exception: Remove stars and reference to non-existent "reviews"" [Undecided,New] https://launchpad.net/bugs/538129 | 15:48 |
| jibel | Keybuk, from the type of reporter, most of them are using the standard setup. | 15:48 |
| mathiaz | tjaalton: I was planning to upload the latest 1.0.X to lucid | 15:48 |
| mathiaz | tjaalton: It seems that 1.1.0 has new features, which is too late for lucid IMO | 15:48 |
| sgallagh | tjaalton: I suspect that the patches in your build-system were the ones that we got pushed upstream a few months ago | 15:48 |
| jibel | Keybuk, the problem appeared in Jaunty, with the release of ext4 | 15:48 |
| tjaalton | sgallagh: actually they just touched the config, and Makefile.am to change some paths | 15:49 |
| tjaalton | mathiaz: well, I'll let sgallagh comment on that :) | 15:49 |
| sgallagh | oh, ok. I thought it was the linking bug we fixed a while ago | 15:49 |
| tjaalton | sgallagh: nah it never got to the package.. | 15:49 |
| Keybuk | jibel: the "standard setup" has changed many times | 15:49 |
| tjaalton | could've uploaded it myself but. | 15:50 |
| sgallagh | mathiaz: Is lucid in feature freeze? | 15:50 |
| mathiaz | sgallagh: yes | 15:50 |
| mathiaz | sgallagh: that's why I was planning to upload the latest 1.0.x (1.0.4) IIRC | 15:51 |
| tjaalton | it's 1.0.5 | 15:51 |
| sgallagh | mathiaz: It's 1.0.5, but there are no functional changes between them. We just discovered that we were missing license attribution on several files. | 15:51 |
| sgallagh | And we removed some dead code | 15:52 |
| tjaalton | the package is in universe though, and because of the linking bug was practically unusable :) | 15:52 |
| tjaalton | so maybe no-one used it in the meantime | 15:52 |
| tjaalton | (other than me) | 15:53 |
| tjaalton | no wait, some Finn thanked on the bug for the linking patch :) | 15:54 |
| sgallagh | :) | 15:54 |
| sgallagh | So, yeah, there are some new features in 1.1 (https://fedorahosted.org/sssd/wiki/Releases/Notes-1.0.99 has a list of pretty much all of them, we've mainly just been stabilizing since then) | 15:55 |
| sgallagh | The three biggest are full IPv6 support, support for ldap referral tracking and we substantially improved performance when enumerate=false (so it's now the better solution for 99% of all deployments) | 15:57 |
| psusi | Keybuk: got some questions for you about ureadahead... does --dump list the files in the order they were accessed? Is that the order they are read in, or are they read in inode order or something else to attempt to speed it up? | 16:08 |
| === beuno is now known as beuno-lunch | ||
| Keybuk | psusi: depends on --sort ;-) | 16:10 |
| psusi | Keybuk: which part? the dumping or the reading? | 16:10 |
| Keybuk | --dump usually dumps files in the order that they'll be opened | 16:10 |
| psusi | ok... and when they are read, are they read in that order, or some other order to attempt to minimize seeks? | 16:11 |
| Keybuk | no | 16:11 |
| Keybuk | ureadahead doesn't read files ;-) | 16:11 |
| Keybuk | files are merely a method of getting to blocks | 16:11 |
| psusi | well, it calls readahead() on the files in question ;) | 16:12 |
| Keybuk | no it doesn't | 16:12 |
| === Tonio_ is now known as Tonio__ | ||
| === Tonio__ is now known as Tonio_ | ||
| psusi | it doesn't? that's what the man page said I could have sworn | 16:12 |
| Keybuk | that's the kind of thing that dumb-arse entirely-un-über readahead implementations do ;-) | 16:12 |
| psusi | ohh, goody.... so you do it better? I was thinking that calling readahead() was sub-optimal | 16:13 |
| psusi | so what does ureadahead do? | 16:13 |
| Keybuk | depends on whether you're using an SSD or HDD :-) | 16:14 |
| * psusi is trying to use defrag to pack the files in the most optimal way | 16:14 | |
| psusi | well let's start with HDD then go into SSD since I just ordered one yesterday and my wife says it arrived an hour ago ;) | 16:14 |
| Keybuk | HDD | 16:14 |
| Keybuk | given a set of files that were opened during boot | 16:15 |
| Keybuk | we query the kernel to find out what segments of those files are in the page cache | 16:15 |
| Keybuk | then, for each of those segments, we query the kernel to break them into lists of on-disk extents | 16:15 |
| psusi | ohh, it doesn't use blocktrace to see what is actually being read and in what order? | 16:15 |
| Keybuk | we take the big list of on-disk extents, and sort that | 16:15 |
| Keybuk | that gives us the "blocks to be read" | 16:15 |
| Keybuk | we can't read blocks directly though, we need file descriptors | 16:16 |
| Keybuk | so we retain the list of opened files (which is sorted by ext inode number, so roughly on disk position) | 16:16 |
| Keybuk | we open all files in one pass | 16:16 |
| Keybuk | then, with all the files open, we iterate the blocks list | 16:16 |
| Keybuk | this means that as far as files are concerned, our reading is entirely random | 16:16 |
| Keybuk | we might read 4k from the end of the file | 16:16 |
| Keybuk | then 4k from the middle of another file | 16:16 |
| Keybuk | then 4k from the start of the first file | 16:16 |
| Keybuk | then 16k from another file | 16:16 |
| Keybuk | etc. | 16:16 |
| psusi | aye, so you read in actual block order to minimize seeks? | 16:17 |
| Keybuk | correct | 16:17 |
| Keybuk | ureadahead under blktrace looks like two (well three) passes | 16:17 |
| psusi | and what method do you actually do the reading by if not readahead()? | 16:17 |
| Keybuk | you have a pass to open the files from start to end of the disk | 16:17 |
| Keybuk | then a pass across the disk to readahead | 16:17 |
| Keybuk | we use readahead, just not "on [whole] files" | 16:17 |
| psusi | right, that's what I thought, you specifically readahead only the parts of the files that ar eneeded | 16:18 |
| Keybuk | yes | 16:18 |
| Keybuk | in a random order with other files interspersed | 16:18 |
| psusi | aye, in the order the blocks actually appear on disk | 16:18 |
| Keybuk | on SSD, this is slightly different | 16:19 |
| Keybuk | we don't break file segments by on disk extents | 16:19 |
| Keybuk | the files list is sorted by access order | 16:19 |
| Keybuk | the block list is "collapsed" files list | 16:20 |
| Keybuk | we iterate the blocks list without opening files | 16:20 |
| Keybuk | so effectively, we read all the blocks for each file in turn, in the order the file was accessed | 16:20 |
| Keybuk | opening files at the first point we have a block for that file | 16:20 |
| Keybuk | this gives a *very* scattered, random read profile under blktrace | 16:20 |
| Keybuk | SSDs like that | 16:20 |
| psusi | hrm... well ok... so having defrag pack the files at the start of the disk should help some since you won't have to do any seeking at all, but ureadahead already eliminates any backwards seeking | 16:22 |
| psusi | so it won't help a whole lot | 16:22 |
| Keybuk | it'll eliminate the seeks | 16:23 |
| Keybuk | the seeks are a big part of the loss of throughput | 16:23 |
| Keybuk | if we had all the data we want to read, at the start of the disk, contiguously | 16:23 |
| Keybuk | we could slam the kernel quickly with it | 16:23 |
| Keybuk | and hope the I/O elevator goes "oh, you want the first 100MB, I can do that" *reeeeeeeeeeeeeeeeeeeeeeeead* | 16:24 |
| psusi | right, but ureadahead already eliminates any backwards seeking so you are only left with some forward seeks to slow you down, so there is still some room for improvement, just not a whole lot | 16:24 |
| Keybuk | forward seeks are still a lot | 16:24 |
| Keybuk | reading data from disk is like shopping with your granny | 16:24 |
| Keybuk | sure, it's very helpful keeping her in a straight line | 16:24 |
| psusi | hehehe | 16:24 |
| psusi | yea | 16:24 |
| Keybuk | if she turns around, you're going to be there for weeks | 16:24 |
| Keybuk | but you're still going to be spending a lot of your time staring at your feet, wondering how slow it's actually possible for you to walk, and experimenting with games of feet placement | 16:25 |
| psusi | it's a shame that there isn't a system call where you could force the kernel to populate the buffer cache with data that you read from a contiguous pack file | 16:25 |
| Keybuk | you'd need to know which file it was | 16:26 |
| psusi | i.e. rather than just put the block trace info in the pack file, actually copy the needed data pages there, so you can read them all in at once and in order from that file at boot | 16:26 |
| Keybuk | which means your pack could go out of date every time the filesystem shifted about a bit | 16:26 |
| psusi | even if the files themselves are scattered all over hell and back | 16:26 |
| psusi | right... true... | 16:26 |
| Keybuk | kernel block cache is mostly along the lines of "N pages at sector X" | 16:26 |
| Keybuk | it'd be nice if we didn't have to open() files to readahead() blocks from them | 16:26 |
| Keybuk | the kernel team are vaguely playing with that | 16:26 |
| mvo | bdmurray: did we get dupes of #369951 in recent history? can you see that with your magic LP superpowers :) ? the empty VarLogDistupgrade200xxx - do we get those on more recent releases like lucid or karmic? | 16:27 |
| psusi | would also be nice if you didn't have to block on readahead, then have the disk idle for a split second while you issue the next readahead | 16:27 |
| Keybuk | we don't have to block on readahead | 16:27 |
| Keybuk | we can use posix_fadvise (WILLNEED) | 16:27 |
| Keybuk | but I didn't find that helped any | 16:27 |
| psusi | what do you mean we don't have to block on readahead? it's a blocking call isn't it? | 16:27 |
| Keybuk | readahead() is, posix_fadvise() isn't | 16:28 |
| psusi | is that actually implemented? | 16:28 |
| Keybuk | in kernel, yes | 16:28 |
| psusi | ohh.. hrm... wonder how that works | 16:28 |
| psusi | ideally you want to keep the disk io queue from being empty ever, which it is for a moment between calls to readahead() | 16:29 |
| Keybuk | that we don't have a problem with | 16:30 |
| psusi | and I seem to remember something about IO plugging where the disk driver decides to plug up when the queue goes empty, and when the first request comes in from the next readahead(), it waits like 20 ms before servicing it to see if any further requests enter the queue and give the elevator a chance to coalese them | 16:30 |
| psusi | why not? | 16:30 |
| nxvl | dholbach: ping | 16:31 |
| === doko_ is now known as doko | ||
| Keybuk | cause we spent a long time staring at blktrace output to make sure we were always getting merges with contiguous blocks | 16:31 |
| Keybuk | it's quite cute | 16:31 |
| Keybuk | when you read 4K from one file, and 4K from another | 16:31 |
| Keybuk | but the blocks are actually contiguous from disk | 16:31 |
| Keybuk | the kernel does a single read | 16:31 |
| psusi | right... | 16:31 |
| Keybuk | and ureadahead on HDD is like IO_PRIO_IVANOVA and CPU_PRIO_GOD | 16:32 |
| psusi | but you don't read 4k from the second file until the 4k from the first file has been read | 16:32 |
| Keybuk | sure we do | 16:32 |
| dholbach | nxvl: pong | 16:32 |
| Keybuk | readahead() doesn't seem to actually block :p | 16:32 |
| psusi | lol, really? | 16:32 |
| psusi | the man page seems to indicate that it does not return until the data is actually in the page cache | 16:32 |
| nxvl | dholbach: about GSoC, i'm participating as community member, where should i send the proposal of my idea? To you or write it somewhere in the wiki? | 16:32 |
| nxvl | dholbach: and until when do i have to send the proposal | 16:33 |
| Keybuk | psusi: pfft, manpages :p | 16:33 |
| psusi | but if it just puts the read request in the queue then returns... then yea. that's fantastic | 16:33 |
| dholbach | nxvl: can you join #ubuntu-gsoc | 16:33 |
| === yofel_ is now known as yofel | ||
| Keybuk | psusi: I didn't see any difference between readahead() and posix_fadvise(WILLNEED) | 16:34 |
| psusi | so then it doesn't matter what order the files are in, as long as defrag packs them all at the start of the disk. ureadahead will read them in order... hrm... I gotta try this... | 16:34 |
| Keybuk | start or end | 16:34 |
| Keybuk | or middle | 16:34 |
| psusi | well, start is usually fastests | 16:35 |
| Keybuk | or in interesting places somewhere across the sector boundaries | 16:35 |
| Keybuk | start's usually around the outside of a cylinder isn't it? :p | 16:35 |
| psusi | it's usually wherever the drive is fastest ;) | 16:35 |
| psusi | up to the drive to figure that out | 16:35 |
| Keybuk | but yeah, sounds good | 16:36 |
| apw | Keybuk, i don't think that can be right, there is no way that i edit source, and then it may or may not be in the file if i open it for 5 s | 16:36 |
| apw | that is mental semantics | 16:36 |
| Keybuk | for added bonus, ureadahead was always intended to be able to output its pack file in a "format ready for defrag" | 16:36 |
| Keybuk | apw: reading back, I don't think I am right - I think a crash has to apply between | 16:36 |
| Keybuk | I may have confused NFS with reality there | 16:36 |
| psusi | well, I stripped the output of --dump down to the bare file names last night... will have to have ls translate that into inode numbers tonight and pass the list to e2defrag and see what happens | 16:36 |
| apw | Keybuk, ok phew | 16:36 |
| Keybuk | psusi: inode numbers are in the pack file | 16:36 |
| Keybuk | would it help if I told you the pack file format? :p | 16:37 |
| psusi | lol... no, I'd rather not write any C code if I can do it with some shell ;) | 16:37 |
| Keybuk | you can do it with python | 16:37 |
| Keybuk | it means you get correct results | 16:37 |
| psusi | I don't know python | 16:37 |
| Keybuk | or you could tell me what data you actually want, in what order | 16:37 |
| Keybuk | and I can knock you up some code in a few minutes ;) | 16:37 |
| psusi | well e2defrag just wants a list of inode numbers and you can tag them with a priority | 16:38 |
| Keybuk | ok, two secs | 16:38 |
| psusi | it then uses that list to alter the standard order it packs the files in, which is normally just inode number order | 16:41 |
| Keybuk | psusi: http://people.canonical.com/~scott/inodes.pl | 16:58 |
| === deryck is now known as deryck[lunch] | ||
| jpds | Keybuk: 404! | 17:02 |
| Keybuk | shouldn't be now | 17:02 |
| unggnu | hi all | 17:08 |
| Keybuk | I so just thought I saw ubuntulog saying "hi all" | 17:08 |
| unggnu | :D | 17:09 |
| unggnu | Are there plans to switch from bz2 to lzma for the repository files? Afaik for some packages lzma is already used so it shouldn't be a big deal. I mean the files are downloaded nearly every day and are quite big I think. | 17:09 |
| unggnu | Also the decompression should be faster than with bz2. :) | 17:09 |
| cjwatson | it's a package-specific decision | 17:10 |
| cjwatson | the default remains gz and is likely to stay that way | 17:10 |
| unggnu | cjwatson: I don't mean for the packages itself but for the information about the packages. | 17:10 |
| cjwatson | oh, ask the launchpad team, not something we control | 17:10 |
| unggnu | cjwatson: something like that: http://archive.ubuntu.com/ubuntu/dists/lucid/universe/binary-i386/ | 17:11 |
| cjwatson | though that said apt might not support it yet | 17:11 |
| unggnu | cjwatson: afaik packages like openoffice and similar are already compressed with lzma so dpkg should be able to do it, at least with Lucid and most likely Karmic | 17:12 |
| unggnu | I don't know, I just thought it would be great especially for people with slower connections. | 17:12 |
| cjwatson | why does that follow? package decompression and index acquisition is completely different code, and dpkg doesn't do that decompression anyway. | 17:13 |
| unggnu | Even with six megabit they take some time. | 17:13 |
| unggnu | cjwatson: Ok, but some parts are able to use lzma that's why I thought it shouldn't be a big deal | 17:13 |
| cjwatson | unggnu: I didn't say it would be a big deal | 17:14 |
| * Keybuk hands cjwatson the "patches welcome" button | 17:14 | |
| cjwatson | anyway, adding it to the dists tree on archive.ubuntu.com is still something the Launchpad team would need to do | 17:14 |
| unggnu | Of course incremental update information would be better but until then :) | 17:15 |
| ogra | it is a big deal for arches that already have issues to handle the current uncompressing though | 17:15 |
| * ogra points to armel | 17:15 | |
| unggnu | ogra: afaik lzma decompresses faster than bz2, it only uses more mem | 17:15 |
| ogra | unggnu, right, which is a problem on armel :) | 17:16 |
| unggnu | But this shouldn't be a problem for ~six MB files | 17:16 |
| ogra | its limited in both, CPU and memory | 17:16 |
| cjwatson | this conversation belongs in a bug report or something | 17:16 |
| unggnu | ogra: they can use bz2 or gz (I suppose there is a reason why the reps are still shipped with gz) | 17:17 |
| Caesar | lucas: so can I reassign that bug back to Ruby then? | 17:17 |
| unggnu | cjwatson: Would it make sense? I mean it is considerable? That's what I am mainly asking. :) | 17:17 |
| unggnu | *possible | 17:18 |
| cjwatson | unggnu: I thought I'd answered that. I don't see why it would be infeasible | 17:18 |
| cjwatson | it might not be *straightforward* for reasons you haven't considered, but I don't see why it would be *infeasible* | 17:18 |
| unggnu | That's the point why I am asking here :=) | 17:19 |
| === MacSlow is now known as MacSlow|capoeira | ||
| lucas | Caesar: I think it's still assigned to it | 17:36 |
| unggnu | cjwatson: btw. this is/was the blueprint for the packages https://wiki.ubuntu.com/dpkg-lzma | 17:36 |
| Caesar | lucas: it is, I'm asking if I should reassign it back to ruby | 17:36 |
| cjwatson | unggnu: thanks, I was aware of that | 17:37 |
| lucas | Caesar: I meant: it is still assigned to ruby. (ruby-defaults, while it should be ruby1.8). Anyway, it's on my radar, and on my todo list | 17:38 |
| Caesar | ok | 17:39 |
| === beuno-lunch is now known as beuno | ||
| === mnepton is now known as mneptok | ||
| === deryck[lunch] is now known as deryck | ||
| doko | Riddell, kees: why is qt4-x11 built with -fno-stack-protector ? | 18:28 |
| nixternal | cjwatson: just got an email about dmb joining cli/mono...did I miss something there? | 18:57 |
| cjwatson | nixternal: requested and approved delegation from the technical board | 18:58 |
| cjwatson | I'm in the process of setting it up, with the DMB as team admin | 18:58 |
| nixternal | gotcha..just wanted to make sure something silly wasn't going on :) | 18:58 |
| nixternal | i get spam emails from time-to-time that are similar in nature | 18:59 |
| cjwatson | ah, no, this was legit | 18:59 |
| nixternal | i got one the other day that said the ubuntu france loco team was now the admin of ubuntu-devel :) | 19:00 |
| cjwatson | maybe I'll change it to "uploaders" | 19:01 |
| maco | are all the amd64 buildd's broken? | 19:03 |
| maco | i just had one package on yellow and one on osmium fail with "chroot problem" | 19:03 |
| james_w | what particular problem? | 19:04 |
| james_w | ntp? | 19:04 |
| maco | james_w: yep | 19:05 |
| maco | both systems | 19:05 |
| ScottK | maco: lamont is giving back the in archive ones. You'll have to retry any PPA builds yourself. | 19:07 |
| maco | ScottK: ok well im leaving for the airport in an hour, so if amarok in kubuntu experimental fails can you retry it for me? | 19:07 |
| maco | (i386 is done) | 19:08 |
| ScottK | maco: Link me. | 19:08 |
| maco | ScottK: https://edge.launchpad.net/~kubuntu-ppa/+archive/experimental/+build/1558557 | 19:08 |
| ScottK | Got it. | 19:08 |
| maco | ScottK: thanks | 19:08 |
| rzr | cjwatson: hi i am reading your email about parted | 19:26 |
| rzr | cjwatson: as fatresize maintainer , how can I help ? BTW I plan to move it to some team | 19:27 |
| rzr | cjwatson: will try to rebuild it this W/E | 19:30 |
| rzr | back | 19:36 |
| Roblob | why are the menus on the left? | 19:44 |
| rzr | cjwatson: i applied to parted debian team | 19:44 |
| Keybuk | Roblob: because Ubuntu comes from the UK | 19:44 |
| Keybuk | if it came from Europe or the US, they'd be on the right | 19:44 |
| vish | lol | 19:44 |
| Keybuk | it's a bit like driving an import | 19:44 |
| maco | Keybuk: :P | 19:45 |
| Roblob | Keybuk, doesnt ubuntu come from ZA? South Africa? | 19:46 |
| maco | Roblob: canonical is based in london | 19:46 |
| maco | Roblob: though mark originally comes from ZA | 19:46 |
| zyga | manjo: ping | 19:48 |
| zyga | marjo: ping | 19:48 |
| zyga | (sorry manjo) | 19:48 |
| cjwatson | rzr: I'll send you a reference to the patch - it's fairly straightforward | 19:50 |
| kees | doko: I don't know -- I find that highly upsetting. | 19:53 |
| kees | doko: anything with such exceptions is supposed to be listed here: https://wiki.ubuntu.com/CompilerFlags#Problems | 19:54 |
| jdong | hmmm do we have a procedure for archive removals (completely), like what we did with sun-java*? | 19:55 |
| jdong | the upstream Sagemath guys are pretty irate about our packages | 19:56 |
| yannick | hey guys how can i get kdelibs >= 4.4. ? | 19:56 |
| jdong | debian bug 573538 | 19:56 |
| ubottu | Debian bug 573538 in sagemath "Please remove the sagemath package" [Grave,Open] http://bugs.debian.org/573538 | 19:56 |
| ScottK | I think there's already a removal bug for sagemath. | 19:57 |
| sebner | doko: MOTU-MONO hasn't been active for years anyways but would it be a good idea to close it as we now finally have our cli-package-set? | 19:58 |
| ScottK | jdong: sagemath is already removed from Lucid. | 19:59 |
| jdong | ScottK: can we backpropagate that removal to Karmic? | 20:00 |
| ScottK | Not a lot we can do about stuff that's already released. | 20:00 |
| cjwatson | jdong: no, sorry | 20:00 |
| jdong | *nods* | 20:00 |
| jdong | ok, I'll let the Debian maintainer know. | 20:00 |
| Chipzz | sigh | 20:02 |
| Chipzz | that looks like a very poor way of handling things | 20:02 |
| Chipzz | (on account of upstream) | 20:02 |
| Chipzz | they should have worked with the debian maintainer to get a more recent version included, or have the bugs fixed | 20:03 |
| Chipzz | but encouraging users to compile it themselves... where did I leave my cluebat? :P | 20:03 |
| jdong | with regards to sagemath, if in the future a proper package shows up, would it be okay to send it through the SRU process to karmic-updates? | 20:04 |
| zyga | mvo: hi! | 20:05 |
| zyga | mvo: how are you? I heard you are ill | 20:06 |
| james_w | jdong: worth a go if there is a significant improvement IMO. No-one's going to pre-approve an unseen package though. | 20:07 |
| mvo | hey zyga - indeed, good to see you! how are you doing? | 20:07 |
| jdong | james_w: oh definitely. Just making sure there's no *SLAP* BAD JDONG CRACK initial reaction to the idea :) | 20:08 |
| Chipzz | reading the discussion further... shipping forked copies of other libraries... another facepalm :P | 20:08 |
| mvo | zyga: I'm much better now, I was sick with a stomach bug, but I'm much better now | 20:08 |
| cjwatson | Riddell: is bug 538231 the same as bug 538142? | 20:08 |
| ubottu | Launchpad bug 538231 in ubiquity "[Lucid]Ubiquity appears to crash in Kubuntu Live CD environment but then runs successfully after error dialogs closed." [Undecided,New] https://launchpad.net/bugs/538231 | 20:08 |
| ubottu | Launchpad bug 538142 in ubiquity "kconfig permissions errors starting kubuntu ubiquity" [Undecided,New] https://launchpad.net/bugs/538142 | 20:08 |
| zyga | mvo: I released c-n-f 0.2.41 | 20:09 |
| zyga | a minor update since previous ubuntu package | 20:09 |
| mvo | zyga: sweet, does it fix bug #507760? | 20:09 |
| ubottu | Launchpad bug 507760 in command-not-found "c-n-f does not suggest commands with numbers ('bzip' does not suggest 'bzip2')" [Low,Fix released] https://launchpad.net/bugs/507760 | 20:09 |
| mvo | zyga: it appears it does \o/ | 20:09 |
| mvo | zyga: I sposnor it tonight! | 20:09 |
| zyga | mvo: thanks | 20:11 |
| zyga | mvo: I'll make a few more releases with less critical fixes | 20:11 |
| zyga | mvo: but this one is targeted for lucid | 20:11 |
| mvo | zyga: excellent, much appreciated | 20:11 |
| mvo | zyga: keep me updated at irc, I will immediately sponsor | 20:11 |
| zyga | mvo: thanks! :-) | 20:11 |
| mvo | well, thank *you* :) | 20:12 |
| zyga | that's all from me, I'm going back to coding | 20:12 |
| mvo | happy hacking | 20:12 |
| * mvo will also do a data-updated while at it | 20:12 | |
| zyga | oh | 20:12 |
| zyga | that reminds me | 20:12 |
| zyga | where can I find scan.data? | 20:12 |
| zyga | I found one in ubuntu source package | 20:12 |
| zyga | mvo: https://edge.launchpad.net/~zkrynicki/+archive/command-not-found (PPA with release) | 20:15 |
| mvo | zyga: http://people.canonical.com/~mvo/command-not-found/ | 20:15 |
| mvo | zyga: I assume you have the code in a bzr branch as well? | 20:15 |
| mvo | ready for merging | 20:15 |
| zyga | mvo: yes | 20:16 |
| zyga | mvo: it's in lp:command-not-found | 20:16 |
| zyga | trunk | 20:16 |
| zyga | mvo: there are +3 new strings I think, I don't know if that's a problem | 20:16 |
| zyga | if so I can work around that by removing some features | 20:16 |
| zyga | mvo: I was going to ask about #533031 | 20:21 |
| GheRivero | hi everyone | 20:21 |
| zyga | bug #533031 | 20:21 |
| ubottu | Launchpad bug 533031 in command-not-found "command-not-found fails to work on ports architectures" [Low,Triaged] https://launchpad.net/bugs/533031 | 20:21 |
| mvo | zyga: its a bit of a problem because we are in UI (string) freeze, but we can mail the translators list if its important | 20:21 |
| * hyperair wonders if jdstrand is around. | 20:21 | |
| mvo | zyga: port> oh, right. its currently not crawling those as the server I run it on has only the normal archive mirrored | 20:22 |
| zyga | mvo: it's not critical, if you want I can work on that to remove the requirement | 20:22 |
| mvo | zyga: I have a look and let you know | 20:22 |
| zyga | thanks | 20:22 |
| zyga | mvo: I integrated ubuntu translations into trunk so hopefully we can have a better state of translations the next time, translations can happen upstream for a change | 20:23 |
| nxvl | bryceh: ping | 20:27 |
| lucas | pitti: can you clarify why you switched ruby1.8 to libreadline-dev instead of libreadline5-dev? according to #553843 it is a license violation | 20:40 |
| lucas | pitti: ruby1.8 is "ruby license or GPLv2". readline6 is GPLv3 | 20:45 |
| Keybuk | lucas: ruby doesn't appear to specify which GPL version, actually | 20:46 |
| Keybuk | it just says "the terms of the GPL" | 20:46 |
| lucas | Keybuk: next line | 20:47 |
| lucas | :-) | 20:47 |
| Keybuk | what next line? | 20:47 |
| lucas | in COPYING? | 20:47 |
| micahg | lucas: I think the plan was to drop libreadline5-dev from Lucid | 20:47 |
| Keybuk | I was reading debian/copyright | 20:47 |
| lucas | never trust the debian maintainer | 20:47 |
| Keybuk | lucas: I'm quoting you on that next time I follow one of your talks at a conference ;-) | 20:48 |
| Keybuk | though that being said | 20:48 |
| Keybuk | COPYING was changed years after debian/copyright was written | 20:48 |
| lucas | * COPYING: explicitly note GPLv2. [ruby-talk:187922] | 20:49 |
| lucas | Date: Sun Apr 9 16:10:40 2006 +0000 | 20:49 |
| Keybuk | right, and debian/copyright was written 2003! | 20:49 |
| Keybuk | but yes, I agree with you | 20:49 |
| Keybuk | ruby1.8 is GPLv2 only | 20:49 |
| Keybuk | so cannot link with GPLv3 code, or LGPLv3 code | 20:49 |
| === MacSlow|capoeira is now known as MacSlow | ||
| lucas | there's another, more serious problem with ruby1.8, actually. we link to openssl, so we basically choose the ruby license, not the GPLv2 one. and then we link to readline5 (in Debian), which is GPLv2 or later | 20:51 |
| Keybuk | does that problem exist in Debian too? :p | 20:53 |
| lucas | Keybuk: yes | 20:53 |
| lucas | Keybuk: (I'm one of the maintainers) | 20:53 |
| Keybuk | hmm, just checking | 20:53 |
| Keybuk | doesn't only libopenssl-ruby1.8 end up linked with libopenssl? | 20:53 |
| Keybuk | and doesn't get linked to readline? | 20:53 |
| Keybuk | that's not _technically_ in violation then <g> | 20:53 |
| lucas | that's correct | 20:54 |
| slangasek | technical violations are the only ones that matter ;) | 20:54 |
| Keybuk | each binary package is individually redistributable without breaking licence | 20:54 |
| Keybuk | so they can be distributed together too | 20:54 |
| Keybuk | (aggregate argument) | 20:54 |
| lucas | mmh, what happens if a ruby app uses both the openssl and readline libraries? | 20:55 |
| Keybuk | except for the libreadline6 link, obviously - that's a definite violation | 20:55 |
| cjwatson | is it possible to use libedit? | 20:55 |
| Keybuk | lucas: emacs and python argument => scripting languages can load plugins that are otherwise licence contradictory | 20:55 |
| cjwatson | it's not quite as good, but the *point* of readline being GPL is that the good stuff is restricted to GPLed programs :) | 20:55 |
| zyga | Keybuk: o_O ? | 20:55 |
| zyga | Keybuk: can you expand that statement, it's quite interesting | 20:56 |
| Keybuk | zyga: it's the FSF's position | 20:56 |
| Keybuk | go look it up on fsf.org ;) | 20:56 |
| zyga | mmm, I will | 20:56 |
| lucas | ok, then we are fine, and just need to revert the ubuntu-specific change | 20:57 |
| zyga | (so a scripting language inside the kernel... ;-) | 20:57 |
| slangasek | Keybuk: I don't think that argument holds water if the ruby app is in our archive | 20:57 |
| cjwatson | lucas: this is still a problem, though, we don't want multiple readline versions in main if we can avoid it | 20:57 |
| lucas | I'll request a sync of the debian version, which also fixes the ruby+threads+timeout/puppet bug | 20:57 |
| cjwatson | and indeed libreadline5 is currently in universe, although presumably that's only once pitti rebuilt ruby against libreadline6 | 20:58 |
| lucas | cjwatson: I don't see a way to avoid it, except dropping readline support in ruby. you don't want to do that, because all ruby developers use irb, which uses readline AFAIK | 20:58 |
| cjwatson | lucas: 20:55 <cjwatson> is it possible to use libedit? | 20:59 |
| cjwatson | it has a readline wrapper, and it's BSD-licensed | 20:59 |
| cjwatson | as I say, it's not quite as good, but it's not that bad either | 20:59 |
| siretart` | while discussing this subject, there is popular request to compile ffmpeg against opencore-amr. however, since the latter uses apache license, this would require us to distribute libavcodec under GPLv3. My conclusion is that this would cause problems for ubuntu. Is that right? | 20:59 |
| lucas | cjwatson: it's a drop-in replacement? | 21:00 |
| cjwatson | to some extent | 21:01 |
| lucas | :-) | 21:01 |
| cjwatson | it has a wrapper which attempts to emulate at least a decent chunk of the readline API | 21:01 |
| cjwatson | I'm not saying it will definitely meet your needs, but it's possible that it might get you out of a hole so it seems worth a look | 21:01 |
| lucas | that might be a long term solution, but I don't see this happening before the lucid release (especially if I'm the one doing it) | 21:03 |
| cjwatson | for lucid, it does seem like going back to readline5, biting our tongues, and accepting two readline versions in main is what it'll have to be | 21:04 |
| cjwatson | at least it isn't on the CD | 21:04 |
| cjwatson | pitti: ^- | 21:04 |
| siretart` | to make matters more complicated, would enabling opencore-amr for the ffmpeg-extra package acceptable? We could then advice users of GPLv2 applications to avoid the ffmpeg-extra package... | 21:06 |
| mvo | zyga: could you add in the debian/changelog what bugs are fixed with the release please? | 21:12 |
| zyga | mvo: such as the stuff listed in the release notes for this version on launchpad? (I'm searching for a link) | 21:13 |
| zyga | https://launchpad.net/command-not-found/trunk/0.2.41 | 21:14 |
| zyga | shall I add that stuff to the changelog below '* new upstream release' ? | 21:14 |
| mvo | zyga: yes, exactly this :) just below new upstream version is fine. and please include the bugnubmers as LP: #bugnr - then they will get auto closed on upload | 21:15 |
| zyga | okay just a moment | 21:16 |
| mvo | sure | 21:16 |
| zyga | I branched from tag 0.2.41ubuntu1 | 21:16 |
| * zyga is pleased to see vim is aware of LP: #[0-9]+ | 21:17 | |
| zyga | mvo: shall I bump version to ubuntu2? | 21:19 |
| mvo | zyga: its not uploaded yet, so we can keep ubuntu1 | 21:21 |
| zyga | k | 21:21 |
| mvo | zyga: you could also use a NEWS file (that would be more upstreamish) and I copy the content into debian/changelog when making releases. but both is fine really | 21:21 |
| zyga | mvo https://code.launchpad.net/~zkrynicki/command-not-found/lucid | 21:24 |
| zyga | mvo: I'll keep the NEWS file up-to-date since .42 :-) | 21:24 |
| zyga | this branch can be used for lucid if we need to cut strings and patch other stuff | 21:24 |
| mvo | zyga: if we can avoid the new strings somehow that would be nice, at least for the beta-1 upload, we need a UI freeze exception for new strings at this point | 21:30 |
| mvo | zyga: thanks for the changelog, that looks good now :) | 21:30 |
| ccheney | anyone here familiar with gtk? | 21:43 |
| zyga | mvo: I'll can revert features that add new strings but this will make version ackward | 21:43 |
| ccheney | i am having a problem linking to it | 21:43 |
| ccheney | http://pastebin.ubuntu.com/394262/ | 21:43 |
| zyga | mvo: basically new strings are for auto-install feature | 21:43 |
| ccheney | during the epiphany browser backport for hardy | 21:43 |
| mvo | zyga: ok, I think we have two option a) file UI freeze exception (should be ok, just one string) and upload on monday b) create lucid branch 2.40ubuntu2 that cheery picks all but the string | 21:45 |
| zyga | mvo: pick the one you like, I'm fine with either since it's my fault it is soo late again | 21:47 |
| mvo | zyga: I would say b) for now, then I can upload tonight :) otherwise a) is fine as well | 21:47 |
| zyga | hmmm, a) would mean less messing with the history, I'll try to fix all the issues in the next few days so that once lucid+1 is around this will not happen again | 21:50 |
| mvo | zyga: yeah, I like a) better too, https://wiki.ubuntu.com/FreezeExceptionProcess has the details (if its ok for you to write the exception) | 21:51 |
| zyga | okay I'm on it | 21:51 |
| zyga | #UserInterfaceFreeze Exceptions ? | 21:52 |
| zyga | or new upstream release? | 21:53 |
| zyga | okay so I'm filing a new bug on /ubuntu/+source/command-not-found about FreezeExceptionProcess | 21:56 |
| RoAkSoAx | jcastro, does the summit sponsorship website still has the bug showing a blank page when finishing requesting the sponsorship? | 22:12 |
| jcastro | RoAkSoAx: yep, pm me your lp username and I can make sure it's in there | 22:14 |
| * jcastro likes to doublecheck | 22:14 | |
| RoAkSoAx | jcastro, done :) | 22:15 |
| mvo | zyga: yes, and please subscribe ubuntu-release when the bug is there | 22:17 |
| mvo | zyga: thanks .) | 22:17 |
| mvo | zyga: I'm off to bed now! | 22:18 |
| zyga | mvo: thanks, bye! | 22:22 |
| jpds | Keybuk: bug #538292 just came up. | 22:42 |
| ubottu | Launchpad bug 538292 in plymouth "Latest plymouth update makes lucid stop at startup" [Undecided,New] https://launchpad.net/bugs/538292 | 22:42 |
| chrisccoulson | heh, i just saw people talking about that in #ubuntu+1 too | 22:44 |
| Keybuk | jpds: it works for me | 22:44 |
| Keybuk | oh, that | 22:45 |
| Keybuk | *shrug* | 22:45 |
| Keybuk | they need to update mountall too | 22:46 |
| chrisccoulson | Keybuk - i'm not sure that's published yet | 22:46 |
| jpds | chrisccoulson: It is. | 22:47 |
| Keybuk | well, people shouldn't be so eager on the update button, should they <g> | 22:47 |
| chrisccoulson | yeah, probably ;) | 22:47 |
| chrisccoulson | jpds - there's no 2.8 in the archive yet: http://archive.ubuntu.com/ubuntu/pool/main/m/mountall/ | 22:48 |
| cjwatson | discussion in #ubuntu-release indicated that we were going to have new libplymouth2 Breaks: old mountall, but I don't see that in the package? | 22:48 |
| === andreasn_ is now known as andreasn | ||
| jpds | chrisccoulson: Oh, the source is published, right. | 22:49 |
| Keybuk | cjwatson: one had to be built before the other | 22:49 |
| Keybuk | or the chroots would have removed upstart | 22:50 |
| Keybuk | and killed themselves | 22:50 |
| cjwatson | oh, I see we're waiting for mountall before going round with the Breaks, for reasons I didn't follow but you and slangasek seemed to be on top of it | 22:50 |
| cjwatson | right, I didn't attach that to missing Breaks the first time | 22:50 |
| slangasek | jpds: just replied to bug #538292 with explanation, sorry | 22:52 |
| ubottu | Launchpad bug 538292 in plymouth "Latest plymouth update makes lucid stop at startup" [Undecided,Fix released] https://launchpad.net/bugs/538292 | 22:52 |
| slangasek | cjwatson: you're a buildd admin? | 22:53 |
| slangasek | mountall/{ia64,sparc} need rescored | 22:53 |
| slangasek | once they start building, I can accept the fixed plymouth | 22:53 |
| slangasek | and it would be nice if that happens sooner than 7h from now | 22:54 |
| cjwatson | slangasek: yup, sec | 22:59 |
| cjwatson | I've taken the precaution of putting the publisher on manual | 23:00 |
| cjwatson | slangasek: both scored up, but I can't do anything about the existing builds running on ia64 | 23:00 |
| cjwatson | so it's still nearly an hour away | 23:01 |
| jpds | cjwatson: amd64 was about to be published and i386 binaries are on the archive. | 23:01 |
| cjwatson | yeah, I've taken it off manual again since there's no benefit with ia64 an hour out | 23:02 |
| cjwatson | jpds: but that wasn't what the precaution was for - if the ia64/sparc builds were going to arrive quickly, I could have got them published faster with the publisher on manual | 23:02 |
| slangasek | oh pah, we got stuck behind eucalyptus and openjdk? | 23:08 |
| cjwatson | slangasek: if you're truly desperate, I think lamont can kill jobs | 23:10 |
| * Caesar discovers mountall and throws up in his mouth a bit | 23:11 | |
| slangasek | cjwatson: if the builds were still at the unpack phase I might worry about dpkg+fsync and the accuracy of the estimate... I think we might as well let this run its course now | 23:13 |
| Caesar | Wow, this mountall thing is a total black box | 23:14 |
| wgrant | The LP estimate is solely based on the previous build times. | 23:14 |
| sistpoty | fta: the name of the binary packages are left to your discretion for bug #537617, just if that was not clear from my comment. Do you have any ETA for landing it in lucid? | 23:15 |
| ubottu | Launchpad bug 537617 in chromium-browser "[FFe] chromium-codecs-ffmpeg for lucid" [Undecided,New] https://launchpad.net/bugs/537617 | 23:15 |
| slangasek | wgrant: yep - but eucalyptus is already at least halfway done now | 23:17 |
| === rzr is now known as rZr | ||
| === slangasek changed the topic of #ubuntu-devel to: don't reboot with libplymouth2 0.8.0~-13 without mountall 2.8! | Archive: Feature Freeze + Beta Freeze | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki. | ||
| === slangasek changed the topic of #ubuntu-devel to: don't reboot with libplymouth2 0.8.0~-13 without mountall 2.8! | Archive: Beta Freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
| slangasek | mountall publishing | 23:47 |
| slangasek | cjwatson: and plymouth accepted again, could use rescoring on ia64/sparc | 23:51 |
| cjwatson | slangasek: dodne | 23:55 |
| cjwatson | *done | 23:55 |
| slangasek | cheers | 23:55 |
| cjwatson | should be quicker this time | 23:55 |
| cjwatson | slangasek: they're taking their time about it. should I put the publisher in manual in the hope of getting all architectures into this hour, or would you rather get i386 in ASAP? | 23:59 |
| cjwatson | (amd64 is waiting as well, or I would just assume the latter) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
