[00:00] Right. Which means I should upload the new evolution-sharp to Jaunty, too. [00:00] * jdong nods [00:00] Sadly I can't do that through Experimental; the new upstream fails to build against < e-d-s 2.24. [00:01] Even though it says it should on the box. :( === vorian is now known as heHATEme [01:30] 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] jdong: Yes, you must be bored. [01:41] 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] imbrandon!! [02:33] 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] kees: no, unfortunately I am not [02:44] 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] I just want to get an understanding of the challenges with a fully parallelized boot [02:45] if it's not a horrible unfinishable mess I'll probably send something out to the mailing list [02:47] 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] heh cool. [02:49] I oddly recall starting to write such a thing two years ago, in fact! [02:49] * jdong greps his ~/src === heHATEme is now known as vorian === hyperair1 is now known as Guest89158 === Guest89158 is now known as hyperair [02:51] https://code.edge.launchpad.net/~uphackers/uphack/uphack-tools [02:51] aha! [02:51] upconv/uphack. [02:51] 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] was that what I was doing over spring break? [03:04] 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] 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] *HOLY CRAP* [03:07] kees: it booted! [03:07] I am not convinced it's any faster though [03:07] and TODO: figure out how to shut it down :D [03:10] 25s in vmware.... [03:10] * jdong is almost curious enough to try this natively [03:12] jdong: what are you playing with now? ;) [03:20] psusi: upstart [03:21] psusi: a quick and dirty python script that generates dummy upstart jobs for each rcS.d-rc2.d script [03:34] 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] right. [03:34] why? [03:34] with a basic set of heuristics for job dependencies. [03:34] parallelized boot [03:34] doesn't rc already have an option to do that? [03:35] psusi: it doesn't seem to be as parallel [03:35] ohh.. I guess it only runs jobs with the same Snn level in parallel... [03:35] I see now why you are surprised that it worked ;) [03:35] psusi: lemme generate a quick dot diagram of my dependency graph urrently [03:36] psusi: http://jdong.mit.edu/~jdong/upstart-dep.png [03:36] pretty neat looking [03:37] 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] ScottK: I was unaware debian has this [03:37] how does that fit into our plan to completely go upstart though? [03:37] this for me is just an experiment in what an upstart-booting parallelized system buys us [03:37] jdong: I'm wondering why we're doing that. [03:38] well upstart represents job relationships in a better way IMO [03:38] it fits the model of the modern Linux machine better than a bunch of start-stop scripts. [03:39] jdong: http://lists.debian.org/debian-devel-announce/2008/11/msg00007.html [03:39] 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] psusi: I think it must. [03:39] jdong: Sure, no doubt it's better, but is it enough better to be worth the additional difference between Debian and Ubuntu. [03:41] 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] psusi: not really when the jobs aren't really bound by the same resource. [03:41] 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] the former is the case according to my bootchart [03:42] 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] like if one job is IO bound and one is CPU bound, then run both at once [03:42] well competing for disk right now is the biggest problem. [03:42] I could care less if they compete for CPU or RAM [03:42] but you don't want to run two jobs at once that are both IO bound [03:43] I think a bit of aio scheduler hackery can work around the IO contention though [03:43] eh? [03:43] psusi: sysv: http://jdong.mit.edu/~jdong/macbook/bootchart-sysv.png [03:43] upstart: http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png [03:43] 27s vs 22s [03:44] 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] still relatively untweaked with mechanically-generated rules. [03:44] the 67 . /lib/lsb/init-function.sh calls are probably representing significant overhead too [03:44] psusi: the AIO scheduler with large timeslices can alleviate a lot of the seeking though. [03:45] psusi: and frankly single tasks during bootup seek crazily enough [03:45] we don't really have any guarantee that each task alone doesn't thrash. [03:45] http://jdong.mit.edu/~jdong/macbook/hardy-upstart-defragged.png [03:45] that's an optimized run with readahead/boot listed files rewritten to disk [03:46] 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] 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] the aio scheduler? is that a new io scheduler? [03:47] I'm confused as to what aio has to do with the elevator [03:48] 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] 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] 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] (2) Yes, I'd like for all the boot files to be near the start of the disk and sequential. [03:49] you don't want to see my symlink farm method for forcing that with a tiny 100MB /prefetch partition :P [03:50] 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] that was my next tier of hacks. [03:51] you're getting ahead of me! [03:51] ;) [03:51] ionicing and nicing was my next set of master ugly hacks :P [03:51] I first want to get this set of jbos correct [03:51] still getting a few races I need to sort out [03:51] hrm... your max disk throughptu was only 12 MB/s? [03:51] rofs and dev/pts mounting not at the right time :) [03:51] that seems rather low [03:51] it's a laptop on ata_piix emulation. [03:51] eww [03:52] this can be a LOT faster with a proper computer. [03:52] in fact I'm curious enough to try it... [03:52] * jdong digs out his production system [03:52] jdong: dual core cpu? kind of funny how the graph only shows 50% IO wait time during readahead-list [03:53] yup [03:55] 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] I need to finish getting that reintroduced to the repository [03:55] :) [03:56] I finally got around to creating a project for it on lp and checking it into bzr [03:57] 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] psusi: modprobe blocks hard in the kernel at several points [03:57] which inflates bootchart [03:57] ok, so 34s stock boot no tricks.... [03:58] *unpacks event.d* [04:02] 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] 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] please help review iptux 0.4.2-0ubuntu1(new package): http://revu.ubuntuwire.com/details.py?upid=4186, thanks [04:08] ScottK-laptop: Hi, just read it [04:08] I'll be sure to ask the last merger next time. Thanks for the heads up. [04:09] nellery: Also, since Debian moved to quilt, I think it's better our change is in quilt too. FYI for next time. [04:09] 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] lidaobing: Is this the same iptux sitting in Debian New? [04:11] ScottK-laptop: I'll definitely look out for that in the future, thanks again [04:11] No problem. [04:11] ScottK-laptop, Debian new? let me check, I think I still waiting for RFS [04:12] 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] ScottK-laptop, I can't find it in Debian new queue, http://ftp-master.debian.org/new.html, any more information? [04:13] 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] lidaobing: Maybe I mis-remember. Let me check. [04:15] 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] 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] 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] Now it's not many hard drives mind you, but it is all of them ... [04:18] ScottK-laptop, no information in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507451, and did not recieve any email for it. [04:18] Debian bug 507451 in wnpp "ITP: iptux -- IP Messenger client for Linux" [Wishlist,Open] [04:21] lidaobing: It's also possible I misremember. [04:51] psusi: ok I might be cheating now: http://jdong.mit.edu/~jdong/upstart-dep-lazy.png [04:51] moved 70% of the bootup to sleep 10; after GDM :D [04:51] jdong: eh? [04:52] psusi: kickstart gdm first and then worry about booting up the rest of the system :) [04:54] doesn't gdm depend on the rest of the system already being started? ;) [04:54] no, the graph shows the boot order relationship [04:54] i.e. it's a dirty topsort of the graph [04:54] i.e. B's "start on starting A" shows as A->B [04:55] jdong: what's readahead_desktop? [04:55] the LTSP version of readahead. [04:55] it doesn't matter here [04:56] I see... you start gdm before things like laptop_mode and and cron... that seems ok [04:56] 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] psusi: I'm gonna do a control run with no readahead [04:57] and then carefully readahead JUST up to the gdm point. [04:57] 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] psusi: everything after gdm is (1) sleep 10 (2) ionice -c3 (3) nice 20 === fta__ is now known as fta [05:01] 22s [05:04] 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] jdong: and what was the base time on a stock system? [05:07] jdong: mountoverflowtmp should probably be done before dbus on down [05:08] psusi: around 37s [05:08] and yes I am reworking the dep tree still [05:08] what uses perl during bootup? [05:10] still about 22s stable. [05:10] I think I've hit a fundamental limit :) [05:10] 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] 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] 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] 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] then start dbus and all after only once the second readahead list is done [05:17] interesting; 34MiB of readahead necessary [05:19] 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] psusi: oh I'm not profiling with upstart enabled. [05:20] I have a simulated sysv setup that activates via bootflag, for profiling [05:20] ahh [05:20] such a hack :D [05:20] just "defragged" readahead data. [05:20] what do you think of having multiple readahead stages? [05:20] untarred it really fast, that is :) [05:21] well I'm considering the idea of multiple readahead stages [05:21] just right now it's terribly annoying to get profiled [05:21] yea... difficult, but may yield sweet fruit [05:21] 20s [05:22] significant difference from rewriting out readahead/boot's files [05:22] 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] hehe, now get them to be stored in the order they are read ;) === santiago-ve is now known as Guest13204 [05:23] lol I think I'm gonna call it a night with stupid bootup tricks :D [05:24] hehe.... I want to see that boot time down to 10 seconds ;) [05:26] psusi: in case you're bored: https://code.edge.launchpad.net/~uphackers/uphack/uphack-tools [05:26] there's upconv which reads in /etc/rc*.d and spits out /tmp/event.d [05:26] and depchart which when executed depchart /tmp/event.d | dot -Tpng > foo.png, creates a .png :) [05:27] psusi: I'd be interested to see a SSD bench [05:27] oh to bootstrap you should probably keep your existing tty* and make them start on started mountall_sh [05:28] otherwise you may find yourself lacking terminal(s) :) [05:28] cool... I got one for you: https://launchpad.net/~e2defrag ;) [05:28] eh? aren't the getty's already started as their own upstart jobs? [05:29] psusi: yes but my magical event.d generator does not generate the special tty jobs [05:29] jdong: I'm saying I thought the tty jobs already existed in event.d and don't need generated from rc scripts [05:29] 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] psusi: and the pre-generated tty jobs depend on "runlevel" [05:29] i.e. the rc jobs [05:30] 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] psusi: not in Intrepid, they "fixed" that :D [05:32] lol... why was it "broken"? ;) [05:32] 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] that's why I said "fixed" [05:34] the "problem" was if the system was fscking it would still allow you to log in. [05:34] and also it would present the login before the hostname was set [05:35] ohh, I see.... it now starts on stopped rc2... before it started on runlevel 2 [05:35] right [05:36] IMO it should start on started rc2 [05:36] and use the service declearation [05:36] with pre-start exec /etc/ .... [05:36] I'd like to see rc2 as "started" when it finishes running. [05:36] makes sense... that way it waits until after rcS but not on rc2 [05:36] not "starting" -> "stopped" [07:53] jdong: I think I'm a bit biased with that question ;-) [09:23] <\sh> moins [09:26] moin [09:37] hiya [09:38] * directhex votes to declare it the weekend again -_- [09:39] it's holiday here in Spain :) [09:42] Hi all [09:43] <\sh> it's UDS time ,-) [09:45] aren't they all still sleeping? [09:52] <\sh> looks like...-6h from europe, right? [09:52] .ca is west coast isn't it? [09:52] wait, no . there [09:52] but my clock says -8 for LA [09:54] <\sh> ah west coast..yeah that's a bit more then -6h [09:54] hehe. why not find out where they are first? ;-) [09:56] -9h from CET. [09:57] does anyone knows where apache sets it's ulimit from ? [09:57] I set this export APACHE_ULIMIT_MAX_FILES="8192" [09:57] in /etc/apache2/envvars [09:58] I have a php file that contains , and I het 1024 [09:58] do I need to modify /etc/security/limits.conf ? [09:58] shouldn't this be documented ? [09:59] * directhex stabs ulimit with a spork [09:59] hey directhex [09:59] morning NCommander [09:59] directhex, I take it your not at UDS? [09:59] \sh, you here? [10:00] 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] The "not-at-UDS" club gathers :) [10:02] 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] slytherin: I looked at it a while ago... I'll check it again [10:03] 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] o_o; === awmcclain is now known as ethan0 [10:04] 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] ethan0, wrong. [10:05] <\sh> ethan0: nope..._all.deb just means, it's architecture independant [10:05] ethan0, .deb is (usually) never source [10:06] It's a binary package then. Ungh. Sorry, I've been up for much too long. [10:06] ethan0, a source package comes in the form of a diff.gz, orig.tar.gz, and .dsc [10:06] Yes, of course. Sorry. [10:06] * ethan0 needs to sleep [10:06] ethan0, an _all might be something like, say, a CLI .dll file [10:07] actually, <£400 for last-minute flights. it was definitely >£1k when i looked previously [10:07] still, too rich for my blood [10:13] anyone here apache expert or packager ? [11:09] is there any chance/likelyhood of a backport of libdmtx to hardy? [11:10] how many reverse dependencies does it have? [11:11] it doesn't appear to have very many, though I could be looking in the wrong place [11:12] as far as I can make out it only wants libpng and libtiff [11:12] mgdm: The package does not exist in hardy. Is that correct? [11:12] slytherin: yeah, it only seems to have appeared in Jaunty [11:15] then you should be fine [11:16] mgdm: report a bug at https://edge.launchpad.net/hardy-backports/+bugs [11:16] I'm just trying to build it just now [11:16] Ah, cool [11:17] mgdm: of course building, installing and testing it will help the backporters to approve it ;) [11:17] I guessed it might :) [11:34] if the package is asking for debhelper >= 7, but Hardy only has 6, is that a major issue? [11:35] yes! it causes baby jesus to cry [11:35] mgdm: hardy backports have 7 but do you really need debhelper7? [11:35] also, i thought dh7 was ni hardy-backports === RainCT changed the topic of #ubuntu-motu to: Masters of the Universe - https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Jaunty: OPEN. | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs [11:36] 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] mgdm: enable hardy-backports to build it === pochu changed the topic of #ubuntu-motu to: Masters of the Universe - https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs [11:38] pochu: OK, I'm trying it, thanks [11:45] Oh, I do have debhelper 7 already installed, but it's not in the pbuilder chroot, I suspect [11:45] (does that sound plausible?) [11:45] it sounds plausible. pbuilders don't tend to have backports on by default [11:49] in English, when you read something out loud, how do you read "e.g.", as "e g" or "exampli gratia" ? [11:49] i say e g [11:49] Also, ##english [11:49] i say "for example". but i'm not a native speaker [11:49] i would also say for example [11:49] oh yes, you could say that too [11:50] I'd say "for example", too, and I'm a native speaker [11:50] thanks you all :) [11:50] i say "egg", but i'm a weirdo! [11:50] lol [11:50] nah, "for example" is correct [11:50] Not on IRC you're not! [11:51] and for i.e. you say "that is"? [11:52] pochu, aye [11:52] cool [11:52] * pochu is studying for the toefl [11:54] i probably wouldn't understand it if someone said "exempla gratia" ;) [11:54] pochu: cool [11:55] * mgdm works out what he's doing wrong [11:57] mgdm: login into pbuilder and look at /etc/apt/sources.list [11:57] if you don't have hardy-backports, that's what is wrong [11:57] or, even better, use OTHERMIRROR and --override-config [11:58] yeah, I went for the OTHERMIRROR option in the end [11:58] I figured that was more sustainable in the long run than logging in and hacking manually [12:02] yay, it builds and runs \o/ [13:09] geser: ping [13:23] I uploaded my package to REVU fifteen minutes ago, and it's still not visible on the website? what could be wrong? [13:24] pmjdebruijn: is this your first upload to revu? [13:24] yes [13:25] pmjdebruijn: did you login to revu prior to upload? [13:26] slytherin: oh crap... I thought I was still logged in from yesterday [13:27] pmjdebruijn: which package is it? [13:27] lensfun [13:27] dput says it's already uploaded [13:27] pmjdebruijn: wait, I meant if logged in even once. If you had then there seem to be some other problem [13:27] pmjdebruijn: what is the dput command you used? [13:27] dput revu lensfun_0.2.3-0ubuntu1_i386.changes [13:28] pmjdebruijn: you need to upload source.changes [13:28] oh silly me [13:28] * pmjdebruijn goes back to the drawing board... [13:33] slytherin: pong [13:34] 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] slytherin: What happened? [13:37] ScottK-laptop: source of library changed between two revisions (not upstream versions), apis missing/changed and hence jbossas4 won't build. [13:37] Lovely. [13:38] ScottK-laptop: and this went unnoticed as I am sure everyone assumed that source of svn5660+dak1 must be same as svn5660 [13:38] ah, there it is [13:38] I already see I have some work to do [13:38] slytherin: sure [13:39] anybody else, willing to check it out? so I can correct several things at one... [13:39] http://revu.ubuntuwire.com/details.py?package=lensfun [13:39] geser: http://paste.ubuntu.com/82457/ [13:43] Oo, lensfun, been meaning to check that out [13:44] slytherin: wow, the .orig.tar.gz changed from over 700 kB to 70 kB with one upload? [13:45] geser: yup [13:45] slytherin: send the mail, it looks ok to me [13:45] mgdm: eh? [13:46] mgdm: lensfun by itself does nothing... it's a library... but it works wonders when ufraw is compiled with lensfun support [13:46] mgdm: I have my own repo at "deb http://ubuntu.pcode.nl/ubuntu intrepid exiv2 ufraw lensfun" [13:46] mgdm: use at own risk, these are development snapshots... the newer exiv2 may break digikam, etc... [13:47] pmjdebruijn: Yeah, I was meaning I wanted to try it out with UFRaw :) I shall check out your repo, though [13:48] mgdm: those aren't released version, just development snapshot... but it works for me [13:48] mgdm: what camera do you have? [13:48] 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] pmjdebruijn: 400D [13:48] mgdm: me too [13:48] cool [13:48] mgdm: I usually start by modifying existing packages... === LucidFox_ is now known as LucidFox === asac_ is now known as asac === _stink__ is now known as _stink_ [14:37] I just removed all obvious/lintian errors from lensfun [14:37] I'd appreciate if somebody would have time to take a look at it sometime this week :) [14:45] Heya gang [14:46] Hi bddebian [14:46] heya bddebian [14:46] bddebian: Heya. [14:47] 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] Hi geser, sebner ScottK-laptop [14:47] ScottK-laptop: Which package? [14:48] bddebian: pybliographer [14:50] Well I uploaded a better version to mentors long ago but I don't think it ever got picked up. [14:50] Didn't I upload that to Ubuntu? [14:52] bddebian: Dunno. Just looking at MoM. Maybe you could upload that to Debian and then we could sync .... [14:53] Aye, let me look at the status of pybliographer [14:53] Great. [15:11] ScottK-laptop: Hmm, weird, looks like 1.2.11 was uploaded to unstable in July. [15:12] Then can we just sync it? [15:13] 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] bddebian: You going to sort it or should I? [15:20] ScottK-laptop: Please do, I don't even have a working Ubuntu install atm, my Ubuntu lappy died :( [15:20] OK. Will do. [15:24] Thanks [16:02] bddebian: Hey, you said gimme a break, here it is: :-) [16:03] mok0: :) [16:03] mok0: I honestly am not trying to ridicule you. I apologize if it came off that way. [16:04] bddebian: no offense taken; I just wanted you & others to focus on real arguments [16:05] bddebian: anyways, if you've seen my latest mail, I offer to take over maintenance of gtk+ 1.2 [16:05] mok0: Yeah, nice :) [16:05] bddebian: but I can't see that it's been orphaned [16:05] Personally, I think we should remove GTK 1.2 [16:06] StevenK: That has been the arguement :) [16:06] StevenK: ah, you guys... [16:07] mok0: You are correct, I don't think gtk+1.2 itself is technically orphaned [16:07] bddebian: ... but it's unmaintained? [16:07] mok0: Of course it hasn't seen a maintainer upload since 2004 :) [16:08] bddebian: okay... so what should I do then? [16:08] Let me check MIA on that DD [16:08] bddebian: thx [16:09] Heh, he retired over a year ago [16:09] 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] Then they can get it from upstream.. [16:10] * bddebian hides [16:10] bddebian: if there _is_ an upstream, yes [16:11] bddebian: gtkglarea for example, upstream is MIA [16:11] all links are dead [16:11] those sources live only in the archives of the various distros [16:12] But I know for a fact that it's still being used [16:12] And since mok0 has volunteered to do the work, people should let him do it .... [16:13] * mok0 hugs ScottK-laptop [16:13] mok0: Exactly my point but I'm checking with the MIA folks to make sure I'm reading that mia-query correctly [16:13] bddebian: I am grateful if you would figure it out [16:13] ScottK-laptop: Agreed but he is talking about 1 package with a butload of unmmaintained/orphaned rdepends [16:15] Right. The rpendends are a different issue. [16:15] Or however you spell that ... [16:16] 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] Well techinically you should ITA: first. [16:17] bddebian: ok, will do... of course I need to persuade a DD to upload it :-) [16:17] I can do that [16:17] bddebian: great, thanks [16:18] mok0: Oddly enough you're talking to one ... [16:18] So start persuading ... [16:19] ScottK. I think he already went soft on me :-) [16:21] heh [16:21] 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] bddebian: I didn't see you comment, but I can guess... it is the lintian that complains about the name, right? [16:23] bddebian: it is a choice of changing the package names or the library names; I'd rather not do either [16:23] mok0: Well the package name really should change but if you are trying to get this in for Lenny, I agree [16:24] bddebian: if you think it's ok to change the package names, I will do that [16:25] mok0: It is but it might break any reverse dependencies. [16:25]