[00:01] <persia> micahg: Hey.  Any idea about enigmail/armel?  Seems to build, and then suddenly fall apart due to a missing chrome.manifest.
[00:01] <micahg> persia: no, I can take a look later
[00:02] <persia> Thanks.
[00:06] <lfaraone> If a package manual talks about using another application to get information to use in this package, and there is a maintainer helper script that uses said other application, but it's not technically needed to run the upstream software, should that be suggests or recommends?
[00:08] <micahg> lfaraone: http://www.debian.org/doc/debian-policy/ch-relationships.html  See section 7.2
[00:08] <lfaraone> micahg: so I guess it's "suggests"?
[00:09] <micahg> lfaraone: It depends
[00:09] <micahg> lfaraone: did you read the 2 descriptions?
[00:10] <micahg> lfaraone: not technically needed bumps it from Depends, the rest is dependent on how it's normally used
[00:10] <persia> Do I need a release team ACK to drop a superceded source package from the archive?
[00:11] <lfaraone> micahg: yes, I did.
[00:11] <micahg> lfaraone: so, the question is how common is it to use the other app, if common, recommends, if not, suggests
[00:11] <lfaraone> micahg: basically, "foo" taks as parameters a bunch of things about your monitor configuration. "foo_easy" (written by me) gets that information from xvidtune.
[00:12] <lfaraone> micahg: and the manpage for "foo" (adapted from upstream text) talks about using xvidtune to get that information.
[00:13] <micahg> lfaraone: actually, U should rephrase, the manual said recommends is a package is found together in all but unusual installations
[00:13] <micahg> oops
[00:13] <micahg> that should be I
[00:13] <lfaraone> mk, suggests still then.
[00:15] <persia> Note that there's a certain amount of subjectivity in the distinction between recommends/suggests.  I've had people disagree with my opinions on which is correct previously (and with good arguments).
[00:15] <micahg> persia: that's exactly why I won't answer the question directly :)
[00:16] <persia> micahg: Always a good choice :)
[02:49] <RoAkSoAx> ScottK: isn't libperl-critic-perl in universe?
[02:49] <ScottK> RoAkSoAx: Not anymore
[02:50] <RoAkSoAx> ScottK: is someone else (besides me or ivoks) requested its inclusion in main?
[02:50] <RoAkSoAx> s/is/has
[02:50] <ScottK> It was needed as a build-dep for something else.
[02:50] <ScottK> I'm going through the Main FTBFS and depwaits
[02:52] <RoAkSoAx> ScottK: oh ok, because we wanted it at first for the Cluster Stack, but then ivoks realized that it wasn't actually needed, and that's why we dropped the hardcoded depends on perl modules for cluster-agents and cluster-glue
[02:57] <RoAkSoAx> ScottK: you might wanna take a look to [1] if you are tracking the dependencies down... [1] https://wiki.ubuntu.com/ClusterStack/MIR?action=diff&rev2=44&rev1=36
[02:57] <ScottK> RoAkSoAx: I'm not specifically focused on cluster stack.  Just getting all the stuff that's already in Main buildable and installable from Main.
[02:58] <ScottK> I think it's a coincidence that your cluster stack stuff got touched so heavily.
[02:58] <RoAkSoAx> ScottK: i know I was just explaining why those MIR's were marked as Invalid :)
[03:00]  * ScottK nods
[03:00] <RoAkSoAx> ;)
[03:11] <MTeck-ricer> So.. does anything actually depend on plymouth other than plymouth-* ? I know a coupdl have Depends: plymouth - but do they actually depend on it being there?
[03:12] <ScottK> Yes.
[03:12] <ScottK> I know what you're thinking.   Don't do it.
[03:12] <MTeck-ricer> ScottK: :P - how do they depend on it?
[03:12] <MTeck-ricer> ScottK: I'm just curious because as far as I can see it looks like it only provides a splash screen
[03:13] <ScottK> I don't recall the details but plymouth is involved in properly serializing IO during boot or something like that.
[03:13] <ScottK> It doesn't.
[03:14] <MTeck-ricer> alrighty
[03:14] <MTeck-ricer> ScottK: thanks
[03:15] <MTeck-ricer> ScottK: so is it not possible to tear those two pieces of functionality apart?
[03:15] <ScottK> MTeck-ricer: Anything is possible.  There is a possible system where they are separated, that's not the one we have.
[03:41] <MTeck-ricer> How can I see what replaced a package from karmic?
[03:45] <persia> MTeck-ricer: You can't, triviallly.  You can try fiddling with grep-dctrl or look at dependencies of the rdepends of the package being replaced.  Sometimes there are transition packages.
[03:46] <MTeck-ricer> persia: oh- i was trying to figure out what replaced gnome-volume-manager
[03:51] <persia> MTeck-ricer: Which bit of gnome-voume-manager?  It used to do lots of different things.  I think the media players replaced some of it, nautilus replaced other bits of it, etc.
[03:52] <persia> But you might ask in #ubuntu-desktop: they're more likely to know for sure.
[03:58] <MTeck-ricer> persia: ok, if you don't know i'll pop over - I want to figure out what handles the magical mount/unmount of external devices
[03:59] <persia> For GNOME, that's nautilus.  For XFCE, that's thunar.  I don't know for other environments.
[04:00] <MTeck-ricer> thunar doesn't do that though
[04:00] <MTeck-ricer> unless there's something it's just not doing on my system
[04:04] <MTeck-ricer> persia: I guess I have to run - but I've been using thunar and it doesn't seem to do any magical mounting
[04:04] <MTeck-ricer>  - when you plug in a device
[04:05] <persia> Ask in #xubuntu-devel : it should.  I know I added it to the MID edition when we did that precisely for this feature.
[04:06] <MTeck-ricer> persia: ok, thanks
[05:12] <psusi> hrm... getting there... after defragging ureadahead time during boot drops from 7 to 4 seconds...
[05:14] <persia> psusi: What's your total wallclock now?
[05:14] <psusi> persia, my what?
[05:14] <persia> Total boot time.
[05:15] <psusi> not sure since it remains a fairly constant around 1 min due to waiting 45 seconds after mountall to shut down
[05:15] <persia> (from the perspective on a clock on the wall of the room in which your computer is contained, in case you're doing something odd with the computer's sense of time during boot)
[05:15] <persia> Ugh.  What's that 45-second wait?
[05:16] <psusi> but before vs after defrag, time spent in ureadahead drpos from 7 to 4 seconds
[05:16] <persia> Right, which made me think you were one of those folks who had the 7-8 second boot.
[05:17] <psusi> ureadahed still spends an unaccptable amount of time open()ing the files since it keeps blocking on a single 4kb read of the directory before continuing
[05:18] <persia> That you consider it unacceptable leads me to believe that it won't be that way for maverick :)
[05:18] <psusi> indeed ;)
[05:18] <psusi> when booting from my rotational disks, it's about 1 second of time spent with virtually zero IO while ureadahead open()s all the files it is about to readahead
[05:19] <psusi> I need to paralellize those opens across multiple threads to speed it up since it seems you can not readahead() directories
[05:19] <psusi> and that's why the open() calls block... have to read the directory blocks to figure out where the files are
[05:19] <psusi> even after defragging
[05:21] <psusi> hopefully during mav I can get a few people to test defrag for me ;)
[05:23] <persia> Did you make a nice GUI that shows all the blocks getting put in the right place?
[05:23] <psusi> yea ;)
[05:23] <persia> Then I'm sure you'll get testers.  People always like GUIs.
[05:24] <psusi> though this defrag program has been around since dinasaures ruled the earth... was originally written by theodore ts'o and remmy card and linus back in like the 1990s
[05:24] <psusi> or 1980s even
[05:24] <psusi> I"m just reviving it
[05:24] <psusi> it's a simple ncurses ascii gui
[05:25] <persia> The main obstacle is the myth that you don't need to defag extN
[05:25] <psusi> generally speaking you don't.. not in the way you "NEED" to defrag window
[05:25] <psusi> windows
[05:25] <psusi> but I'm getting it to interact with ureadahead to pack the files that ureadahead reads at the start of the disk so they can be real uber fast
[05:26] <persia> I think the semantic distinction between "don't need" and don't "NEED" has been lost along the way.
[05:26] <psusi> exactly
[05:26] <psusi> windows NEEDS defragmented since it tends to get HORRDIBLY, HEDIOUSLY FRAGMENTED due to using the most retard algorithm for block allocation known to man
[05:27] <psusi> most of the time ext[234] does a good job of minimizing file fragmentation these days, especially ext4
[05:28] <persia> Yeah.  OS 7 did something like that, where it loaded the kernel, extensions, type mapping, base applications, and directory entries at the "beginning" of the disk, so they would get read (in order) on startup for faster startup.  Mind you, that was still measured in minutes, but...
[05:28] <persia> Well, if there's free space, yeah, it's rare to have a fragmented file.
[05:28] <psusi> but this old e2defrag program lets you specify a priority list so it will pack certain files first.. so I can have all the files that ureadahead wants packed at the start of the disk so they read in real fast
[05:29] <psusi> crap, wife says it's past my bed time
[05:29] <psusi> have to resume this tomorrow... night...
[05:30] <persia> Are modern rotary disks fast enough that one can actually put all the bits in order at the beginning and read them, or does one still benefit from staggering it a bit to deal with discrepancies between sustained throughput through the interfaces and raw disk read speed?
[05:30] <persia> Ah, good night.
[05:44] <MTeck-ricer> persia: just figured it out :D    sudo aptitude install thunar-volman     hald && thunar --daemon
[05:45] <MTeck-ricer> persia: thanks :)
[06:58] <micahg> how does one recover from this in a prerm script:  update-alternatives: error: alternative path /usr/bin/seamonkey doesn't exist.
[07:10] <micahg> persia: around?
[07:37] <persia> micahg: Now.
[07:37] <micahg> persia: :)
[07:37] <micahg> how does one recover from this in a prerm script:  update-alternatives: error: alternative path /usr/bin/seamonkey doesn't exist.
[07:40] <persia> One 1) only runs the prerm under certain conditions (check the arguments), and 2) tests for the presence/absence of an alternative path prior to calling update-alternatives.
[07:46] <micahg> persia: so if I do a -e on the path before running it I should be ok?
[07:48] <persia> micahg: Um, I think you want something richer, but that's a minimal test
[07:49] <micahg> persia: is there a better way
[07:50] <persia> Well, update-alternatives accepts --query and --display.
[07:54]  * micahg will go with simple for now
[08:22] <dholbach> good morning
[08:23] <adahendra> morning
[10:21] <james_w> persia: could you take a look at https://code.edge.launchpad.net/~voronov84/ubuntu/lucid/ubuntu-dev-tools/lucid/+merge/23577 please?
[13:11] <MTeck-ricer> persia: I thought it was working, wake up and no more :(
[14:00] <c_korn> can sbuild be configuered to run lintian -i on the generated debs ?
[17:49] <blueyed> Any hints on skipping dbconfig setup with DEBIAN_FRONTEND=noninteractive? (bug 560144)
[18:31] <ScottK> pychecker is back in Universe after the next publisher run.  Thanks again ajmitch.
[18:43] <arand> If there are already simple-cdbs patches named both with letters and numbers (10.patch bar.patch foo.patch) should one maintain that naming and just add z01_foobar.patch (to fix order) or rename the old patches with numbers, when trying to keep the fix as SRU-friendly as possible?
[18:44] <ScottK> arand: Don't rename the old patches.  An SRU should be the slightest fix possible.
[18:45] <arand> ScottK: Ok, noted.
[19:04] <MTeck-ricer> Is there any PHP-5.2.x package for 10.04?
[19:05] <MTeck-ricer> I'm dealing with an ugly issue that I need to use the old version of php
[19:14] <micahg> MTeck-ricer: don't upgrade to lucid then
[19:16] <MTeck-ricer> micahg: I'm just curious if it's an option. That's the one and only issue with 10.04 and that has nothing to do with Ubuntu - that's bad coding.
[19:17] <samgee> hi guys. I found http://archive.ubuntu.com/ubuntu/pool/universe/g/gambas2/gambas2-doc_1.9.49-2ubuntu1_all.deb, but there doesn't seem to be a source package for that version. That's a bug, right?
[19:20] <joaopinto> samgee, the source is available, source package name gambas2
[19:20] <jpds> samgee: Might be related to bug #549041.
[19:21] <samgee> jpds, oh lovely, that's the bug I indirectly reported to James :)
[19:21] <jpds> Heh.
[19:22] <samgee> joaopinto, I know what the source package's name is, I just can't find it for that version
[19:22] <samgee> I find it a bit strange that it's only of medium importance, though
[19:24] <joaopinto> samgee, ops :|
[19:25] <samgee> joaopinto, thanks for helping anyway ;)
[19:34] <samgee> btw, is there anything I can do to help fix that bug? Apart from the gpl violation it's also just annoying when I come across it while working on our own repo.
[19:39] <jpds> samgee: Fix Soyuz?
[19:40] <samgee> I guess so
[19:40] <jpds> I would ask around in #launchpad-dev.
[19:40] <samgee> ok, thanks
[19:40] <RoAk> james_w, why would I get this while doing a bzr diff? http://paste.ubuntu.com/418789/
[19:57] <james_w> RoAk: probably the root id changed, but I'm not sure
[19:59] <RoAk> james_w, weird, how would I resolve it?
[20:00] <james_w> RoAk: dunno, depends what you are doing
[20:00] <geser> last time I saw this, I ignored it and hoped it won't reappear in the next merge
[20:01] <micahg> ttx: is there any reason why phpmyadmin doesn't depend on some version of mysql server?
[20:01] <RoAk> james_w, i'm merging redhat-cluster from debian testing. THe current version in Ubuntu a new upstream release package by ivoks, so Im guessing that something went wrong there?
[20:01] <ttx> micahg: hmmm... because it can be installed on a separate host, maybe ?
[20:02] <james_w> RoAk: probably a bug in the importer. I think you should just carry on
[20:02] <RoAk> james_w, will do then. thanks :)
[20:03] <micahg> ttx: the problem is that we're getting faliures if mysql isn't configured before mysql
[20:03] <micahg> ttx: I meant mysql before phpmyadmin
[20:04] <ttx> micahg: is there a bug number ?
[20:04] <ttx> zul: could you look into that ^ ? I'm leaving now
[20:04] <zul> sure
[20:04] <zul> is there a bug number?
[20:04] <micahg> ttx: zul: bug 566840
[20:05] <micahg> zul: I saw a couple others
[20:05] <zul> micahg: its a common dbconfig-common problem
[20:06] <micahg> zul: is there a master bug to dupe these to?
[20:06] <zul> not really its a design of dbconfig-common
[20:07] <micahg> zul: well, should we create a bug then?  This happens with other mysql based apps as well like request tracker
[20:07] <ajmitch> the problem is that postinst shouldn't just blow up, though it does it on too many packages
[20:08] <zul> micahg: sure go ahead....hey ajmitch
[20:08] <ajmitch> morning
[20:08] <micahg> zul: k, should I subscribe you?
[20:08] <zul> micahg: yep
[20:08]  * micahg will do this later
[20:35] <doctormo> ScottK: This is basically what I want to do: http://imagebin.ca/view/79p58iGb.html
[20:37] <ScottK> Looks ~right in the amount of time I have to look at it now.
[20:39] <doctormo> It passes the ebert review test, I'm going to dig up some other people to have a look too: persia?
[20:57] <andreserl> james_w, could you take a quick look to lp:~andreserl/ubuntu/lucid/redhat-cluster/merge-from-testing-lp-566858 and see if the branch is correct?
[22:19] <persia> doctormo: Chapter 2: drop "contrib"  Maybe <i>others</i>?, chapter 3: `debuild -b` to get binary, chapter 4: the queue uses sbuild rather than pbuilder (but a special fork of sbuild: maybe "buildd queue"?)
[22:20] <persia> james_w: looks right: I'll merge that in a bit.
[22:22] <persia> So, lovely.  bzr merge can't actually process that :/
[22:36] <doctormo> persia: Where you saying that a packager should write their control file manually?
[22:37] <persia> Lots of places.  I generally say that in any forum where it's appropriate.  I don't think our control file generation tools are good enough yet.
[22:37] <persia> We do best for python, with python-stdeb and python-distutils-extra (listed in the order of my preference), but we do fairly poorly for other sorts of code.
[23:21] <imbrandon> evening all
[23:27] <ajmitch> hi imbrandon
[23:34] <imbrandon> soooo i need to find a DD near ( ~100miles ) me
[23:34] <imbrandon> lol
[23:35] <imbrandon> maybe a lazyweb post about it
[23:35] <imbrandon> bring someone out of the woodwork
[23:37] <imbrandon> ajmitch: you do python(web) stuff for work alongside your php dont you ?
[23:38] <imbrandon> i wanna commission a specific feature for a python cms ( floss ) even if i have to pay to get it done, i just cant wrap my head arround it to get it "right"
[23:44] <ajmitch> imbrandon: I do a little
[23:46] <imbrandon> intrested in looking into my request ? i'm *estimating* ( not well because i'm not a python guru ) its about a ~2 hour "project" and i'm willing to put $100usd into it , we can take it private if your intrested ( this is a gpl'd cms and i would like the code to also be released gpl etc so it has a chance to make it upstream )
[23:58] <ajmitch> imbrandon: ok