[00:20] <wgrant> abentley, bac: Can you please land my branches that you reviewed? They're all Soyuz-approved™.
[02:04] <abentley> wgrant, I'm not currently able to run the test suite to completion.
[02:05] <wgrant> abentley: Urgh. Anyway, mwhudson has EC2ed them.
[02:05] <abentley> mwhudson, thanks!
[02:05] <abentley> wgrant, wait-- do you mean that they've been tested but mwhudson isn't landing them.
[02:05] <abentley> ?
[02:06] <wgrant> abentley: They are in the process of landing through ec2.
[02:06] <abentley> wgrant, cool.
[03:59] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/package-branch-listing-speedup/+merge/22993 1070 lines
[03:59] <thumper> sorry
[04:07]  * thumper popping out to get real coffee and drop off some children's dvds back to the video store
[04:07] <StevenK> thumper: The question is, who watched them?
[04:08] <thumper> StevenK: I watched a part of the black stallion, but not all, nor the sequal
[04:11] <wgrant> Is it just me, or does download-cache only have a 2.6 x86_64 meliae egg, and not a 2.6 i386 one?
[04:18] <StevenK> Sigh, devkit-disks, I hate you.
[04:19] <StevenK> Why does it only mount Mass Storage devices *sometimes*
[04:19] <wgrant> StevenK: Isn't that one of DX's new decisions?
[04:20] <StevenK> Oooh, bitter much
[04:20] <wgrant> Well, "why not" is enough rationale.
[04:21]  * StevenK puts his fingers in his ears and says Lalalalala a lot
[04:22] <wgrant> Heh.
[06:28] <jtv> mwhudson: hi, any news on allow-import-password?
[06:28] <mwhudson> jtv: no, got kind of sidetracked
[11:13] <noodles775> jelmer: do you want to take a look at james_w' branch first? (it's a non-soyuz one ;) ), otherwise I'll jump right in.
[11:14] <james_w> it's rather simple :-)
[11:14] <noodles775> Oh, I was going by the line count before you resolved the conflicts :)
[11:14] <noodles775> jelmer: nm.
[11:14] <noodles775> lol
[11:14] <noodles775> r=me
[11:15] <james_w> thanks
[11:15] <james_w> please twiddle the knobs and I'll throw it at ec2
[11:15] <noodles775> Done.
[11:15] <james_w> and I need to use [testfix], correct?
[11:17] <noodles775> Yep, `bzr log --limit 50 | grep testfix` will show you an eg or two.
[11:19] <james_w> thanks
[11:19] <james_w> sent
[11:19]  * james_w just used --textfix
[11:19]  * noodles775 didn't know about that option... great.
[13:36] <bac> wgrant: is mwhudson landing all of your approved branches or do you need me to help?
[13:45] <wgrant> bac: They're all approved and all but one is tested, but PQM rejected three of them due to testfix.
[13:47] <bac> wgrant: i'll be glad to help but i don't want to duplicate effort.  why don't you send me an email with the URLs of the MPs and what you need me to do for each.  please copy noodles775 and mwhudson.
[13:47] <bac> i'll then land them when we're out of testfix
[13:50] <jml> ... which should be any moment now-
[14:24] <noodles775> bac, wgrant : I've sent off ~wgrant/launchpad/bug-549907-stop-using-slave-build-id a few hours ago too.
[14:25] <noodles775> (still playing)
[14:28]  * bac wishes he could send a branch off for testing and landing from the MP page
[14:56] <wgrant> PQM is alive?
[14:59] <wgrant> If it is... can someone please land https://code.edge.launchpad.net/~wgrant/launchpad/bug-538844-master-side/+merge/22681, https://code.edge.launchpad.net/~wgrant/launchpad/more-buildmaster-cleanup/+merge/22735 and https://code.edge.launchpad.net/~wgrant/launchpad/remove-dbnote/+merge/22736? They all passed ec2test a few hours ago (with the current devel rev), but were rejected by PQM.
[15:03] <noodles775> Sure. Hrm, how do I land something *not* via ec2, without branching?
[15:03]  * noodles775 looks at ec2 land code.
[15:05] <wgrant> noodles775: bzr lp-land, maybe?
[15:06] <noodles775> wgrant: yep, was just reading bzr help lp-land, thanks!
[15:06] <wgrant> Not sure if that handles generating the [r=foo] stuff, though.
[15:07] <noodles775> ugh, bzr: ERROR: exceptions.ValueError: Cannot determine Bazaar host. "https://api.edge.launchpad.net/beta/" not a recognized Launchpad API root.
[15:08] <wgrant> Yay, version-naïve code.
[15:08]  * noodles775 updates pqm plugin
[15:10] <noodles775> OK, that helped, but now it complains about lacking revisions... I'm guessing lp-land still requires a local branch?
[15:10] <noodles775> bzr: ERROR: Public branch "bzr+ssh://bazaar.launchpad.net/~wgrant/launchpad/bug-538844-master-side" lacks revision<EMAIL_ADDRESS>[15:10]  * noodles775 branches and tries.
[19:58] <rockstar> abentley, can you do a review (maybe two) for me?
[19:59] <abentley> rockstar, sure.  Working up the description for my merge request right now.
[20:01] <rockstar> abentley, great.
[20:04] <rockstar> abentley, here's the easy one: https://code.edge.launchpad.net/~rockstar/launchpad/ihasrecipes-person/+merge/23045
[20:04] <rockstar> abentley, the next one still needs changes since I'm not making DistroSeries implement IHasRecipes
[20:09] <abentley> rockstar, I recommend using lp-propose (née lp-submit) and the lp_review_body plugin.
[20:11] <rockstar> abentley, yeah, I've been meaning to set that up.
[20:12] <abentley> rockstar, maybe I'll walk you through that on our next call.
[20:13] <abentley> rockstar, test_person_implements_hasbranches looks misnamed.
[20:14] <abentley> rockstar, similarly test_product_implements_hasbranches
[20:15] <abentley> rockstar, test_product_getRecipes comment looks wrong.
[20:16] <abentley> rockstar, docstring in lib/lp/registry/model/product.py is wrong.
[20:17] <rockstar> abentley, argh. c-n-p errors...
[20:18] <abentley> rockstar, originally you were going to try adaptation, right?  What problems did you run into with that?
[20:19] <rockstar> abentley, the fact that I wanted to get something done and not fart around with zope oddities.
[20:21] <rockstar> The docstring was a thinko, not a c-n-p error.  *facepalm*
[20:21] <abentley> rockstar, adding coupling between Person and Recipe seems like tech debt.  could you file a bug to reexamine it?
[20:22] <rockstar> abentley, what do you mean "adding coupling" ?
[20:22] <abentley> rockstar, Person (and Product, I guess) now have to know what a Recipe is.
[20:23] <abentley> There is a dependency now that wasn't there before.
[20:23] <rockstar> abentley, yeah, I guess you're right.  I'll file a bug and say "let's think about adapters again"
[20:23] <abentley> rockstar, cool.
[20:23] <rockstar> abentley, by that reasoning though, IHasBranches should probably also be an adapter.
[20:24] <abentley> rockstar, yes, there should be an adapter for Person that provides IHasBranches.
[20:25] <rockstar> abentley, yeah, I bet that would happen more often if zope wasn't stingy.  :)
[20:25] <abentley> rockstar, at least in the ideal, registry doesn't depend on us and we don't depend on other apps like Soyuz.
[20:26]  * rockstar nods
[20:26] <sinzui> abentley, yes, and we must do better at decoupling the features
[20:27] <rockstar> sinzui, we aren't in the habit of it.  I think that's what the problem really is.
[20:27] <abentley> rockstar, could you ping me when you've updated those doc errors?
[20:27] <rockstar> We haven't really focused on not coupling features.
[20:27] <sinzui> rockstar, indeed. It is easier to see the problem now that we have separate trees
[20:27] <rockstar> abentley, pushed, waiting for scanner...
[20:27] <rockstar> sinzui, yeah, that is helpful.
[20:28] <abentley> rockstar, cool.  I'll watch it then.
[20:28] <rockstar> It would probably reduce the risk of circular imports by an order of magnitude also.
[20:33] <rockstar> abentley, just noticed one of the comments is still wrong...  :/
[20:35]  * rockstar waits for scanner again.
[20:43] <rockstar> abentley, alright, everything should be kosher now.
[20:44] <abentley> rockstar, looking...
[20:46] <abentley> rockstar, products can have sourcepackage branches, but your product.getRecipes() doesn't include them, right?
[20:47] <rockstar> abentley, good question.  I have no idea.
[20:47] <rockstar> abentley, I was under the assumption that querying the Branch table would bring them all in.
[20:47] <rockstar> If that's not the case, "eep."
[20:48] <abentley> I don't think it would do that.
[20:48] <abentley> I thought you were deliberately excluding them.
[20:48] <rockstar> abentley, I don't know why I would deliberately exclude them.
[20:48] <abentley> AIUI, sourcepackagebranches do not necessarily have a product.
[20:48] <rockstar> abentley, ah, well, in that case, they wouldn't come up associated with the product then.
[20:48] <abentley> You need to have a link between the sourcepackage and the product.
[20:49] <abentley> And then to find sourcepackagebranches, you'd need to find the branches whose sourcepackage was linked to that product.
[20:49] <rockstar> abentley, hm, I question whether or not it matters then.  If the source package doesn't have a product, than it shouldn't show up by product anyway.
[20:49] <rockstar> I suspect we'll probably want related recipes for a source package, but I wasn't going to implement that until someone wanted it.
[20:50] <abentley> rockstar, if you want to exclude sourcepackagebranches for now, you need to tweak your comment slightly.
[20:51] <abentley> "IProduct.recipes should provide all the SourcePackageRecipes attached to that product." => "IProduct.recipes should provide all the SourcePackageRecipes attached to that product's branches"
[20:51] <rockstar> abentley, Sure.
[20:51] <rockstar> abentley, done.
[20:52] <abentley> rockstar, r=me.
[20:52] <rockstar> abentley, cheers.
[21:35] <abentley> rockstar, could you please review https://code.edge.launchpad.net/~abentley/launchpad/answer-ordering/+merge/23050?
[21:36] <abentley> rockstar, Also, request-build is ready for review: https://code.edge.launchpad.net/~abentley/launchpad/request-build/+merge/22570
[21:37] <rockstar> abentley, gotcha.  I'm on it.
[21:37] <rockstar> abentley, r=me on the ordering one, looking at the other one now.
[21:39] <rockstar> abentley, what's up with pylint now?
[21:40] <abentley> rockstar, I don't know.
[21:40] <rockstar> abentley, I wonder why we still have pylint when it never seems to do anything but give us false positives.


[06:53] <KGB-1> gnome-2048 Kushagra Karira 295493 * commented merge request !1 * https://salsa.debian.org/gnome-team/gnome-2048/-/merge_requests/1#note_295493
[07:14] <oSoMoN> good morning desktoppers
[07:16] <jibel> morning all
[07:16] <duflu> Hi oSoMoN and jibel
[07:20] <oSoMoN> salut jibel, hey duflu
[07:30] <jibel> Hey duflu oSoMoN
[07:51] <jpnurmi> good morning
[08:03] <seb128> goood morning desktopers!
[08:06] <didrocks> good morning
[08:07] <duflu> Hi seb128 and didrocks
[08:08] <didrocks> hey duflu
[08:09] <jibel> salut didrocks seb128
[08:09] <jibel> and jpnurmi
[08:10] <jpnurmi> hey oSoMoN jibel duflu seb128 didrocks :)
[08:10] <duflu> Hi jpnurmi
[08:12] <didrocks> salut jibel, hey jpnurmi
[08:18] <seb128> hey didrocks duflu jibel oSoMoN jpnurmi, how are you?
[08:19] <duflu> seb128, not bad. Did another interview today and the weather is finally great. How are you?
[08:19] <seb128> duflu, I'm alright thanks!
[08:19] <didrocks> I’m good thanks, cold but sunny :)
[08:20] <seb128> cold and sunny is the best weather :)
[08:20] <seb128> for winter at least
[08:21] <didrocks> yep!
[08:21] <duflu> Yeah best weather for exploring new places too
[08:24] <Nafallo> morning
[08:25] <didrocks> hey Nafallo
[08:25] <duflu> Morning Nafallo
[08:30] <oSoMoN> good morning jpnurmi, seb128, didrocks, Nafallo
[08:35] <didrocks> hey oSoMoN
[12:59] <jbicha> good morning
[13:05] <oSoMoN> hey jbicha
[13:10] <jbicha> hi :)
[13:10] <Nafallo> hey jbicha :-)
[13:16] <KGB-0> gnome-2048 Jeremy Bicha 295516 * commented merge request !1 * https://deb.li/3dz1j
[13:39] <KGB-0> gjs signed tags f90aeac Jeremy Bicha upstream/1.70.1 * Upstream version 1.70.1 * https://deb.li/WEI0
[13:40] <KGB-0> gjs upstream/latest 369342f Jeremy Bicha * pushed 8 commits (first 5 follow) * https://deb.li/ijzSF
[13:40] <KGB-0> gjs upstream/latest 5344e57 Philip Chimento meson.build * build: Post-release version bump * https://deb.li/Azai
[13:40] <KGB-0> gjs upstream/latest b9e1220 Evan Miller gi/arg.cpp * arg: Replace gsize with size_t * https://deb.li/306Hh
[13:40] <KGB-0> gjs upstream/latest 3e0f64b Simon McVittie installed-tests/js/meson.build * installed-tests: Install matchers.js * https://deb.li/d6en
[13:40] <KGB-0> gjs upstream/latest 62025d4 Evan Welsh gi/ arg.cpp arg.h function.cpp * Handle optional out parameters in callbacks * https://deb.li/3YEQ7
[13:41] <KGB-0> gjs upstream/latest 01cd32b Simon McVittie meson.build * build: Link with libatomic if necessary * https://deb.li/34QuU
[13:41] <KGB-0> gjs pristine-tar 280f0e0 Jeremy Bicha gjs_1.70.1.orig.tar.xz.delta gjs_1.70.1.orig.tar.xz.id * pristine-tar data for gjs_1.70.1.orig.tar.xz * https://deb.li/iEb1
[15:03] <seb128> hey there
[15:03] <seb128> kenvandine, want to review the rls bugs?
[15:03] <kenvandine> yes!
[15:03] <seb128> let's do it!
[15:03] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html
[15:04] <seb128> bug #1954970 we discussed and said we should target it but I forgot to nominate
[15:05] <seb128> there is a bunch of those, I will clean those up a bit later
[15:05] <seb128> the alsa and bluez ones
[15:05] <seb128> bug #1959596
[15:05] <seb128> I think we should accept it since we install systemd-oomd now
[15:07] <seb128> k, let's assume kenvandine agrees and moving on
[15:07] <kenvandine> agreed
[15:07] <seb128> https://bugs.launchpad.net/ubuntu/+source/libnma/+bug/1955944
[15:08] <seb128> that's an obvious one and there is a patch, I will sponsor it after the review
[15:08] <seb128> and that's it for j incoming
[15:08] <kenvandine> great
[15:08] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html
[15:08] <seb128> bug #http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html
[15:08] <seb128> ups
[15:08] <seb128> bug #1956434
[15:09] <seb128> I don't really know about that component but the patch and rational seem to make sense, I will review it for sponsoring
[15:09] <seb128> and that's it for J
[15:09] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html
[15:10] <seb128> only a bluez one already assigned, I will untag
[15:10] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-tracking-bug-tasks.html
[15:10] <seb128> nothing really interesting that we didn't discuss previously there
[15:11] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[15:11] <seb128> same bluez one
[15:11] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[15:11] <kenvandine> ok
[15:11] <seb128> nothing new there
[15:12] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[15:12] <seb128> no desktop section
[15:12] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html#
[15:12] <seb128> nothing new there
[15:12] <seb128> and I think that's it
[15:13] <seb128> I will try to clean up the noise really for next week, I said that a few times but usually do some and then get sidetracked and forget to finish
[15:13] <kenvandine> great, thanks!
[15:13] <seb128> kenvandine, thanks!
[21:08] <KGB-0> gnome-control-center Robert Ancell 295598 * commented merge request !22 * https://deb.li/im1e


[03:44] <sarnold> sudip: probably the launchpad team doesn't know much about that service; if you can file a bug on https://bugs.launchpad.net/britney/+filebug it'll be less likely to be overlooked
[12:53] <cjwatson> sudip,sarnold: or ask on #ubuntu-release
[21:27] <sarnold> cjwatson,sudip, ahh good point re: #ubuntu-release, thanks
[21:28] <sudip> thanks sarnold cjwatson, will ask on #ubuntu-release next week, I think people are still on holiday. :)
[21:30] <sarnold> hopefully :) I'm just here to see if the world is on fire
[21:33] <arraybolt3> when was the world last *not* on fire? :)
[21:44] <sarnold> well, okay, a part of the world that I can influence :)
[22:37] <nelgin> Hi there. I have downloaded a source and debian.xz patch file from launchpad. I want to apply the patches and compile, however I'm not sure how to do that. I saw something about using quilt push but it complains about not being able to find the files.


[12:10] <crimsun> ah, that would explain why this firmware is loaded in Dapper whereas I have to wait a tick before hotplugging the sound device in Edgy
[12:10] <crimsun> I'll just have to fix the loader then
[01:04] <zul> Keybuk: is it possible to remove xen-3.0.2+hg9697-1 from the archive?
[02:45] <Keybuk> zul: the particular version?
[02:46] <Keybuk> when a package is removed ... it can't come back
[02:47] <zul> Keybuk: yes that version, i have a new one to be uploaded that works for edgy
[02:47] <Keybuk> just upload the new version then
[02:48] <Keybuk> it'll supersede the old one
[02:48] <zul> im keeping getting rejects sayint that new version is older than the one in the archive
[02:49] <Keybuk> right, what version are you uploading?
[02:49] <zul> gimme a sec
[02:49] <Keybuk> I only see xen 2.0.6-1 in the archive
[02:49] <zul> trxen-3.0_3.0.2+20060724_source.upload
[02:50] <zul> sorry...
[02:50] <zul> xen-3.0_3.0.2+20060724_source.upload
[02:50] <Keybuk> right
[02:50] <Keybuk> that version is older than the one in the archive
[02:50] <zul> hmm...ok
[02:50] <Keybuk> 3.0.2+20060724 < 3.0.2+hg9697-1
[02:50] <Keybuk> because "+" < "+hg"
[02:51] <Keybuk> why the change in version number?  why not use the +hgNNNN format again?
[02:51] <zul> ah ok...so should it be 3.0.2-20060724?
[02:51] <Keybuk> no
[02:51] <Keybuk> it should be 3.0.2+hg(number bigger than 9697)-1
[02:52] <zul> so 3.0.2+hg11127-1
[02:52] <Keybuk> right
[02:52] <zul> ok ill do that
[02:52] <zul> thanks
[02:52] <Keybuk> 11127 > 9697 ... so you win
[02:52] <Keybuk> unless you have a very good reason, stick to the version numbering in the archive
[02:52] <Keybuk> even if you disagree with it
[02:52] <zul> ok
[03:03] <lifeless> Keybuk: around ?
[03:10] <Keybuk> lifeless: yup
[03:13] <lifeless> can you eyeball this quickly -
[03:13] <lifeless> https://launchpad.net/products/launchpad/+bug/53698
[03:14] <lifeless> its a discussion about a change to dyson, it tried to register a cvs snapshot of grass
[03:14] <lifeless> which failed the upstream version number format check. But more interestingly, cvs snapshots are not that interesting, so we're considering how to get it to not register that
[03:15] <Keybuk> lifeless: it's more of a single e-mail than a discussion
[03:15] <lifeless> I'd just like your thoughts on it
[03:15] <Keybuk> don't really have any
[03:15] <lifeless> ok, fair enough.
[03:15] <Keybuk> I agree that it doesn't make sense to import cvs snapshots
[02:43] <zul> hi
[09:59] <crimsun> Keybuk: RE: the mount-by-UUID conversion: Does it handle [read-only]  NTFS mounts?
[09:59] <Keybuk> why wouldn't it?
[10:00] <crimsun> well, it appears to have correctly converted it, but I'm uncertain about the actual writing of the UUID
[10:01] <crimsun> for reference:
[10:01] <crimsun> # /dev/sda1 -- converted during upgrade to edgy
[10:01] <crimsun> UUID=58E475CEE475AEBE /media/sda1 ntfs umask=022,nls=utf8,users 0 0
[10:01] <crimsun> but /media/sda1 is empty after a reboot
[10:02] <Kamion> doesn't look like a proper UUID
[10:02] <crimsun> hmm, true, the others are of the form '11f6ccb2-f5bd-4d3b-87cc-c6fe260023fd'
[10:03] <crimsun> so that incorrect UUID is from ``/sbin/vol_id -u /dev/sda1''
[10:07] <Keybuk> Kamion: that's what NTFS uuids seem to look like
[10:08] <Keybuk> quest scott% ls /dev/disk/by-uuid
[10:08] <Keybuk> 2b4dde85-714c-42fa-b43f-02af9c64dc4b@  7d074f9a-80e7-4f0c-89aa-8efa8366766a@
[10:08] <Keybuk> 43DB-3ADE@                             C84C0C3A4C0C25B2@
[10:08] <Keybuk> of course, vol_id could be on the cock, but it shouldn't matter given things just convert to /dev/disk/by-uuid anyway
[10:08] <Keybuk> crimsun: does "mount" claim it's mounted?
[10:08] <crimsun> Keybuk: no
[10:09] <Keybuk> of course, the interesting thing is whether mount can support those uuids :)
[10:12] <Keybuk>  * For now, only ext2, ext3, xfs, ocfs, ocfs2, reiserfs, swap are supported
[10:12] <Keybuk> "no"
[10:12] <crimsun> right, "no such partition found"
[10:12] <Keybuk> http://lists.opensuse.org/archive/opensuse-commit/2006-Jun/0412.html
[10:13] <Keybuk> lamont: how much would you hurt me?
[10:13] <mjg59> No jfs?
[10:13] <lamont> Keybuk: what is that adding?
[10:14] <Keybuk> lamont: it replaces mount's current "find the uuid" code with calls to libvolume_id
[10:14] <Keybuk> (well it's got the code to do that in it, anyway)
[10:15] <lamont> if the patch is reasonably clean, and libvolume_id is reasonable sane (rather than full of festering security vuls), I'd be happy to include it in debian, too.  Then again, I need to corner you sometime and figure out what the right answer is for my debian-issue that you were able to just smash through when you last branched util-linux for dapper....
[10:15] <lamont> of course, assuming that it works with the existing stuff as well, rather than forcing user changes.... :-)
[10:15] <Keybuk> what's the debian issue?
[10:15] <lamont> hwclock.sh
[10:16] <Keybuk> oh, which one?
[10:16] <Keybuk> hwclock.sh is a zillion issues all to itself
[10:16] <lamont> we need to set the clock before we load the modules so that we can mount /usr so that we can get the TZ to set the clock.
[10:16] <Keybuk> that's not entirely true
[10:16] <Keybuk> you need to set the clock before you run depmod
[10:17] <Keybuk> not "load the modules"
[10:17] <lamont> right
[10:17] <lamont> and actually, modules startup doesn't run depmod anymore
[10:17] <lamont> (the bug in question is the front of the #debian-devel topic...)
[10:17] <lamont> 342887\
[10:18] <Keybuk> yeah. it's amazing how Debian stop arguing once Ubuntu has gone ahead and changed it anyway
[10:18] <lamont> yep
[10:18] <Keybuk> so hwclock.sh is an annoying case:
[10:18] <Keybuk> it DOES need to run before dhclient
[10:18] <lamont> it helped that someone else was doing bootchart type stuff and discoverd that depmod takes _FOREVER_
[10:18] <Keybuk> yet needs /dev/rtc, which udev creates
[10:19] <Keybuk> heh, we noticed that 6 months ago!
[10:19] <lamont> yep
[10:19] <lamont> I think debian noticed that it took much longer to boot debian than ubuntu....
[10:19] <Keybuk> it takes less time to boot a clean debian than ubuntu
[10:19] <Keybuk> because they support less crazy fabbione shit
[10:19] <Keybuk> (yay, edgy's dropped it all)
[10:19] <lamont> yeah fabbione! :-0)
[10:21] <lamont> the simple solution to the /dev/rtc thing is to quit compiling it as a module... if the hardware is there, you want it.
[10:22] <Keybuk> yes
[10:22] <fabbione> Keybuk: we can do that too.. install lvm and raid stuff only on demand.. we just never did it :)
[10:22] <lamont> fabbione: fix that. kthxbye
[10:22] <lamont> (CONFIG_RTC that is)
[10:22] <fabbione> lamont: what arch?
[10:22] <lamont> arch: any
[10:23] <fabbione> how do you want it? M or Y or just fix the driver?
[10:23] <fabbione> the latter i accept patches :)
[10:23] <lamont> it's an architecture independant fact that I need the RTC available before we do stuff.
[10:23] <lamont> =Y
[10:23] <lamont> it's very tiny, you see....
[10:23] <fabbione> lamont: ok i will talk to Ben and Kamion
[10:23] <fabbione> yup
[10:24] <fabbione> but CONFIG_RTC is not available on all arches as it is iirc
[10:24] <lamont> oh, well, just on the architectures where there is something that (uniquely) provides /dev/rtc
[10:25] <fabbione> i will look at it
[10:25] <lamont> better yet - just change Kconfig to force it on when it can. :-)
[10:25] <fabbione> ehehe
[10:25] <lamont> oh, that'll probably be an ABI bump, of course...
[10:25] <fabbione> no big deal on edgy
[10:26] <lamont> of course, I want it in etch
[10:26] <lamont> and edgy. :-)
[10:26] <fabbione> etch i can't do nothing.. file  a bug on those kernel guys
[10:26] <fabbione> but there will be people objecting to it for another 398398439 reasons
[10:26] <Kamion> there are some arches where there are multiple possible providers of /dev/rtc, aren't there?
[10:27] <Kamion> so you might have to deal with the problem anyway :(
[10:27] <fabbione> Kamion: i am not sure..
[10:28] <Kamion> hmm, there's a whole drivers/rtc/ tree now with rtc-dev.ko and stuff, so maybe that's been fixed
[10:28] <fabbione> i think Al Viro was working on a generic rtc implementation across all arches
[10:28] <fabbione> or there was at least
[10:28] <fabbione> no idea if it's fixed in .17
[10:29] <fabbione> we can always do it the old good way
[10:38] <lamont> Keybuk: if the volume_id patch looks sane, pls file a bug against the debian util-linux package with a pointer, and I'll merge it in
[10:43] <Keybuk> lamont: hmm, looking through the code, mount is using libblkid
[10:43] <lamont> yes
[10:43] <lamont> and before that, it used it's own random guessing techniques
[10:53] <fabbione> except the code in libblkid is a copy or almost of the one in util-linux :)
[11:36] <lamont> fabbione: not my problem :-)
[11:42] <mjg59> Keybuk: http://lkml.org/lkml/2006/7/25/280 ?
[11:49] <Keybuk> mjg59: interesting


[05:18] <markwalt> Hiya
[05:26] <valorie> hello markwalt
[05:29] <markwalt> What's new?
[05:41] <valorie> linuxfest nw is coming up
[05:41] <valorie> wrote to the list about it recently
[05:42] <markwalt> Hrm.  I don't seem to have anything in my email with "linuxfest" in it.  I must not be signed up on that list.  Can you point me to it?
[05:43] <valorie> https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-wa
[05:51] <markwalt> Thanks, I signed up
[05:51] <valorie> cool
[05:52] <valorie> you can see the sparse previous posts in the archives
[05:54] <markwalt> Yeah, I was just reading February's archive
[05:55] <valorie> :-)
[05:57] <markwalt> Pidgin does *not* make the best IRC client.
[06:01] <markwalt> better
[06:02] <markwalt> Pidgin was clunky and weird.  X-chat seems more like my style.
[06:28] <valorie> well, I'm a KDE user, and my favorite is Konversation
[06:28] <valorie> never liked xchat
[06:28] <valorie> not pidgin either
[06:31] <markwalt> xchat seems okay, I'm still getting used to it.
[06:32] <markwalt> I haven't been on IRC in over 15 years.  And back when I was regularly using it, I used mIRC or PIRCH, on Windows.  xchat reminds me a bit of mIRC, I guess.
[06:33] <valorie> mirc was my favorite on Win, yes
[06:33] <valorie> I absolutely love konvi though
[06:34] <markwalt> I'm running XCFE.  Konversation is probably usable in XFCE.  I might try it.
[06:39] <valorie> certainly, you can use any application in the archives
[06:39] <valorie> xubuntu is great
[06:39] <markwalt> I like Xubuntu a lot
[06:41] <valorie> we should all be happy with our tools, IMO
[06:41] <valorie> I say this sometimes: it's software, not religion
[06:43] <markwalt> Tell that to Reddit
[06:45] <valorie> I pretty much stay off there
[06:45] <valorie> women are not treated will there, in general
[06:46] <markwalt> I've noticed that.  The place is pretty anti-feminist, which is weird, because it's also fairly liberal.  I guess it's mostly liberal jerks.
[06:47] <valorie> no idea, but critiquing feminism is one thing
[06:47] <valorie> trolling women is another entirely