[00:00] <RAOF> Right.  Which means I should upload the new evolution-sharp to Jaunty, too.
[00:00]  * jdong nods
[00:00] <RAOF> Sadly I can't do that through Experimental; the new upstream fails to build against < e-d-s 2.24.
[00:01] <RAOF> Even though it says it should on the box. :(
[01:30] <jdong> kees: I must be bored out of my mind; I'm actually rewriting all my rcS and rc2 scripts as upstart jobs, without using lsb-functions at all
[01:41] <TheMuso> jdong: Yes, you must be bored.
[01:41] <jdong> TheMuso: I'd be willing to bet money this would make bootup thrash like hell and not terribly useful until I get a SSD :)
[02:01] <TheMuso> imbrandon!!
[02:33] <kees> jdong: ah you at uds? it'd be great to see the work. i know both keybuk and kirkland are very interested in doing that kind of thing
[02:44] <jdong> kees: no, unfortunately I am not
[02:44] <jdong> kees: my first go-through will likely be a hackjob that involves extensive copy-pasting from our init system with my best guesses at the dependency relationships :)
[02:45] <jdong> I just want to get an understanding of the challenges with a fully parallelized boot
[02:45] <jdong> if it's not a horrible unfinishable mess I'll probably send something out to the mailing list
[02:47] <jdong> I've BARELY got to S37 :)
[02:48]  * jdong wonders if he can write a mechanical python hook to generate wrapper upstart event jobs based on installed init.d scripts
[02:48] <kees> heh cool.
[02:49] <jdong> I oddly recall starting to write such a thing two years ago, in fact!
[02:49]  * jdong greps his ~/src
[02:51] <jdong> https://code.edge.launchpad.net/~uphackers/uphack/uphack-tools
[02:51] <jdong> aha!
[02:51] <jdong> upconv/uphack.
[02:51] <jdong> is it sad that I've done so many of these crazy things I don't know if I conceived it in a dream or actually wrote it?
[02:52]  * jdong tries to think "What plane" mentioned in revno 6....
[02:52] <jdong> was that what I was doing over spring break?
[03:04] <psusi> if a package generates conf files after it is installed, is there any way for dpkg to keep track of that so they can be removed if the package is purged?
[03:05] <psusi> I'm wondering about /var/lib/gconf/defaults/*... dpkg does not show the files as having come from any package, but gconf2-common created the directory with no files in it... I assume they must have been generated somehow after install?
[03:07] <jdong> *HOLY CRAP*
[03:07] <jdong> kees: it booted!
[03:07] <jdong> I am not convinced it's any faster though
[03:07] <jdong> and TODO: figure out how to shut it down :D
[03:10] <jdong> 25s in vmware....
[03:10]  * jdong is almost curious enough to try this natively
[03:12] <psusi> jdong: what are you playing with now? ;)
[03:20] <jdong> psusi: upstart
[03:21] <jdong> psusi: a quick and dirty python script that generates dummy upstart jobs for each rcS.d-rc2.d script
[03:34] <psusi> you mean you are making an upstart job for each individual script instead of just having one job that runs /etc/init.d/rc?
[03:34] <jdong> right.
[03:34] <psusi> why?
[03:34] <jdong> with a basic set of heuristics for job dependencies.
[03:34] <jdong> parallelized boot
[03:34] <psusi> doesn't rc already have an option to do that?
[03:35] <jdong> psusi: it doesn't seem to be as parallel
[03:35] <psusi> ohh.. I guess it only runs jobs with the same Snn level in parallel...
[03:35] <psusi> I see now why you are surprised that it worked ;)
[03:35] <jdong> psusi: lemme generate a quick dot diagram of my dependency graph urrently
[03:36] <jdong> psusi: http://jdong.mit.edu/~jdong/upstart-dep.png
[03:36] <jdong> pretty neat looking
[03:37] <ScottK> jdong: Now that Debian has dependency base boot sequencing done with sysv init's, how much is this conversion really likely to buy us?
[03:37] <jdong> ScottK: I was unaware debian has this
[03:37] <jdong> how does that fit into our plan to completely go upstart though?
[03:37] <jdong> this for me is just an experiment in what an upstart-booting parallelized system buys us
[03:37] <ScottK> jdong: I'm wondering why we're doing that.
[03:38] <jdong> well upstart represents job relationships in a better way IMO
[03:38] <jdong> it fits the model of the modern Linux machine better than a bunch of start-stop scripts.
[03:39] <ScottK> jdong: http://lists.debian.org/debian-devel-announce/2008/11/msg00007.html
[03:39] <psusi> I have often wondered whether paralellizing the boot scripts might cause more slow down that it makes up for, due to all the tasks competing for resources at once
[03:39] <jdong> psusi: I think it must.
[03:39] <ScottK> jdong: Sure, no doubt it's better, but is it enough better to be worth the additional difference between Debian and Ubuntu.
[03:41] <psusi> jdong: wouldn't each job finish faster if it wasn't fighting the others for access to the cpu, ram, and disk IO?
[03:41] <jdong> psusi: not really when the jobs aren't really bound by the same resource.
[03:41] <psusi> I mean theoretically the only way you get benefit from parallel jobs is if each job is only using a subset of the available resources, so each job will use the resources that the other jobs aren't.... if they are competing for the same resources though, it slows things down
[03:42] <jdong> the former is the case according to my bootchart
[03:42] <psusi> so you almost need a way of scheduling the jobs that uses information about what resources they use so it only parallelizes jobs that don't conflict for the same resource
[03:42] <psusi> like if one job is IO bound and one is CPU bound, then run both at once
[03:42] <jdong> well competing for disk right now is the biggest problem.
[03:42] <jdong> I could care less if they compete for CPU or RAM
[03:42] <psusi> but you don't want to run two jobs at once that are both IO bound
[03:43] <jdong> I think a bit of aio scheduler hackery can work around the IO contention though
[03:43] <psusi> eh?
[03:43] <jdong> psusi: sysv: http://jdong.mit.edu/~jdong/macbook/bootchart-sysv.png
[03:43] <jdong> upstart: http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png
[03:43] <jdong> 27s vs 22s
[03:44] <psusi> if both jobs are IO bound, wouldn't it be best to just run them sequentially so that they aren't causing the head to keep seeking back and forth?
[03:44] <jdong> still relatively untweaked with mechanically-generated rules.
[03:44] <jdong> the 67 . /lib/lsb/init-function.sh calls are probably representing significant overhead too
[03:44] <jdong> psusi: the AIO scheduler with large timeslices can alleviate a lot of the seeking though.
[03:45] <jdong> psusi: and frankly single tasks during bootup seek crazily enough
[03:45] <jdong> we don't really have any guarantee that each task alone doesn't thrash.
[03:45] <jdong> http://jdong.mit.edu/~jdong/macbook/hardy-upstart-defragged.png
[03:45] <jdong> that's an optimized run with readahead/boot listed files rewritten to disk
[03:46] <psusi> take readahead-list for example.. it looks like right now you block the remaining tasks until readahead is done, because you don't want them trying to read bits before readahead gets them, causing seeking
[03:46] <psusi> ideally you want to start other jobs that are more cpu bound while readahead runs so you can keep both the disk and cpu busy
[03:46] <psusi> the aio scheduler? is that a new io scheduler?
[03:47] <psusi> I'm confused as to what aio has to do with the elevator
[03:48] <psusi> jdong: ideally you want the files readahead is fetching to be all sequential near the start of the disk... or at least modify readahead to be able to keep a cached copy of all of it somewhere like windows' prefetching does
[03:49] <jdong> psusi: (1) that depchart is not up to date; there ARE a few other things that I have moved up to be parallel with readahead
[03:49] <psusi> jdong: being able to pack the readahead files sequentially at the start of the disk is one of the reasons I'm trying to rescue e2defrag
[03:49] <jdong> (2) Yes, I'd like for all the boot files to be near the start of the disk and sequential.
[03:49] <jdong> you don't want to see my symlink farm method for forcing that with a tiny 100MB /prefetch partition :P
[03:50] <psusi> what would be nice is if you could have the kernel block the other jobs if they request a block that readahead has not already pulled into cache and wait until readahead gets it without seeking... maybe you could do that with IO priorities?
[03:51] <jdong> that was my next tier of hacks.
[03:51] <jdong> you're getting ahead of me!
[03:51] <psusi> ;)
[03:51] <jdong> ionicing and nicing was my next set of master ugly hacks :P
[03:51] <jdong> I first want to get this set of jbos correct
[03:51] <jdong> still getting a few races I need to sort out
[03:51] <psusi> hrm... your max disk throughptu was only 12 MB/s?
[03:51] <jdong> rofs and dev/pts mounting not at the right time :)
[03:51] <psusi> that seems rather low
[03:51] <jdong> it's a laptop on ata_piix emulation.
[03:51] <psusi> eww
[03:52] <jdong> this can be a LOT faster with a proper computer.
[03:52] <jdong> in fact I'm curious enough to try it...
[03:52]  * jdong digs out his production system
[03:52] <psusi> jdong: dual core cpu?  kind of funny how the graph only shows 50% IO wait time during readahead-list
[03:53] <jdong> yup
[03:55] <psusi> I wonder how much it will help to use e2defrag to pack the files on readahead-list in order at the start of the disk
[03:55] <psusi> I need to finish getting that reintroduced to the repository
[03:55] <jdong> :)
[03:56] <psusi> I finally got around to creating a project for it on lp and checking it into bzr
[03:57] <psusi> hrm... I wonder why you still have a good deal of disk IO after the readahead is done... looks like it is done by modprobe
[03:57] <jdong> psusi: modprobe blocks hard in the kernel at several points
[03:57] <jdong> which inflates bootchart
[03:57] <jdong> ok, so 34s stock boot no tricks....
[03:58] <jdong> *unpacks event.d*
[04:02] <jdong> 27s upstart
[04:03]  * psusi shakes his head at his WD raptors and their WAAAAAY off standby timers
[04:07]  * ScottK-laptop thinks anyone who uses WD hard drives deserves whatever they get.
[04:07] <ScottK-laptop> nellery: I just sent you kind of a nasty note about your milter-greylist merge.  I'm not as annoyed as the comment in the bug probably sounds.
[04:08] <lidaobing> please help review iptux 0.4.2-0ubuntu1(new package): http://revu.ubuntuwire.com/details.py?upid=4186, thanks
[04:08] <nellery> ScottK-laptop: Hi, just read it
[04:08] <nellery> I'll be sure to ask the last merger next time.  Thanks for the heads up.
[04:09] <ScottK-laptop> nellery: Also, since Debian moved to quilt, I think it's better our change is in quilt too.  FYI for next time.
[04:09] <ScottK-laptop> nellery: Note that once we get past roughly DIF, merges are pretty much free for all if they haven't been merged at least once in the cycle.
[04:10] <ScottK-laptop> lidaobing: Is this the same iptux sitting in Debian New?
[04:11] <nellery> ScottK-laptop: I'll definitely look out for that in the future, thanks again
[04:11] <ScottK-laptop> No problem.
[04:11] <lidaobing> ScottK-laptop, Debian new? let me check, I think I still waiting for RFS
[04:12] <psusi> ScottK-laptop: why do you say that?  don't like high performance hardware?  I've been messing with lm-sensors and laptop-mode lately and it seems these things have very strange ideas of when they should spin down... one of these days I need to write a kernel patch to have it manage the standby of disks properly instead of leaving it to them
[04:12] <lidaobing> ScottK-laptop, I can't find it in Debian new queue, http://ftp-master.debian.org/new.html, any more information?
[04:13] <ScottK-laptop> psusi: Excepting one hard drive in a laptop that died right after it was in a car in a severe accident, every single hard drive I've had fail that was less than 5 years old in the last 20 years has been a WD.
[04:13] <ScottK-laptop> lidaobing: Maybe I mis-remember.  Let me check.
[04:15] <psusi> ScottK-laptop: wow, that's hard to believe... in my many years of experience WD drives are usually very reliable... though usually not that fast.. you sure you aren't thinking of IBM?  specifically their deskstar series?  or as I like to call them, deathstar
[04:15] <ScottK-laptop> lidaobing: I don't see it there now, but I'm pretty sure it was.  I wonder if it got rejected for something.  A lot of stuff got processed through New yesterda.
[04:16] <ScottK-laptop> psusi: Nope.  That's my experience.  The laptop HD that died in the car accident was an IBM, but I think that's the only one of those I've had.
[04:16] <ScottK-laptop> Now it's not many hard drives mind you, but it is all of them ...
[04:18] <lidaobing> ScottK-laptop, no information in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507451, and did not recieve any email for it.
[04:21] <ScottK-laptop> lidaobing: It's also possible I misremember.
[04:51] <jdong> psusi: ok I might be cheating now: http://jdong.mit.edu/~jdong/upstart-dep-lazy.png
[04:51] <jdong> moved 70% of the bootup to sleep 10; after GDM :D
[04:51] <psusi> jdong: eh?
[04:52] <jdong> psusi: kickstart gdm first and then worry about booting up the rest of the system :)
[04:54] <psusi> doesn't gdm depend on the rest of the system already being started? ;)
[04:54] <jdong> no, the graph shows the boot order relationship
[04:54] <jdong> i.e. it's a dirty topsort of the graph
[04:54] <jdong> i.e. B's "start on starting A" shows as A->B
[04:55] <psusi> jdong: what's readahead_desktop?
[04:55] <jdong> the LTSP version of readahead.
[04:55] <jdong> it doesn't matter here
[04:56] <psusi> I see... you start gdm before things like laptop_mode and and cron... that seems ok
[04:56] <psusi> jdong: I'm wondering if it is doing readahead on things that gdm or the things gdm starts reads, in which case it probably isn't a great idea to start gdm before it
[04:56] <jdong> psusi: I'm gonna do a control run with no readahead
[04:57] <jdong> and then carefully readahead JUST up to the gdm point.
[04:57] <psusi> jdong: and you know, there are probably some things, like rsyncd, that could be started up after gdm has had some time to initialize and get to a login
[04:59] <jdong> psusi: everything after gdm is (1) sleep 10 (2) ionice -c3 (3) nice 20
[05:01] <jdong> 22s
[05:04] <psusi> jdong: ohh, so you give gdm 10 seconds to start up then start loading everything else with low priority?  after the user already has a login prompt?  nice
[05:05] <psusi> jdong: and what was the base time on a stock system?
[05:07] <psusi> jdong: mountoverflowtmp should probably be done before dbus on down
[05:08] <jdong> psusi: around 37s
[05:08] <jdong> and yes I am reworking the dep tree still
[05:08] <jdong> what uses perl during bootup?
[05:10] <jdong> still about 22s stable.
[05:10] <jdong> I think I've hit a fundamental limit :)
[05:10] <psusi> jdong: also it looks like readahead is executed in parallel to most everything else... probably should wait for readahead to finish or the things that would benefit from it can fight with readahead seeking back and forth
[05:12] <psusi> or ideally maybe use multiple readahead lists for several different stages... readahead stage 1, then boot the parts that use those files while readahead stage 2 runs in the background, then once stage1 finishes, launch stage2 jobs
[05:14] <psusi> see what I'm getting at?  maybe take dbus as a good split point... build one readahead list for everything prior to dbus... read that list in entirely first, then start all jobs prior to dbus
[05:14] <psusi> then have a second readahead list for all jobs starting with dbus and after, and read that list at the same time as you run all of the jobs before dbus
[05:15] <psusi> then start dbus and all after only once the second readahead list is done
[05:17] <jdong> interesting; 34MiB of readahead necessary
[05:19] <psusi> also stop_readahead looks like it is run in parallel with many jobs, so it may or may not record files needed by, policykit, for example
[05:20] <jdong> psusi: oh I'm not profiling with upstart enabled.
[05:20] <jdong> I have a simulated sysv setup that activates via bootflag, for profiling
[05:20] <psusi> ahh
[05:20] <jdong> such a hack :D
[05:20] <jdong> just "defragged" readahead data.
[05:20] <psusi> what do you think of having multiple readahead stages?
[05:20] <jdong> untarred it really fast, that is :)
[05:21] <jdong> well I'm considering the idea of multiple readahead stages
[05:21] <jdong> just right now it's terribly annoying to get profiled
[05:21] <psusi> yea... difficult, but may yield sweet fruit
[05:21] <jdong> 20s
[05:22] <jdong> significant difference from rewriting out readahead/boot's files
[05:22] <psusi> no sense making mountall_sh and networking wait for readahead to finish fetching data that won't be needed until you start cups
[05:22] <psusi> hehe, now get them to be stored in the order they are read ;)
[05:23] <jdong> lol I think I'm gonna call it a night with stupid bootup tricks :D
[05:24] <psusi> hehe.... I want to see that boot time down to 10 seconds ;)
[05:26] <jdong> psusi: in case you're bored: https://code.edge.launchpad.net/~uphackers/uphack/uphack-tools
[05:26] <jdong> there's upconv which reads in /etc/rc*.d and spits out /tmp/event.d
[05:26] <jdong> and depchart which when executed depchart /tmp/event.d | dot -Tpng > foo.png, creates a .png :)
[05:27] <jdong> psusi: I'd be interested to see a SSD bench
[05:27] <jdong> oh to bootstrap you should probably keep your existing tty* and make them start on started mountall_sh
[05:28] <jdong> otherwise you may find yourself lacking terminal(s) :)
[05:28] <psusi> cool... I got one for you: https://launchpad.net/~e2defrag ;)
[05:28] <psusi> eh?  aren't the getty's already started as their own upstart jobs?
[05:29] <jdong> psusi: yes but my magical event.d generator does not generate the special tty jobs
[05:29] <psusi> jdong: I'm saying I thought the tty jobs already existed in event.d and don't need generated from rc scripts
[05:29] <jdong> psusi: from what I remember, to bootstrap copy the auto-generated event.d files into /etc/event.d, then rm /etc/event.d/rc*
[05:29] <jdong> psusi: and the pre-generated tty jobs depend on "runlevel"
[05:29] <jdong> i.e. the rc jobs
[05:30] <psusi> I could have sworn the way it was already the runlevel event started the gettys and /etc/init.d/rc 2 in parallel
[05:31] <jdong> psusi: not in Intrepid, they "fixed" that :D
[05:32] <psusi> lol... why was it "broken"? ;)
[05:32] <psusi> I thought it was like that because the gettys were the first and only startup jobs that had been converted to the upstart system from sysv
[05:34] <jdong> that's why I said "fixed"
[05:34] <jdong> the "problem" was if the system was fscking it would still allow you to log in.
[05:34] <jdong> and also it would present the login before the hostname was set
[05:35] <psusi> ohh, I see.... it now starts on stopped rc2... before it started on runlevel 2
[05:35] <jdong> right
[05:36] <jdong> IMO it should start on started rc2
[05:36] <jdong> and use the service declearation
[05:36] <jdong> with pre-start exec /etc/ ....
[05:36] <jdong> I'd like to see rc2 as "started" when it finishes running.
[05:36] <psusi> makes sense... that way it waits until after rcS but not on rc2
[05:36] <jdong> not "starting" -> "stopped"
[07:53] <siretart> jdong: I think I'm a bit biased with that question ;-)
[09:23] <\sh> moins
[09:26] <zerwas> moin
[09:37] <pochu> hiya
[09:38]  * directhex votes to declare it the weekend again -_-
[09:39] <pochu> it's holiday here in Spain :)
[09:42] <smaftoul> Hi all
[09:43] <\sh> it's UDS time ,-)
[09:45] <pochu> aren't they all still sleeping?
[09:52] <\sh> looks like...-6h from europe, right?
[09:52] <directhex> .ca is west coast isn't it?
[09:52] <directhex> wait, no . there
[09:52] <directhex> but my clock says -8 for LA
[09:54] <\sh> ah west coast..yeah that's a bit more then -6h
[09:54] <Nafallo> hehe. why not find out where they are first? ;-)
[09:56] <Koon> -9h from CET.
[09:57] <smaftoul> does anyone knows where apache sets it's ulimit from ?
[09:57] <smaftoul> I set this export APACHE_ULIMIT_MAX_FILES="8192"
[09:57] <smaftoul> in /etc/apache2/envvars
[09:58] <smaftoul> I have a php file that contains <? system("ulimit -n"); ?> , and I het 1024
[09:58] <smaftoul> do I need to modify /etc/security/limits.conf ?
[09:58] <smaftoul> shouldn't this be documented ?
[09:59]  * directhex stabs ulimit with a spork
[09:59] <NCommander> hey directhex
[09:59] <directhex> morning NCommander
[09:59] <NCommander> directhex, I take it your not at UDS?
[09:59] <NCommander> \sh, you here?
[10:00] <slytherin> NCommander: Just FYI ... the freezes I was seeing on my ibook are almost completely gone after blacklisting rfkill_input module.
[10:00] <\sh> NCommander: nope...:) I'm not at UDS :)
[10:00] <Koon> The "not-at-UDS" club gathers :)
[10:02] <slytherin> Koon: are you keeping watch on pkg-java checkins? some of the maven packages we were planning to work on have entered Debian NEW queue.
[10:03] <Koon> slytherin: I looked at it a while ago... I'll check it again
[10:03] <directhex> NCommander, not until someone starts paying for my travel costs, no. california is one of the few places which would cost me more than my mortgage payments to visit
[10:03] <NCommander> o_o;
[10:04] <ethan0> I'm so sorry for this easy question, but if I have a *_all.deb, I could extract the source and rebuild for ubuntu, right? _all have source included, right?
[10:05] <directhex> ethan0, wrong.
[10:05] <\sh> ethan0: nope..._all.deb just means, it's architecture independant
[10:05] <directhex> ethan0, .deb is (usually) never source
[10:06] <ethan0> It's a binary package then. Ungh. Sorry, I've been up for much too long.
[10:06] <directhex> ethan0, a source package comes in the form of a diff.gz, orig.tar.gz, and .dsc
[10:06] <ethan0> Yes, of course. Sorry.
[10:06]  * ethan0 needs to sleep
[10:06] <directhex> ethan0, an _all might be something like, say, a CLI .dll file
[10:07] <directhex> actually, <£400 for last-minute flights. it was definitely >£1k when i looked previously
[10:07] <directhex> still, too rich for my blood
[10:13] <smaftoul> anyone here apache expert or packager ?
[11:09] <mgdm> is there any chance/likelyhood of a backport of libdmtx to hardy?
[11:10] <pochu> how many reverse dependencies does it have?
[11:11] <mgdm> it doesn't appear to have very many, though I could be looking in the wrong place
[11:12] <mgdm> as far as I can make out it only wants libpng and libtiff
[11:12] <slytherin> mgdm: The package does not exist in hardy. Is that correct?
[11:12] <mgdm> slytherin: yeah, it only seems to have appeared in Jaunty
[11:15] <pochu> then you should be fine
[11:16] <pochu> mgdm: report a bug at https://edge.launchpad.net/hardy-backports/+bugs
[11:16] <mgdm> I'm just trying to build it just now
[11:16] <mgdm> Ah, cool
[11:17] <pochu> mgdm: of course building, installing and testing it will help the backporters to approve it ;)
[11:17] <mgdm> I guessed it might :)
[11:34] <mgdm> if the package is asking for debhelper >= 7, but Hardy only has 6, is that a major issue?
[11:35] <directhex> yes! it causes baby jesus to cry
[11:35] <sebner> mgdm: hardy backports have 7 but do you really need debhelper7?
[11:35] <directhex> also, i thought dh7 was ni hardy-backports
[11:36] <mgdm> Sorry, I'm an utter newbie, just trying to build this Jaunty package on Hardy but I don't really know what I'm doing
[11:37] <pochu> mgdm: enable hardy-backports to build it
[11:38] <mgdm> pochu: OK, I'm trying it, thanks
[11:45] <mgdm> Oh, I do have debhelper 7 already installed, but it's not in the pbuilder chroot, I suspect
[11:45] <mgdm> (does that sound plausible?)
[11:45] <directhex> it sounds plausible. pbuilders don't tend to have backports on by default
[11:49] <pochu> in English, when you read something out loud, how do you read "e.g.", as "e g" or "exampli gratia" ?
[11:49] <orly_owl> i say e g
[11:49] <orly_owl> Also, ##english
[11:49] <laga> i say "for example". but i'm not a native speaker
[11:49] <phytopius> i would also say for example
[11:49] <orly_owl> oh yes, you could say that too
[11:50] <mgdm> I'd say "for example", too, and I'm a native speaker
[11:50] <pochu> thanks you all :)
[11:50] <directhex> i say "egg", but i'm a weirdo!
[11:50] <pochu> lol
[11:50] <directhex> nah, "for example" is correct
[11:50] <orly_owl> Not on IRC you're not!
[11:51] <pochu> and for i.e. you say "that is"?
[11:52] <directhex> pochu, aye
[11:52] <pochu> cool
[11:52]  * pochu is studying for the toefl
[11:54] <laga> i probably wouldn't understand it if someone said "exempla gratia" ;)
[11:54] <laga> pochu: cool
[11:55]  * mgdm works out what he's doing wrong
[11:57] <pochu> mgdm: login into pbuilder and look at /etc/apt/sources.list
[11:57] <pochu> if you don't have hardy-backports, that's what is wrong
[11:57] <directhex> or, even better, use OTHERMIRROR and --override-config
[11:58] <mgdm> yeah, I went for the OTHERMIRROR option in the end
[11:58] <mgdm> I figured that was more sustainable in the long run than logging in and hacking manually
[12:02] <mgdm> yay, it builds and runs \o/
[13:09] <slytherin> geser: ping
[13:23] <pmjdebruijn> I uploaded my package to REVU fifteen minutes ago, and it's still not visible on the website? what could be wrong?
[13:24] <slytherin> pmjdebruijn: is this your first upload to revu?
[13:24] <pmjdebruijn> yes
[13:25] <slytherin> pmjdebruijn: did you login to revu prior to upload?
[13:26] <pmjdebruijn> slytherin: oh crap... I thought I was still logged in from yesterday
[13:27] <RainCT> pmjdebruijn: which package is it?
[13:27] <pmjdebruijn> lensfun
[13:27] <pmjdebruijn> dput says it's already uploaded
[13:27] <slytherin> pmjdebruijn: wait, I meant if logged in even once. If you had then there seem to be some other problem
[13:27] <slytherin> pmjdebruijn: what is the dput command you used?
[13:27] <pmjdebruijn> dput revu lensfun_0.2.3-0ubuntu1_i386.changes
[13:28] <slytherin> pmjdebruijn: you need to upload source.changes
[13:28] <pmjdebruijn> oh silly me
[13:28]  * pmjdebruijn goes back to the drawing board...
[13:33] <geser> slytherin: pong
[13:34] <slytherin> geser: do you have time to review a mail? Sending it to Debian java mailing list. I don't want my anger to get reflected strongly in the mail.
[13:36] <ScottK-laptop> slytherin: What happened?
[13:37] <slytherin> ScottK-laptop: source of library changed between two revisions (not upstream versions), apis missing/changed and hence jbossas4 won't build.
[13:37] <ScottK-laptop> Lovely.
[13:38] <slytherin> ScottK-laptop: and this went unnoticed as I am sure everyone assumed that source of svn5660+dak1 must be same as svn5660
[13:38] <pmjdebruijn> ah, there it is
[13:38] <pmjdebruijn> I already see I have some work to do
[13:38] <geser> slytherin: sure
[13:39] <pmjdebruijn> anybody else, willing to check it out? so I can correct several things at one...
[13:39] <pmjdebruijn> http://revu.ubuntuwire.com/details.py?package=lensfun
[13:39] <slytherin> geser: http://paste.ubuntu.com/82457/
[13:43] <mgdm> Oo, lensfun, been meaning to check that out
[13:44] <geser> slytherin: wow, the .orig.tar.gz changed from over 700 kB to 70 kB with one upload?
[13:45] <slytherin> geser: yup
[13:45] <geser> slytherin: send the mail, it looks ok to me
[13:45] <pmjdebruijn> mgdm: eh?
[13:46] <pmjdebruijn> mgdm: lensfun by itself does nothing... it's a library... but it works wonders when ufraw is compiled with lensfun support
[13:46] <pmjdebruijn> mgdm: I have my own repo at "deb http://ubuntu.pcode.nl/ubuntu intrepid exiv2 ufraw lensfun"
[13:46] <pmjdebruijn> mgdm: use at own risk, these are development snapshots... the newer exiv2 may break digikam, etc...
[13:47] <mgdm> pmjdebruijn: Yeah, I was meaning I wanted to try it out with UFRaw :) I shall check out your repo, though
[13:48] <pmjdebruijn> mgdm: those aren't released version, just development snapshot... but it works for me
[13:48] <pmjdebruijn> mgdm: what camera do you have?
[13:48] <mgdm> I usually compile things like hugin, enblend, etc from scratch, I should learn how to package them (or find if someone else has done it already)
[13:48] <mgdm> pmjdebruijn: 400D
[13:48] <pmjdebruijn> mgdm: me too
[13:48] <mgdm> cool
[13:48] <pmjdebruijn> mgdm: I usually start by modifying existing packages...
[14:37] <pmjdebruijn> I just removed all obvious/lintian errors from lensfun
[14:37] <pmjdebruijn> I'd appreciate if somebody would have time to take a look at it sometime this week :)
[14:45] <bddebian> Heya gang
[14:46] <geser> Hi bddebian
[14:46] <sebner> heya bddebian
[14:46] <ScottK-laptop> bddebian: Heya.
[14:47] <ScottK-laptop> bddebian: I noticed you've got at least one merge pending.  Are you planning on dealing with it or should be find someone else?
[14:47] <bddebian> Hi geser, sebner ScottK-laptop
[14:47] <bddebian> ScottK-laptop: Which package?
[14:48] <ScottK-laptop> bddebian: pybliographer
[14:50] <bddebian> Well I uploaded a better version to mentors long ago but I don't think it ever got picked up.
[14:50] <bddebian> Didn't I upload that to Ubuntu?
[14:52] <ScottK-laptop> bddebian: Dunno.  Just looking at MoM.  Maybe you could upload that to Debian and then we could sync ....
[14:53] <bddebian> Aye, let me look at the status of pybliographer
[14:53] <ScottK-laptop> Great.
[15:11] <bddebian> ScottK-laptop: Hmm, weird, looks like 1.2.11 was uploaded to unstable in July.
[15:12] <ScottK-laptop> Then can  we just sync it?
[15:13] <bddebian> Hmm, he also put a 1.3.2-1 in Experimental.  The merge on the 1.2.11 looks very strange.  So a sync would probably be OK except that it might puke on the tarball. :(
[15:15] <ScottK-laptop> bddebian: You going to sort it or should I?
[15:20] <bddebian> ScottK-laptop: Please do, I don't even have a working Ubuntu install atm, my Ubuntu lappy died :(
[15:20] <ScottK-laptop> OK.  Will do.
[15:24] <bddebian> Thanks
[16:02] <mok0> bddebian: Hey, you said gimme a break, here it is: <BR\> :-)
[16:03] <bddebian> mok0: :)
[16:03] <bddebian> mok0: I honestly am not trying to ridicule you.  I apologize if it came off that way.
[16:04] <mok0> bddebian: no offense taken; I just wanted you & others to focus on real arguments
[16:05] <mok0> bddebian: anyways, if you've seen my latest mail, I offer to take over maintenance of gtk+ 1.2
[16:05] <bddebian> mok0: Yeah, nice :)
[16:05] <mok0> bddebian: but I can't see that it's been orphaned
[16:05] <StevenK> Personally, I think we should remove GTK 1.2
[16:06] <bddebian> StevenK: That has been the arguement :)
[16:06] <mok0> StevenK: ah, you guys...
[16:07] <bddebian> mok0: You are correct, I don't think gtk+1.2 itself is technically orphaned
[16:07] <mok0> bddebian: ... but it's unmaintained?
[16:07] <bddebian> mok0: Of course it hasn't seen a maintainer upload since 2004 :)
[16:08] <mok0> bddebian: okay... so what should I do then?
[16:08] <bddebian> Let me check MIA on that DD
[16:08] <mok0> bddebian: thx
[16:09] <bddebian> Heh, he retired over a year ago
[16:09] <mok0> StevenK: We've had the discussion on d-d. I dislike the idea of retiring libraries just because they are not needed by the distribution itself. There are users who need the libraries to compile their own programs
[16:10] <bddebian> Then they can get it from upstream..
[16:10]  * bddebian hides
[16:10] <mok0> bddebian: if there _is_ an upstream, yes
[16:11] <mok0> bddebian: gtkglarea for example, upstream is MIA
[16:11] <mok0> all links are dead
[16:11] <mok0> those sources live only in the archives of the various distros
[16:12] <mok0> But I know for a fact that it's still being used
[16:12] <ScottK-laptop> And since mok0 has volunteered to do the work, people should let him do it ....
[16:13]  * mok0 hugs ScottK-laptop
[16:13] <bddebian> mok0: Exactly my point but I'm checking with the MIA folks to make sure I'm reading that mia-query correctly
[16:13] <mok0> bddebian: I am grateful if you would figure it out
[16:13] <bddebian> ScottK-laptop: Agreed but he is talking about 1 package with a butload of unmmaintained/orphaned rdepends
[16:15] <ScottK-laptop> Right.  The rpendends are a different issue.
[16:15] <ScottK-laptop> Or however you spell that ...
[16:16] <bddebian> mok0: OK, I'm going to file an O: on gtk+1.2 then you can just take over maintainance, closing the O:
[16:16] <bddebian> Well techinically you should ITA: first.
[16:17] <mok0> bddebian: ok, will do... of course I need to persuade a DD to upload it :-)
[16:17] <bddebian> I can do that
[16:17] <mok0> bddebian: great, thanks
[16:18] <ScottK-laptop> mok0: Oddly enough you're talking to one ...
[16:18] <ScottK-laptop> So start persuading ...
[16:19] <mok0> ScottK. I think he already went soft on me :-)
[16:21] <bddebian> heh
[16:21] <bddebian> mok0: Did you see my question about the soname of gtkglarea also?  I have it ready to upload but wasn't sure if you wanted to leave the soname mismatch?
[16:22] <mok0> bddebian: I didn't see you comment, but I can guess... it is the lintian that complains about the name, right?
[16:23] <mok0> bddebian: it is a choice of changing the package names or the library names; I'd rather not do either
[16:23] <bddebian> mok0: Well the package name really should change but if you are trying to get this in for Lenny, I agree
[16:24] <mok0> bddebian: if you think it's ok to change the package names, I will do that
[16:25] <bddebian> mok0: It is but it might break any reverse dependencies.
[16:25] <mok0> ... and make a transitional package too
[16:25] <mok0> :)
[16:25] <mok0> exactly
[16:26] <bddebian> mok0: Are you trying to get it in time for Lenny?  If so, I'd say let's leave it for now.
[16:27] <mok0> bddebian: to be honest I thought lenny was frozen already
[16:27] <bddebian> mok0: It is but if you are fixing bugs/etc we can ask for an exception
[16:28] <mok0> bddebian: The upload closes 4 bugs + the ITA bug
[16:28] <mok0> bddebian: but they are all minor/trivial
[16:29] <mok0> bddebian: like, putting a .o file in /usr/lib :-)
[16:29] <bddebian> Aye, I'll upload, then ask for an exception, thanks
[16:30] <mok0> bddebian: great
[16:31] <mok0> bddebian: then I can ask for an Ubuntu sync; right now there's a dumb merge
[16:32]  * mok0 asserts getting rid of a merge is better than sex
[16:33] <laga> error: assertion failed
[16:33] <bddebian> +1
[16:34] <mok0> laga: heh
[16:35] <ScottK> siretart: Are you @ UDS this time?
[16:38] <siretart> ScottK: no, not this time. :(
[16:38] <siretart> ScottK: are you going to attend?
[16:39] <ScottK> siretart: No.  The timing was poor.  I'm hoping to find someone who is there who can hunt down how to listen in remotely.
[16:39] <rjune> heh
[16:39] <bddebian> mok0: OK, gtkglarea uploaded and the orphan bug for gtk+1.2 is 508182 .  I'm probably going to get an ass-kicking for that one by the way there were shitloads of uploaders including the GNOME team :(
[16:39] <rjune> I want to find someone who is there as well.
[16:39] <rjune> I have a URL I need to get to ogra
[16:40] <mok0> bddebian: uh-uh
[16:40] <ScottK-laptop> bddebian: Then one of them can adopt it now if they want.
[16:40] <mok0> bddebian: perhaps I should hold off a while before doing work on the package
[16:44] <ScottK> Grumble.  From the relevant wiki page, "Mf you cannot attend in person, you can still listen to the conferences or take part in them remotely. More information will be made available close to the conference date."
[16:44]  * ScottK wonders how close ...
[16:49] <hefe_bia> I know you're all busy, but I'd be so happy if someone could take a look at Tomboy-Blogposter in REVU, a small plugin for posting tomboy notes to your blog. It's been advocated multiple times before (by mok0 and sikon) and now the issues that were only fixable by upstream are fixed, too... It's my first package... http://revu.ubuntuwire.com/details.py?package=tomboy-blogposter
[16:49]  * ScottK-laptop tries communication via planet ....
[16:51]  * mok0 volunteers to take a look at tomboy-blogposter later today (although he thinks mono is evil)
[16:53] <hefe_bia> mok0: thank you!
[16:54]  * hefe_bia still does not understand why mono without WinForms is bad.
[16:54]  * hefe_bia likes python better, though ;)
[16:55] <ScottK-laptop> hefe_bia: The problem is that there is no knowing what patent claims may exist against it.  The best term I could use is 'risky'.
[16:57] <sharms> ScottK-laptop: the question is though, which languages are you fully aware of which patent claims exist against them?
[16:57] <sharms> or can you ever be aware
[16:57] <ScottK-laptop> sharms: Fully, none.  But given the origin of c#, it's clearly more risky.
[16:57] <hefe_bia> ScottK-laptop: ah, I see. I thought that that was cleared somehow now. Too bad - First I was so sceptic about it (coming from C++) but I grew to like C# as a language.
[16:58] <sebner> ScottK-laptop: it's in fedora and debian so ubuntu shouldn't be scared :P
[16:58] <ScottK-laptop> sebner: In patents, prior use and even prior art don't help much.  There's really no way to know if Microsoft is just biding their time or they've changed their tune.
[16:59] <mok0> hefe_bia: Imagine a situation where most of the important apps in Ubuntu are mono apps; and Microsoft decides it's time to make their patent claims...
[16:59] <ScottK-laptop> Mind you, having been involved in the development of open source technology that later showed up in Microsoft patent claims, I may be more sensititve than most.
[16:59]  * hyperair waits for directhex to start his rant on C# FUD
[16:59] <mok0> ScottK, .... once the patent is awarded, there's nothing you can do??
[16:59] <sharms> I would say as vague as patents are though, I would be just as worried about python, ruby etc
[17:00] <sharms> their patents would not just apply to C#
[17:00] <mok0> sharms: they'd be laughed out of court for that
[17:00] <sharms> thats why they are not in court right now? :)
[17:00] <mok0> sharms: but Mono is a direct re-implementation of parts of .NET
[17:01] <mok0> sharms: even Miguel agrees on that
[17:02] <sharms> I agree there too, I am just saying that if they go full out and decide to shut down mono apps, a lot of other things would be at risk too
[17:02] <mok0> sharms: ... and he is now employed by Novell, who have made a deal with Microsoft
[17:02] <sebner> ScottK-laptop: sure but since the Open Invention Network protects mono I'm fine
[17:02] <hefe_bia> mok0: I understand. As I said I thought the patent issues had somehow been solved. (Maybe I was a victim of propaganda...) Though I see the problem if patents apply.
[17:02] <mok0> hefe_bia: Nothings ever solved with big corporations
[17:03] <ScottK-laptop> hefe_bia: The problem isn't that it's solved, but that we just can't know.
[17:03] <mok0> hefe_bia: just look at how the SCO trial is going...
[17:03] <hefe_bia> Anyways I wouldn't start a new development with mono for Linux.
[17:03] <sharms> The mono website says 'Jim miller from microsoft': 'Basically a grant is given to anyone who want to implement those components for free and for any purpose. '
[17:03] <sharms> http://www.mono-project.com/FAQ:_Licensing
[17:04] <mok0> sharms: oh, on the mono website? That's completely worthless as documentation in court
[17:04] <ScottK-laptop> sharms: So MS fires the guy and claims he was speaking out of turn.
[17:04] <ScottK-laptop> Meaningless.
[17:05] <sharms> it's a fun discussion, because there is not a correct answer until the courts decide, so we really get nowhere :)
[17:05] <hefe_bia> But can they claim patents on parts that were standardized? Or is the problem that the implementation may accidently violate patents?
[17:05] <mok0> sharms: right
[17:05] <ScottK-laptop> hefe_bia: Standards have no affect on patents.
[17:06] <mok0> One of the problems is that Microsoft have never told what patents they say Linux is violating
[17:06] <broonie> Or what they mean by Linux for that matter.
[17:06] <mok0> ... so they keep everyone in a state of uncertainty
[17:06] <mok0> broonie: yes
[17:07] <mok0> Like most others, when they say "Linux" they mean the whole working OS
[17:07] <mok0> + apps
[17:07] <mgdm> is adding a Build-Depend on pkg-config a good/bad/stupid thing to do?
[17:08] <pochu> mgdm: good, if your package need it
[17:08]  * hefe_bia thinks he has to read up on the topic... Thanks for the insight.
[17:08] <mgdm> it seems to
[17:09] <hyperair> if configure.ac contains PKG_CHECK_MODULES then adding pkg-config to build-dep is fine i think
[17:11] <sebner> ScottK-laptop: http://www2.apebox.org/wordpress/linux/51/ :)
[17:12] <mgdm> I won't say I'm getting the hang of it, but I've nearly got the package I asked for the backport for updated to a new upstream release
[17:12] <mgdm> (libdmtx)
[17:12] <pochu> hmm
[17:12] <pochu> mgdm: backports are backported from the package in the development version, so you shouldn't need to update anything...
[17:13] <mgdm> the package in Jaunty isn't the latest upstream, it's the latest in Debian
[17:13] <pochu> ah, then you are updating the package for jaunty, right?
[17:13] <mgdm> I did this for myself as an exercise, to see if I can work out how to package things - if it isn't useful then at least I've learned something
[17:14] <mgdm> if I can submit it to Jaunty then that'd be fine by me too :)
[17:16] <pochu> mgdm: what's the latest upstream release?
[17:16] <mgdm> 0.6.0
[17:17] <mgdm> versus 0.5.2 that's in Jaunty
[17:20] <ScottK-laptop> sebner: I agree that a lot of the anti-mono crowd is over the top, but as the guy says, the combination of Microsoft's history of bad behaviour, the Novell deal, and the broken US patent system leave some room for reasonable concern.
[17:20] <NCommander> mgdm, if you finish the updated package, post it to Launchpad, and then ping me, and I'll review for upload
[17:20] <sebner> ScottK-laptop: sure but life is a game and I won't hide myself in the cellar for the rest of my life
[17:20] <mgdm> NCommander: great, thanks. I'll need to try it out on my laptop, it has my GPG keys
[17:21] <mgdm> NCommander: this is the first one I'll have done though, so expect some WTFery :)
[17:21] <NCommander> Well, I'm at UDS
[17:21] <NCommander> so my time to review time is somewhat high ATM
[17:21] <ScottK-laptop> mgdm: You can always just make a new gpg key, add it to your LP profile, and then upload ...
[17:21] <mgdm> understandable
[17:22] <mgdm> ScottK-laptop: I could... but I'm leaving for home in < 8 minutes :)
[17:22] <ScottK-laptop> Ah.  No point then.
[17:22] <pochu> mgdm: actually you don't need your gpg key to attach the diff.gz to a launchpad bug ;)
[17:22] <mgdm> Ah...
[17:22] <mgdm> there isn't a bug for a new upstream version, shoudl I file one?
[17:22] <pochu> yup
[17:22] <mgdm> ok
[17:23] <mgdm> I need to add something else to the changelog first
[17:24] <NCommander> mgdm, remember to subscribe ubuntu-universe-sponsors
[17:26] <mgdm> Done
[17:26] <mgdm> https://bugs.edge.launchpad.net/hardy-backports/+bug/306280
[17:26] <NCommander> Oh, this is a backport?
[17:26] <NCommander> Backports are different
[17:26] <NCommander> THe updated version MUST be in jaunty
[17:27] <mgdm> Oh, I botched that
[17:27] <NCommander> and as a general rule
[17:27] <NCommander> We don't backport libraries
[17:27] <NCommander> I'll look at it later
[17:27] <mgdm> Feck, I filed it in the wrong place
[17:29] <mgdm> if I file it against "ubuntu" rather than hardy-backports will that be more correct?
[17:29] <pochu> yes. you can add an Ubuntu task to the same bug report
[17:34] <sharms> ScottK: looks like Mike posted a blog entry same time you did
[17:35] <mgdm> I need to leave just now, if anyone has any hints for putting that bug in the right project, ping me...
[17:36] <ScottK> sharms: Mike's blog entry doesn't have any information that's actually useful for remote participation.  I responded to his.
[17:36] <sharms> gotcha
[17:37] <ScottK> But icecast.ubuntu.com is starting to have some useful information.
[17:40] <pochu> mgdm: I've added an Ubuntu task for you (click on "Also affects distribution", then Ubuntu and libdmtx)
[17:52] <mgdm> pochu: ah, great, thanks - I wasn't sure if that was right
[17:52] <mgdm> does the .diff.gz look sensible, if you have any time to look?
[17:53] <pochu> not really right now
[18:20] <mgdm> pochu, and everyone: thanks for all your help :)
[20:33] <crimsun> someone poke Hobbsee
[20:38] <Hobbsee> crimsun: poke back
[22:38] <meoblast001> hi
[22:38] <meoblast001> whats the package name for mozilla-xpcom
[22:41] <Hobbsee> xulrunner or similar, probably
[22:41] <meoblast001> i installed that
[22:47] <jdong> xulrunner-1.9-dev?
[22:47] <jdong> xulrunner-1.9-dev: /usr/lib/xulrunner-devel-1.9.0.3/xpcom-config.h
[22:48] <meoblast001> jdong: how would i tell wxMozilla that it has a different name
[22:48] <jdong> I have no idea what you mean?
[22:49] <meoblast001> this is what it tells me http://rafb.net/p/PE42Ul79.html
[22:49] <meoblast001> and i already have xulrunner-1.9-dev installed
[22:50] <jdong> a search and replace from mozilla-xpcom to xulrunner-xpcom should do it.
[22:50] <jdong> libxul-dev: /usr/lib/pkgconfig/xulrunner-xpcom.pc
[22:50] <jdong> that's the pkg-config file you want to address that error
[22:50] <jdong> note libxul-dev
[22:51] <meoblast001> ok im not familiar with pkg-config
[22:51] <meoblast001> so what am i doing?
[22:51] <jdong> installing libxul-dev
[22:51] <meoblast001> rephase please
[22:51] <meoblast001> ok
[22:51] <meoblast001> then...
[22:52] <jdong> then in your project find-and-replace everything that says "mozilla-xpcom" to "xulrunner-xpcom"
[22:52] <meoblast001> thats the configure script that has the error
[22:52] <meoblast001> i got this working before
[22:52] <meoblast001> well... it worked before
[22:52] <meoblast001> dont know why it wont work now
[22:52] <jdong> Ubuntu hasn't shipped mozilla-xpcom for several releases?
[22:53] <meoblast001> then where do i get it?
[22:53] <jdong> you don't get it.
[22:53] <jdong> as I said, you reconfigure your *project* to buidl against XULRUNNER-xpcom
[22:53] <meoblast001> what is it included in?
[22:53] <jdong> I don't know how I can make this any clearer....
[22:54] <meoblast001> this isnt my project.... this is wxMozilla
[22:54] <meoblast001> i dont know what would need to be changed in it cuz i didnt write it
[22:54] <meoblast001> i think i need to tell the configure script its real name
[22:54] <meoblast001> is that what its sayingi n that pastebin i gave you
[22:55] <jdong> you need to patch wxmozilla's buildsystem everywhere you see MOZILLA-xpcom change it to XULRUNNER-xpcom
[22:55] <jdong> this is the 4th time I've said the exact same thing.
[22:55] <meoblast001> ok
[22:55] <jdong> you should NOT be trying to find mozilla-xpcom.
[22:55] <meoblast001> now its clear to me
[22:56] <meoblast001> somehow i got it to work in the past
[23:01] <meoblast001> jdong, what about mozilla-nspr?
[23:04] <meoblast001> ok
[23:04] <meoblast001> found it
[23:07] <meoblast001> i've about had it with this stupid package naming scheme
[23:18] <meoblast001> jdong, changing the configure script made errors in them makefile