[12:37] <norsetto_> g'night all
[12:47] <alvinc> hey folks.  i'm trying to debmirror gutsy.  can someone recommend me a good source?
[12:47] <alvinc> archive.ubuntu.com doesn't seem to have Release files setup.  i haven't looked that closely alas
[12:50] <lamont> slangasek: binaries that land after release (or whatever - when the archive is locked down in LP) are SOL
[12:50] <lamont> Fujitsu: has happened before
[12:52] <lamont> slangasek: hppa got all of main (win).  universe is, um, universe...
[12:52] <lamont> if people have gutsy/hppa universe packages that they really want to see in the archive, I'm happy to bump those to the head of the universe queue
[12:53] <lamont> then again, I don't think many people care about hppa
[12:54] <superm1> lamont, how come hppa is so far behind?
[12:57] <lamont> superm1: because it started building about 2 weeks ago
[12:57] <lamont> maybe 3.
[12:57] <lamont> two buildds -> 5 weeks or so to build everything.  The non-LP archive is sitting at somewhere around 97% on graph2
[12:59] <imbrandon> non-LP archive ?
[12:59] <lamont> imbrandon: deb http://people.ubuntu.com/~lamont/hppa/gutsy-stage0 main restricted universe multiverse
[12:59] <lamont> see also gutsy-stage0.hppa.png
[01:00] <lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy2-short-nohppa.png is more readable than http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy2-short.png for the other architectures
[01:00] <TheMuso> /c/c~
[01:00] <TheMuso> ugh
[01:00] <imbrandon> ahh
[01:01] <lamont> gutsy-stage0 has been slowly getting overwritten with debs from LP
[01:01] <lamont> (as I smash them into that archive)
[01:01] <imbrandon> heh
[02:27] <zul> hey imbrandon
[02:30] <imbrandon> heya zul
[02:37] <bddebian> Heya gang
[02:55] <bddebian> They TheMuso, Hobbsee
[02:57] <Hobbsee> hiya
[02:59] <therethinker> is there a PDF of the Debian Policy Manual?
[02:59] <zul> dont think so
[03:00] <therethinker> found it
[03:00] <therethinker> http://www.debian.org/doc/debian-policy/policy.pdf.gz
[03:00] <gnrfan> therethinker: yeap those docs are in PDF always too
[03:01] <therethinker> Thanks :-)
[03:34] <Hobbsee> oh, hardy's not in there yet?
[03:34] <persia> Hobbsee: It doesn't seem to be.  Do you have the magic powers required to poke the appropriate people?
[03:35] <Hobbsee> nto at this time of day
[03:35] <Hobbsee> and not when i'm heading out
[03:36] <Hobbsee> not sure who the appropriate ppl are yet, tbh
[03:40] <LaserJock> persia: have you looked for a bug report about that?
[03:40] <Hobbsee> wont be a point doing a lp bug on it
[03:40] <Hobbsee> it'll be a -drivers thing, i think
[03:40] <persia> LaserJock: Not yet.  Does that work?
[03:40] <LaserJock> Hobbsee: you think?
[03:40] <LaserJock> I suppose that Hardy just needs to be created
[03:41] <StevenK> I daresay Hardy will turn up soonish, after people have finished stressing about Gutsy
[03:41] <Hobbsee> that'd be my guess, too
[03:41] <LaserJock> but a "future" milestone should work, no?
[03:41] <StevenK> There's a 'later' milestone, right?
[03:41] <persia> StevenK: Right.  On the other hand, for bug management purposes, it'd be nice to be able to open a CVE bug, and mark that it not only needs to be fixed for hardy, but that we need to roll it back to gutsy as well.
[03:45] <ScottK> speaking of CVE's...  Someone who has some time might want to look into Bug #152738 and see about *-security fixes for Feisty and however far back it needs to go.  I got the new version in Gutsy just under the wire.
[03:45] <ubotu> Launchpad bug 152738 in knowledgeroot "UVFe [CVE-2007-5156]  disable uploads of unknown filetypes" [Medium,Fix released]  https://launchpad.net/bugs/152738
[04:01] <TheMuso> c
[04:01] <TheMuso> wrong window again...
[04:10] <superm1> TheMuso, i've been using virtualbox so much that i catch myself pressing <right-ctrl> to leave Xchat windows :)
[04:12] <TheMuso> superm1: lol
[04:26] <StevenK> Sigh. Must remember if I ctrl-c tail -f, I *don't* end up killing the process that is logging.
[04:31] <TheMuso> heh
[04:33] <mertiki> Hello everyone, I fixed a bug which affect the Gutsy user interface in Qt3 apps and the maintainer of the package uploaded the patch. The only problem is that the fixed package isn't in the repositories and if Gutsy is released without that fixed package, it will be released with a folder with too restrictives permissions so it will be pretty more complicate to fix
[04:33] <mertiki> Does somebody can help around this ?
[04:33] <mertiki> Bug #145709
[04:33] <ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 ~/.qt owner root and missing qtrc result result in ugly appearance" [Undecided,Fix committed]  https://launchpad.net/bugs/145709
[04:33] <imbrandon> mertiki: when was it uploaded and by who ?
[04:34] <Hobbsee> imbrandon: that'll be by Riddell
[04:34] <mertiki> By Jonathan Riddell, 3 days ago
[04:34] <imbrandon> mertiki: then i'm sure it will be taken care of, its just waiting in the queue i'm sure
[04:34] <imbrandon> heya Hobbsee
[04:34] <ScottK> LaserJock: I thought the LP people said that the launchpad janitor bugs were all going to be reverted, but it's apparently started running again and is invaliding more bug.
[04:35] <Hobbsee> hiya
[04:35] <mertiki> imbradon : thanks, I wanted to make sure has I know the importance of that bug :)
[04:35] <ScottK> bug/bugs
[04:35] <LaserJock> ScottK: yeah, I got a couple new ones
[04:35] <ScottK> I don't think they've reverted anything and are continuing to close bugs.
[04:35] <LaserJock> I wonder if they were trying to fix something
[04:35] <persia> Perhaps the reversion has been delayed until the 24th, along with the other LP updates?
[04:36] <ScottK> Yes, but it was supposed to be stopped and reverted.
[04:36] <ScottK> That was what we were told.
[04:36] <ScottK> What has happened is the opposite.
[04:36] <ScottK> More bugs getting closed.
[04:36] <Hobbsee> no, it got rejected.
[04:36] <persia> ScottK: #launchpad might have a reason
[04:36] <LaserJock> yeah, they were going to test stuff first
[04:36] <Hobbsee> LaserJock: heh, how useful
[04:37] <mertiki> Hobbsee : The Riddell package got rejected?
[04:37] <ScottK> persia: LaserJock is our liaison and stuff and I'm not at my polite best when talking with LP developers.  I thought it might be better to ask him to look into it.
[04:37] <Hobbsee> mertiki: yes
[04:37] <LaserJock> ScottK: will do
[04:37] <persia> ScottK: Ah.  Yes.  Good point :)
[04:37] <ScottK> LaserJock: Thanks.
[04:37] <persia> LaserJock: Did you never find anyone else to liaison?
[04:37] <LaserJock> I planned on talking with kiko about it
[04:37] <LaserJock> I noticed that I got a couple of bugs
[04:38] <Hobbsee> LaserJock: he's on holidays for 2 weeks
[04:38] <mertiki> Hobbsee : Hum that's bad, can I do something to help around that? Because if Gutsy is released without that fix, all Qt3 apps will look ugly with big fonts
[04:38] <Hobbsee> mertiki: trying to find out why it was rejected.
[04:38] <mertiki> Hobbsee : Thanks
[04:39] <mertiki> the problem with the qt3 bugs is that the /etc/qt3 folder actually exist in Gutsy but has very low permissions, so if the package is fixed, it won't install properly because of that folder with wrong permissions
[04:41] <mertiki> That's why I suggest fixing that bug before the stable release or the problems will be more complicate to fix just by update
[04:41] <Hobbsee> mertiki: i cant do much until the europeans wake up, until i've found out who's rejected it, and why.
[04:41] <Hobbsee> and that wont happen for another ~10 hours.
[04:41] <ScottK> mertiki: For the release, what's done is done.
[04:42] <mertiki> ScottK : Ok.. the release candidate means that it's too late?
[04:44] <mertiki> Anyway, thanks a lot for your work on this. If you want more information about that bug, I wrote detailed reasons in the comment 7 of the LP : 145709
[04:44] <Hobbsee> mertiki: um, no?  we have more stuff going in after the RC.
[04:45] <persia> (but no more going in after Archive Freeze)
[04:45] <ScottK> mertiki: No, but the archive is pretty frozen right now.
[04:45] <mertiki> Ok I understand :)
[04:46] <mertiki> Does somebody knows when the Hardy repositories will open ?
[04:46] <TheMuso> WHenever they open.
[04:47] <mertiki> that's a good answer :P
[04:47] <TheMuso> As in, who knows.
[04:47] <mertiki> Hum ok! Thanks
[04:48] <Hobbsee> mertiki: few weeks after gutsy
[04:48] <mertiki> Ok !
[04:48] <mertiki> I go to bed now, @+ and thanks everyone
[04:49] <Hobbsee> mertiki: it was because it was far too late, they want to upsh it to -updates
[04:49] <ajmitch> hello
[04:49] <persia> ajmitch: Hi!
[04:50] <bddebian> Heya persia, ajmitch
[04:50] <mertiki> Hobbsee : Ok! Too bad I found the problem this late, anyway, thanks again
[04:51] <TheMuso> Youch dbian import freeze is early...
[04:51] <TheMuso> Or has it always been that early in the cycle?
[04:52] <mertiki> Hobbsee : One last thing : I think that my patch won't be enough to fix the problem if it's not released with Gutsy, so further work will have to be done on this.
[04:52] <Hobbsee> mertiki: tell slangasek that when he wakes up.  he and Riddell made that decision
[04:53] <mertiki> Hobbsee: I will
[04:53] <TheMuso> And it looks like the toolchain should be ready by next thursday, according to that schedule.
[04:54] <persia> mertiki: Do you mean the permissions issue or the missing configuration issue?  The latter is fairly easy to workaround with the right scripts (although harder than the current state).
[05:00] <ajmitch> persia: maybe because hardy is LTS, so less time to import debian crack
[05:00] <persia> ajmitch:That sounds ideal to me: see my new agenda item for Friday
[05:01] <ajmitch> I see
[05:03] <TheMuso> persia: Aye, good item.
[05:04] <ScottK> persia: As part of your preparation for discussing that item, I'd suggest making sure you are familiar with pitti's proposed (and now planned AFAIK) simplified freeze structure.
[05:05] <persia> ScottK: Documentation pointer?
[05:06] <Hobbsee> hm, there's an idea.
[05:06] <Hobbsee> link?  :)
[05:07] <ScottK> persia: https://wiki.ubuntu.com/UbuntuDevelopment#head-93c8a38bbc124f5d34af970893deffc4bc91700e
[05:07] <persia> Hobbsee: https://wiki.ubuntu.com/MOTU/Meetings
[05:08] <ScottK> persia: First message in the thread: https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024278.html
[05:08] <Hobbsee> thanks.  i'm lazy
[05:09] <persia> ScottK: I'm actually in agreement with merging FeatureFreeze, UpstreamVersionFreeze, and NewPackagesUniverseFreeze all into "Feature Freeze".  I just want it to happen extra early for hardy - it's more work for motu-uvf, but we should have a better chance of fixing all the FTBFS, unmetdeps, etc. before release.
[05:10] <imbrandon> ugh, and now it starts, people upgrading before its ready http://digg.com/linux_unix/Upgrading_to_Ubuntu_7_10_NOW_before_the_rush
[05:10] <ajmitch> imbrandon: that's expected
[05:10] <ajmitch> no doubt the motu-uvf team will happily cope
[05:10] <ScottK> persia: OK.  I think what pitti proposed is now the baseline from which we should discuss any Universe unique changes.
[05:10] <persia> ScottK: I'm not opposed, but I'd rather have the discussion Friday.
[05:11] <ScottK> Right.  Just wanted to make sure you were aware.
[05:11] <persia> For now, I'm basing it on the draft Hardy release schedule, as the most official document I could find.
[05:12] <Hobbsee> ajmitch: you're on the council. you trump all o fus.
[05:12] <persia> imbrandon: Now that everything (except OOo for sparc) is accepted, is there really any harm in users pulling an update?  I thought we were just building CDs and preparing support infrasrtucture at this point.
[05:12] <ajmitch> Hobbsee: for now
[05:12] <Hobbsee> ajmitch: oh, you're quitting too?
[05:12] <ajmitch> Hobbsee: and how can you say that, being on both archive & release teams?
[05:12] <Hobbsee> persia: i doubt that's final, or anywhere near it yet.  there's usually a BOF about such things
[05:13] <Hobbsee> ajmitch: easily - just because i'm on those teams doesnt mean that i have access - or access that i'm allowed to use
[05:13] <persia> Hobbsee: Completely understood.  I'm hoping we can get consensus on some Universe matters as input to the BOF
[05:13] <ajmitch> just because I'm on the MC doesn't mean that I can do anything apart from smile & say nice things about people applying for MOTU
[05:14] <persia> ajmitch: You could scowl and say unpleasant things.
[05:14] <ajmitch> nor do I expect to be around on voip for UDS
[05:14] <bluefoxicy> ajmitch:  how do you think I feel?
[05:14] <ajmitch> bluefoxicy: do I care? :)
[05:15] <bluefoxicy> The maintainer of pax-utils asked me to update it to the latest version at the beginning of gutsy and I never did D:
[05:15] <bluefoxicy> err, the developer
[05:15] <Hobbsee> bluefoxicy: yes, but you suck.
[05:15] <bluefoxicy> apparently I'm the maintainer
[05:15] <Hobbsee> it's too late now, i'll just reject your upload.
[05:15] <bluefoxicy> Hobbsee:  Irrelevant!  Sucking has nothing to do with packaging!
[05:15] <bluefoxicy> Sucking is for cleaning things and drinking fountain sodas.
[05:17] <ajmitch> it probably won't
[05:17] <persia> Why shouldn't VoIP work?
[05:17] <ajmitch> it never has worked very well, usually due to poor microphones, noisy rooms, etc
[05:17] <ScottK> Because tcp/ip isn't designed for that kind of thing.
[05:18] <Hobbsee> ajmitch: the recent lot wasnt so bad, iirc
[05:19] <ajmitch> then it's just timezones that will hate me :)
[05:22] <bddebian> Wow is swi-prolog ugly
[05:23] <mdomsch> pardon my ignorance, but do I read StableReleaseUpdates to mean that after release, no new packages for a given release are added to universe?
[05:23] <ajmitch> mdomsch: correct
[05:24] <ajmitch> a release doesn't get added to, except via -backports which are unsupported
[05:24] <LaserJock> mdomsch: only specific, important bug fixes
[05:24] <Hobbsee> greetings, mdomsch
[05:24] <mdomsch> ok, that's good to know - and is different than my experience with other distros
[05:25] <mdomsch> good evening Hobbsee
[05:25] <Hobbsee> mdomsch: being dell, i've no idea if you can shove your fixes into -updates - whether the rules differ for you
[05:25] <ajmitch> no doubt there'll be some flexibility where required
[05:25] <mdomsch> I'm not looking to bend the rules (yet :-) - just understand them for now
[05:25] <Hobbsee> haha :)
[05:25] <ajmitch> rules are bent often enough around here
[05:26] <Hobbsee> oh, fricking hell.  why are people really lazy, and not checking if their packages install and upgrade?
[05:26] <bddebian> Say it isn't so.. :-)
[05:26] <Hobbsee> there's a hook in pbuilder, it's not that hard.
[05:29] <ajmitch> heh
[05:39] <TheMuso> Hobbsee: What package?
[05:39] <Hobbsee> TheMuso: yours, Adri2000's, open office
[05:40] <TheMuso> Hobbsee: They still causing problems?
[05:40] <Hobbsee> TheMuso: nah
[05:40] <Hobbsee> well, the ooo may well be
[05:41] <imbrandon> gnight
[05:41] <imbrandon> all
[05:41] <ajmitch> night imbrandon
[05:43] <bddebian> Gnight imbrandon
[05:50] <ScottK> mdomsch: I wonder if it would be useful to get stuff like DKMS into Debian proper and let Ubuntu import it from there?
[05:50] <mdomsch> ScottK, yes it would, however the road to being a DD is longer than the road to being a MOTU
[05:50] <mdomsch> and we're not shipping debian
[05:51] <mdomsch> so while I'm having a hard time getting a teammate to step up and become a MOTU
[05:51] <mdomsch> it's an even harder sell to have them spend time becoming a DD
[05:51] <Hobbsee> mdomsch: some people here are also DD's, adn therefore can sponsor, if that's a help
[05:51] <Hobbsee> mdomsch: what, you dont want to be the only one doing it?  :)
[05:52] <mdomsch> that I'm doing it indicates my whip isn't long enough to reach the right people :-)
[05:52] <mdomsch> but it's fun to learn too
[05:52] <Hobbsee> mdomsch: ahh, so you're one of the high up ones?  i see.
[05:53] <mdomsch> ++ungood
[05:53] <mdomsch> yeah, I've been here longest of anyone doing Linux
[05:53] <ajmitch> that's expected, since Provides is for virtual packages
[05:54] <Hobbsee> mdomsch: ah, interesting.
[05:54] <mdomsch> so we've got BIOS payload packags
[05:54] <mdomsch> in RPM right now
[05:54] <Hobbsee> mdomsch: here works.  either's fairly quiet, and we cant upload random crack now anyway
[05:55] <mdomsch> in RPM we say package name is system_bios_ven_0x1028_dev_0x01a8, version is A08
[05:55] <mdomsch> then later, we learn that dev_0x01a8 is really marketing name for "Precision 380"
[05:55] <Hobbsee> because giving out sane names is really quite boring :)
[05:55] <mdomsch> so, in the RPM we change the name to system_bios_Precision_380, and obsolete and provide the old name and version
[05:57] <persia> mdomsch: You could use versioned conflicts: and replaces: to the old name, and a new upload of the old package that has versioned depends on the new package, just to force upgrades.
[05:57] <mdomsch> I don't want to force upgrades, I want them to happen naturally (e.g. when version A09 is out and pacakged with the new name)
[05:58] <mdomsch> I think because it's a one-time rename, it'll work out
[05:58] <persia> mdomsch:  Right, and you want to use a new source name, correct?
[05:58] <mdomsch> right
[05:58] <persia> So, BIOS_S3kret-1 is just a normal package.
[05:58] <bddebian> heh
[05:59] <Hobbsee> surely that should go in -partner?  :P
[05:59] <persia> BIOS_Release_name conflicts and replaces BIOS_S3kret <= 1
[05:59] <mdomsch> yes
[06:00] <persia> BIOS_S3kret-2 is a meta-package only depending on BIOS_Release_name
[06:00] <persia> So, those who installed BIOS_S3kret get the updates, which are all managed in BIOS_Release_name.  Those who installed BIOS_Release_name never had any issues.
[06:01] <persia> Ah.  Right.  Of course.  It should be BIOS_S3kret-0.72-1.  Sorry for the confusion.
[06:01] <Hobbsee> persia: is the -2 part of the name of the source here?  or is that version?
[06:01] <mdomsch> ok, and I still need BIOS_Release_name to Provide something
[06:01] <Hobbsee> mdomsch: no you dont - conflicts adn replaces do that.  you dont need provides at all - unless i'm misreading you.
[06:01] <mdomsch> because in fact we ask apt for the virtual package
[06:01] <persia> mdomsch: It can provide BIOS_S3kret.
[06:01] <mdomsch> yes
[06:02] <mdomsch> that will work
[06:02] <persia> And when you update OEM-settings-meta, you can change the depends.
[06:02] <Hobbsee> persia: please tell me that you're working around the apt bug that happens when multiple packages provide teh same package.
[06:03] <persia> Thinking, I agree with Hobbsee: skip the provides.  The update to OEM-settings-meta should do the job nicely, and conflicts/depends is clean.
[06:03] <Hobbsee> persia: s/depends/replaces/?
[06:03] <persia> Hobbsee: No.  Just working around an attempt to use versioned provides
[06:03] <Hobbsee> persia: right, but you do want to avoid the apt bug as well.
[06:03] <Hobbsee> (causes lovely things like bibletime to be installed in arabic, by default)
[06:04] <persia> good conflicts bad, meta update changes depends (I should have written conflicts/replaces/depends)
[06:04] <mdomsch> http://pastebin.domsch.com/11 shows an example of what we pass to apt-get install
[06:04] <Hobbsee> persia: ah right
[06:04] <persia> Hobbsee: That only happens with | - not an issue when the meta-package depends on a real package.
[06:05] <persia> Those are all package names?
[06:05] <joejaxx> persia: with the blank triggers for dpkg are those executed everytime dpkg runs instead of an individual package? or are they just there
[06:06] <Hobbsee> persia: unsure where the | comes into it, but yes, it'd be depended on a virtualpackage, i see.
[06:06] <mdomsch> persia, those are virtual provides in RPMs, yes
[06:06] <joejaxx> instead of being triggered by an individual package*
[06:06] <persia> joejaxx: You're imagining I have a slightly better understanding than I do :)
[06:06] <persia> My base understanding is that they are managed by particular packages, but the ldconfig wrapper script makes lots of packages use triggers.
[06:07] <persia> mdomsch: OK.  So the RPM Provides: all the listed packages (with names like "pci_firmware(ven_0x8086_dev_0x27d8_subven_0x1028_subdev_0x01a8)/system(ven_0x1028_dev_0x01a8)")?
[06:07] <mdomsch> yes
[06:07] <joejaxx> persia: i am wondering what the blank triggers are for if they do not specify any packages in them :)
[06:07] <persia> Ah.  That looked like a function call rather than a package name :)
[06:08] <mdomsch> yum install $(inventory_firmware -b) finds the highest versioned package that Provides those things
[06:08] <mdomsch> acts similar to apt-get -m install ...
[06:09] <persia> You could do it with provides for all the names, but you'd just be polluting the namespace, in my opinion.  What generalised behaviour do you seek from OEM-settings-meta?
[06:09] <mdomsch> persia, right now we've got system BIOS for 240+ systems available in RPMs
[06:09] <mdomsch> so you can do
[06:09] <mdomsch> yum install $(inventory_firmware -b)
[06:09] <mdomsch> update_firmware
[06:10] <mdomsch> and it downloads the latest firmware for your system, and installs it
[06:10] <mdomsch> http://linux.dell.com/firmware-tools/
[06:10] <persia> Ah.  So inventory_firmware -b checks the state of the local HW to build the list of names, and then looks for the packages (named whatever) that provide the named values in order to install the correct updated firmware?
[06:10] <mdomsch> has papers etc on the whole firmware-tools thing
[06:10] <mdomsch> bingo
[06:12] <mdomsch> I'm trying to get this into debs now
[06:12] <mdomsch> 2/3 of the way done
[06:12] <mdomsch> firmware-tools and firmware-addon-dell packages are pretty much done
[06:12] <joejaxx> anyone else know what the blank dpkg triggers do? :)
[06:12] <mdomsch> now I'm working on the template for the bios payload files
[06:12] <persia> Right.  Just add unversioned provides of BIOS_S3kret to BIOS_Release, and do versioned conflicts/replaces on BIOS/S3kret in BIOS_Release.  apt / aptitude / libept will do the right thing.  I'd also advise uploading post-name-change BIOS_S3kret binaries that depend on the appropriate BIOS_Release, just to be clean.
[06:12] <mdomsch> persia, got it, thanks!
[06:14] <Hobbsee> mdomsch: stupid question, but are you intending to get this in for gutsy?
[06:14] <persia> mdomsch: If you could also do an update of firmware-tools-data to change the mapping between raw hex codes and desired packages to match the new names, it would be extra nice, but that may be harder to keep in sync.
[06:14] <mdomsch> Hobbsee, no
[06:14] <mdomsch> Hobbsee, if my minions had finished the work they started in May, yes
[06:14] <Hobbsee> mdomsch: oh good, just checking
[06:14] <Hobbsee> (yay, minions)
[06:15] <joejaxx> lol
[06:15] <mdomsch> persia, http://linux.dell.com/repo/firmware will be exactly that
[06:15] <mdomsch> persia, that exists for RPMs today, will add debs soon as this works
[06:16] <Hobbsee> mdomsch: have you thought about pushing this to -partner?
[06:16] <mdomsch> we've also got a repo/software, into which we'll put our own stuff that didn't make gutsy
[06:16] <Hobbsee> mdomsch: so you can get it in for gutsy (later?)
[06:16] <persia> mdomsch.  That's really clean.  Are you pre-feeding the signing keys, etc.?
[06:16] <ajmitch> Hobbsee: you have your stick, no need for a whip as well
[06:16] <mdomsch> Hobbsee, not sure, I haven't heard of -partner
[06:16] <Hobbsee> mdomsch: it's the old commercial, but i've no idea of it's status.
[06:16] <mdomsch> persia, not sure how to do the pre-feeding yet - just figured out how to create and sign a repo
[06:16] <Hobbsee> s/commercial/-commercial/
[06:17] <mdomsch> I'm fine with putting them on linux.dell.com - it's fast and easy
[06:17] <Hobbsee> mdomsch: might want to stick it in a ppa, too, so you dont have to do your own repo.  oh wait, you cant sign them that wya.
[06:17] <mdomsch> I have to sign all the payload debs anyhow with Dell's key
[06:17] <Hobbsee> hm
[06:17] <Hobbsee> yeah
[06:17] <persia> mdomsch: I don't have as much knowledge about oem-install as I'd like, but I think you want to make sure that apt knows about the key used to sign the bios repository by default, as otherwise users will be given a security warning.
[06:17] <mdomsch> apt-key add foo
[06:18] <mdomsch> ok, I'll remind our folks to do that
[06:18] <Hobbsee> mdomsch: oh, i see.  yes, that's a pain, then, because you cant sign it with the ubuntu archive key.
[06:18] <mdomsch> michael brown is working on the installer
[06:18] <persia> Sure, but you have to run that on install.  When you do that it actually populates a text file somewhere, which could probably be prestuffed into your CD/image/whatever
[06:20] <mdomsch> yeah - he can make it apt-get add ourkeyfiles
[06:20] <mdomsch> that's a good idea, I hadn't gotten there yet
[06:20] <mdomsch> I just figured out the signing thing 30 minutes ago
[06:21] <StevenK> The signing thing is complicated at best anyway
[06:21] <Hobbsee> persia: you're meaning about preseeding ubiquity?
[06:21] <StevenK> (Bloody impossible at worst)
[06:21] <mdomsch> it's not too bad as long as your directory structure matches what apt-ftparchive and apt-get expect
[06:21] <mdomsch> if it doesn't (and mine didn't for a while), you're hozed
[06:22] <persia> Hobbsee: Something like that: I thought oem-install was a little more flexible (although I'm not by any means an expert)
[06:22] <Hobbsee> persia: ah, i might be confusing migration-assistant and oem-install, seeing as the recent discussions have been on the former
[06:23] <Hobbsee> mdomsch: for hardy and beyond, are you adding files to our cds, or are you remastering our cds, and adding dell stuff?
[06:23] <Hobbsee> mdomsch: (and what stuff is added on the dell cds now anyway?)
[06:24] <mdomsch> Hobbsee, I believe everything we need is in gutsy now :-)
[06:24] <mdomsch> we've been filing issues and getting stuff in and fixed
[06:24] <mdomsch> we'll continue to do that
[06:24] <Hobbsee> mdomsch: oh neat!  so what did you end up doing when you first did ubuntu on the dells?
[06:25] <Hobbsee> cd image-wise.
[06:25] <mdomsch> like right now, we only have 1 add-on module - for our modems, so we drop that in factory-installed, and post on the web
[06:25] <bddebian> Gnight folks
[06:25] <mdomsch> nothing at first cd image-wise
[06:25] <Hobbsee> right
[06:25] <mdomsch> just the stock CDs
[06:25] <Hobbsee> interesting.
[06:25] <mdomsch> then after a bit we had to respin the CDs to fix 3 drivers needed at install time
[06:26] <mdomsch> because driver disks at install never worked - they do now in gutsy
[06:26] <ajmitch> no doubt it'd take awhile before linux on dells is available here
[06:26] <Hobbsee> ajmitch: they'll come to us, before they come to you.  we're bigger :P
[06:26] <mdomsch> ajmitch, you're where?
[06:27] <ajmitch> NZ
[06:27] <persia> ajmitch: Just pay the tax, and point at the repo mentioned above :)
[06:27] <mdomsch> we're getting there - slowly...
[06:27] <Hobbsee> mdomsch: but au first, right?
[06:27] <ajmitch> persia: can't be bothered :)
[06:27] <ajmitch> I probably won't replace my laptop for at least a year or so
[06:27] <mdomsch> I don't honestly know who's next
[06:28] <ajmitch> I didn't expect you would know the mind of the marketing & sales people :)
[06:28] <Hobbsee> ajmitch: that depends on hwo far his whip extends
[06:28] <Hobbsee> ajmitch: and on that note, please, can i have my whip back, and my big piece of concrete?
[06:28] <ajmitch> ok
[06:29] <LaserJock> wha?
[06:29] <LaserJock> you can't do that
[06:29] <Hobbsee> thankyou
[06:29] <ajmitch> LaserJock: she'll beat me up otherwise!
[06:29] <Hobbsee> persia: oh, i do occasionally at wokr :P
[06:29] <persia> ajmitch: You have to get the stick first
[06:29] <LaserJock> ajmitch: that's why you steal her point stick of DOOM
[06:29] <mdomsch> must sleep
[06:29] <mdomsch> thanks for the pointers tonight
[06:29] <Hobbsee> mdomsch: you found the crazy-land, methinks.
[06:29] <ajmitch> night mdomsch :)
[06:31] <ajmitch> bye Hobbsee :)
[06:31] <LaserJock> persia: super ultra government secret
[06:31] <persia> Ahh...
[06:34] <ajmitch> LaserJock: then why are you telling us about it?
[06:34] <LaserJock> oohhh, right
[06:34] <LaserJock> hmmm
[06:35] <LaserJock> now everybody look over here!
[06:35] <StevenK> If it's US government issue, it won't work ...
[06:35] <LaserJock> dang it, no batteries
[06:35] <ajmitch> StevenK: but everyone knows that the us government has covered up countless conspiracies
[06:37] <persia> I expressly disclaim having covered anything up during the period I certainly wasn't working for the US government
[06:46] <luk_> so you kind of agree that you were covering things up while you were working for the US government? :-)
[06:49] <persia> luk_: I prefer to think of it as a wordy "no comment"
[06:56] <shirish> Hi all, no programmer here, just somebody who's curious/interested to know stuff about debian/rules & make
[06:57] <shirish> persia there is , I've read it but still couple of things are not clear to me.
[06:58] <persia> shirish: Which page doesn't include the complete answer?
[06:58] <shirish> persia: it may have but I'm trouble understanding the same. https://help.ubuntu.com/6.06/ubuntu/packagingguide/C/basic-scratch.html
[06:59] <persia> OK.  Which part don't you understand?
[06:59] <shirish> I'm trying to understand the binary-arch section therein
[07:00] <persia> The binary-arch rule is called to construct an architecture-specific .deb file for the source.
[07:00] <shirish> persia: for e.g. I have an p4 i386 architecture, so if I wanted to compile a program so it builds for my specific machine, is there a specific way to do that? Also can I give some sort of flag to make so it compiles specifically for my system
[07:01] <shirish> persia: sorry if the question is confusing, I'm confused ;)
[07:01] <persia> The build system should autopopulate your build archicture (I think it's $DEB_BUILD_ARCH), so you don't have to do anything special.
[07:03] <persia> shirish: You might get more information from http://doc.ubuntu.com/ubuntu/packagingguide/C/ch04.html
[07:03] <shirish> persia: thanx a lot ;)
[07:09] <imbrandon> ldd /usr/bin/AbiWord-2.4
[07:09] <imbrandon> err
[07:10] <jdong> linux-gate.so.1 => (0xffffe0000)
[07:10] <jdong> ;-)
[07:10] <persia> imbrandon: You just need to install the right bot :)
[07:10] <imbrandon> heh
[07:10] <imbrandon> talk about chan spam
[07:10] <imbrandon> persia: i'm tinkering with that idea we had the other night
[07:10] <imbrandon> cant sleep
[07:10] <imbrandon> lol
[07:11] <persia> imbrandon: The maintainer-in-a-box idea?
[07:11] <imbrandon> yea
[07:11] <persia> How's progress?
[07:12] <imbrandon> throwing togather some simple bash scripts to do it first, just kinda a proof of concept type thing
[07:12] <TheMuso> imbrandon: Whats the idea?
[07:12] <TheMuso> 3~/c
[07:12] <TheMuso> ugh
[07:13] <imbrandon> TheMuso: a GUI something between a live MOTU and checkinstall
[07:13] <imbrandon> fist step add proper dependancy resolution to checkinstall
[07:13] <imbrandon> ;)
[07:13] <TheMuso> imbrandon: Um...
[07:13] <TheMuso> imbrandon: Why?
[07:13] <jdong> imbrandon: so something like dh_make on steroids?
[07:14] <persia> TheMuso: This isn't something we would use, but something to suggest in preference to checkinstall for upstreams / getdeb crack addicts
[07:14] <ajmitch> TheMuso: he likes crack
[07:14] <TheMuso> persia: Ah ok.
[07:14] <imbrandon> exactly
[07:14] <persia> Also, if we had support scripts that could accurately test things like "Are the dependencies correct", we'd have stronger QA in general.
[07:15] <TheMuso> Dep checking is something that *has* to be done by hand IMO.
[07:15] <TheMuso> Short of already having a built binary to get shlibs info from.
[07:15] <TheMuso> Even then...
[07:15] <pwnguin> bingo
[07:15] <persia> TheMuso: Why?  If you can determine the target language, and you have all the correct build-deps installed at test time, can't you ust trace?
[07:16] <persia> s/ust/just/
[07:16] <jdong> TheMuso: you can also probably use some form of inotify/strace-on-open() hooked up to apt-file search
[07:16] <TheMuso> persia: I guess so, but I still don't like the idea.
[07:16] <persia> TheMuso: Why not?  Is checkinstall better?
[07:16] <TheMuso> persia: Of course not, but afaik it doesn't do dep checking.
[07:16] <imbrandon> TheMuso: thats the idea, build it fist localy , check deps, make chroot, get deps build clean , all auto
[07:17] <persia> jdong: That sounds painful :(
[07:17] <imbrandon> and 99% likely upstream will be building it localy and have the deps installed to begin with, and thats the target
[07:17] <pwnguin> instead of the developer identifying build deps explicitly, they set up their build, and then apt-file hits some massive search
[07:18] <pwnguin> you'd need both
[07:18] <pwnguin> ldd into apt-file
[07:18] <persia> pwnguin: Why?  The tool is intended for upstreams.  They already have everything installed.
[07:19] <pwnguin> because check install already does that crap
[07:19] <imbrandon> checkinstall dosent
[07:19] <imbrandon> it dose no dep check whats so ever
[07:19] <jdong> checkinstall does nothing but put installed files into a data.tar.gz
[07:19] <pwnguin> thats what i mean
[07:19] <jdong> while imbrandon's idea can potentially generate like 95% debian source packages
[07:19] <jdong> 95% correct
[07:20] <persia> pwnguin: The idea is to pre-populate the control file
[07:20] <pwnguin> i know
[07:20] <pwnguin> ldd tells you which libraries you need. apt-file tells you which libraries are in which package. seems simple to me
[07:21] <imbrandon> something similar to `ldd /some/bin|cut -f 2 -d "blah"|apt-file search -`
[07:21] <pwnguin> however
[07:21] <pwnguin> ldd isn't nessecarily the entire story on build deps i dont think
[07:21] <jdong> pwnguin: strace/inotify would be :D
[07:22] <TheMuso> Which gives you a list of the shared libs a binary is linked against, and no deeper.
[07:22] <pwnguin> jdong: i'd bet it grabs /etc/passwd :P
[07:22] <jdong> pwnguin: also we can have simple static heuristics on what libfoo translates to what libfoo-dev
[07:22] <TheMuso> whereas ldd gives you the lot.
[07:22] <imbrandon> TheMuso: nice
[07:23] <jdong> imbrandon: have you fired this idea off to a mailing list yet? I think it'd be really cool to discuss
[07:24] <imbrandon> jdong: yea i'm writing a spec too, just craping out some proof of concept scripts first
[07:24] <jdong> awesome
[07:24] <TheMuso> imbrandon: You going to be at UDS
[07:25] <persia> TheMuso: That's much cleaner.  Thanks.
[07:25] <imbrandon> TheMuso: trying to get there, jorge is working on some $$ options
[07:25] <TheMuso> persia: np.
[07:26] <TheMuso> One could always look at how dh_shlibs does it.
[07:26] <TheMuso> dh_shlibdeps even
[07:27] <TheMuso> ah it uses dpkg--shlibdeps
[07:27] <persia> TheMuso: And then just use grep-dctrl to get the appropriate -dev for the linked libraries?
[07:28] <TheMuso> persia: I guess so.
[07:28] <imbrandon> brandon@hood:~/files/easybuild$ apt-file search libz.so.1
[07:28] <imbrandon> lib64z1: usr/lib64/libz.so.1
[07:28] <imbrandon> lib64z1: usr/lib64/libz.so.1.2.3.3
[07:28] <imbrandon> zlib1g: usr/lib/libz.so.1
[07:28] <imbrandon> zlib1g: usr/lib/libz.so.1.2.3.3
[07:28] <imbrandon> hrm
[07:28] <imbrandon> more than one
[07:29] <persia> imbrandon: perhaps local heuristics to never use lib64 or lib32 by default?  While it's sometimes correct, it seems like a special case.
[07:30] <persia> TheMuso: You have deep envy for the /usr/lib32/ directory?
[07:30] <TheMuso> persia: At least to learn about all that kinda stuff re 32/64 libs, etc.
[07:31] <TheMuso> And, I desire a multi-core CPU for development/audio work.
[07:31] <persia> TheMuso: Ah.  Makes sense.
[07:32] <persia> The Muso: what sort of contention are you reaching now?  Depending on your workload, you may be as well served by two faster cores.
[07:33] <TheMuso> persia: Yeah, thats what I'm trying to weigh up.
[07:34] <imbrandon> persia: hrm why not just use something like `mkdir debian && dpkg-shlibdeps /usr/bin/AbiWord-2.4 && cd debian/ && cat substvars``
[07:34] <persia> TheMuso: Another way to ask the question is how many virtual synths / effects you plan to run.  If it's >= 5, you probably want quad.
[07:35] <TheMuso> persia: Thats the thing, it may be a few, as there are some VST plugins that look really nice, particularly Native Instrument's Hamond plugin.
[07:38] <persia> imbrandon: Hrm.  Maybe.  I'm thinking more in-context, so that you'd be in a maintainers directory, and you'd have prepopulated most of debian/ so you will be generating substvars as part of the first cycle build (if you've detected a language that requires this).  It's more taking the output of substvars & getting the right -dev packages for build-depends.
[07:39] <persia> (otherwise, it's just {shlibs:Depends}
[07:39] <persia> )
[07:40] <imbrandon> hrm true
[07:41] <persia> TheMuso: quad is probably good, although depending on your budget, you might consider that the kernel supports Kore
[07:41] <imbrandon> crap , what about things like autotools etc that are only build-deps not runtime deps ?
[07:42] <TheMuso> persia: kore?
[07:42] <persia> TheMuso: Native Instruments Kore : outboard VST host with USB control
[07:43] <persia> imbrandon: You'll need heaps of heuristics.  Autotools is easy when compared to properly differentiating all the scripting languages, and grabbing their internal dependency information (at least python, perl, and ruby make this a little easier)
[07:44] <imbrandon> right
[07:45] <pkern_> persia: re yesterday: Should I setup a debcheck for hardy?
[07:46] <pkern> ScottK: Do you remember the nick of the person who wanted to test the firehol SRU?  He already installed the version out of proposed and confused me with it, but in the end confirmed on IRC *only* that it worked correctly.
[07:47] <TheMuso> persia: ooooo
[07:47] <persia> pkern: I think Fujitsu is running that.  I thought we were talking about FTBFS detection.
[07:47] <StevenK> persia: Right.
[07:48] <persia> TheMuso: Yep.  I don't know if the Kore VSTs work with linux hosts, but at least the USB driver is in the kernel.
[07:49] <TheMuso> persia: So the kore hardware uses different type of VST plugins?
[07:50] <persia> TheMuso: There are special "Kore" version VSTs that mimic the standard GUIs and use the Kore for processing.  If hosting those doesn't work directly, one can treat it as an outboard synth with USB audio, but that's not as interactive.
[07:50] <TheMuso> right.
[07:52] <pkern> persia: Both, in fact.  Both unmetdeps and FTBFS must be resolved to ensure consistency of the distribution.  Do you happen to know if there is some public URL of Fujitsu's instance?
[07:53] <TheMuso> persia: Thats only useful if I was using heaps of VSTs. I'd likely only use 1, if not 2.
[07:54] <persia> TheMuso: Huh?  Offboard hosts means less onboard cores.
[07:54] <TheMuso> persia: It needs a software app to run it.
[07:55] <TheMuso> Or does it actually use the external hardware to do the DSP?
[07:55] <TheMuso> Nevertheless, you do need to run the app on your machine to use it.
[07:55] <persia> TheMuso: It actually uses the hardware DSP, and it has an offline mode, so if you load the synths, you can drive it with MIDI alone.
[07:55] <TheMuso> Right.
[07:56] <TheMuso> Anyway, I'll keep it in mind.
[07:56] <persia> pkern: https://lists.ubuntu.com/archives/ubuntu-motu/2007-August/002045.html represents my latest knowledge of the existing tools.
[07:57] <persia> Umm..  Except the RC bugs list moved to django.ajmitch.net.nz/rcbugs/
[08:02] <TheMuso> c
[08:02] <TheMuso> argh
[08:06] <pkern> persia: Hm.  FTBFS bugs on Debian are filed by the buildd maints pretty reliably. On LP the go pretty much unnoticed (for synced universe packages).  We have that information in LP +builds but don't use it?
[08:07] <persia> pkern: That's half the issue.  The other half is detecting packages that have not tried to build during the current release cycle (sometimes we go > 1 year between compilations, and unsuprisingly find the package now FTBFS)
[08:09] <pkern> persia: Right.
[08:09] <pkern> persia: But then all this information is *currently* not easily retrievable from LP.
[08:10] <persia> pkern: Right.  If you can come up with some good ideas about a possible UI, preparing a draft spec for MOTU review and eventual submission to LP would be great.
[08:10] <persia> Alternately, if you can determine a way to scrape it from the current interface (or email lists + repo data) and show it external, that works as well.
[08:14] <pkern> I WON'T SCRAPE, DAMN IT.
[08:14] <pkern> Sorry. \:
[08:16] <persia> pkern: That's probably better anyway :)  I think there might be some text or xml exports available (you'd want to ask someone more informed) that might make it less painful to use LP as a service, in case that makes a difference.
[08:30] <imbrandon> hrm is there no /etc/inittab in ubuntu
[08:31] <Fujitsu> imbrandon: Not since we moved to upstart.
[08:31] <imbrandon> ugh ok, whats the qequiv ?
[08:31] <imbrandon> equiv?
[08:31] <Amaranth> /etc/event.d/?
[08:32] <Fujitsu> Something in there, probably.
[08:32] <Amaranth> rcS is the one that drives the legacy boot
[08:33] <Amaranth> I don't think an inittab equivalent exists
[08:33] <Fujitsu> imbrandon: What are you looking to change?
[08:33] <imbrandon> the tty1 spawn
[08:33] <imbrandon> i got it
[08:34] <Fujitsu> imbrandon: Ah, yeah.
[08:34] <imbrandon> /sbin/getty -n -l /usr/local/sbin/autologin 38400 tty1
[08:34] <imbrandon> err
[08:34] <imbrandon> yea
[08:35] <imbrandon> lets hope i dont screw the pooch on this one
[08:35] <imbrandon> heh
[08:35] <imbrandon> \untested code
[08:35] <Amaranth> Well, you always have tty2 :P
[08:36] <imbrandon> :)
[08:36] <imbrandon> true
[08:37] <imbrandon> made a little C app to autologin tty1 , then bash_profile to startx and xinit to startfluxbox
[08:37] <imbrandon> lol
[08:37] <imbrandon> all to get rid of gdm and autologin
[08:37] <imbrandon> shesh
[08:38] <imbrandon> but with 64mb ram, i need to have as little running as possible ;)
[08:38] <imbrandon> ok anyhow, back in a few ( if it works )
[08:38] <persia> imbrandon: xdm is a little lighter, if you like...
[08:39] <imbrandon> persia: yea if this dont work thats the next thing
[08:39] <imbrandon> bbiab
[08:40] <dholbach> good morning
[08:40] <dholbach> hey imbrandon
[08:40] <TheMuso> Hey dholbach.
[08:40] <imbrandon> heya dholbach , rebooting brb
[08:40] <dholbach> hey TheMuso
[08:41] <persia> Could someone in -security (or wherever one must be) please mark bug #152964 as public?
[08:41] <ubotu> Bug 152964 on http://launchpad.net/bugs/152964 is private
[08:42] <pkern> Package declares a build time dependency on aolserver4-dev (>= 4.0+cvs20040121-2) which cannot be satisfied on powerpc. aolserver4-dev (>= 4.0+cvs20040121-2) 4.5.0-10ubuntu1 is available.
[08:42] <TheMuso> StevenK: Did you get my PM?
[08:42] <pkern> That debcheck is broken somehow.
[08:43] <Fujitsu> pkern: Is that mine?
[08:43] <persia> pkern: That was true 24 hours ago.  The fix just went in overnight.
[08:44] <pkern> Fujitsu: Yes.
[08:45] <pkern> persia: Point is rather debcheck borkage. I don't care about that information. The package obviously isn't broken if a sufficient package is available.
[08:45] <Fujitsu> Um, woah, something is really broken.
[08:45] <Fujitsu> 879 unmetdeps on all archs? I doubt it.
[08:45] <pkern> Fujitsu: Indeed.
[08:45] <persia> pkern: 4.5.0-10ubuntu1 could not be installed
[08:45] <Fujitsu> persia: It doesn't check that.
[08:45] <pkern> Then take http://alt.qeuni.net/~william/debcheck/debcheck.py?dist=gutsy&package=kdeutils
[08:45] <imbrandon> woot, from power button to fluxbox desktop with *no* interaction and no hickups
[08:46] <persia> Odd.  That was the problem.  Oh well...
[08:46] <persia> imbrandon: With menus too?
[08:46] <pkern> Fujitsu: It doesn't consider newer packages to be sufficient somehow, although it notices them.
[08:46] <imbrandon> persia: yup
[08:46] <imbrandon> ok nuff playing for me, night all
[08:47] <TheMuso> How often does the PPA publisher run?
[08:48] <StevenK> TheMuso: Yup, was just doing other work.
[08:48] <Fujitsu> TheMuso: Every 20 minutes.
[08:48] <Fujitsu> 0, 20, 40.
[08:48] <TheMuso> StevenK: np
[08:48] <TheMuso> Fujitsu: Thanks
[08:49] <TheMuso> StevenK: I just thought there was a problem along the way re freenode somewhere...
[08:49] <TheMuso> no hurry
[08:57] <Fujitsu> pkern: I think the machine it was running on ran out of RAM, which would mean the version comparison would always fail. Rerunning now...
[08:57] <Fujitsu> Bah, rsync on archive.ubuntu.com is really slow at the moment.
[08:58] <pkern> Fujitsu: So you really need a local mirror and Packages information is not sufficient?
[08:59] <Fujitsu> pkern: It only mirror dists/
[08:59] <Fujitsu> *mirrors
[08:59] <pkern> Fujitsu: Ah ok. I just fetch that with wget for sourcedeps.
[09:00] <pkern> BTW: Does Ubuntu enable pdiffs for released distributions? Probably not?
[09:01] <Fujitsu> pkern: Soyuz doesn't do them, so no.
[09:02] <Fujitsu> pkern: The debcheck run just finished - everything looks good.
[09:03] <pkern> Looks better, thanks.
[09:05] <pkern> And bunch of apache modules with broken depends because apache-dev 1.x is no longer available.
[09:05] <pkern> s/And/A/
[09:05] <pkern> Fujitsu: Looks not too bad overall.
[09:06] <Fujitsu> Yeah.
[09:06] <Fujitsu> Most of it is apache.
[09:06] <Fujitsu> (most of the breakage on every arch, that is)
[09:07] <pkern> The "Depends Main on !Main" part is also quite important because universe might be deactivated and aptitude will choke.
[09:07] <persia> Most of those seem to be Recommends.  I thought that was acceptable.
[09:08] <pkern> persia: Hm ok then.  I'd guess I'll have to try that out.
[09:08] <Fujitsu> It's not acceptable in Debian, and that's where I stole the code from :P
[09:08] <persia> Fujitsu: Is it acceptable for Ubuntu?
[09:09] <Fujitsu> persia: There's no policy... you'd have to ask somebody more powerful.
[09:10] <persia> Fujitsu: "powerful"?  Perhaps I could force a decision from them, but you seem to be a respository of all knowledge that has passed this channel since at least edgy (if not earlier)
[09:10] <Fujitsu> Hah. I don't deal with much main stuff, and I've never seen a policy on Recommends. If there's a lot of stuff in main that Recommends stuff elsewhere, then it's probably not against policy.
[09:11] <pkern> Hm, it looks good. Just tried tracker and aptitude just puts an unavailable stamp on the list.
[09:11] <pkern> i.e. you won't notice the missing recommends.
[09:11] <persia> Well, one might notice, but it's not actually deeply broken.
[09:12] <Fujitsu> anastacia does the main dependencies anyway.
[09:12] <TheMuso> c
[09:13] <pkern> anastacia?  That must be an Ubuntu girl, it's certainly not canonic (i.e. dak)! :-P
[09:13] <TheMuso> gah wrong tab
[09:13] <persia> pkern: She is.
[09:13] <Fujitsu> pkern: Yeah, anastactia and gina are the two new Ubuntu ones, IIRC.
[09:13] <Fujitsu> Bah, anastacia.
[09:16] <Fujitsu> persia: That seems unmodified from Debian... would it have Ubuntu ones in it?
[09:17] <pkern> Fujitsu: What does anastacia do?
[09:17] <persia> Fujitsu: Yep.  There's a shared effort to make sure names stay unique.  Given the specific personalities involved in dak management and Ubuntu archive management, I can understand the impulse.
[09:17] <Fujitsu> pkern: Checks that things in main don't depend on other components.
[09:18] <Fujitsu> And also notes if things are in main but not seeded or depended upon by other things.
[09:18] <Fujitsu> persia: Ah.
[09:18] <pkern> And generates component-mismatches.txt?
[09:20] <Fujitsu> pkern: That'd be it.
[09:23] <persia> Found it.  According to http://cvs.debian.org/dak/docs/README.names?rev=1.24&root=dak&view=auto, there are 9 Canonical tools
[09:24] <pkern> s/Canonical/canonical/?
[09:24] <persia> pkern: No.  "Canonical".
[09:24] <Fujitsu> Ah, right.
[09:24] <Fujitsu> Most of those are ooold.
[09:25] <Fujitsu> poppy is the Soyuz FTP server, I know that one..
[09:26] <persia> Fujitsu: Has Soyuz removed their identities as they are assimilated?
[09:26] <StevenK> Soyuz doesn't make use of dak, though - I thought they just took the general idea and implemented it themselves?
[09:27] <Fujitsu> persia: Pretty much.
[09:27] <Fujitsu> StevenK: That's right.
[09:27] <Fujitsu> And introduced gina in the process (imports non-Syuz distros into Soyuz, like -security)
[09:28] <persia> Gina?  Someone should stuff that into CVS.
[09:28] <Fujitsu> AFAIK, the only bits of dak being used at the moment are.. britney, for consistency checks, and the rest for -security.
[09:28] <persia> But we still use at least anastacia, bridget, gina, and poppy, no?
[09:29] <Fujitsu> What's bridget?
[09:29] <Fujitsu> poppy will be renamed soon :(
[09:30] <persia> Hrm.  bridget used to be mentioned on the wiki, but she's gone, so I presume she has become borg
[09:33] <persia> Fujitsu: Does that test against "restricted" as well?
[09:34] <Fujitsu> persia: No, I didn't bother to check for that, as so little is there. It's trivial to add, if you want.
[09:34] <persia> Fujitsu: I tend to chase RC bugs and oldlibs for QA stuff, but if it's trivial, it might be nice for debcheck people.
[09:46] <Fujitsu> persia: Done and rerun.
[09:49] <persia> Fujitsu: Thanks.  Even better, no changes jump out for attention :)
[09:49] <Fujitsu> Yep.
[09:50] <persia> So do all of these need bumping to multiverse?
[09:51] <persia> Also, http://alt.qeuni.net/~william/debcheck/debcheck.py?dist=gutsy&package=request%2dtracker3%2e4 confuses me when compared with the withinuniverse check
[09:52] <Fujitsu> They should be, yes. Most of them are related to cdrecord, it seems.
[09:52] <Fujitsu> I think there's a bug with the safety check if the package name has a `.'
[09:52] <persia> How do we do that?  Is it just lots of ~ubuntu-archive bugs?
[09:52] <Fujitsu> Or one bug with multiple tasks.
[10:05] <soren> persia: You don't mean "negative" rather than "decreasing"?
[10:05] <persia> soren: We haven't yet reached negative over periods longer than a week or so (as far as I can tell), but we're getting really close to 0.
[10:06] <soren> Really? I haven't been paying much attention to bug stats..
[10:06] <persia> Further, I think we'll go negative soon, given the improvement in tools, and the increased number of contributors.
[10:06] <persia> Best I can tell we reached ~20,000 last December, around ~30,000 in April, and are only around ~34,000 now.
[10:07] <soren> We rock! :)
[10:11] <Fujitsu> persia: UWN already publishes dB/dt.
[10:12] <persia> Fujitsu: I just keep seeing so many people commenting about us having 30,000 bugs.  Personally I think that's a good thing (because of dB/dt), but it doesn't seem externally perceived as such.
[10:14] <Fujitsu> Yeah.
[10:15] <Fujitsu> We had a big problem for a while, but it's certainly getting better.
[10:16] <persia> I think it was just the lack of a strong recruiting model for edgy - we had user growth, but less contributor growth.
[10:16] <geser> morning
[10:17] <Fujitsu> Hi geser.
[10:17] <geser> Hi Fujitsu
[10:18] <Fujitsu> persia: I've fixed the issue with package names with a `.' in them.
[10:18] <Fujitsu> The Perl script mangles them to `_', which the frontend didn't take into account.
[10:19] <persia> libapache-mod-fastcgi is in multiverse?
[10:19] <Fujitsu> fastcgi is non-free.
[10:19] <persia> Ahh...
[10:21] <persia> That's annoying.  It can be used, copied, modified, distributed, and sublicensed, but only to implement FastCGI.
[10:21] <Fujitsu> Haha.
[10:21] <persia> http://www.fastcgi.com/mod_fastcgi/docs/LICENSE.TERMS
[10:22] <Fujitsu> How stupid.
[10:22] <persia> It's so close to free that an ISC license would probably have offered stronger protection.
[10:24] <nxvl> hi!
[10:24] <Fujitsu> When did cdrecord and mkisofs head to multiverse? Weren't they the non-evil versions a while ago?
[10:25] <white> Fujitsu: stuff coming from cdrkit is good
[10:25] <white> rest is evil
[10:26] <Fujitsu> white: That's what I thought.
[10:27] <Fujitsu> Bah.
[10:27] <Fujitsu>  * no longer provide the dummy packages 'cdrecord', 'mkisofs' and
[10:27] <Fujitsu>     'cdda2wav', since we now have cdrtools in multiverse
[10:28] <Fujitsu> So we have all this lovely stuff that must be demoted.
[10:28] <persia> Fujitsu: Alternately you could revert that change :)
[10:29] <Fujitsu> I'm sure it was made for a reasonable reason in the first place.
[10:29] <Fujitsu> siretart: ^^
[10:30] <siretart> sorry?
[10:30] <Fujitsu> siretart: You removed the cdrecord dummy package from cdrkit.
[10:30] <Fujitsu> Why?
[10:30] <siretart> Fujitsu: cdrecord and mkisofs need to be in multiverse until the licencing discussion with the TB have been sorted out
[10:30] <siretart> Fujitsu: because we now ship both cdrkit (in main) and cdrtools (in multiverse).
[10:31] <persia> siretart: Isn't cdrecord licensed in a way that anyone in Germany gets sued?
[10:31] <Fujitsu> Is what's-his-name getting annoyed about us using his names?
[10:31] <siretart> persia: no it isn't
[10:31] <siretart> Fujitsu: no, he isn't
[10:31] <siretart> Fujitsu: I've been packaging his software in very close cooperation (as in several hours phone calls)
[10:31] <StevenK> Fujitsu: Schilling
[10:32] <Fujitsu> StevenK: I thought it was him, but wasn't quite sure.
[10:32] <siretart> :)
[10:32] <Fujitsu> Why exactly are we preferring that the non-free version?
[10:32] <Fujitsu> s/that //
[10:32] <siretart> Fujitsu: that is a very good question that is currently discussed in private by the TB
[10:32] <Fujitsu> In private? Urgh.
[10:33] <siretart> feel free to write an inquiry
[10:33] <Fujitsu> Particularly because we have just released Gutsy with it.
[10:33] <siretart> what is the problem with that?
[10:33] <Fujitsu> siretart: We have a fair few packages in universe depending on cdrecord.
[10:34] <Fujitsu> Observe most of http://alt.qeuni.net/~william/debcheck/debcheck.py?dist=gutsy&list=withinuniverse&arch=ANY
[10:34] <siretart> Fujitsu: no. we have a fair packages depending on wodim with a possibly broken dependency field
[10:35] <persia> So the packages concerned should be updated to depend on wodim?
[10:35] <siretart> ideally, they would have an alternate dependency (wodim | cdrecord)
[10:35] <siretart> or (genisoimage | mkisofs)
[10:35] <siretart> or maybe even the other way round
[10:35] <persia> Does wodim / genisoimage provide drop-in replacement so that we don't have to change anything else?
[10:36] <siretart> persia: please look at the packages I've dropped from cdrkit
[10:36] <siretart> persia: those packages just installed a SYMLINK to their cdrkit counterparts, and nothing else
[10:36] <siretart> so those pacakges are actually tested with the wodim/genisoimage.
[10:37] <persia> Ah.  Cool.  I'll look a little deeper prior to asking any more :)
[10:38] <siretart> in fact, there have been only 2 packages in main FTBFS'ing because of those symlink dropped
[10:38] <siretart> one of them was d-i ;)
[10:40] <Fujitsu> siretart: Thanks for clarifying.
[10:40] <persia> So for the affected packages, the procedure is to 1) add the alternate dependency, 2) patch to alternately use the alternate names if the calls are hardcoded, and 3) upload back into universe?
[10:40] <Fujitsu> I think so.
[10:41] <Fujitsu> Actually, shouldn't most things have been fixed in Debian?
[10:41] <persia> That's a lot easier, and perhaps something of the right size for new contributors.
[10:41] <siretart> Fujitsu: exactly
[10:41] <Fujitsu> Do they have cdrtools in non-free?
[10:41] <siretart> Fujitsu: no
[10:42] <persia> Debian cdrkit still provides cdrecord / mkisofs
[10:43] <Fujitsu> OK, so there's no real incentive for Debian maintainers to change their packages, other than (hopefully) bugs.
[10:44] <persia> Right.  Some probably have, others may not have.  Still, it's not a huge list, and something we can do for hardy.
[10:44] <Fujitsu> Yep.
[10:44] <Fujitsu> Nice easy things for contributors.
[10:47] <persia> Fujitsu: based on that, and on the expectation of similar possibilities for the others, I'm far more tempted towards the one-bug-per-package model than the many-tasks model, but I won't set it up for a couple weeks yet.
[10:48] <Fujitsu> It would be nice to have task-specific comments at times, I think.
[10:49] <persia> Fujitsu: Task-specific?  I was thinking more that if this was to be farmed to contributors, there would be value in not collating the materials, as there may be little commonality.
[10:49] <Fujitsu> Ah, true.
[10:49] <Fujitsu> Ignore me.
[10:50] <persia> Fujitsu: Of course, if you just want to do it next week, feel free to do it all in one bug :)
[10:54] <nxvl> persia: how do i download code from launchpad
[10:54] <nxvl> persia: im trying to help on Displayconfig-gtk
[10:54] <persia> nxvl: Um..  What task are you trying to accomplish towards which you would like to download cod.
[10:55] <persia> nxvl.  OK.  First thing is that I'm not always here, and might be busy, so it's best to just ask the question generally.  There are lots of helpful people in the channel.
[10:55] <Fujitsu> Mmm... cod.
[10:55] <nxvl> persia: but i love you and i have seen you are here :D
[10:55] <persia> Second thing is that you probably want to run `apt-get source displayconfig-gtk`.  If should either give you current source, or directions as to how to get current source.
[10:56] <persia> nxvl: accolades appreciated, but just as a matter of general practice.  I don't like the idea that things can't happen because one person isn't around, and think it's better to do things in teams.
[10:57] <nxvl> heh, i was just kidding :P ok, from now on i will not send messages with a persia: in the begining :D
[10:57] <persia> nxvl: Thanks.  I'll still answer anyway :)
[10:58] <nxvl> i know
[10:58] <nxvl> :D
[11:00] <nenolod> persia, but you have a fan
[11:00] <nenolod> :P
[11:01] <persia> nenolod: The weather is getting cooler in the northern hemisphere, so it's not as critical to maintain them :)
[11:01] <nenolod> heheheh
[11:08] <huats> morning all
[11:08] <Fujitsu> Hi huats.
[11:08] <huats> Fujitsu: hi
[11:12] <nenolod> hm
[11:13] <nenolod> does anyone here know if there is a 7.10RC1 install CD/DVD for PPC? the linux harddisk in my G5 is about to fail, so I think i'll just go ahead and reinstall now :s
[11:14] <Fujitsu> nenolod: You could get the final candidate ISOs, which will likely be the actual release.
[11:14] <nenolod> ah. they have been finalised?
[11:14] <nenolod> great
[11:14] <nenolod> i first upgraded to ubuntu from debian sarge using dist-upgrade ;)
[11:15] <persia> https://iso.qa.stgraber.org/qatracker doesn't list powerpc yet though
[11:15] <Fujitsu> persia: It's unsupported, so probably won't be listed.
[11:15] <Fujitsu> http://cdimage.ubuntu.com/ports/daily/20071016/
[11:16] <Fujitsu> nenolod: Not finalised as such, but if no issues are found they will likely be the same as those that are released in aroun 48 hours.
[11:16] <nenolod> great. thanks :)
[11:18] <nenolod> this will do just fine, thanks Fujitsu ;)
[11:18] <nenolod> ooh. we support PA-RISC? fascinating.
[11:18] <persia> nenolod: If it doesn't work in some interesting way, please report it :)
[11:18] <nenolod> i was running gentoo on my HP PA-RISC kit. ;p
[11:19] <nenolod> persia, of course i'll whine if the installer blows up
[11:19] <nenolod> :P
[11:19] <Fujitsu> nenolod: hppa was dropped in Edgy, but has been mostly restored for Gutsy.
[11:19] <Fujitsu> Not everything has built yet, unfortunately :(
[11:20] <persia> The install CD should work though, right?
[11:21] <Fujitsu> I believe so.
[11:21] <Fujitsu> I think main built.
[11:21] <persia> The buildds prefer main to universe, don't they?
[11:21] <nxvl> good night everyone!
[11:22] <nenolod> persia, i think so
[11:22] <nenolod> or at least, that's what i have noticed on rebuilds
[11:22] <nenolod> but i don't pay much attention to stuff like that
[11:22] <Fujitsu> persia: They do.
[11:22] <persia> nenolod: You should be fine then, although you'll want to watch the repositories as they fill (and I'm not sure they will fill completely).
[11:23] <Fujitsu> Particularly as publisher hopefully won't run again.
[11:24] <nenolod> persia, well, i don't think i will try to install it on PA-RISC atm :P
[11:24] <persia> Fujitsu: No?  It's been running regularly all day...
[11:24] <Fujitsu> persia: Oh, it's automatic again? I was disconnected for about an hour, so might have missed it.
[11:25] <Fujitsu> I wonder if binaries can violate CURRENT like they do FROZEN.
[11:25] <persia> Yep.  It's automatic again, but I'm fairly sure that no new sources are uploaded.
[11:25] <persia> Interesting question.  We'll find out Thursday :)
[11:25] <Fujitsu> Yeah.
[11:25] <slangasek> nenolod: so, er, you ran Debian on your powerpc and Gentoo on your hppa?  That's, er, odd :)
[11:26] <Fujitsu> Hi slangasek.
[11:26] <slangasek> hello, I'm not really here
[11:26] <nenolod> slangasek, well, at the time I was more interested in Gentoo, but Gentoo has more internal bitching than Debian and Fedora combined
[11:27] <nenolod> i suspect it has to do with the average age of contributors to gentoo though, most of them are children
[11:27] <nenolod> :P
[11:27] <slangasek> I hadn't noticed
[11:27] <nenolod> well, it's the userbase which is the turnoff in the gentoo experience
[11:28] <nenolod> like when gentoo killed off XMMS, they decided to go lynch the audacious and bmp developers (and not the guy who removed xmms)
[11:28] <slangasek> yes, the rampant power consumption of building everything locally isn't a turn-off at all ;)
[11:28] <nenolod> slangasek, oh. just upgrade your systems in winter and turn off the heat :)
[11:29] <Fujitsu> Gentoo on servers is great fun, particularly if you leave them for a few months and try to perform a security upgrade.
[11:29] <nenolod> Fujitsu, yeah, one of my friends had to do overtime because of that
[11:29] <nenolod> :D
[11:29] <slangasek> nenolod: I find that using standard heating elements in the winter leads to a much lower failure rate on my hardware
[11:29] <Fujitsu> I inherited quite a few, but they're progressively being replaced with more sane systems.
[11:30] <nenolod> slangasek, me too... which is why i have been migrating back to debian/ubuntu :P
[11:31] <nenolod> and honestly,
[11:31] <nenolod> gentoo is great if you have no life
[11:31] <nenolod> but i would rather have a life
[11:31] <nenolod> or spend my lack of having a life doing more interesting things
[11:31] <nenolod> (however you choose to see it ;))
[11:56] <oly_mk2> hi, i wonder if someone could help me, i have created a package successfully but its 200mb
[11:56] <oly_mk2> is there a file that i can use to tell the build system to ignore a folder ?
[11:57] <oly_mk2> or do i have to delete it before building my package each time ?
[11:58] <oly_mk2> thought someone here might know if it can be done,
[11:58] <oly_mk2> i have looked on google but probably using wrong terminology
[12:05] <norsetto> oly_mk2: its for personal use?
[12:05] <oly_mk2> for now, but in future it will be more general
[12:06] <jussi01> ANyone know alberto milones nick?
[12:06] <oly_mk2> but for now i am learning package building, for my program
[12:06] <norsetto> oly_mk2: is there a flag you can pass to configure to disable the inclusion of that poarticular feature? Otherwise you can remove it from your temporary build directory in your binary target
[12:07] <oly_mk2> well the folder is .bzr, and its a python program no configure file
[12:08] <nenolod> ah great. the new HDD shows up in OSX.
[12:08] <norsetto> ok, for .bzr most probably there is a debuilder flag, like -I, let me check
[12:08] <nenolod> that means i should have good chance for it showing up in ubuntu too. ;)
[12:09] <norsetto> oly_mk2: yes, adding -I.bzr to debuild should do
[12:09] <oly_mk2> okay i will have a look at that and try it out
[12:16] <norsetto> jussi01: You can search for people here: https://launchpad.net/people/
[12:16] <jussi01> norsetto: thanks
[12:16] <norsetto> jussi01: and find that his nick is tseliot
[12:16] <jussi01> :)
[12:18] <oly_mk2> is debuild an alternative to dpkg-deb ?
[12:18] <oly_mk2> because thats what i have been using to build my package so far
[12:18] <norsetto> oly_mk2: its a wrapper for dpkg-buildpackage
[12:19] <norsetto> oly_mk2: so, the -I is just passed to dpkg-buildpackage, which in turn is passing it to dpkg-source
[12:22] <norsetto> oly_mk2: I think its also worth telling you that dpkg-deb is just a tool to manipulate archives, you should certainly not use it to build packages (even if they are python)
[12:23] <oly_mk2> oh, okay  did not know that, damn and i liked how simple it was :p
[12:25] <oly_mk2> thxs for the info norsetto, though i am installing debuild now to have a play with
[12:26] <norsetto> oly_mk2: yeah, its gonna be a bit trickier, you have to add a rules file to start with
[12:26] <oly_mk2> yeah just found this, and a changelog file
[12:26] <oly_mk2> i just needed a control script and a postinst script with the other system
[12:27] <Schnitz> hi all
[12:28] <norsetto> oly_mk2: you may find this helpful: http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html; mind that its being migrated to the wiki
[12:29] <oly_mk2> okay thxs again norsetto, will have a look at that
[12:29] <norsetto> oly_mk2: python packages are actually tricky, for the time being since its just for you its most probably ok, but if you mean to distribute it you should certainly have a look at the Debian python policy
[12:31] <oly_mk2> okay, probably be a while till it ready for distribution, been using a shell script for install up till now
[12:32] <norsetto> oly_mk2: heck, you should code a python script for that ;-)
[12:33] <oly_mk2> lol, i did consider it, but it helped with my bash knowldge so i cant complain
[12:33] <oly_mk2> why are python programs tricky anyway
[12:33] <oly_mk2> i would have thought they would be easy
[12:34] <norsetto> oly_mk2: just in case, have a look at some python packages we have in the archive, and the script they use. Its usually called setup.py
[12:34] <oly_mk2> okay able to recommend a good one ?
[12:34] <oly_mk2> thats quite simple, to get me started:)
[12:37] <norsetto> oly_mk2: https://wiki.ubuntu.com/MOTU/ReferencePackages
[12:37] <nenolod> Fujitsu, is it normal for the livecd to take 5 to 7 minutes to load?
[12:37] <norsetto> oly_mk2: I think jokosher should be a good example to follow
[12:38] <oly_mk2> okay excellent thxs for all this help,
[12:38] <pwnguin> remind me again why i need a search indexer?
[12:42] <norsetto> pwnguin: get rid of the blasted thing ;-)
[12:42] <dholbach> norsetto: do you BCC ubuntu-motu{,-mentors}?
[12:42] <dholbach> norsetto: that's why all the mails end up in the moderation queue
[12:42] <norsetto> dholbach: why, it should be that originators that count?
[12:43] <dholbach> Reason:  	Message has implicit destination
[12:43] <norsetto> dholbach: but, ok, since it is like this I will take care to not repeat the mistake
[12:43] <dholbach> no problem
[12:44] <dholbach> hehe
[12:44] <norsetto> dholbach: I hope you did a good job with jokosher, I'm giving that as an example of a good python package ;-)
[12:45] <dholbach> oh, now I hope so too ;-)
[12:45] <dholbach> there's ReferencePackages somewhere on the wiki
[12:45] <norsetto> dholbach: scroll up few rows.....
[12:45] <dholbach> hehe.... :)
[12:46] <dholbach> doing too many things at the same time, I guess
[12:46] <dholbach> excusez-moi
[12:46] <dholbach> hey Tonio_ - how's it going?
[12:46] <Tonio_> dholbach: hey ;)
[12:46] <dholbach> Tonio_: how's big K looking?
[12:46] <Tonio_> dholbach: well pretty fine, except I'm at work since 27 hours non-stop :)
[12:47] <dholbach> hope you'll get some sleep soon again
[12:47] <Tonio_> dholbach: I'd say nice, except we are one cycle late compared to ubuntu/gnome hehe :)
[12:47] <Tonio_> as always :)
[12:47] <dholbach> Tonio_: one cycle late?
[12:47] <Tonio_> dholbach: we miss some features ubuntu has, like the new apt protocol
[12:48] <Tonio_> dholbach: I started forking on it, but we'll have it once cycle late compared to ubuntu
[12:48] <Tonio_> that's life, we're used to that :)
[12:48] <Tonio_> dholbach: how are you ?
[12:48] <dholbach> good good - a bit tired, but OK - just doing a few ISO tests
[12:49] <Tonio_> hehe, I can imagin a release week is busy for canonical employees :)
[12:50] <dholbach> I think I'm better off than others
[12:50] <dholbach> imagine working on the kernel have "last minute bugs to fix" ;-)
[12:50] <dholbach> ... and ...
[12:52] <Tonio_> dholbach: yeah, I guess benC isn't having a good time right now hehe :)
[12:52] <Tonio_> hi ajmitch
[12:52] <ajmitch> hi
[12:52] <dholbach> I think it's all looking quite good
[12:52] <norsetto> as long as he fix the bloated mac80211
[12:54] <pwnguin> strange
[12:54] <pwnguin> i brought a package into my ppa from debian
[12:55] <pwnguin> and it wants to install  libode0debian1
[12:56] <pwnguin> its not mentioned anywhere excplicitly that i can see
[12:56] <norsetto> pwnguin: can be a depend of a depend
[12:56] <pwnguin> thats the thing
[12:56] <pwnguin> if that were the case, i'd also need to install that middle depend
[12:57] <norsetto> pwnguin: are you using apt-get or dpkg?
[12:57] <pwnguin> libode0debian1 mu-cade mu-cade-data
[12:57] <pwnguin> apt-get
[12:58] <pwnguin> mu-cade is the package i pulled from Debian
[12:58] <pwnguin> ah. hmm
[12:59] <norsetto> pwnguin: you can check it with: apt-cache rdepends libode0debian1
[12:59] <pwnguin> Depends: mu-cade-data (= ${source:Version}), ${shlibs:Depends}, ${misc:Depends}
[01:00] <ScottK> pkern: leonel
[01:00] <norsetto> pwnguin: you can use a dpkg -I on the deb to check how the shlibs was expanded
[01:04] <pwnguin> norsetto: isn't that the same as apt-cache show?
[01:04] <pkern> ScottK: k thx
[01:04] <norsetto> pwnguin: sure it is (if you update your cache)
[01:05] <rexbron> siretart: Have a moment to talk about ffmpeg?
[01:06] <pwnguin> well, mystery solved. this particular game did indeed use ode
[01:06] <siretart> rexbron: sure
[01:07] <pwnguin> if i had read anything from the actual upstream, i'd have realized that sooner =(
[01:07] <norsetto> pwnguin: only the meek read, real men do it the hard way ;-)
[01:08] <siretart> rexbron: what's up?
[01:08] <rexbron> siretart: Would it be possible for hardy to get a new version from CVS
[01:09] <pwnguin> norsetto: well the hard way kept saying it was needed. im not about to wait another hour to find out it doesnt work without that build dep :P
[01:09] <siretart> rexbron: sure! however, since I co-maintain it in debian, I'd prefer to do the work over there, and then push the result to ubuntu
[01:10] <rexbron> I initally started packaging an app called jahshaka, which in turn means I need to package OpenLibraries (and several other base libs). I believe that the OpenLibraries depends on some new funtionality introduced
[01:10] <siretart> rexbron: since debian is far away from freezing, we work on that right now!
[01:10] <rexbron> siretart: cool
[01:10] <rexbron> :D
[01:10] <siretart> rexbron: is this an offer for help?
[01:13] <coNP[uni] > Hey MOTUs!
[01:17] <rexbron> siretart: I know little regarding packaging from cvs
[01:17] <rexbron> but I am willing to learn
[01:29] <proppy> hi
[01:50] <fernando> moin all
[02:08] <proppy> norsetto_limbo: ping
[02:08] <persia> proppy: limbo usually means just that :)
[02:09] <proppy> let me google translate it
[02:10] <proppy> oh
[02:45] <Schnitz> hello
[02:58] <Hobbsee> ScottK: nice mail to -d-d, btw.  i've just sent a similar one.
[02:59] <ScottK> Hobbsee: Which?  The getdeb one?
[02:59] <Hobbsee> ScottK: nah.  4 days left
[02:59] <siretart> rexbron: sorry, I was away
[02:59] <ScottK> Ah.
[02:59] <Hobbsee> although i found some interesting stuff about getdeb ,recently
[02:59] <ScottK> Oh?
[02:59] <siretart> rexbron: I'd suggest that you look at the svn on svn.debian.org, and look at how the packaging of ffmpeg works
[03:00] <ScottK> Hobbsee: Would you be up for uploading a couple of source backports for me?
[03:00] <siretart> rexbron: feel free to ask me specific questions either here, or in #debian-devel/oftc
[03:00] <Hobbsee> ScottK: about their QA, and about what they're trying to do.
[03:00] <ScottK> Hobbsee: It's Universe packages, but source backports take a core-dev no matter what.
[03:00] <Hobbsee> yeah
[03:01] <ScottK> Hobbsee: I've reviewed the debdiif in Bug #151308 and it should be good to go with no trouble.
[03:01] <ubotu> Launchpad bug 151308 in feisty-backports "please backport Clamav from Gutsy to Feisty " [Undecided,Confirmed]  https://launchpad.net/bugs/151308
[03:03] <ScottK> Hobbsee: Bug #153287 is the other.
[03:03] <ubotu> Launchpad bug 153287 in dapper-backports "Please source backport pyspf 2.0.4-1 from Gutsy to Dapper" [Wishlist,Confirmed]  https://launchpad.net/bugs/153287
[03:08] <jdong> persia: make sure the guy who you're talking to is not gonna try to use your knowledge for evil? :)
[03:08] <persia> jdong: That fails sharply in an open collaboration environment
[03:09] <jdong> it's the whole " 4oz of toothpaste doesn't kill people, terrorists kill people" argument....
[03:09] <jdong> persia: critiquing faulty security successfully implies that someone can directly use that to exploit a weakness :)
[03:09] <jdong> otherwise you didn't do a good job critiquing
[03:10] <jdong> just don't go making hackomatix scripts and we'll be fine :)

[03:11] <persia> jdong: That's why I was hoping there were some common guidelines on how to demonstrate penetration without providing instruction (although I'll admit I received most of my knowledge of penetration from critiques)
[03:12] <jdong> persia: I think uncoded instruction is good enough
[03:12] <jdong> persia: it prevents the script kiddies from directly using it, which is really all that you can hope to avoid
[03:13] <Whoopie> jdong: hi, could you have a look at bug 117900? thanks!
[03:13] <ubotu> Launchpad bug 117900 in vim "security update not installed because of higher version number of the backported vim" [Undecided,Invalid]  https://launchpad.net/bugs/117900
[03:13] <persia> jdong: Makes sense.  Thanks (although I'll probably catch keescook at some future point as well).
[03:13] <jdong> persia: yeah, he's gonna be your expert on this
[03:14] <jdong> Whoopie: have you tried build-testing the version of vim you propose?
[03:15] <Whoopie> jdong: sorry, no.
[03:16] <Whoopie> jdong: problem is that I'm already on feisty. But I think, it's still valid for others. I'm thinking about closing it with "edgy is too old, upgrade to upcoming gutsy" or leave it open.
[03:16] <jdong> Whoopie: nah, leave it open -- edgy is still a supported distro
[03:21] <persia> Support is an interesting thing.  One of my coworkers installed Dapper last night, because he wanted more support than he thought he might get from Feisty.
[03:22] <zul> support usually means security updates
[03:23] <persia> zul: Only security?  I would think also standard SRU updates, etc.
[03:23] <zul> persia: true but mostly security updates
[03:24] <Treenaks> not "support" as in "more hardware support" or "better help on forums/mailinglists/irc/from canonical"
[03:24] <Treenaks> well.. for longer, but not more :_)
[03:24] <persia> For Dapper?  Years more, no?
[03:25] <Treenaks> persia: sure, but try installing dapper on a brand-new machine with lots of new hardware
[03:25] <persia> Treenaks: True enough.
[03:25] <zul> Treenaks: yeah but if you are going to backport the kernel to dapper is a lot of work
[03:26] <Treenaks> persia: I've had a machine here where even the gutsy drivers don't detect the sound chipset properly, and the on-board ATi card doesn't do anything when not using the Vesa driver
[03:26] <persia> Treenaks: Sounds like you didn't do your HW research before purchasing :)
[03:26] <Treenaks> zul: sure, I know why it is :) I'm just trying to point out that the word "support" might be a bit confusing to people not used to the term being used in the way it's used wrt Ubuntu releases
[03:26] <Treenaks> persia: I didn't buy it, my employer did :)
[03:38] <amachu_> bluekuja: hi
[03:38] <amachu_> just started to go through packaging again... and now little deeper to make
[03:38] <amachu_> :-)
[03:45] <Kopfgeldjaeger> hi (amsg)
[03:46] <norsetto> hey proppy, wanna have fun with a nice python bug?
[03:46] <jdong> lol, that's not how you lure em!
[03:46] <jdong> "hey, wanna big tasty cookie?"
[03:47] <norsetto> jdong: don't worry, he can't resist when he sees python
[03:54] <proppy> norsetto: yep letme finish that phonecall
[03:57] <bddebian> Heya gang
[03:57] <dholbach> hey bddebian
[03:58] <bddebian> Hi dholbach
[04:01] <proppy> norsetto: back
[04:02] <norsetto> bddebian: hi bd
[04:02] <bddebian> Heya norsetto
[04:03] <norsetto> proppy: ok, think you can have a look at this: bug 152438 ?
[04:03] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Medium,Confirmed]  https://launchpad.net/bugs/152438
[04:05] <proppy> lets chroot !
[04:12] <proppy> norsetto: reading the debianbugs troll
[04:16] <proppy> norsetto: looks like its fixed upstream
[04:16] <proppy> according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409864#88
[04:16] <ubotu> Debian bug 409864 in viewvc "viewvc: No such file or directory: '/usr/lib/templates/directory.ezt' for SVN, but CVS works OK" [Important,Open] 
[04:17] <norsetto> proppy: yes, do you think that last patch will fix it?
[04:17] <proppy> let me try, the patch may have some others issue
[04:18] <norsetto> brb
[04:22] <norsetto> proppy: because it seems to me that that patch (not the authorization part, the path part) its already in the version we have
[04:27] <proppy> norsetto: I don't see viewvc in feisty
[04:27] <norsetto> proppy: was called viewvcs then
[04:27] <norsetto> proppy: sorry, viewcvs
[04:28] <proppy> norsetto:
[04:29] <proppy> http://paste.ubuntu.com/951/
[04:29] <proppy> ok
[04:32] <norsetto> proppy: what that patch seems to be doing is just replacing this line in viewvc-install: contents = re.sub('^#![^\n] *', ReEscape(shbang), contents)
[04:32] <norsetto> proppy:: with this: contents = re.sub('^#![^\n] *', _escape(shbang), contents)
[04:37] <proppy> need to check ReEspace implementation against _escape
[04:37] <proppy> so
[04:38] <proppy> def ReEscape(str):
[04:38] <proppy>   return string.replace(str, "\\", "\\\\")
[04:39] <proppy> (04:22:38 PM) norsetto: proppy: because it seems to me that that patch (not the authorization part, the path part) its already in the version we have
[04:39] <proppy> you mean in feisty ?
[04:39] <norsetto> proppy: in gutsy
[04:39] <proppy> cause I already got ReEscape in feisty
[04:39] <proppy> oh ok
[04:40] <proppy> I thought the bug needed to be reproduce in feisty
[04:40] <proppy> I confirm that the string ReEscape exist in feisty
[04:40] <norsetto> proppy: I'm actually not sure that the debian bug IS the same as our bug. I was able to reproduce it, but wasn't able to reproduce the ubuntu one
[04:41] <norsetto> proppy: yes, that is the case for gutsy too, the patch attached to the debian bug claims to solve the path issue by subst ReEscape with _escape
[04:42] <proppy> "after dist-upgrade from viewcvs in feisty"
[04:42] <norsetto> proppy: it actually seems to me that the reporter of that was on a high dose of crack
[04:42] <proppy> does this mean that the bug occured when upgrade from feisty to gutsy ?
[04:42] <proppy> or that the bug occured when upgrade to feisty ?
[04:42] <norsetto> proppy: no, I could reproduce the debian one on a fresh gutsy install
[04:43] <norsetto> proppy: thats why I think the ubuntu bug is similar, perhaps due to the same cause, but its not the same
[04:43] <proppy> ok let me clone a gutsy chroot
[04:45] <proppy> I've attached the debian patch
[04:45] <proppy> just in case
[04:47] <norsetto> asac: re bug 107093, its as worst as ever. ff freezes after few secs only
[04:47] <ubotu> Launchpad bug 107093 in firefox "System freezes (possibly Gecko)" [Medium,Incomplete]  https://launchpad.net/bugs/107093
[04:48] <proppy> norsetto: is diff vc-feisty/usr/src/viewcvs-0.9.2+cvs.1.0.dev.2004.07.28/viewcvs-install vc-gutsy/usr/src/viewvc-1.0.3/viewvc-install usefull ?
[04:49] <norsetto> asac: don't know it makes sense to you, but was working fine until I tried granparadiso, which deleted my .mozilla dir, after which it started freezing again
[04:50] <norsetto> proppy: don't think so
[04:50] <proppy> :)
[04:56] <proppy> norsetto: trying to reproduce the bug with apache + viewvc
[04:57] <norsetto> proppy: yes, thats what I did, try to navigate to an svn repo and you should see the crash
[04:57] <mertiki> slangasek : Are you there?
[04:57] <asac> norsetto: granparadiso doesn't delete the .mozilla dir
[04:58] <asac> norsetto: if you adopted granparadiso pretty early ... or from mozillateam archives you might have trashed your profile a bit though.
[04:58] <norsetto> asac: well, that what it did when I tested few days ago, you remember it?
[04:58] <asac> norsetto: please try with a fresh profile as i requested
[04:58] <asac> norsetto: no ... i don't remember :)
[04:58] <asac> sorry
[04:58] <norsetto> asac: you asked me to test something, what was it?
[04:58] <asac> norsetto: maybe Ubulette asked you?
[04:58] <norsetto> asac: oh yeah, the install script, the typo (utf-8)
[04:59] <asac> hmm ... so please move it again away and start firefox 2 only :)
[04:59] <norsetto> asac: anyhow, it deleted the .mozilla dir, after which the freezing come back as worst as ever. I really think it is Cache related
[05:00] <norsetto> asac: yes, thats what I did, and bang, freeze was back
[05:02] <norsetto> ubulette :-) thats a fanny one. I should change my nick to ubuleur .....
[05:03] <proppy> norsetto: http://paste.ubuntu.com/952/
[05:04] <proppy> something is wrong with my svn configuration
[05:05] <norsetto> proppy: in my case it was failing as it couldn't find foo/format
[05:05] <proppy> dpkg-reconfigure viewvc and fixed my mistake
[05:05] <proppy> norsetto:
[05:05] <proppy> it works for me
[05:06] <proppy> first I get this
[05:06] <proppy> An Exception Has Occurred  The root "svn" is unknown. If you believe the value is correct, then please double-check your configuration.
[05:06] <proppy> and then when using the name I give to my svn root
[05:06] <proppy> using dpkg-reconfigure
[05:06] <asac> norsetto: did you install anything from mozillateam repository?
[05:06] <proppy> which is uppercase SVN
[05:06] <proppy> it works
[05:06] <asac> norsetto: which version of libnspr4-0d and libnss3-0d do you have installed?
[05:06] <norsetto> asac: no, but I tested your nlswrapper thingie
[05:07] <proppy> norsetto: let me upload this somewhere so you can check yourself
[05:07] <asac> nspluginwrapper?
[05:07] <norsetto> asac: yes
[05:07] <norsetto> asac: libnspr4-0d    4.6.6-3
[05:07] <norsetto> asac: libnss3-0d     3.11.5-3
[05:07] <asac> norsetto: please see which versions you have installed of all these packages ... and try to remove flashplugin-nonfree mozilla-plugin-gnash as well as nspluginwrapper to see if things go away
[05:08] <asac> norsetto: and check is there anything left after doing this in /usr/lib/firefox/plugins/
[05:08] <norsetto> asac:nspluginwrapper and flashplugin-nonfree were installed on another partition
[05:09] <norsetto> asac: they have nothing to do with the firefox problem; its a plain firefox, noextension/plugin/nothing
[05:10] <asac> norsetto: installed on another partition? what happened with that partition?
[05:10] <norsetto> asac: since I can't use firefox, I installed kubuntu on another partition, and I'm using that
[05:11] <asac> norsetto: anyway ... attach a strace -e open -f firefox &> /tmp/strace.log to the bug
[05:11] <asac> and let me know
[05:11] <norsetto> asac: ok, for that I have to log off
[05:13] <Hobbsee> dear people, please dont send me memos, kthxbye.
[05:14] <norsetto> proppy: sorry, have to log off, see u later
[05:15] <proppy> see you
[05:16] <Adri2000> TheMuso: looks like ubuntu4 of audacious-plugins doesn't fix the upgrade :/ (bug #152918) is it the same for ubuntustudio-look?
[05:16] <ubotu> Launchpad bug 152918 in audacious-plugins "Try to replace libcurl.so from audacious-plugins-extra" [High,Fix released]  https://launchpad.net/bugs/152918
[05:17] <jussi01> Adri2000: TheMuso will be asleep right now
[05:17] <Hobbsee> Adri2000: why the hell not?
[05:17] <Hobbsee> oh, wait, you didnt actually do the second fix.
[05:18] <Hobbsee> so i wont blast you for not testing twice, especially so close to a freeze
[05:20] <Adri2000> what is the "second fix"? and I didn't upload anything, as finally TheMuso's upload has been accepted
[05:21] <Hobbsee> but his doesnt work either
[05:24] <Adri2000> exactly. and I'm afraid there is the same problem with ubuntustudio-look
[05:25] <Hobbsee> but i'm surprised that both of you didnt actually check.
[05:28] <Hobbsee> TheMuso: consider this your smacking with the cluebat.  you officially SUCK.
[05:28] <Hobbsee> Adri2000: please fix this properly, and run it past me first.
[05:30] <Hobbsee> Adri2000: ubuntustudio-look was the other?  looking
[05:32] <Adri2000> Hobbsee: yes, and I'm fixing (hopefully for real now) audacious-plugins atm. I could do ubuntustudio-look as well, but I've never touched any ubuntustudio package, so maybe we'll wait TheMuso or someone else?
[05:46] <hash_> Hi, I want to get an existing Debian package into Ubuntu's Universe repository, so I did: https://bugs.launchpad.net/ubuntu/+bug/129952 . I'm wondering when the binaries will be available in the Ubuntu Universe repository?
[05:46] <ubotu> Launchpad bug 129952 in ubuntu "please sync package m17n-contrib from debian unstable" [Wishlist,Fix released] 
[05:46] <hash_> Is there anything more I need to do?
[05:46] <Adri2000> Hobbsee: http://adrishost.homeip.net/~adri2000/ubuntu/audacious-plugins_1.3.5-3ubuntu4.1.debdiff
[05:47] <Hobbsee> Adri2000: now i've managed to confuse myself greatly, but at least this shouldnt bite us during upgrade paths and such - only for those doing daily upgrades of gutsy
[05:47] <Hobbsee> Adri2000: i *think* that's still broken.
[05:48] <Hobbsee> Adri2000: for those who do daily updates for gutsy.
[05:48] <norsetto> asac: strace attached to bug 107093
[05:48] <ubotu> Launchpad bug 107093 in firefox "System freezes (possibly Gecko)" [Medium,Confirmed]  https://launchpad.net/bugs/107093
[05:48] <Adri2000> hash_: it failed to build : https://launchpad.net/ubuntu/+source/m17n-contrib/1.1.3-1/+build/381360
[05:49] <Adri2000> Hobbsee: yes for feisty -> gutsy there should be any problem
[05:49] <Adri2000> Hobbsee: why do you think it's still broken?
[05:49] <Hobbsee> Adri2000: would be nice to fix it properly though, for those who do update
[05:49] <Adri2000> of course
[05:49] <Hobbsee> Adri2000: because it breaks for those already having upgraded to ubuntu4
[05:50] <Hobbsee> (which is, uh, everyone, based on the release cycle?)
[05:50] <Hobbsee> Adri2000: if they have ubuntu4, it wont replace any previous version, and will still get hit over and over by this bug - you've effectively done what TheMuso did.
[05:51] <Hobbsee> you need to C&R ubuntu4
[05:51] <Adri2000> ahh right, so that should rather be << 1.3.5-3ubuntu4.1
[05:51] <Hobbsee> yup
[05:51] <Hobbsee> so either <= ubuntu4 or << ubuntu4.1
[05:51] <Adri2000> yep
[05:51] <Hobbsee> because in current state, it'll break for everyone who upgrades, when they get the update thru -updates sometime in the future.
[05:51] <Adri2000> and... I'm not sure if Replaces is needed, the Debian maintainer only put conflicts
[05:52] <Hobbsee> apt seems to handle it better if replaces si added
[05:52] <Adri2000> ok
[05:52] <Hobbsee> as in, it doesnt leave the question of "so, which one do you actually want?"
[05:52] <hash_> Adri2000: the logs says: "Built successfully" and the web page says: "Status:  	 Failed to upload"
[05:53] <Hobbsee> hash_: erk.  that's a soyuz bug.
[05:54] <Adri2000> hash_: you're right, I misread
[05:54] <hash_> Adri2000: no probs. :-)
[05:55] <hash_> Hobbsee & Addr2000: So what do I need to do to get the binary built and in the repo for gutsy?
[05:55] <Hobbsee> asking.
[05:55] <Hobbsee> it may be far too late
[05:55] <proppy> norsetto: hi back
[05:56] <norsetto> proppy: bad news are always back ....
[05:57] <proppy> norsetto: I've got an url for you
[05:57] <proppy> norsetto: http://lp152438.aminche.com/
[05:59] <Hobbsee> hash_: [01:58]  <cjwatson_> Hobbsee: I think it's unlikely that those will be processed now
[05:59] <proppy> you can log via ssh
[05:59] <proppy> wait
[05:59] <Hobbsee> hash_: needed this 2+ days ago.
[05:59] <Hobbsee> er, 1+ day ago
[06:00] <hash_> Hobbsee: even for the Universe repository?
[06:00] <Hobbsee> hash_: yes.  we want -security for when gutsy opens.
[06:01] <Hobbsee> hash_: this thing died 2 months ago.  this thing failed a month and a half ago - and it's taken you this long to notice, and to act on the FTBFS emails?
[06:01] <Hobbsee> gah.  kill first sentence.
[06:01] <hash_> Hobbsee: What FTBFS emails?
[06:02] <asac> norsetto: try to purge font packages and see if you find a bad one
[06:02] <Hobbsee> are you listed as the maintainer there?
[06:02] <hash_> Hobbsee: not for Ubuntu, only for Debian.
[06:02] <Hobbsee> hm, seems so
[06:02] <norsetto> asac: what do you mean purge?
[06:03] <asac> apt-get remove --purge PACKAGENAME
[06:03] <norsetto> asac: any particular suspicion before I wipe out all my fonts?
[06:04] <hash_> Hobbsee: In Sept, in launchpad (https://bugs.launchpad.net/ubuntu/+bug/129952) I asked about what happened to the binaries, but got no response.
[06:04] <ubotu> Launchpad bug 129952 in ubuntu "please sync package m17n-contrib from debian unstable" [Wishlist,Fix released] 
[06:04] <hash_> Hobbsee: Should I have received emails when the upload failed?
[06:05] <Hobbsee> oh, and bddebian never responded.
[06:05] <Hobbsee> hash_: usually, yeah.  although i'm not sure what happens if you're only hte maintainer, not the uploader
[06:05] <bddebian> About?
[06:05] <proppy> norsetto: I was unable to reproduce it in gutsy
[06:05] <proppy> norsetto: as show the url below
[06:06] <hash_> Hobbsee: ah, so the uploader would have got an email?
[06:06] <norsetto> proppy: what if it is a real svn repo? Because I tired with one, and was getting an error too
[06:06] <asac> norsetto: no ... try deja.. fonts
[06:07] <bddebian> Hobbsee: What didn't I respond about?
[06:07] <norsetto> asac: ok, back to the other partition ......
[06:07] <asac> norsetto: yes try to remove the ttf-dejavu* packages you have
[06:07] <Hobbsee> bddebian: failed to upload - would have thought you'd responded to the bug report
[06:07] <Hobbsee> hash_: he would have, yeah.
[06:08] <bddebian> Hobbsee: Sorry I'm barely paying attention as I'm at work.  What bug?
[06:08] <Hobbsee> https://bugs.launchpad.net/ubuntu/+bug/129952
[06:08] <ubotu> Launchpad bug 129952 in ubuntu "please sync package m17n-contrib from debian unstable" [Wishlist,Fix released] 
[06:09] <hash_> Hobbsee: This is disappointing, I did all the requirements in august just to get this into Gutsy and then inquired what went wrong in Sept, and now I find out it's too late.
[06:09] <Adri2000> Hobbsee: http://adrishost.homeip.net/~adri2000/ubuntu/audacious-plugins_1.3.5-3ubuntu4.1.debdiff < I built that one, and dpkg -i the binaries works (whereas it didn't work previously with the wrong version in conflicts/replaces), so I guess it's good now. can I upload?
[06:09] <Hobbsee> i know, but we release in 2 days, and there's a time where it's absolutely frozen.  you picked tha ttime.
[06:09] <bddebian> Crap, I must have missed that one, sorry :-(
[06:10] <hash_> so does this mean, it'll have to wait till the next version of Ubuntu?
[06:10] <Hobbsee> -Replaces: audacious-plugins-extra (<= 1.3.5-3ubuntu2)
[06:10] <Hobbsee> +Conflicts: audacious (<< 1.2)
[06:10] <Hobbsee> Adri2000: why was ^ (the second half) OK to drop?
[06:10] <proppy> norsetto: the svn repo it shows was created with svnadmin
[06:11] <proppy> norsetto: you can check command history and file change on http://hg.lp152438.aminche.com/
[06:11] <norsetto> proppy: any chance you can mirror another repo?
[06:11] <proppy> norsetto: I've put you ssh keys in root/.ssh/authorized_keys
[06:12] <proppy> norsetto: http://lp152438.aminche.com/#SshAccess
[06:12] <proppy> norsetto: If you want to try with the failing svn repo
[06:12] <proppy> failing
[06:12] <proppy> I can do it myself
[06:12] <proppy> just give me the url for the one you tried
[06:14] <Adri2000> Hobbsee: because if a conflicts b, b doesn't need to conflict a, no? and I look in Debian and the maintainer didn't put any additional conflicts/replaces to audacious-plugins-extra
[06:14] <proppy> oops I missed my japanese class :(
[06:14] <Adri2000> Hobbsee: a file was moved from -plugins-extra to -plugins, so now -plugins conflicts with and replaces the old -plugins-extra
[06:15] <Hobbsee> Adri2000: ah right.
[06:15] <Hobbsee> yep
[06:15] <luk_> pong to whoever highlighted me :-)
[06:17] <Adri2000> Hobbsee: is -proposed already open?
[06:17] <proppy> norsetto: which repository do you want me to try
[06:17] <proppy> norsetto: any repo ?
[06:18] <Hobbsee> Adri2000: i doubt it
[06:20] <norsetto> proppy: try this: svn://svn.debian.org/pkg-ralink/
[06:21] <norsetto> asac: I deleted the dejavu fonts, seems faster (and so far no freeze, which is a recent record)
[06:22] <proppy> norsetto: does viewvc support listing remote repository ?
[06:23] <proppy> norsetto: or should I import it in a locally created repository ?
[06:23] <leonel> do-release-upgrade  works  for  PPC   upgrading from feisty to gutsy ?
[06:23] <proppy> norsetto: cause there is no svn clone :)
[06:23] <Adri2000> Hobbsee: but still, I upload now? and it'll be accepted when -proposed opens?
[06:23] <norsetto> proppy: I imported a local repo
[06:23] <asac> norsetto: ok ... have fun :)
[06:24] <norsetto> proppy: and tried to access it with viewvc, but get an error (something like foo/format not found). No matter what root I specify
[06:24] <norsetto> asac: was that it? Bloody dejavu-fonts ? Come on ......
[06:24] <asac> yeah
[06:25] <proppy> norsetto: which command did you use to import svn://svn.debian.org/pkg-ralink/ in a local repo ?
[06:25] <proppy> norsetto: svn co svn://svn.debian.org/pkg-ralink/ then svn import . /svnroot ?
[06:25] <norsetto> asac: any likely explanation why mandatory fonts (in ubuntu-dekstop) are causing this????
[06:25] <asac> is it mandatory?
[06:25] <norsetto> asac: yes
[06:26] <Hobbsee> Adri2000: i think that's fine.  i think.
[06:26] <asac> i couldn't track this down ... no ... apparently it doesn't happen for all, so most likely has something to do with your X/driver setup
[06:26] <norsetto> asac: dejavu-core is a depends of all -desktop metapackages
[06:27] <asac> norsetto: did you have -extra as well?
[06:27] <asac> maybe it just happens with extra?
[06:27] <norsetto> asac: yes
[06:28] <norsetto> asac: exyta is a depends of ttf-dejavu, which depends on | openoffice org and | gnome-core
[06:28] <proppy> norsetto: on #svn http://paste.ubuntu.com/958/
[06:28] <proppy> norsetto: did you use svnsync ?
[06:28] <norsetto> asac: ok, let me reinstall the core ones only
[06:30] <norsetto> proppy: no, it wasn't svnsync
[06:31] <proppy> So you only imported some file into your local repository
[06:31] <proppy> not the all the revision
[06:31] <proppy> ?
[06:31] <proppy> s/some file/the trunk/
[06:32] <proppy> If you try to make viewvc a checkouted directory it won't work
[06:33] <proppy> I understand viewvc is looking for a svn repo, not a svn working copy
[06:33] <norsetto> proppy: no, I didn't import just some files, I imported the whole repo
[06:35] <norsetto> asac: so far so good, thanks a bunch!! Just keep the bug open, I want to do some more testing before I can confirm this as solved. THANKS!
[06:35] <proppy> can you give me the command you used ?
[06:35] <asac> norsetto: please add a ttf-dejavu-extra target in that bug if it turns out to be that package
[06:35] <norsetto> asac: you bet I will
[06:36] <asac> thanks
[06:38] <norsetto> proppy: let me see if I have it in my history
[06:47] <proppy> norsetto: Is this the error you had: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/?root=pkg-ralink
[06:47] <proppy> ?
[06:48] <proppy>  SubversionException: ("Can't open file '/tmp/pkg-ralink/format': No such file or directory", 2)
[06:48] <norsetto> proppy: thats the one
[06:48] <proppy> norsetto: it's not a bug
[06:48] <norsetto> proppy: can't find it in history, too long ago
[06:48] <proppy> norsetto: viewvc wait for a svn repository
[06:48] <norsetto> proppy: isn't format in .svn?
[06:48] <proppy> norsetto: not a checkouted working copy
[06:49] <proppy> norsetto: nop, svn is a centrealised versionning system
[06:49] <proppy> norsetto: the repository structure is totally different from the working copy one
[06:50] <proppy> when you checkout, you do not have all the history of the file, like with mercurial or bazaar for example
[06:50] <norsetto> proppy: so, the only way to clone a repo locally is to use this svnsync?
[06:50] <proppy> yep
[06:50] <proppy> which diff all the revision two per two
[06:50] <proppy> and import the changeset one by one
[06:51] <norsetto> proppy: cvs, svn, hg, bzr, git, anything else? Can somenone invent a new one pls?
[06:51] <proppy> norsetto: but you can clone it with cp or rsync, if you have ssh access to the source repository :)
[06:52] <proppy> norsetto: monotone ?
[06:53] <norsetto> proppy: as ScottK said once, I can only have so many vcs in my head, and my limit is slightly below one ......
[06:53] <norsetto> proppy: I still have to decide which one :-)
[06:54] <ScottK> Bitkeeper is still around (and still proprietary).
[06:54] <proppy> go mercurial !
[06:54] <norsetto> proppy: anyhow, back to the bug, it seems that the debian one is then not related to the ubuntu one
[06:54] <proppy> norsetto: see the fantastic web interface http://hg.lp152438.aminche.com/ :)
[06:55] <proppy> norsetto: I think they are related, but that it's already fixed in gutsy
[06:55] <norsetto> proppy: if I really have to use one, then I'm afraid its gonna be bzr ......
[06:55] <proppy> norsetto: maybe we should get feisty a try ?
[06:55] <proppy> bddebian: hg fan ?
[06:56] <norsetto> proppy: no, he just tends to vomit on my shoes if someone names bzr
[06:56] <proppy> norsetto: what do you suggest to do next ?
[06:56] <proppy> 1/ reproduce it in debian ?
[06:56] <proppy> 2/ reproduce it in feisty ?
[06:57] <proppy> we need to reproduce it somewhere somehow
[06:57] <proppy> I guess
[06:57] <norsetto> proppy: I can only see one way to test it, install viewcvs in fiesty and after upgrade to gutsy upgrade it to viewvc
[06:58] <proppy> debootstrap feisty
[06:58] <proppy> install viewvc
[06:58] <proppy> check if it works ?
[06:58] <proppy> apt-get dist-upgrade
[06:59] <proppy> check if it still (don't) works ?
[06:59] <proppy> right ?
[07:00] <norsetto> proppy: no, you really need to install viewcvs and then upgrade to viewvc if you want to test the migration script. Perhaps, its possible to test it stand alone; you can find the script in the /debian of viewvc
[07:01] <proppy> ohhh ok
[07:01] <proppy> I just get it
[07:01] <proppy> I didn't catch it was related to the name change
[07:01] <norsetto> proppy: I need to test something, I might freeze my machine, so if I don't answer you know why ......
[07:01] <proppy> :)
[07:01] <proppy> ok
[07:06] <proppy> norsetto: so debootstrap feisty install viewcvs check if it works, apt-get dist-upgrade, apt-get install viewvc, check if it still don't work.
[07:09] <proppy> oups too late
[07:12] <proppy> 07:06:30 PM) proppy: norsetto: debootstrap feisty, install viewcvs, check if it works, apt-get dist-upgrade, apt-get install viewvc, check if it still (doesn't) work.
[07:13] <norsetto> proppy: I don't have the bug report handy, was it a cvs or svn problem? Or independent?
[07:14] <proppy> norsetto: seems that debian people says its svn only
[07:14] <proppy> norsetto: I will test it with both
[07:14] <proppy> norsetto: initialising a repository is just one command away for each
[07:27] <norsetto> asac: oh well, it was a good try, no matter if ttf-dejavu (-core, extra or plain) are installed or not, still freezing
[08:19] (hellboy195/#ubuntu-motu) hi, I'm new in packaging and I try to package a new gtk frontend for MDP (Music Player Daemon). I have mpd under the depencies but if I try to install the package (not fully debian valid - testing use for me) the software index get's b0rken. but if I perform a "sudo apt-get -f install" apt installs mpd and everything works fine than. what is wrong? http://ubuntuusers.de/paste/16252/   : buh quite long message ^^ . thx in advance
[08:21] <geser> hellboy195: only apt installs dependencies, dpkg prints only an error and aborts the package installation
[08:22] <hellboy195> geser: that means there is nothing I can do an all is correct?
[08:25] <Amaranth> hellboy195: if you use gdebi to install it it would pull in mpd too
[08:25] <nxvl> here, in Peru LoCo Team we are preparing an installfest for the Gutsy release and i've been ask to give a talk about MOTU, so i wonder if someone has talk about that so i can use his presentation as base for mine
[08:26] <hellboy195> ok nice to hear :D. Ahm 1 stupid question again :( . i have launchpad beta account so i can build my packages there. what ".changes" do i have to upload? what dpkg-buildpage made or pbuilder ?
[08:29] <geser> hellboy195: yourpackage_source.changes
[08:32] <hellboy195> geser: thx :D . Ah ^^ and what does Build-Depends-Indep mean? i havn't found that in any documentation but i saw it in severel control files
[08:36] <ScottK> YokoZa1: How are you today.
[08:37] <geser> hellboy195: that are build-depends for architecture independent files (like documentation) e.g if you build a -doc package
[08:37] <ScottK> YokoZa1: Any thoughts about a feisty-backport for Wine 0.9.46?
[08:37] <hellboy195> geser: ah. cool. thx :D
[08:39] <geser> hellboy195: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps
[08:40] <hellboy195> geser: ah i can remember i read that but since i'm new to packaging i don't/didn't understand that
[08:51] <bddebian> Heya geser, ScottK
[08:51] <geser> Hi bddebian
[08:51] <ScottK> heya bddebian.
[08:51] <sistpoty> hi folks
[08:51] <ScottK> Hello sistpoty.
[08:51] <geser> Hi sistpoty
[08:51] <sistpoty> hi ScottK and geser
[08:51] <sistpoty> sheesh, /me needs to do s.th. about bandwith... note to self phone provider tomorrow *g*
[08:51] <bddebian> Heya sistpoty
[08:51] <sistpoty> hi bddebian
[08:51] <sistpoty> bddebian: thanks again for your work on trigger!
[08:51] <bddebian> Heh, I didn't get very far :-(
[08:51] <sistpoty> it builds again, doesn't it?
[08:51] <bddebian> Yes, but the -data package is still behind :(
[08:51] <hellboy195> Ah I think packaging is difficult at the beginning but it makes a lot of fun. A mentor or something like this is very welcomed ;O
[09:11] <hellboy195> bluekuja: there is a nice interview of you on the plant ;)
[09:11] <bluekuja> hellboy195: yeah! just seen it!
[09:12] <bluekuja> hellboy195: is it nice? :)
[09:12] <hellboy195> bluekuja:  sure. 18 years and already so famous
[09:13] <bluekuja> :)
[09:13] <bluekuja> hellboy195: thanks :) I've appreciated
[09:15] <hellboy195> bluekuja: well I'm 17 and new to packaging so I think every MOTU is a kind of "hero" for me so I'm not sure if my words have any value ^^
[09:16] <sistpoty> bluekuja: damn, another pic of a really clean work area... makes me feel more embarassed about my work area *g*
[09:16] <sistpoty> cheater :P
[09:16] <bluekuja> hehehe
[09:16] <bluekuja> lol
[09:17] <bluekuja> hellboy195: you're really young, feel free to ping for every question :)
[09:18] <bluekuja> sistpoty: nice :)
[09:18] <imbrandon> pics?
[09:19] <hellboy195> bluekuja: thx for this possibility :)  btw you are interested in p2p things in future? don't forget the incredible frostwire ;)
[09:19] <bluekuja> imbrandon: http://behindmotu.files.wordpress.com/2007/09/100_1461.jpg
[09:19] <sistpoty> bluekuja: well. *cough*, thanks
[09:19] <sistpoty> imbrandon: behind mout
[09:19] <sistpoty> motu even
[09:19] <rick_h> That is the desktop of a MOTU.
[09:19] <rick_h> and here I was keeping a ~/packaging dir
[09:20] <bluekuja> hellboy195: yeah definitely. I'll move to create a team soon. But as I said would be nice to have more ppl in!
[09:20] <bluekuja> rick_h: my desktop is pretty confusing
[09:20] <bluekuja> sistpoty: did you cover your desktop with the terminal for any particular reason?
[09:20] <rick_h> more power to you
[09:21] <bluekuja> rick_h: :)
[09:21] <hellboy195> bluekuja: :) . btw may I ask you in which town you life (i expect in italy) - maybe I not as far away as you think
[09:21] <sistpoty> bluekuja: no, that's what my regular desktop looks like... one fullscreen konsole (with several tabs open), and most probably kmail and maybe firefox open...
[09:21] <bluekuja> hellboy195: Udine, quite near from Venice
[09:22] <hellboy195> bluekuja: great XD
[09:22] <bluekuja> sistpoty: that's cool then!
[09:22] <bluekuja> hellboy195: what about you?
[09:22] <hellboy195> bluekuja: you every heard about "hermagor" ?
[09:22] <sistpoty> (I guess I'm the one application per desktop person, which will then run always fullscreen *g*)
[09:22] <bluekuja> lol yeah
[09:22] <bluekuja> hellboy195: 100 km from here?
[09:23] <hellboy195> bluefoxicy: uhh more. from hermagor to Villach (i think you know this town) are 55km
[09:23] <bluekuja> well, we are *quite* near then
[09:23] <bluekuja> hellboy195: if you get the chance to come here, ping me
[09:24] <bluekuja> hehe
[09:25] <hellboy195> bluekuja: well. we'll see. "non me viene in mente quanti kilometri sono da udine a villach"  <-- to make my teacher proud xD
[09:25] <blueyed> ScottK: really bad that bug 135695 is not fixed, although the debdiff was available for a long time. Would I now just do s/gutsy/hardy/ in the debdiff? (the package isn't in Debian anymore).
[09:25] <ubotu> Launchpad bug 135695 in php-interbase "FTBFS: depends on php4-dev, which has been removed" [Undecided,Confirmed]  https://launchpad.net/bugs/135695
[09:25] <ScottK> blueyed: Agreed.  I just didn't have time to sort through it when it didn't apply.
[09:26] <bluekuja> hellboy195: lol
[09:26] <blueyed> It applied all the time..
[09:26] <ScottK> blueyed: You want two: gutsy/hardy and gusty/gutsy-proposed.
[09:26] <bluekuja> hellboy195: I guess 90-100
[09:27] <zul> ajmitch: thats because you are sounded by sheep and they are probably allergic to wool
[09:28] <hellboy195> bluekuja: yeah. quite near.  hmm I'll ping you if I need help with my next Italien homework ^^ :P
[09:28] <slangasek> genetically-modified cotton sheep
[09:28] <bluekuja> slangasek: lol
[09:28] <bluekuja> :)
[09:28] <bluekuja> hellboy195: great!
[09:29] <ScottK> slangasek: Normally we don't push SRUs until after they are uploaded to the follow-on development release.  Any opinions about if it'd be OK to push stuff like fixing package FTBFS to gutsy-proposed now?
[09:30] <slangasek> ScottK: it's my understanding that gutsy-proposed is open, and some packagesare already being uploaded
[09:30] <ScottK> OK.  I think we need to produce some rules for that for Universe then.  Thanks.
[09:30] <hellboy195> bluekuja: but I don't expect you are learning german?
[09:30] <bluekuja> hellboy195: english only
[09:30] <bluekuja> :)
[09:31] <ScottK> zul, StevenK, and soren: Any objections to allowing uploads to gutsy-proposed now with a single motu-uvf ack?
[09:31] <hellboy195> bluekuja: That's a pitty
[09:32] <soren> ScottK: TBH, I don't know the current policy for that? Is that the same as it would be for feisty-proposed?
[09:32] <zul> me either
[09:32] <ScottK> Normally we don't upload an SRU until it's fixed in the development release.
[09:32] <sistpoty> ScottK: is hardy open already? it'd be nice if you could keep a list of stuff that needs to go to hardy after it's open otherwise
[09:32] <ScottK> And any MOTU can do it.
[09:33] <ScottK> sistpoty: No.
[09:33] <sistpoty> ScottK: can you milestone for hardy in LP?
[09:33] <ScottK> Since we have no development series to do first, I'm thinking motu-uvf ack instead.
[09:33] <ScottK> sistpoty: Not yet.
[09:34] <sistpoty> or otherwise abuse it to get to that list (e.g. by tags)?
[09:34] <ScottK> We can just grab a list of what's in gutsy-updates when hardy opens and have our list.
[09:35] <sistpoty> sounds like a good idea then :)
[09:35] <ScottK> Stuff like blueyed's bug above it'd be a shame to leave it open longer than needed.
[09:36] <sistpoty> sure, I'm merely worried to not get regressions into hardy... not by which policy this is done ;)
[09:37] <sistpoty> ajmitch: btw: I'm interested in your work area now :P
[09:38] <ScottK> zul, soren, StevenK?
[09:38] <ajmitch> sistpoty: sorry, it's classified
[09:39] <sistpoty> ajmitch: hehe
[09:39] <zul> ScottK: i would wait but convince me otherwise
[09:40] <hellboy195> bluekuja: well. I'm off now. Thx for the talk and I ping you if I need help ;)
[09:40] <ScottK> zul: Why wait if it's just stuff with no downside risk.
[09:40] <soren> ScottK: Are you sure it's even possible?
[09:40] <ScottK> soren: slangasek says it is.
[09:40] <bluekuja> hellboy195: take care and feel free to ping anytime
[09:40] <sistpoty> cya hellboy195
[09:40] <ScottK> There are Main uploads going there now.
[09:40] <hellboy195> :D cya
[09:40] <zul> ScottK: fine with me then
[09:40] <ScottK> Particularly FTBFS bugs.
[09:40] <soren> ScottK: Hm... I guess it can't hurt, then.
[09:41] <sistpoty> zul: imo we shouldn't wait if it's possible already...
[09:41] <ScottK> OK.  I'll write a mail to the MOTU list then.
[09:41] <zul> sistpoty: 15:40 < zul> ScottK: fine with me then
[09:41] <sistpoty> of course there's the factor "devs should be able to take a break", but none other that I could see
[09:41] <ScottK> sistpoty: They can take all the break they want.  Hobbsee's not here to make them.
[09:42] <sistpoty> haha
[09:43] <zul> sistpoty: ive already taken a break
[09:44] <sistpoty> zul: so do I, almost for the entire gutsy cycle :P
[09:44] <zul> sistpoty: i wish ;)
[09:45] <sistpoty> hm... it's just a bad job to mainly work on a FOSS project, ("oh, I'll just checkout if it still builts on gutsy... just this commit and then...")
[09:46] <sistpoty> (as in work on a paid basis)
[09:47] <zul> i would love to be paid to work on a foss project but thats just me anyways
[09:47] <proppy> norsetto: I've reproduced the bug
[09:47] <proppy> norsetto:  info on http://lp152438.aminche.com/
[09:48] <sistpoty> zul: the advantages of working for university :)
[09:49] <proppy> oups close wrong window
[09:49] <proppy> norsetto_: ping
[09:49] <sistpoty> and bad isn't the right word, as I'm pretty content, but I'm never done after I go home with the job
[09:49] <norsetto_> proppy: pong
[09:50] <zul> sistpoty: true
[09:51] <ajmitch> sistpoty: you're luckier than most
[09:51] <sistpoty> ajmitch: I definitely guess so... even though it doesn't pay to much :)
[09:51] <sistpoty> s/to/too/
[09:52] <ajmitch> neither does my job
[09:52] <Adri2000> ScottK: I've uploaded audacious-plugins to gutsy-proposed today at 16:30UTC (if you're not aware: TheMuso's fix doesn't work), so could you give it an ack so that it can be accepted quickly? Hobbsee reviewed my upload and said ok to upload, but I'd need a clear ack. it's bug #152918.
[09:52] <ubotu> Launchpad bug 152918 in audacious-plugins "Try to replace libcurl.so from audacious-plugins-extra" [High,Fix committed]  https://launchpad.net/bugs/152918
[09:53] <ScottK> Adri2000: Sure.  Is this one going to work?
[09:53] <proppy> norsetto_: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/
[09:53] <proppy> norsetto_: same error
[09:54] <proppy> I've updated #152438 with the steps to reproduce it
[09:54] <proppy> with a link to the step :)
[09:54] <proppy> what is the next step ?
[09:54] <proppy> bug #152438
[09:54] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Medium,Confirmed]  https://launchpad.net/bugs/152438
[09:54] <ScottK> Adri2000: Acked
[09:54] <ScottK> blueyed: I acked your php bug for upload to gutsy-proposed.
[09:55] <Adri2000> ScottK: that's *the* question :). I used the same conflicts/replaces as in debian, and my tests were successful. thanks
[09:55] <Adri2000> ScottK: should I subscribe ubuntu-archive?
[09:55] <proppy> norsetto_: diff -Nru lp152438.2/usr/lib/viewvc/ lp152438/usr/lib/vievc is empty
[09:56] <proppy> norsetto_: in lp152438.2 I got the package installed on gutsy
[09:56] <proppy> norsetto_: in lp152438 i get the package upgrade from feisty to gutsy
[09:56] <ScottK> Adri2000: Yes.
[09:58] <blueyed> ScottK: thanks.
[09:59] <proppy> norsetto_: http://lp152438.aminche.com/viewvc.diff.txt
[09:59] <proppy> here is the diff between gutsy and feisty->gutsy configuration file
[10:00] <proppy>  -template_dir = /etc/viewvc/templates is removed
[10:00] <blueyed> Is this channel logged somewhere?
[10:01] <ScottK> !logs | blueyed
[10:01] <ubotu> blueyed: Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/
[10:02] <blueyed> Schnitz: I've talked with one of the tvbrowser devs today. He said that it works with icedtea-java, too - not only sun-java.
[10:04] <blueyed> Schnitz: there are already .debs available also: http://wiki.tvbrowser.org/index.php/Weitere_Pakete_-_(K)ubuntu - HTH
[10:05] <Schnitz> blueyed: thanks for your help i'll take a look at it tomorrow
[10:06] <Schnitz> blueyed: the wiki always says that it'll only work with java, the debs available there also depend on the sun java
[10:24] <proppy> norsetto_: overwriting the configuration file with the gutsy installed version
[10:24] <proppy> norsetto_: does fix the error
[10:25] <proppy> norsetto_:  the bug is related to viewcvs to viewvc configuration migration
[10:41] <proppy> norsetto: I updated bug #152438
[10:41] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Medium,Confirmed]  https://launchpad.net/bugs/152438
[10:46] <allee> siretart: hast du zufaellig eine nfsroot mit 2.6.22-14 kernel probiert?  Dell Optiplex 620 and 740 booten mit -14 nicht mehr.  3-wochen alte nfsroot mit -12 geht :(   Und -12 und -14 moegen den nagelneuen Optiplex 755 nicht.
[10:47] <allee> ich brauch 'ne muetze schlaf.  Ich schau morge mal  wo's genau klemmt
[10:48] <proppy> norsetto: I'll get back to you tomorrow with this one, next step is to figure out what is missing in viewvc configuration file migration script
[10:49] <allee> oops, that's not #fai.  Sorry
[10:49] <norsetto> proppy: can you check just by adding only this: template_dir = /etc/viewvc/template ?
[10:49] <siretart> allee: sorry, bin ich nicht dazu gekommen, bei mir geht ehrlichgesagt ziemlich drunter und drueber
[10:49] <siretart> allee: oh, a bit german doesn't hurt here ;)
[10:49] <proppy> norsetto: already checket
[10:50] <norsetto> proppy: and? Its not enough?
[10:50] <proppy> norsetto: http://lp152438.aminche.com/
[10:50] <proppy> norsetto:  adding template_dir option by applying the following patch didn't help
[10:50] <proppy> norsetto: http://hg.lp152438.aminche.com/rev/7626c04ded48
[10:50] <proppy>  overwriting viewvc.conf with the gutsy installed one does fix the error changeset: http://hg.lp152438.aminche.com/rev/aee52cf25866 http://lp152438.aminche.com/cgi-bin/viewvc.cgi/ display the correct content
[10:50] <allee> siretart: heh :) Same here.  Otherwise I would have noticed the regression.
[10:51] <norsetto> proppy: strange, everything else doesn't seem relevant
[10:52] <proppy> norsetto: if you log on the machine
[10:52] <proppy> norsetto: you can rewing the configuration file to their previous revision
[10:52] <proppy> norsetto: and check by yourself if you want
[10:53] <proppy> norsetto: hg revert -r 30 viewvc.conf
[10:53] <proppy> the whole filesystem is versionned
[10:54] <norsetto> proppy: so, if you just substitute the new conf file, everything is ok, but if you migrate the old one -> bug?
[10:54] <proppy> yep
[10:55] <norsetto> proppy: ok, so it confirms that it has nothing to do with the debian bug
[10:55] <proppy> yes and no
[10:56] <norsetto> proppy: how would you check what is it that makes the difference?
[10:56] <proppy> the debian one is fixed upstream
[10:57] <proppy> the ubuntu one is related to the same fix, which don't show up in the upgrade process
[10:57] <Kopfgeldjaeger> n8
[10:57] <proppy> don't you think ?
[10:57] <norsetto> proppy: I'm not following you
[10:58] <proppy> norsetto: some lines are missing in the upgraded configuration file
[10:59] <proppy> norsetto: I bet those lines fix the debian bug
[10:59] <norsetto> proppy: and some are changed
[10:59] <proppy> norsetto: do you follow me ?
[11:00] <norsetto> proppy: no, I really don't see what is relevant in the debian bug
[11:01] <proppy> norsetto: the debian bug is not helping us, but our future fix may help the debian bug
[11:01] <norsetto> proppy: I don't know, in any case we are fixing it for debian, as we can't upload whatever patch we come with now
[11:02] <proppy> freeze freeze ?
[11:02] <proppy> freeze is frozen ? :)
[11:02] <norsetto> proppy: as freeze as it could be
[11:03] <proppy> (10:56:23 PM) norsetto: proppy: how would you check what is it that makes the difference?
[11:03] <norsetto> proppy: I really don't see what else it could be: this: default_root = ? Doesn't seem relevant
[11:04] <ScottK> proppy and norsetto: see /topic for info on early uploads to gutsy-updates (MOTU ML for details).
[11:04] <norsetto> scottK; yeah, just saw your email to the list
[11:05] <proppy> norsetto: template_dir is added
[11:05] <proppy> and all the template line are commented
[11:05] <proppy> check at the end of the diff
[11:05] <proppy> http://hg.lp152438.aminche.com/rev/aee52cf25866
[11:05] <proppy> letme paste this somewhere
[11:06] <norsetto> proppy: yes, these are the only relevant changes
[11:06] <proppy> norsetto: http://paste.ubuntu.com/967/
[11:06] <proppy> norsetto: I do try add the template dir option
[11:07] <proppy> norsetto: but i forgot to comment other template options
[11:07] <proppy> let me try it
[11:07] <norsetto> proppy: ok, can you try it with this now? lets see if we are lucky
[11:08] <proppy> norsetto: it was definilty a good idead to version this chroot :)
[11:10] <proppy> norsetto: file reverted bug is back http://lp152438.aminche.com/cgi-bin/viewvc.cgi/
[11:10] <proppy> norsetto: let me patch it
[11:12] <norsetto> proppy: I knew I did see it before, the template_dir one is patch 102_viewvc.conf_Debian_customization
[11:14] <norsetto> proppy: assuming that just commenting the [templates]  section works, I'm not so sure we could easily patch it (of course not if it was edited)
[11:15] <norsetto> proppy: but at least it would be a good work-around solution to add it in the bug report
[11:15] <proppy> norsetto: doesn't help
[11:15] <proppy> norsetto: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/ bug still here
[11:15] <proppy> norsetto: with following patch http://hg.lp152438.aminche.com/rev/1992b51f1bdf
[11:16] <norsetto> proppy: zut ....
[11:16] <proppy> zut de zut
[11:16] <norsetto> proppy: that was done inline I guess?
[11:17] <proppy> inline ?
[11:17] <proppy> you mean I edited it by hand ?
[11:17] <norsetto> proppy: yes, you just edited the conf file
[11:17] <proppy> yep
[11:17] <norsetto> proppy: but I think you should not comment out [templates]  ..... try
[11:18] <proppy> norsetto: I don't know how to cut a diff into part
[11:18] <proppy> norsetto: I already try it :)
[11:18] <norsetto> proppy: its ok
[11:18] <proppy> i just forgot to commit between the two
[11:18] <proppy> but let me do it :)
[11:19] <proppy> norsetto: http://hg.lp152438.aminche.com/rev/77b4f44d8941
[11:20] <proppy> norsetto: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/ bug still here
[11:20] <bddebian> Later folks
[11:20] <norsetto> bye bddebian
[11:20] <proppy> bddebian: bye
[11:22] <proppy> norsetto: I must have forgot something
[11:22] <ScottK> bigon: Why are you filing sync bugs now?
[11:23] <ScottK> It is.
[11:23] <norsetto> proppy: can you try adding this: "cvsgraph_path =" and this "cvsgraph_conf = cvsgraph.conf" too?
[11:23] <bigon> ScottK: I was trying something with requestsync, I've closed the bug as wontfix
[11:24] <ScottK> bigon: OK.
[11:24] <proppy> norsetto: you noticed they commented cvsdb too ?
[11:24] <norsetto> proppy: yes, but is also in the old one
[11:25] <proppy> norsetto: let me install emacs, I can't stand vi
[11:25] <norsetto> proppy: nano?
[11:27] <proppy> norsetto: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/ still here
[11:27] <proppy> norsetto: http://hg.lp152438.aminche.com/rev/200b77115357
[11:28] <norsetto> proppy: yes, that is disabled anyhow
[11:29] <norsetto> proppy: since we are shooting in the dark, lets try "default_root = " too
[11:29] <proppy> ok
[11:29] <proppy> norsetto: just had the same idead
[11:30] <proppy> norsetto: I changed default_root and it works
[11:30] <norsetto> proppy: bastard of a conf file ....
[11:30] <norsetto> proppy: do we still need to comment out the [templates]  ?
[11:30] <proppy> http://hg.lp152438.aminche.com/rev/c56b8107f236
[11:30] <proppy> http://lp152438.aminche.com/cgi-bin/viewvc.cgi
[11:31] <proppy> letme try it
[11:31] <proppy> we must not forget to click on svn
[11:31] <proppy> to figure if it really work
[11:31] <proppy> s
[11:31] <norsetto> proppy: yes, just did that, its ok
[11:31] <proppy> let me revert the file to it upgraded state
[11:31] <proppy> and just change the default_root
[11:34] <proppy> norsetto: I get a different error http://lp152438.aminche.com/cgi-bin/viewvc.cgi/
[11:35] <proppy> with just default_root
[11:35] <proppy> I'll try to add the following one by one, template_dir, and then comment template option to figure out the minimal patch
[11:35] <norsetto> proppy: yes, template_dir is needed anyhow, try that and default_root only first
[11:37] <norsetto> proppy: it would be cool if just these two are enough, we can easily add default_root to the existing debian patch
[11:38] <proppy> root@lp152438:/etc/viewvc# hg diff -r 20 -r 30 . | patch
[11:38] <proppy> patching file viewvc.conf
[11:38] <proppy> mercurial joy :)
[11:38] <proppy> http://lp152438.aminche.com/cgi-bin/viewvc.cgi
[11:39] <proppy> it works
[11:39] <proppy> http://hg.lp152438.aminche.com/rev/3678a4e60d59
[11:39] <proppy> let me extract the patch
[11:41] <norsetto> proppy: be careful, mercury is poisonous .....
[11:41] <proppy> norsetto: http://lp152438.aminche.com/viewvc-template-fix.patch.txt
[11:42] <norsetto> proppy: thats pretty cool, we just need to modify debian patch 102_viewvc.conf_Debian_customization
[11:42] <norsetto> proppy: in line with that
[11:43] <norsetto> proppy: if you do that, and you can test again if an upgrade with that works, we are done .....
[11:44] <proppy> let me update the launchpad bug
[11:44] <proppy> with the new patch first
[11:44] <norsetto> proppy: wait .....
[11:44] <proppy> ?
[11:44] <proppy> http://lp152438.aminche.com/cgi-bin/viewvc.cgi/file?root=svn&view=log
[11:44] <proppy> yes
[11:44] <norsetto> proppy: test it properly first, you never know, there is no rush
[11:44] <proppy> you're right :)
[11:44] <proppy> following failed
[11:44] <proppy> when viewing a file it fails
[11:45] <norsetto> proppy: ok, perhaps it needs to comment out the [templates]  too then
[11:47] <proppy> yep
[11:47] <proppy> that what I thought :)
[11:47] <norsetto> proppy: if you read the comment, that actually makes sense
[11:48] <norsetto> proppy: "Templates are specified relative to the installation directory"
[11:48] <norsetto> proppy: "
[11:48] <norsetto> But if you want to
[11:48] <norsetto> +# use a different template for a particular view, simply uncomment
[11:49] <proppy> norsetto: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/file?root=svn&view=log
[11:49] <proppy> norsetto: http://hg.lp152438.aminche.com/rev/bd3f4a489700
[11:49] <proppy> it works
[11:50] <proppy> lets fix the patch
[11:50] <norsetto> proppy: so, before anything else, can you prepare a new version of patch 102_viewvc.conf_Debian_customization and check that it applies correctly during upgrade?
[11:53] <proppy> norsetto: http://lp152438.aminche.com/viewvc-template-fix.patch.txt
[11:54] <proppy> norsetto: installing dpkg-dev
[11:57] <proppy> and cdbs-edit-patch
[11:58] <pkern> imbrandon, siretart: foaf:nick for team RDF will be on edge tomorrow.
[11:59] <proppy> cdbs-edit-patch failed with
[11:59] <proppy> root@lp152438:/usr/src/viewvc-1.0.3# cdbs-edit-patch 102_viewvc.conf_Debian_customization
[11:59] <proppy> /usr/bin/cdbs-edit-patch: 30: dh_testdir: not found
[11:59] <imbrandon> pkern: rockin
[11:59] <proppy> does it lack a dependency ?
[11:59] <proppy> to debhelper
[11:59] <ajmitch> pkern: how useful
[11:59] <pkern> ajmitch: Ironic?
[12:00] <ajmitch> though I think that we wanted the schema extended for ssh keys as well, iirc
[12:00] <ajmitch> I can't recall what the bug was now
[12:00] <pkern> ajmitch: Yep, but that's IMHO not so critical because we could go to ~lpnick/+sshkeys now.
[12:00] <pkern> ajmitch: As now the lpnick information is available.
[12:01] <ajmitch> except that for a team like ubuntu-universe-contributors, it hits LP many many times
[12:01] <ajmitch> though it was ubuntu-dev that was being scraped
[12:01] <proppy> norsetto: oups norsetto the patch are quilt based
[12:01] <norsetto> proppy: yes
[12:01] <proppy> norsetto: so cdbs-edit-patch is no help here
[12:02] <pkern> ajmitch: I heared that the ssh key information in the way it was proposed is not standarised (+spelling).
[12:02] <proppy> need to find a wiki page about quilt
[12:02] <pkern> Sorry, I really have to go to bed now, it's a really painful week for me.
[12:02] <ajmitch> no, it's not
[12:02] <norsetto> proppy: wait, I have one
[12:02] <ajmitch> which is why there needed to be a special namespace for it, rather than being in foaf:
[12:02] <ajmitch> pkern: good night
[12:02] <norsetto> proppy: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[12:03] <proppy> https://wiki.ubuntu.com/MOTU/School/PatchingSources?action=show&redirect=MOTU%2FHowToPatch ?
[12:03] <proppy> ok
[12:03] <pkern> ajmitch: Thus I just pushed foaf:nick.  Because that's straightforward and now we don't need to scrape anymore.  wot was proposed as namespace, but it looked wrong, too.  Thanks and gn8 ;)
[12:03] <norsetto> hey threee link in a row, a sure sign of good luck
[12:04] <proppy> norsetto: :)
[12:04] <proppy> norsetto: quilt sounds hype
[12:04] <ajmitch> quilt is useful
[12:04] <imbrandon> pkern: where did you learn this ?
[12:04] <imbrandon> ( about the faof )
[12:05] <ajmitch> probably in a bug report?
[12:06] <imbrandon> ajmitch: would be a suprise, heh the bug was filed 8+ months ago
[12:10] <norsetto> proppy: don't forget control and changelog need to be changed too, release is gutsy-proposed
[12:14] <proppy> norsetto: wait
[12:15] <proppy> norsetto: viewvc.conf.dist template options are already commented in gutsy upstream
[12:15] <proppy> norsetto: so changing to patch won't do anything right ?
[12:15] <norsetto>  proppy: wait a sec, the bug is for feisty?
[12:16] <proppy> norsetto: feisty upgrade to gutsy
[12:16] <norsetto> proppy: yes, so what do you mean by "gutsy upstream"
[12:16] <proppy> norsetto: http://hg.lp152438.aminche.com/file/b494291f621b/usr/src/viewvc-1.0.3/viewvc.conf.dist
[12:17] <proppy> norsetto: oups in mean gutsy sources
[12:17] <proppy> I mean
[12:17] <proppy> you tell me to update 102_viewvc.conf_Debian_customization
[12:17] <norsetto> proppy: thats is the new .conf, which gets installed if its not an upgrade
[12:18] <proppy> which update the .dist file
[12:18] <proppy> it will not solve our upgrade problem
[12:18] <norsetto> proppy: ah!
[12:18] <norsetto> norsetto: so, this should go in viewvc.config
[12:19] <norsetto> I didn't know william lima left ....
[12:19] <proppy> yep was just checking it
[12:20] <proppy> norsetto: http://hg.lp152438.aminche.com/file/b494291f621b/usr/src/viewvc-1.0.3/debian/viewvc.config
[12:20] <proppy> norsetto: pretty scarry
[12:20] <norsetto> now I'm talking with myself, whats next .....
[12:21] <proppy> norsetto: they are using a python program to update the config file
[12:21] <norsetto> proppy: well : default_root="cvs" is in there
[12:21] <proppy> norsetto: http://hg.lp152438.aminche.com/file/b494291f621b/usr/src/viewvc-1.0.3/debian/viewvc-config
[12:22] <proppy> norsetto: It will not be easy to comment some line dynamicly
[12:23] <proppy> norsetto: and it really depends on how the upgrading fellow has messed up its config file
[12:23] <norsetto> proppy: thats what these two scripts are trying to deal with
[12:24] <norsetto> proppy: for instance: default_root=`/usr/lib/viewvc/viewvc-config --get default_root -c $VIEWVC_CONFIG_FILE`
[12:25] <proppy> norsetto:
[12:25] <norsetto> proppy:
[12:25] <proppy> norsetto: wait default_root works after all
[12:25] <proppy> norsetto: I've changed it in the viewvc.conf
[12:25] <proppy> norsetto: http://lp152438.aminche.com/cgi-bin/viewvc.cgi/
[12:25] <proppy> norsetto: back to svn
[12:26] <norsetto> proppy: right, so, why didn't before .....
[12:27] <proppy> wait
[12:27] <norsetto> proppy: lets do it this way for the time being, ask the reporter what  he is using for template_dir and in [templates] 
[12:27] <TheMuso> Adri2000: The thing is, ubuntustudio-look worked. What I think the problem with audacious-plugins is that audacious-plugins-extra has a pre-depends on audacious-plugins
[12:28] <proppy> norsetto: interesting
[12:28] <norsetto> proppy: ask him to change template_dirs to /etc/viewvcs/ and comment out the template dirs in ] templates]  (unless he used those)
[12:29] <norsetto> proppy: at least that would be a work-around
[12:36] <proppy> norsetto: https://bugs.edge.launchpad.net/ubuntu/+source/viewvc/+bug/152438 updated
[12:36] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Medium,Confirmed]