[00:00] <dupondje> gotto sleep, thx for the help crimsun
[00:01] <shadeslayer> jmarsden: there?
[00:02] <shadeslayer> ok if the builder says dependency wait on some-dev file,is problem at my end?
[00:02] <dupondje> oh its accepted :) thx :D
[00:03] <shadeslayer> any ideas?
[00:03] <crimsun> shadeslayer: which source package?
[00:03] <asac> shadeslayer: depends on the case ;) ... if you are wondering about this, it probably means the problem is on your end, yes.
[00:03] <RAOF> shadeslayer: That depends on whether some-dev is meant to be available in the archive.
[00:04] <shadeslayer> https://launchpad.net/~rohangarg/+archive/kde-extra/+packages << choqok karmic package
[00:05] <shadeslayer> i just sent it for a rebuild about 2 mins ago
[00:05] <RAOF> That doesn't look like it's in dep-wait?
[00:05] <RAOF> It's built successfully on lpia.
[00:06] <shadeslayer> RAOF: yeah but for amd 64 it said dep-wait on libqt4-dev
[00:06] <shadeslayer> RAOF: and btw are PPA archives expanded on requests?
[00:07] <crimsun> it doesn't say anything of that sort for the amd64 karmic build
[00:07] <shadeslayer> crimsun: yeah i sent it for a rebuild 2 mins ago
[00:07] <shadeslayer> and what about : 1 failed
[00:07] <shadeslayer> in completed builds
[00:07] <RAOF> I think he might mean kopete-facebook?  That's dep-wait for libqt4-dev, which has a versioned dependency against a version that's not in Karmic.
[00:08] <shadeslayer> RAOF: had the same error for choqok too
[00:08] <shadeslayer> RAOF: can you explain the error?
[00:08] <RAOF> shadeslayer: Does it really require libqt4-dev >= 4.6.0~rc1?  Because Karmic has 4.5.2
[00:08] <shadeslayer> RAOF: 4:4.6.0-1ubuntu3~karmic1~ppa1
[00:09] <shadeslayer> RAOF: in : 500 http://ppa.launchpad.net karmic/main Packages
[00:09] <shadeslayer> RAOF: does this mean itll not build? or its just searching for that package?
[00:09] <RAOF> shadeslayer: Yeah, but your PPA isn't building against that other random PPA; It's grabbing the libqt4-dev from the official archives, which have 4.5.2.
[00:10] <shadeslayer> RAOF: so,will it build eventually?
[00:10] <RAOF> No, it won't.
[00:10] <crimsun> i.e., local repos have no bearing on repos available to your PPA
[00:10] <shadeslayer> RAOF: ok so how do i get the required dep?
[00:10] <crimsun> (could you imagine the chaos otherwise?)
[00:10] <RAOF> If you add the PPA which contains 4.6.0 as a dependency of your PPA then it will build.
[00:11] <RAOF> (And people who don't have that PPA in their sources.list won't be able to install your packages)
[00:11] <shadeslayer> RAOF: where do i add this? im new to building stuff :P
[00:11] <shadeslayer> RAOF: ok ill mention it in the PPA description
[00:11] <RAOF> It's somewhere in the PPA setup page; I forget quite where.
[00:12] <shadeslayer> ok
[00:12] <shadeslayer> found it :)
[00:21] <shadeslayer> and on what basis are PPA sizes increased?
[02:05] <crimsun> Uploaders.gz, nice.
[02:08] <ajmitch> crimsun: hm?
[02:08] <crimsun> ajmitch: just musing over bits from planet.debian, 'tis all
[02:09] <ajmitch> ah, I probably glanced at that post at some point
[02:09] <ajmitch> or the rss client has yet to catch up :)
[02:11] <ajmitch> now to convince wgrant to add it to soyuz...
[02:18]  * wgrant is home now.
[02:19] <ajmitch> wgrant: a nice quiet flight back?
[02:23] <wgrant> ajmitch: The first was quite full, but the second not so much.
[02:25]  * ajmitch went along to the open day on saturday for a bit, which was sort of interesting
[02:26] <wgrant> Wellington seems to like pouring during the weekends.
[02:28] <ajmitch> yeah, the weekend wasn't exactly useful for exploring wellington
[02:29] <wgrant> We did wander around quite a bit on Saturday, while it wasn't raining.
[02:30] <StevenK> ajmitch: Sort of useful?
[02:30] <ajmitch> for about 5 minutes then?
[02:30]  * StevenK had to leave the hotel at 4am for his flight
[02:31] <wgrant> ajmitch: More like 5 hours.
[02:31]  * ajmitch is glad he had a 7pm flight yesterday
[02:31] <ajmitch> much easier to be awake then, and not have to stay up all night
[02:31]  * wgrant was on the wonderful 6am flight too.
[02:33] <ajmitch> now it's back to work, with a large pile of stuff to catch up on
[02:38] <StevenK> ajmitch: Ditto.
[02:38] <StevenK> wgrant: Ouch
[02:47] <ajmitch> StevenK: since you hassled me about not doing much ubuntu work, got anything in mind that I should look at? :)
[02:55] <StevenK> ajmitch: FTBFS? :-)
[02:56] <ajmitch> ah, the rusty spoon option
[02:57] <crimsun> speaking of which, why was libglade2.0-cil-dev demoted to universe?
[02:57] <crimsun> some mono packages in main now FTBFS
[02:58] <crimsun> even stranger, it only appears to have been demoted on i386? ...
[02:58] <persia> Maybe an accept accident?
[02:59] <crimsun> well, I haven't updated in a couple hours, so I could be outdated
[02:59] <persia> ajmitch: If you want something simpler than FTBFS, NBS is always a good way to pass a few hours.
[03:01]  * ajmitch sees a lot of zope.* packages in depwait
[03:01] <persia> That would be the python-van merge.
[03:01] <ajmitch> it requires a merge now? I'm seeing 1.3.0-3 on my lucid VM
[03:02]  * persia gets confused and looks again
[03:02]  * ajmitch doesn't know how often the autosync is still running
[03:02] <ajmitch> https://edge.launchpad.net/ubuntu/+source/van.pydeb claims it was updated 38 hours ago, but the zope.* packages already want something newer
[03:03] <persia> Indeed, it needs a sync.  I wonder how that worked, as it should have been caught in sid -> testing.
[03:04] <ajmitch> I won't bother filing sync bugs for those ones just yet
[03:04] <persia> Somehow the zope stuff migrated 17th Jan, and python-van.pydeb not until Saturday.
[03:05] <ajmitch> odd
[03:05] <persia> So probably just needs the archive-admin of the day to run a script (which shouldn't happen for many hours, given the identity of the AAotD, and their local timezone)
[03:05]  * ajmitch doesn't know the archive admin rotation
[03:06] <persia> Indeed.  Maybe it identifies some issue with sid->testing, because it's based on binary promotion, and doesn't guarantee buildability.
[03:06] <persia> https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[03:06] <ajmitch> thanks
[03:07]  * ajmitch wonders if james_w is even back home yet
[03:07] <ScottK> I lot of Zope stuff is in churn right now due to python2.4 removal in Debian.
[03:07] <ScottK> I/A
[03:07] <persia> NCommander: Are you up for some bootstrapping today?
[03:07] <RAOF> crimsun: libglade2.0-cil-dev is new, and arch:all (as are the rest of the -cil-dev packages).  We in the debian-cli team probably need to pay a bit more attention to what's happening in Lucid.
[03:08] <ScottK> python-stdlib-extensions finally built on mips, so we should see python2.6 in Testing tomorrow.
[03:08] <crimsun> RAOF: yeah, the rmadison output threw me
[03:10] <ajmitch> ScottK: so the binNMU list will get processed sometime soon in debian, and things will settle down?
[03:10]  * ajmitch has been following debian-python a bit
[03:10] <ScottK> ajmitch: For a fairly wild definition of settle down, I imagine.
[03:10] <ajmitch> but not -release
[03:11] <ajmitch> I'm sure it'll be smooth & ponies will rejoice, etc
[03:11] <ScottK> The binNMU list for dropping 2.4 was ~40 packages.  The binNMU list for adding 2.6 is over 300.
[03:21]  * james_w is not here, but can run an auto-sync
[03:22] <ajmitch> james_w: sorry, wasn't meaning to wake you from your jetlag or holiday :)
[03:22] <james_w> no problem :-
[03:22] <james_w> )
[03:23] <ScottK> As long are you aren't breaking any of your rules about logging into the server holding the actual Ubuntu archive...
[03:24] <james_w> heh, I think that rule has to be based on local timezone, or it would be too confusing :-)
[03:25] <ScottK> The one I was thinking of was based on blood alcohol content.
[03:26] <james_w> oh yeah, it's a little too early in the day for that to be a worry
[03:26] <ajmitch> if you're still in NZ, then surely it's not too early?
[03:27] <persia> Somehow that says more about NZ than about the time of day
[03:27] <ajmitch> persia: true :)
[03:27] <ScottK> It's always after 5PM somewhere.
[03:30] <persia> Maybe I'm missing somewhere, but I don't think it's after 5PM Monday anywhere right now.
[03:31] <persia> (should be about 16:45 furthest east)
[03:31]  * ScottK didn't specify a day.
[03:31] <ajmitch> persia: currently 17:15 in the chatham islands
[03:31] <persia> ajmitch: I keep forgetting about them, and their special summer timezone.
[03:33] <ajmitch> most people would forget about them
[03:33] <persia> Well, it's only in the summer that it matters.  In the winter they have a more westerly timezone, and fall behind other places.
[04:32] <shadeslayer> good morning :)
[04:50] <NCommander> persia, of what?
[04:50] <persia> fp-compiler on powerpc
[04:52] <persia> NCommander: Essentially, it means stripping down the fpc source, building just fp-compiler, and then installing that result to be able to build fpc (which includes all the libraries).
[04:52] <NCommander> persia, *cries*
[04:52] <NCommander> persia, my PPC is semidead though :-/
[04:53] <persia> NCommander: I thought that bootstrapping had to be done on the buildds.  If I give you some signed .debs, would that work?
[04:55] <NCommander> persia, I can give lamont done debs, then he does a rebuild, but I can't do binary uploads
[04:55] <NCommander> unless I have powers of which I'm thus unaware of
[04:55] <persia> NCommander: Ah.  I picked on you because you're listed as in the assigned team for the bug :)
[04:56] <persia> But if you could pass on bug #67544 that would be lovely.  I'm happy to generate a .deb if it helps, but I'm not convinced the buildds *should* trust me.
[05:15]  * james_w would like to remind everyone that we are still in the autosync time, and so don't need bug reports for syncs of unmodified packages
[05:17] <james_w> oh, I see what's going on
[05:18] <persia> unstable?
[05:18] <james_w> yeah
[05:19] <persia> While it's tempting to call it impatience, I know that we've seen a few things that FTBFS or DEPWAIT because sid->testing doesn't seem to check build-deps.
[05:25] <james_w> I'm happy that it now takes longer for the automated parts of sync processing than the manual parts though
[05:26] <StevenK> \o/
[05:26]  * StevenK fixed that bit
[05:29] <persia> Adding several "sleep 300" calls to the automated part?
[05:30] <StevenK> persia: No, I wrote a script that automated large parts of the manual syncs
[05:30] <persia> Oh, cool.
[05:31] <StevenK> persia: Which james_w fixed to be even cooler
[05:32] <persia> So, last I remember one just fed a bug number, and it did stuff.  Does it now automatically grab the bugs from LP rather than requiring one to type the numbers?
[05:33] <StevenK> persia: That's the first script. I wrote a script that grabbed the bugs from LP and spat out lines suitable to be fed to the first script.
[05:34] <persia> And it somehow detects when they are requests from unstable/experimental/testing?
[05:34]  * persia remembers pain on this point previously
[05:34] <StevenK> No, you can switch it, and it changes the output
[05:35] <persia> Oh, so the script only pulls bugs from LP that match some specific debian pocket?
[05:35] <StevenK> persia: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/sync-helper.py
[05:36] <hyperair> am i allowed to call apt-get source within debian/rules?
[05:36] <StevenK> hyperair: No
[05:36] <hyperair> =(
[05:36] <hyperair> hmm this makes it a tad bit harder..
[05:36] <StevenK> hyperair: Well, explain why you want to?
[05:36] <persia> Um, why not?  It should be fine as long as something has been arranged so it doesn't need network access.
[05:36] <hyperair> StevenK: i'm working on packaging poppler-sharp
[05:37] <hyperair> StevenK: poppler-sharp generates bindings based on the poppler code.
[05:37] <StevenK> persia: You can't expect that it has on the buildds, for example
[05:37] <persia> That's what build-dependencies are for :)
[05:38] <hyperair> StevenK: i'm thinking it might be nice to use apt-get source to get the most current poppler source code so rebuilds are easy if poppler gets updated.
[05:38] <persia> But the better way to solve it is to either build-dep on some poppler binary (generating a poppler-source binary is the least good way: doing it from header analysis probably easiest).
[05:38] <hyperair> header analysis?
[05:38] <persia> OR to have poppler-sharp be a patch against the poppler source and build as part of that.
[05:39] <hyperair> hmm
[05:39] <hyperair> that's an interesting idea.
[05:39] <hyperair> i hadn't thought of that
[05:39] <persia> Sure.  Presumably poppler exports some headers so stuff can build against it's C API.  Those should describe everything you need for bindings.
[05:39] <hyperair> good point, i'll try looking into that
[05:39] <persia> Investigating the other code is just asking to end up exposing a private interface that changes without warning.
[05:39] <hyperair> what does gapi2-parser look at?
[05:40] <RAOF> The headers.
[05:40] <hyperair> alright. i'll see if i can force it to make do without the source then
[05:41] <persia> StevenK: That is nifty.  I can think of ways to abuse it ("Please never, never sync this"), but it must save heaps of time.
[05:41] <StevenK> persia: The script has a "Skip" for that
[05:41] <RAOF> hyperair: Actually, poppler-sharp does that analysis at build-time?
[05:42] <hyperair> RAOF: yes
[05:42] <hyperair> http://github.com/jacintos/poppler-sharp
[05:42] <hyperair> there isn't a tarball release
[05:42] <persia> StevenK: That's not what I'm talking about (although, yet), but I'm not going into details here (plus I'll stop distracting you).
[05:43] <RAOF> hyperair: Ah.  Generally, gapi users ship the pre-extracted raw symbols; that's how gtk#, gnome#, etc do it.
[05:43] <hyperair> i see.
[05:44] <hyperair> RAOF: should i convince the author to do that, or generate a tarball with pre-extracted raw symbols?
[05:44] <RAOF> It's entirely possible that you want to generate the raw xml as a part of constructing the original tarball, given that you'll need to generate the tarball anyway.
[05:45] <RAOF> Heh.  Too slow.  Yes, I'd generate the raw xml and shove it in the original tarball.  Convincing upstream to ship the raw xml is probably a good idea, too.
[05:45] <RAOF> Um... they already *do*
[05:45] <RAOF> http://github.com/jacintos/poppler-sharp/blob/master/poppler-sharp/poppler-api.raw
[05:46] <RAOF> I don't think you actually need to have the poppler source available at build time.
[05:46] <hyperair> RAOF: oh yeah, you're right!
[05:46]  * hyperair facepalms
[05:47] <hyperair> i was reading too much into the README
[05:48] <RAOF> You may need to do steps (2) & (3) when generating the tarball, depending on how rapidly poppler's API changes.
[05:49] <hyperair> hmm
[06:49] <dholbach> good morning
[06:55] <shadeslayer> dholbach: mornin
[06:55] <dholbach> hi shadeslayer
[08:15] <runasand> hm, how long does it usually take before a package is synced from debian to ubuntu? Or is this something I need to file a bug for? :)
[08:18] <shadeslayer> dholbach: whats : https://wiki.ubuntu.com/MeetingLogs/devweek1001/AdoptUpstream
[08:19] <dholbach> shadeslayer: Jorge and I will talk about https://wiki.ubuntu.com/Upstream/Adopt
[08:19] <dholbach> brb
[08:20] <shadeslayer> ok
[08:26] <randomaction> runasand: if the package is in testing and Ubuntu version has no Ubuntu-specific changes, it usually takes 1-2 days
[08:26] <runasand> randomaction: ok, thanks :)
[09:02] <shadeslayer> how long does it take to be a MOTU?
[09:03] <shadeslayer> *become a
[09:16] <persia> shadeslayer: There's no time rule, but there is a typical expectation of having been involved in Ubuntu Development for a complete development cycle (although there have been exceptions).
[09:35] <dholbach> I personally like the question "how long until I can start contributing?" better :-)
[09:38] <persia> But that has the simple answer "No time at all, you can do it today" :)  Plus, shadeslayer was already working on the kopete-facebook update and backport
[09:38] <persia> (and maybe other stuff I didn't see)
[11:50] <hyperair> mok0: could i bother you with bug #511375? =)
[12:03] <mok0> hyperair: 2 secs
[12:20] <SevenMachines> hi there, i was looking to merge gstreamer0.10-plugins-bad from debian unstable but the lv2 plugin fails all its tests. is it better to leave it in even though its probably broken or disable it? http://paste.ubuntu.com/362562/
[12:21] <persia> SevenMachines: You may have identified why it FTBFS on all arches (see http://qa.ubuntuwire.com/ftbfs/)
[12:22] <persia> Does lv2 work even though it fails the tests?  Maybe we need newer lv2 libs?
[12:22] <persia> ScottL: Do you know anything about gstreamer & LV2 ?
[12:24] <SevenMachines> i fixed the FTBFS with 0.10.17-1ubuntu2 but it was recommended to merge with sid since it essentially contains the same patches but also fixes a crash they introduce
[12:26] <SevenMachines> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549189. i guess it shopuld be disabled then
[12:28] <persia> heh.  So if you merge 0.10.14-4, you disable with no crash :)
[12:29] <persia> And if ScottL (or someone) can figure it out, it can be re-enabled (I pick on ScottL because I know he was working on lv2 stuff)
[12:30] <SevenMachines> 0.10.14-4 isnt even in sid yet for whatever reason, 0.10.14-3 with lv2 disabled should be ok though?
[12:31] <persia> Erm, we've both missed something critical :)
[12:31] <persia> 0.10.14-4 << 0.10.17-3
[12:31] <SevenMachines> :)
[12:32] <SevenMachines> i'll give it a test with lv2 enabled and see what happens, i'll probably disable it though unless someone who knows about these things thinks different
[12:33] <persia> Really, I think you need to connect with ScottL, if you can.
[12:33] <persia> There may be someone else, but that's the name that shows up with LV2 the most in my logs.
[12:33] <persia> You might need a newer LV2 or something, but I'm not sure.
[12:36] <MohammadRRR> Hi , I Have A Lot Of Deb Files And I Have Created Packages.gz file now i want to create Release File What Should I do ?
[12:36] <persia> Capitalise less?
[12:36] <persia> Aside from that, apt-ftparchive is a quick'n'dirty way to do things.
[12:37] <mok0> hyperair: you need sponsorship I guess...
[12:37] <hyperair> mok0: yeah i do.
[12:37] <MohammadRRR> persia : could you plarese help me what should i exactly Enter . i am a beginner
[12:38] <mok0> hyperair: great, I'll take a look after lunch
[12:38] <hyperair> thanks =)
[12:38] <persia> MohammadRRR: I don't remember precisely.  `man apt-ftparchive` may be useful.  You may also want to try the support channel (#ubuntu)
[12:39] <MohammadRRR> persia : First i have gone there but they said I sould come here . i have read the manual but i have not learn anything please help
[12:41] <persia> Hrm.  Well, I don't remember precisely, so I'm not the best person.  We don't generally create archives here (we use Soyuz), but maybe someone else can help you.
[12:42] <mok0> MohammadRRR: usually the tools create the Packages.gz etc files
[12:53] <SevenMachines> looks like libgstlv2 really does segfault gstreamer, its not just failing tests
[12:54] <persia> Can you get a stacktrace?  Is it just unsafe coding and easy to fix?
[12:54] <shadeslayer> persia: hey
[12:55] <persia> shadeslayer: Hey.
[12:55] <shadeslayer> persia: ive built packages for lucid and need sponsors for updating the packages there... where do i find motu sponsors?
[12:55] <shadeslayer> persia: file a bug in launchpad?
[12:55] <persia> !sponsorship
[12:55] <persia> !sponsor
[12:55] <persia> Grr.
[12:55] <shadeslayer> https://wiki.ubuntu.com/SponsorshipProcess
[12:56] <persia> Right.
[12:56] <shadeslayer> yeah as it says.. file a bug,against what?
[12:57] <persia> shadeslayer: The package that has the "problem"
[12:58] <shadeslayer> persia: ah ok
[12:58] <shadeslayer> was reading https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[12:58] <shadeslayer> persia: do i give them a link to my PPA too where the package is being held?
[12:58] <shadeslayer> or do i attach the files..
[12:59] <persia> I usually prefer a debdiff against the current source, or an attached diff.gz for an update.
[12:59] <shadeslayer> hmm
[13:01] <SevenMachines> persia: i'll try and get a trace, i can see why debian never actually put it in the .install though, although they do build it
[13:01] <persia> SevenMachines: If you install pkg-create-dbgsym in your local builder, it gives you ddebs, which can be handy for that.
[13:02] <persia> Do you know how to track down the crash once you get the trace?
[13:02] <SevenMachines> probably not
[13:03] <persia> Well, if you can get a trace (with symbols) within the next hour, ask me, and I'll debug it with you.
[13:03]  * geser sees persia giving an ad-hoc "Interpreting stack trace" session :)
[13:03] <persia> If it takes longer, ask here and maybe someone else will.
[13:03] <persia> geser: That's the way I prefer them, really.  Nobody asks enough questions in formal sessions.
[13:04] <geser> yes, it's often easier to learn from own cases (you're more interested)
[13:05] <SevenMachines> i've seen enough stack traces in my own c++ stuff but i know literally nothing about gstreamer
[13:06] <persia> Doesn't matter.  Code is code.  I remember foolishly picking an ObjC crash for a session once, and it ended up that the attendees (largely geser, IIRC) helped me understand it :)
[13:06] <persia> At the final stage, when you find the problem function, then you need to know, but at that point the entire framework doesn't much matter anyway.
[13:25] <mok0> hyperair: "patch unexpectedly ends in middle of line"
[13:25] <hyperair> huh?
[13:25] <hyperair> O_o
[13:25] <hyperair> how are you getting that?
[13:26] <mok0> hyperair: patch -p1 < ../codelite-debdiff
[13:26] <hyperair> weird..
[13:26] <mok0> hyperair: it successfully patched 3 files
[13:27] <mok0> hyperair: "Hunk #3 succeeded at 40 with fuzz 1."
[13:28] <hyperair> hmm
[13:28] <hyperair> maybe the uploaded package to the archive does not match my local git tree
[13:28] <mok0> hyperair: I'm concerned that debian/patches/03_move-helper-binaries.patch might be screwed up
[13:28] <hyperair> it was screwed up
[13:28] <hyperair> that's the cause of the bug.
[13:28] <mok0> hyperair: can you send me the proper one?
[13:29] <hyperair> http://paste.ubuntu.com/362595/
[13:29] <hyperair> gimme a moment to dget codelite
[13:35] <hyperair> mok0: the patch uploaded seems to be screwed up for some reason or other. weird.
[13:36] <mok0> hyperair: I think it's a missing newline at the end
[13:36] <hyperair> http://paste.ubuntu.com/362600/
[13:36] <hyperair> use this instead
[13:36] <hyperair> i generated it the same way
[13:36] <hyperair> i'm thinking something happened while i was uploading the attachment
[13:36] <mok0> hyperair: ok
[13:37] <hyperair> yeah it seems to be missing a newline.
[13:37]  * mok0 tries again
[13:37] <hyperair> weird. i wonder if thunderbird's whacking up my patches..
[13:39] <mok0> hyperair: patch works now w/o problems
[13:40] <hyperair> mok0: that's good =)
[13:40] <mok0> hyperair: doing a test build now...
[13:40] <hyperair> that can take a while, depending on the machine =p
[13:41] <mok0> hyperair: I know, I've compiled codelite several times :-)
[13:41] <hyperair> figures =p
[13:41] <mok0> hyperair: my machine is pretty fast though
[13:41] <hyperair> that's good
[13:41]  * hyperair uses ccache to compensate
[13:41] <mok0> hyperair: it's a quad6600
[13:41] <hyperair> that is fast
[13:41] <hyperair> i had to undervolt my CPU to get codelite to testbuild on my notebook
[13:42] <hyperair> there are only two compilations that can drive my CPU that mad -- codelite, and the kernel.
[13:42] <mok0> hyperair: I've had it a couple of years now, I'm still very happy with it
[13:42] <mok0> heheh
[13:42]  * hyperair still runs a dual core..
[13:43] <mok0> the q6600 was the best price/performance cpu you could buy for a long whle
[13:43] <mok0> Haven't checked TomsHardware for a while now
[13:43] <hyperair> hmm
[13:43]  * hyperair didn't go shopping for desktops
[13:44] <hyperair> live in a dorm overseas, can't drag that many things along with me
[13:45] <mok0> hyperair: you don't have to. Have you ever heard about something called "Internet" :-D
[13:45] <hyperair> mok0: mm yeah. it's a very familiar sounding word. i wonder what it was again..
[13:45] <hyperair> =p
[13:45] <mok0> :)
[13:45] <hyperair> my desktop's still going strong
[13:45] <hyperair> my single-core P4
[13:45] <hyperair> ;-)
[13:46] <mok0> hyperair: nice and CO2-friendly
[13:46] <hyperair> well everything about it except the CMOS battery holder which doesn't seem to want to connect my CMOS battery to the motherboard (so when it's unplugged, the clock resets), and the stupid nvidia GPU flickering away..
[13:46] <persia> CO2-friendly?
[13:47] <hyperair> but i'm sure the nvidia GPU flickering is a fault of the stupid legacy driver.
[13:47] <mok0> persia: uhm, older CPUs tend to use a lot less energy
[13:47] <hyperair> mok0: do they?
[13:47] <mok0> Yeah
[13:47] <hyperair> mok0: iirc multicores use less..
[13:48] <hyperair> because they can run at lower frequencies, yada yada
[13:48] <persia> It really depends on the CPU.
[13:48] <hyperair> oh it doesn't help that acpi-cpufreq conveniently removed support for my CPU.
[13:48] <Laney> I thought P4s weren't so good on energy consumption
[13:48] <mok0> hyperair: yes that's true. Hmm, I guess you have to go back to P3's to get a lot lower power consumption
[13:48]  * persia has single-cores that run <1W and multicores that run >70W and vice-versa
[13:48] <hyperair> O_o
[13:48] <hyperair> 70W?
[13:48] <hyperair> i can power several notebooks with that you know?
[13:49] <hyperair> like three notebooks.
[13:49] <mok0> 70W is what I've read
[13:49] <hyperair> three notebooks playing music and compiling kernels at the same time
[13:49] <mok0> hyperair: indeed
[13:49] <persia> hyperair: There are >100W processors available, if you have the cooling.
[13:49] <hyperair> with maximum panel brightness
[13:49] <persia> Lowest number I've ever seen is 0.2W
[13:49] <hyperair> 0.2 is tiny
[13:49] <hyperair> seriously tiny.
[13:49] <mok0> persia: for what....?
[13:49] <mok0> persia: ARM?
[13:50] <hyperair> that'd explain why our ARM buildds are so slow =p
[13:50] <persia> ARM & SH both get that low.
[13:50] <hyperair> (at least, i think it was arm that was slow)
[13:50] <persia> The ARM buildds aren't anything so low :)
[13:50] <mok0> I think the marvell wall-plug server uses a couple of watts
[13:50] <persia> sparc seems slowest from my "rebuild foo on all arches" tests.
[13:50] <persia> SheevaPlug?  I think that's 5-10 or so.
[13:51] <mok0> persia: OK, I stand corrected
[13:51] <persia> Unfortunately, dist-upgrade to karmic on that crashes hard.
[13:51] <hyperair> ouch.
[13:51] <mok0> persia: is that a kernel related issue?
[13:51] <hyperair> speaking of dist-upgrade, i should probably dist-upgrade to lucid one of these days.
[13:51] <mok0> hyperair: ugh
[13:52] <hyperair> mok0: is lucid in a bad state at the moment?
[13:52] <mok0> hyperair: I dont know.... karmic was in a pretty poor shape even at release time
[13:52] <persia> mok0: ISA issue  The processor doesn't support the ISA used for armel in karmic.  Like trying to run Karmic on an i386
[13:52] <hyperair> mok0: but karmic now is splendid!
[13:52] <hyperair> mok0: and i was pretty happy with karmic from the betas all the way up
[13:52] <hyperair> make that alphas
[13:53] <mok0> hyperair: it's fine now
[13:53] <mok0> I've become very sceptical about the fixed release schedule
[13:53] <hyperair> i'd say karmic's the best ubuntu release since intrepid.
[13:53] <hyperair> but yeah, the fixed release schedule is a little annoying sometimes.
[13:53] <hyperair> perhaps we need to push freezes earlier?
[13:53] <persia> kernel doesn't work either, but due to the annoyances of ARM kernels, you basically need a separate kernel for *every* board, and there's only a couple supported in the archives.
[13:54] <persia> We need to push testing harder.
[13:54] <mok0> Yes
[13:54] <persia> Way back when, we used to close lots of the bugs.
[13:54] <mok0> Now it doesn't matter how many bugs are open
[13:55] <mok0> Release before all
[13:55] <persia> Now, we have lots and lots of bugs, and lots of people don't even bother to try to get all the merges done immediately or fix all the NBS / FTBFS right away.
[13:55] <persia> No, it was Release-on-Release-Day back then too.
[13:55] <persia> We just tried harder.
[13:55] <mok0> persia: "well, we can always fix those bugs in the next release"
[13:55] <hyperair> afaik 6.06 was pushed back
[13:55] <hyperair> i mean why wasn't it 6.04?
[13:56] <hyperair> maybe we should do the same for lucid.
[13:56] <persia> I don't think it's worth it.  it didn't help much for Dapper.
[13:56] <mok0> There should be 1 year of development for the LTS
[13:56] <persia> Things age too quickly for that.
[13:56] <hyperair> agreed
[13:56] <persia> Essentially, there's 2 years of development for an LTS.
[13:56] <persia> But it's a mindset thing.
[13:57] <mok0> persia: how's that?
[13:57] <persia> Well, right now FTBFS and NBS are full of stuff.  Those need clearing.
[13:57] <hyperair> i can't seem to bring myself to spend the effort backporting things all the way down to hardy in my PPA despite it being a LTS
[13:57] <persia> Once clear, we should chase UEHS.
[13:57] <hyperair> what's NBS?
[13:57] <hyperair> and UEHS?
[13:57] <persia> If that's clear, then it becomes worth doing things like piuparts testing or autopkgtest.
[13:58] <persia> But if we're not even keeping up with NBS and FTBFS, it's hard to suggest doing more QA stuff to make sure the release is clean.
[13:58] <persia> hyperair: NBS is stuff no longer built from source.  Transitions.
[13:58] <hyperair> i see.
[13:58] <persia> So if Package A used to build libfoo1 and now it builds libfoo2, we need to migrate everthing.  The NBS page lists everything needing work.
[13:59] <persia> UEHS is the Ubuntu External Health System.  For all the packages that aren't maintained in Debian, it checks what has watch files, and tells us what we need to merge directly with upstream (as opposed to just what we need to merge from Debian).
[14:00] <hyperair> i see.
[14:00] <persia> In my opinion, if we manage a release with clean FTBFS, NBS, UEHS, and rcbugs, we'll be in very good shape.
[14:00] <persia> But it's been a while since we managed that.
[14:00] <mok0> persia: I agree, but there's no concerted effort
[14:00] <persia> hyperair: If you want more info: read https://wiki.ubuntu.com/UbuntuDevelopment/NBS
[14:01] <hyperair> i should spend some time looking at these lists. i admit i haven't actually looked much
[14:01] <persia> mok0: How do you think it should be concerted?  In the past, we used to just put QA tools in the /topic, and people did them.
[14:01] <mok0> persia: I don't see the MOTU working as a team anymore
[14:01] <persia> How can we improve that?
[14:02] <mok0> persia: I don't know... but now the MOTU team seems to be disbanded anyways
[14:02] <hyperair> aren't the MOTU disappearing?
[14:02] <ScottK> No
[14:02] <hyperair> yeah like that
[14:02] <mok0> yep
[14:02] <hyperair> disbanding.
[14:02] <ScottK> That was the plan at one point, but not anymore.
[14:02] <hyperair> oh it isn't?
[14:02] <hyperair> so what's the plan now?
[14:03] <ScottK> The plan is that we're working on a plan, but it ought to look a lot like what we had before, but with combined SRU/release/sponsorship teams.
[14:03] <persia> The discussion is very current, and likely to come to conclusion on 2nd February.  https://wiki.ubuntu.com/Specs/MOTULucid has more.
[14:03] <persia> Err. https://wiki.ubuntu.com/Specs/LucidMOTU
[14:04] <hyperair> aj
[14:04] <hyperair> ah*
[14:04] <persia> The DMB is expected to review that spec on the 2nd, and we should understand the future more clearly.
[14:04] <mok0> That discussion has been going on waaay too long, and without the participation of the MOTU team
[14:04] <persia> But, yeah, I think the uncertainly (since Intrepid) hasn't helped any.
[14:05] <ScottK> mok0: We had a session at the last UDS that had a lot of MOTU participation.
[14:05] <persia> mok0: I'm not sure that's accurate.  Many MOTU have been involved in the discussions.  I know I've been vocal, and I've seen others.
[14:05] <mok0> persia: ... out of the 80+ motus?
[14:05] <persia> And lots of MOTU participation at the UDS sessions in Prague and Mountain View as well.
[14:05] <ScottK> persia: That's true, but I think that it's also fair to say a lot of the work was done in isolation from MOTU.
[14:05] <persia> mok0: Well, let me ask you this: why haven't you been involved in the discussions?
[14:05] <hyperair> are there only 80+ MOTUs? i thought there were more than that
[14:06] <ScottK> No, and many of those aren't active.
[14:06] <mok0> persia: Things have been discussed at the UDS'es like you say.
[14:06] <mok0> persia: ... and I haven't been able to go
[14:06] <persia> ScottK: I think that's a perception thing.  I feel like I've been involved in a lot of the discussions, and not because of any non-MOTU roles I may have.
[14:07] <persia> mok0: Well, w.u.c/ArchiveReorganisation was drafted on the wiki, and mostly discussed in #ubuntu-devel or #ubuntu-meeting during TB meetings.
[14:07] <ScottK> I think the MC was much more involved than MOTU in general.
[14:07] <mok0> ScottK: I think you are right
[14:07] <persia> I think that was true, but aside from one teleconference, I believe that's been a matter of self-selection.  Some MC members have not been very involved.
[14:08] <ScottK> persia: The reason I scheduled the future of MOTU session at the last UDS was this very concern.
[14:08] <ScottK> It may just be that I wasn't aware of how to be involved before.
[14:08] <persia> It's like anything else: speak up and do stuff.
[14:08] <persia> But yeah, I don't think there was any call for participation or anything.
[14:08] <sistpoty|work> hi folks
[14:09] <mok0> It's very difficult to become involved in a discussion that nobody really knows anything about
[14:09] <persia> I think that's part of why it's taken so long, because nobody really knew.
[14:09] <persia> It takes discussion to come to conclusion.
[14:09] <mok0> The feeling is that it's something decided by the "higher-ups" and canonical
[14:10] <sistpoty|work> DktrKranz: thanks for sponsoring my nmu for ktoon! :)
[14:10] <xteejx> Waht is the standard for Ubuntu packages. Is it "all files except the binary to run the program go in /usr/share/, and the executable binary goes is usr/bin"? Or is it something else?
[14:10] <sistpoty|work> xteejx: it's FHS (documents can be found in debian-policy package)
[14:10] <persia> See, I've always believed there are no "higher-ups" in MOTU.  I even consider MC mostly having a judicial or review role.
[14:10] <xteejx> Ok, I'll Google
[14:11] <xteejx> Now I know what to look for..thank you :)
[14:11] <mok0> persia: that may be true on paper
[14:11] <sistpoty|work> xteejx: "file hierarchy standard" should give you good results ;)
[14:11] <xteejx> sistpoty|work: Great! Thank you :)
[14:11] <persia> And the Ubuntu Governance stuff explicity restricts Canonical from making some classes of decisions (although Canonical has a huge influence, and many decisions are taken by Ubuntu people who are involved with Canonical).
[14:11] <mok0> persia: that fact is that some ppl carry more weight than others
[14:12] <persia> Well, I like to think that's because of what those people do.
[14:12] <persia> Like I think ScottK carries huge weight because he's willing to speak up on lots of things.
[14:12] <mok0> persia: circle completed
[14:12] <persia> Right, but that's not something externally imposed.
[14:12] <persia> Anyone who does stuff carries weight.
[14:13] <persia> I picked on ScottK precisely because he doesn't have that many formal roles right now.
[14:13] <mok0> persia: that proposal doesn't come from ScottK
[14:13] <persia> Which proposal?
[14:14] <mok0> persia: disband MOTU proposal
[14:14] <sistpoty|work> motu will go away?
[14:14] <ScottK> No, but the one persia pointed to did happen because I pushed at UDS for something like it.
[14:14] <ScottK> sistpoty|work: No
[14:14] <sistpoty|work> ah, good :)
[14:15] <persia> As far as I know, that proposal comes from sabdfl thinking nobody would want to be negatively defined, and nobody being able to come up with a positive definition until ScottK did.
[14:15] <persia> ("Can only upload to packages not considered special" being an example of negative defintion)
[14:15] <mok0> What I'm saying is that the discussion itself is detrimental to the morale of the team
[14:15] <ScottK> Personally I can't find the difference between that and packages not in Main/Restricted.
[14:16] <ScottK> mok0: I completely agree.
[14:16] <persia> There isn't one.
[14:16] <persia> mok0: Absolutely, and I think it's shown effects in the quality of what we ship.
[14:16] <mok0> We are seeing the result of that with the poor state of karmic at release time
[14:16] <persia> Hardy was the best universe we've shipped in my opinion.
[14:17] <persia> So, if we want to keep MOTU, we need to step up and say things.
[14:17] <DktrKranz> sistpoty|work: np, it will be accepted later tonight, though
[14:17] <mok0> persia: yes, fortunately
[14:17] <sistpoty|work> DktrKranz: yes, read that :)
[14:17] <DktrKranz> :)
[14:18] <mok0> persia: well, the MC ceased
[14:18] <persia> Well, that's because we don't have quorum.
[14:18] <persia> And we didn't want to have an election with the uncertainty, because we didn't think the right people would get nominated or selected.
[14:18] <mok0> persia: If you prefer to put that way... the consequences are the same
[14:18] <persia> If you really want to push for an MC election, reply to my mail.  We can have one.
[14:19] <ScottK> mok0: MC != MOTU
[14:19] <persia> I'm not special in MOTU just because I'm MC, until it gets to the point where oversight is required.
[14:19] <persia> And I fully expect ALL MOTU to oversee the MC.  Otherwise it doesn't work.
[14:19] <mok0> ScottK: well, it's very hard to have a large team without elected leadership
[14:19] <persia> But we've never had elected leadership.
[14:19]  * ScottK agrees with persia.
[14:19] <persia> We've always been led by the people who are in this channel doing.
[14:20] <persia> w.u.c/MOTU/Leaders is a good page
[14:20] <ScottK> mok0: MC is more like the judge than the leader.
[14:20] <persia> And while some of those positions are elective, many are not.
[14:20] <persia> Yes.
[14:20] <mok0> Perhaps "leadership" was not the exact right word
[14:20] <persia> MC is *not allowed* to make decisions on it's own unless otherwise nothing will happen.
[14:20] <persia> We could decide not to hold an election, but that's just an announcement of what is happening.  Anyone can call for an election if they want.
[14:21] <mok0> persia: but MC is allowed to make initatives, call for meetings etc
[14:21] <persia> Personally, I don't think it's worth it right now.
[14:21] <persia> The MC is not allowed to call for meetings.
[14:21] <persia> MOTU calls for meetings.
[14:21] <persia> The MC is supposed to attend meetings and be available in case things get out of hand.
[14:21] <persia> So, if you want a MOTU Meeting, update the wiki page and send out an announcement.
[14:22] <persia> I used to do that all the time.  I don't now, just because I think we've solved most of the policy issues that were hassles then.
[14:22] <mok0> ... but we haven't solved the decreasing quality of the repo
[14:23] <persia> No.
[14:23] <persia> But the MC can't solve that: it's not an MC thing.  See https://wiki.ubuntu.com/MOTU/Council which limits MC activities.
[14:23] <mok0> ... and we haven't solved the diminishing morale of the team
[14:23] <persia> MOTU has to solve that.
[14:23] <persia> Well, I hope that redefinition will help with that.
[14:24] <persia> Do you agree with the definition in the proposal that will be reviewed on the 2nd?  If so, please attend and argue for it.  If not, please mail ubuntu-motu@ and start a discussion.
[14:24] <mok0> Just look at the zero activity on ubuntu-motu
[14:24] <mok0> persia: I don't know where to start and where to end
[14:25] <persia> mok0: Well, where are you now, and where do you want to be?
[14:25] <xteejx> Hmm, the FHS in the Debian Policy Manual says nothing specifically about where things should be stored, whether "pictures and media should be stored in /usr/share/" or not. So am I right in assuming that an entire python package can install to /usr/bin/foo/* and not to worry about where the media files for package foo actually go? It's just that it appears that everything is linked specifically to each other in order to work correctly.
[14:25] <xteejx> FHS just says not to put anything in /usr/local
[14:25] <persia> xteejx: /usr/lib/foo/*
[14:25] <persia> /usr/bin/foo
[14:26] <xteejx> persia: So everything can go in /usr/bin/foo/...
[14:26] <xteejx> ?
[14:26] <persia> /usr/share/foo/* (for graphics and sound)
[14:26] <persia> No.
[14:26] <persia> /usr/lib/foo/* should have arch-specific stuff, and, annoyingly, python
[14:26] <persia> /usr/share/foo/* should have arch-independent stuff like graphics and sounds and text files
[14:27] <persia> /usr/share/doc/foo/* should have the documentation
[14:27] <persia> /usr/bin/foo should start the program
[14:27]  * sistpoty|work wonders if a picture of an pention 3 is arch-specific :P
[14:27] <sistpoty|work> pentium even
[14:27] <xteejx> So let me get this straight in my head.... /usr/share/foo/ = media  /usr/lib/foo/ = python .py files  /usr/bin/foo is the actual .py file to run  and /usr/share/foc/foo/* is the documentation?
[14:27] <persia> :)
[14:28] <xteejx> I meant doc :)
[14:28] <persia> Except policy states no extensions in /usr/bin, so /usr/bin is a python script with #! /usr/bin/python as the first line.
[14:28] <persia> Otherwise, yes.
[14:28] <persia> (unless someone with more python packaging knowledge wants to correct me)
[14:29] <xteejx> persia: So /usr/bin/* is *purely* the initial .py file to run the game?
[14:29] <persia> Except it's not a .py file.
[14:30] <xteejx> Ohh... I understand I think.... it's a small file that tells python to run the game and invoke the .py from the /usr/lib/foo/blah.py ?
[14:31] <sistpoty|work> xteejx: if it's a game the executable can also go to /usr/games (just to add more confusion)
[14:31] <persia> And /usr/lib/games/
[14:31] <xteejx> Huh?
[14:31] <persia> And there's /var/lib/ and /var/cache as well, to make it more complicated :)
[14:32] <persia> Games are special.  They use /usr/lib/games/foo/* instead of /usr/lib/foo/* and /usr/games/foo rather than /usr/bin/foo
[14:32] <xteejx> Well...I *was* beginning to understand! lol
[14:33] <xteejx> So /usr/share/foomedia/* is the same?
[14:34] <persia> No, /usr/share/foo/*
[14:34] <xteejx> That's what I meant :)
[14:34] <persia> and /usr/share/games/foo/*
[14:35] <xteejx> The first for applications, second just for games?
[14:35] <persia> Right.
[14:35] <xteejx> Whew! Talk about confusing, but I think I got it now.
[14:35]  * persia completely fails to understand why games have this super-special hierarchy, but they do
[14:36] <geser> I can understand to not put games into /usr/bin, but see no benefit for the other own directories
[14:37] <persia> geser: Why?
[14:37] <sistpoty|work> maybe FHS creators have forseen that game data is usually quite large?
[14:37] <persia> There's namespace rules anyway, so there can't be a file conflict.
[14:37] <sistpoty|work> (so a different partition might be suitable)
[14:37] <persia> Ah, that makes sense.
[14:38] <xteejx> What about game documentation, is that /usr/share/doc/games/foo/* ?
[14:38] <persia> Or it might need to be local vs. remote on /usr/share/ or users complain about access times.
[14:38] <sistpoty|work> or that ;)
[14:38] <persia> xteejx: No, that's still /usr/share/doc/foo*
[14:38] <geser> persia: if you not put games into /usr/bin/ you can exclude them from appearing in PATH (and tab-completetion)
[14:38] <xteejx> Ahh ok
[14:39] <xteejx> persia: I'm saving this for reference, can you check I've 100% got it right please? I don't want to start off and get it wrong and then have to mess about starting over
[14:39] <xteejx> http://paste.ubuntu.com/362636/
[14:40] <persia> Looks right.
[14:40] <xteejx> Cool
[14:40] <persia> Try to make /usr/bin/* be /usr/bin/foo, except when you need to distribute multiple executables.
[14:40] <xteejx> Ok. Just a double check again sorry... /usr/games/foo (executable) for games, not /usr/bin/games/foo ?
[14:41] <POX> xteejx: if your package is arch:all, use /usr/share/foo/ for .py files, if it's arch:any - use /usr/lib/foo/ (.py and .so files have to be in the same directory)
[14:41] <POX> (or symlink .py files from /usr/share/foo if you want)
[14:41] <xteejx> I'm beginning to wonder why I'm trying heh :)
[14:42] <SevenMachines> does this look like a problem in libslv2 rather than the lv2 plugin for gstreamer? http://paste.ubuntu.com/362620/
[14:43] <xteejx> POX: I thought python could compile natively on any arch, as it's just a language?
[14:43] <POX> xteejx: .py files, Python extensions are written in C
[14:43] <xteejx> POX: Oh :)
[14:44] <xteejx> Probably a stupid question... how do I know whether to choose arch: any or all?
[14:44] <POX> if you have .so file in you package, it's arch:any
[14:45] <xteejx> So, as it's all .py it's all and the .py files go in /usr/share/foo/*
[14:45] <POX> (that check works for most Python related packages)
[14:45] <xteejx> ?
[14:46] <POX> yes
[14:46] <xteejx> Ok
[14:46] <POX> or /usr/share/games/foo
[14:46] <xteejx> Ok, it's a game, so there then I assume? :)
[14:46] <persia> SevenMachines: Which program has rdf_uri.c ?
[14:47] <xteejx> POX: What about a arch: any python game, is that still /usr/lib/foo/* or is it /usr/lib/games/foo/* ?
[14:47] <POX> one of them, yes (probably the second one)
[14:48] <SevenMachines> persia: librdf0 (redland)
[14:48] <SevenMachines> thats what i'm looking at just now anyway
[14:48] <persia> SevenMachines: It looks to me that slv2 is either calling some librdf function unsafely, or there is a bug in librdf.
[14:49] <xteejx> Ok, sorry if I keep going on about it, I just want to make sure 100% I learn exactly how it should be, so thank you all for your help I really appreciate it, and once I get used to all this you will definitely start seeing a few more games in Ubuntu! :)
[14:49] <persia> SevenMachines: Look at src/world.c:154 and see what happens if one passes world=0x17958c0
[14:49] <persia> And read the librdf docs to see if maybe slv2 should be trapping an error conditoin.
[14:49] <persia> (with exception handling)
[14:50] <persia> Alternately, look in librdf and see why librdf_free_uri would be crashing with that input.
[14:59] <xteejx> In the upstream source package I have /font /gfx and /sfx - these would go in /usr/share/games/foo/* ... /plugins - would go in /usr/lib/games/foo/* ... /i18n < don't know ... and in / .py files go in /usr/share/games/foo/*.py ... / the .sh game start script goes in /usr/games/*.sh ... and there's the changelog.txt, options.cfg and README.txt in /  is that all correct, and also where do the 4 unknows go? Sorry to be a pain
[15:02] <hyperair> mok0: thanks for the upload =)
[15:02] <mok0> hyperair: you're welcome :-)
[15:04] <persia> i18n usually goes in /usr/share
[15:04] <persia> And drop the .sh from /usr/games/foo.sh  It should just be /usr/games/foo
[15:05] <persia> The docs (changelog, options, readme) belong in /usr/share/doc
[15:09] <xteejx> persia: http://paste.ubuntu.com/362651/ I hope I have it right now :)
[15:09] <persia> xteejx: You're going to end up with the entire text of the FHS if you keep at it :)
[15:09] <persia> And not every .sh or .py file needs the extension stripped, just the ones in the default path
[15:11] <gnomefreak> what controls the processes in ps aux? im looking for a source package for the [flush-*] process
[15:12] <xteejx> persia: The FHS was of no use to me, all it said was don't put anything in /usr/local :(
[15:13]  * gnomefreak thinks 18 is too many
[15:13] <persia> xteejx: Hrm?  It gets more specific than that.
[15:13] <xteejx> persia: I'm not worried though, I'd rather know all this stuff and get it all right and learn :)
[15:13] <persia> xteejx: Look at http://www.pathname.com/fhs/pub/fhs-2.3.html
[15:14] <xteejx> persia: Ohhhhhhh - I was reading http://www.debian.org/doc/debian-policy/ch-opersys.html
[15:14] <sistpoty|work> gnomefreak: pdflush? I think these are kernel threads
[15:14] <persia> xteejx: Um, that's only the exceptions :)
[15:15] <gnomefreak> sistpoty|work: thanks i will ask in -kernel
[15:15] <xteejx> persia: I did wonder why it didn't say much.
[15:15]  * xteejx is embarrassed
[15:19] <xteejx> It does make a bit more sense now ;)
[15:19] <xteejx> But I have the basics noted down for future use, which should be sufficient in most cases
[15:21] <xteejx> persia: Can I restructure the upstream source I downloaded into these folders, so that it can just all be installed to / ? with the directories branching off of course. And I know I'll need to edit some python script to re-point to each other won't I?
[15:26] <xteejx> i.e. /home/me/build/usr/share/games/foo/font , etc so that all the /usr stuff in my /home/me/build/ can be installed with a script to the correct place when packaged?
[15:28] <xteejx> Anyone?
[15:29] <persia> Don't repack the source.  Use dh_install
[15:30] <xteejx> Can dh_install be told where to put each of these files?
[15:30] <Laney> yes, see the manpage
[15:31] <xteejx> Ok...also (I must be really annoying now!!)...will I have to edit the pointers in the .py files to these new directories, or does dh_install do this too?
[15:33] <xteejx> I see, so dh_install moves the files from the temporary build section to the required directory?
[15:34] <xteejx> Does it matter that there is no Makefile or ./configure script, I don't need to make these do I?
[15:35] <persia> Not if nothing needs be made
[15:36] <persia> This guide is a bit out of date, and I now recommend dh(1) rather than CDBS, but https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling may help./
[15:37] <cjohnston> Don't forget... Ubuntu Developer Week is starting in 30 minutes in #ubuntu-classroom and #ubuntu-classroom-chat  - http://wiki.ubuntu.com/UbuntuDeveloperWeek
[15:37] <SevenMachines> it seems a no change rebuild of libslv2 gets rid of all gstreamers lv2 woes, any idea why that is? just so i can put something in the changelog if nothing else
[15:37] <xteejx> persia: That would be better, since it's all just python scripts, nothing needs built from the source it just works
[15:37] <persia> SevenMachines: debdiff the repo deb and the rebuild deb and see if anything changed.
[15:38] <persia> xteejx: So use rules.tiny, an install file, a docs file, and a manpages file :)
[15:38] <xteejx> persia: Ummm.....one step at a time hehe ;)
[15:39] <persia> Nah.  Big lumps, and ask questions.  Same as the buggy package you made yesterday that you then had to fix.
[15:40] <xteejx> persia: Lol
[15:41] <xteejx> persia: I just want to pee people off by asking so much! I did enough of that in #ubuntu-bugs, now I've triaged a good 2000+ bugs and am part of Bug Control hehe
[15:41] <xteejx> *DON'T want* oops
[15:41] <SevenMachines> seems like [-librasqal1-] {+librasqal2+} is the relevant bit here
[15:42] <persia> SevenMachines: So the changelog should read "Rebuild for librasqal1 to librasqal2 transition"
[15:42] <Laney> Just put "No-change rebuild to pick up new xxx as part of yyy transition" or similar
[15:43] <persia> And the version should be 0.6.6-2build1 (not -2ubuntu1) so we know we can safely sync if a new version appears in Debian.
[15:43] <Laney> (you can use dch -R to create the correct changelog entry)
[15:43] <SevenMachines> ok, will do. should be safe to enable lv2 in gstreamer build once libslv2-9 is updated at least
[15:44] <SevenMachines> persia: yep, i remember that, i made that mistake last time
[15:46] <persia> SevenMachines: Nice bit of research, and very nice conclusion to an initial FTBFS fix.
[15:47] <xteejx> I think #ubuntu-classroom will be helpful in 13 mins for me
[15:47] <SevenMachines> persia: thanks for the help, it started out as a relatively simple merge (my first one) and escalated rapidly out of control :)
[15:48] <persia> This was your first merge?  Wow!
[15:48] <persia> Very nice work indeed.
[15:48] <SevenMachines> gstreamer plugins bad
[15:49] <SevenMachines> would enabling lv2 in a merge be the right thing to do? or keep the changes from debian as small as possible
[15:49] <SevenMachines> and maybe add lv2 as part of another fix
[15:50] <persia> I think it's better to make as many improvements to a package as possible in a single upload, so you can improve a different package.
[15:50] <persia> Just be careful with the changelog indentation to indicate what is from previous Ubutnu versions and what is new.
[15:51] <SevenMachines> theres a format to do that?
[15:54] <persia> SevenMachines: https://lists.ubuntu.com/archives/lucid-changes/2010-January/002506.html has an example
[15:55] <persia> I don't personally think that class of Maintainer change needs a changelog entry, but it's clear which changes are retained from previous Ubuntu versions, and which were added anew.
[15:55] <persia> Of course, when uploading these, it's better to use debuild -S -v${last-ubuntu-version} so that one can also see the Debian changes.
[15:56] <xteejx> persia: One more question sorry, if the files are going to be moved around during install, surely they will need editing to comply with the locations? Am I right in thinking that I'll need to edit the .py files to point at the new location before I build?
[15:57] <SevenMachines> i was following the merging guide and having a debdiff from new debian to new ubuntu and old ubuntu to new ubuntu
[15:58] <persia> xteejx: It's better to ask questions generally.  I'll probably answer them anyway, but soemone else might be faster, especially if I go to bed.
[15:59] <persia> xteejx: If you need to change files, patch them.  Adding --with quilt is an easy way to do that with rules.tiny.
[15:59] <xteejx> persia: Sorry I forget about timezones sometimes
[15:59] <persia> Read about quilt in the patch systems section of the packaging gude
[15:59] <xteejx> Will do. And that will patch the files to the needed way I take it?
[16:00] <persia> SevenMachines: I usually just want the debdiff from Debian to new Ubuntu (as it matches the tar.gz).  I can generate the rest locally easily enough.
[16:00] <persia> xteejx: That can patch the files however you want.
[16:00] <xteejx> Really? Cool, just what I need :)
[16:01] <SevenMachines> ok, i'll take care of that once slv2 is rebuilt. thanks again
[16:14] <persia> SevenMachines: Just as a note, we'd really prefer a legal name in changelogs for proper attribution of authorship.
[16:16] <SevenMachines> ok, i'll see about changing that in the future
[16:21] <ScottK> persia: I think that goes too far.  I think we prefer something that appears to be a legal name.
[16:22] <persia> No, I think we prefer a legal name, and don't bother to check carefully, so are easily duped.
[16:23] <persia> Because the rationale for using such a name is related to attribution.
[16:23] <persia> So we don't care if it's a real name, only that it's a name that can take attribution and grant licensing.
[16:23] <persia> But that requires a legal name.  That we don't bother to enforce a WoT is just failure of due dilligence.
[16:24] <SevenMachines> Guy Incognito it is then :) I'll put my actual name in future, i just tend to default to seperating id's, its no problem though
[16:24] <persia> And without a WoT, any effort to enforce accurate reporting of legal names is a bit questionable.
[16:25] <ScottK> That's all true, but I think it goes a bit too far to say we actually prefer something we make no effort to get.
[16:29] <MTecknology> How can I mark that one package conflicts with another in the debain/control file?
[16:29] <persia> ScottK: Hrm.  I think we have different semantic weightings to "prefer".  I prefer to eat waffles for breakfast, but I probably make them twice a year because I'm lazy.
[16:29] <persia> MTecknology: Conflicts:
[16:32] <MTecknology> persia: it's just simple enough to make sense :P - thanks
[17:01] <bddebian> Heya folks
[17:01] <MTecknology> hi
[17:02] <sebner> huhu bddebian :)
[17:02] <persia> bddebian: Hey.  I wanted to ask you about libticalcs and libtifiles and libtifiles2 and friends.
[17:02] <persia> Do you remember any of this by any chance?
[17:03] <bddebian> Heya sebner, persia
[17:03] <persia> (you last appear to have worked with those several years back)
[17:03] <bddebian> persia: Aye, what about them?
[17:05] <kamalmostafa> persia: Um...  hi folks -- I've been working on libticalcs and libtifiles {with and without the 2} at ScottK's request.
[17:05] <persia> Well, you put libtifiles2 in Ubuntu a long time ago, and since then there was a libtifiles in Debian, and then an update in Ubuntu.  Never any versions in common, but there's namespace collision that seems to be causing build/dependency issues.
[17:05] <persia> And kamalmostafa will benefit from your memory and wisdom :)
[17:06] <kamalmostafa> I've actually got them fixed (the 2-package changes merged into the non-2 packages) -- they await ScottK's review.
[17:06] <bddebian> I thought libtifiles was recently removed finally?
[17:06] <kamalmostafa> (Not to say that I wouldn't benefit from any wisdom that may be imparted!)
[17:07] <persia> bddebian: You filed a removal in Debian?
[17:08] <bddebian> No, I thought someone else had recently.  I might be mistaken though.
[17:09] <persia> bddebian: So, what's your recommendation.  Merge?  Drop?  Upload the nice versions kamalmostafa prepared to Debian?
[17:10] <kamalmostafa> bug 507741
[17:10] <kamalmostafa> bug 507740
[17:11] <kamalmostafa> I don't think my versions need to go to Debian -- the other way 'round I think.  Per ScottK, we will be keeping libtifiles and libticalc (from Debian) from here on in -- and removing our libtifiles2 and libticalcs2 packages.  (there are actually a couple more in the libti family which I will get to next).
[17:12] <persia> kamalmostafa: The only reason I added that option was because bddebian seemed to think they would be removed from Debian.
[17:12] <persia> (and he uploaded the *2 versions originally, and is now very active in Debian QA)
[17:13] <bddebian> Whichever makes more sense.  I would say lets remove one or the other.
[17:13] <persia> kamalmostafa: Also, aren't our packages newer upstream versions?
[17:13] <persia> bddebian: Nicely avoided :)
[17:14] <bddebian> persia: That wasn't my intent, I just don't have a vested interest in the packages, I just wanted to have the latest back then.  I'll gladly help where I can.
[17:15] <persia> bddebian: Understood.  I didn't mean to imply you were trying to get out of anything :)
[17:15] <bddebian> :)
[17:16] <kamalmostafa> persia: Yes, but I merged in the changes from our "2" versions so we don't lose any functionality -- I think we're just trying to get the package naming aligned between us and Debian.
[17:17] <kamalmostafa> (those changes were relatively minor -- Debian is almost caught up to the latest up-up-stream version at this point).
[17:17] <persia> kamalmostafa: That makes lots of sense.  I just got confused by the bug when I saw it a couple days ago and it seemed to imply that our stuff was newer than Debian's.
[17:17] <persia> When as far as I could tell, they were independent packagings of leapfrogging versions.
[17:18] <persia> So I figured it was worth asking the original Ubuntu uploader, especially because Debian didn't seem to be getting a lot of maintenance on those packages.
[17:18] <persia> But I've done that now, so will go back to ignoring these packages :)
[17:18] <kamalmostafa> Well, as stated, ScottK set me on this task, so he needs to review the work before I propose for merge, but if anyone else wants to take a look the branches are attached to those two bug reports.
[17:18] <persia> bddebian: Thanks for your insight and explanations.
[17:19] <bddebian> NP, sorry I am not more help. :(
[17:23] <mok0> q
[17:27] <mok0> Any users of bzr buildpkg here?
[17:29] <mok0> I have deliberately constructed my tar.gz file so it doesn't contain some of the bzr specific files, such as .gitignore. However, when I build the source package using bzr builddeb, those file end up in diff.gz... annoying
[17:34] <persia> mok0: You might be able to pass "-- -i -I", but that might break something else.
[17:35] <mok0> persia: yeah, but it's a longish list of files
[17:35] <mok0> persia: for example, there's a README.bzr file which is not relevant for those downloading the package in tar.gz format
[17:35] <persia> Are they really stuff that's not already in the -i -I default list?  For me, 99% of what I want to ignore works without adding any globs.
[17:36] <mok0> persia: .gitignore files
[17:36] <persia> Oh.  Yeah.  Won't help that.
[17:36] <persia> .gitignore ought be ignored.  If not, that's probably a bug.
[17:37] <mok0> persia: guess I'll have to construct a long  -i -I line. Really would be nice to have a .bzr-builddeb-ignore file to contain all those
[17:38] <persia> Maybe construct one?
[17:38] <persia> Done once, it can be reused indefinitely :)
[17:39] <mok0> persia: perhaps I should consider submitting a branch merge proposal :-)
[17:39] <persia> And then accept it in the packaging branch?
[17:40] <persia> Where I get confused is, that if this is done, how does one ensure it gets uploaded?
[17:40] <persia> How can a developer know if the right source is that in the archive or that in the branch?
[17:41] <mok0> persia: hm I need to think it throug
[17:41] <mok0> h
[17:59] <geser> DktrKranz: I've seen the comment in your gpsd upload. Is there a way to resolve the DEPWAITs on a newer libgps-dev in lucid?
[18:00] <geser> Laney: lucid has some DEPWAITs on mono-devel >= 2.4.3. Do you have an idea when lucid will get it?
[18:15] <Laney> geser: hopefully v soon. Transition is almost ready to roll over now
[18:18] <sebner> hi geser Laney
[18:18] <Laney> hiya sebnerkins
[18:23] <ScottK> bddebian, kamalmostafa, and persia: My thought was to align to the Debian packages and then look at what should go back to Debian.  As we have it now, we have different source package names and that needs to be fixed first.
[18:32] <\sh> guys, very strange problem...dpkg --purge tries to remove the whole /opt directory...but should only remove /opt/<whatever> ... any clue about this problem?
[18:34] <\sh> forget about that
[18:34] <\sh> found my answer
[18:36] <mok0> \sh: what was it?
[18:36] <\sh> mok0: read http://www.mail-archive.com/debian-devel@lists.debian.org/msg230790.html
[18:37] <\sh> it's a false positive this strange warning
[18:37] <mok0> ah interesting
[18:44] <kamalmostafa> ScottK: i'm available if you need me re: the libti stuff.
[18:44] <ScottK> kamalmostafa: Thanks.  I'm sorry it's take me so long to look at.
[18:45] <kamalmostafa> ScottK: really no problem Scott.
[18:48] <randomaction> so, was the problem with TeXLive uninstallable solved?
[19:24] <ScottK> Yes
[19:26] <randomaction> cjk still FTBFS with the same error: https://launchpad.net/ubuntu/+source/cjk/4.8.2+git20090105-4/+build/1461227
[19:26] <randomaction> (and it's in universe)
[19:27] <ScottK> Then it's not the problem I was solvling.  Mine was just a Main/Universe mismatch
[19:30] <randomaction> hmm ok, when will the texlive-base-bin binary go away? (It's not built by any source package anymore) Is a removal bug required?
[19:30] <randomaction> it seems its presence leads to FTBFS
[19:34] <Laney> does it have any rdepends?
[19:35] <randomaction> a lot, but it's provided by a new binary, texlive-binaries
[19:37] <randomaction> so actually texlive-base-bin should become a virtual package, but there's still an old and uninstallable version of it (at least that's what geser suggested)
[19:40] <ScottK> It'll go away when it doesn't have any rdepends.
[19:40] <geser> Laney: most rdepends of texlive-base-bin are unversioned, so texlive-binaries providing texlive-base-bin works for them
[19:41] <ScottK> Right, virtual provides aren't versioned and so will always fail.
[19:41] <ScottK> (if the depends is versioned)
[19:42] <geser> ScottK: do you know if the archive-admins will remove it although its NBS file is not empty?
[19:42] <ScottK> geser: Generally not, but if there's a good reason, perhaps.
[19:42] <ScottK> One of the reasons not to remove it is that it's then hard to find what packages still need to be adjusted.
[19:44] <Laney> a combination of edos-debcheck and grep-dctrl could do it
[19:44] <geser> ScottK: the NBS file lists also those packages which have an unversioned dependency on texlive-base-bin
[19:44] <ScottK> geser: I think the solution then is to make a list of the versioned ones, get them fixed, and then ask for removal.
[19:46] <randomaction> that sounds doable :)
[19:46] <geser> ScottK: a quick check with grep "texlive-base-bin (" in /var/lib/apt/lists shows me only one package left: jadetex (bug #511399)
[19:47] <ScottK> geser: Sounds easy enough then.
[19:55] <randomaction> What's needed to bootstrap a package? (eigenbase-resgen build-depends on its own binary)
[19:56] <geser> in the worst-case: a build-admin :(
[19:57] <geser> try to get the package build without itself, and once you got it, undo it in the next step
[19:58] <dupondje> what is quite easy to help a bit in Ubuntu ? :) Easy to help with ftbfs packages ?
[19:59] <geser> dupondje: ftbfs might be easy (because the build happened at a wrong time, and the issue is resolved now -> give-back) or hard (needing patching)
[19:59] <Laney> maybe turning bugs with patches into bugs ready for sponsoring
[19:59] <randomaction> looking at the FTBFS list, we still have a fair number of const char* cases
[20:00] <dupondje> geser: well it can be the patch is quite easy also :)
[20:00] <geser> true, depending on the patch
[20:01] <dupondje> just don't know what the steps are exactly to fix ftbfs packages :)
[20:02] <geser> randomaction: if you're a familiar with ant build files, you could check if you manage to build it without itself
[20:04] <geser> dupondje: the first step is: find out why it failed and how to fix it
[20:06] <dupondje> geser: just apt-get source ? and then trying to fix so it builds ?
[20:07] <geser> dupondje: I usually start with looking at the existing build log to see if I have an idea what's the problem is
[20:07] <MTecknology> What's the best place to ask about packaging? I've been told this isn't the right place for that
[20:08] <geser> it is the right place
[20:09] <dupondje> and what is 'Newer in Debian' ? :) means its quite useless to fix it as it needs to be synced from debian first ?
[20:09] <dupondje> or
[20:10] <geser> dupondje: can you provide a little more context? (which page/url are you talking about?)
[20:11] <dupondje> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi, first package cdrkit
[20:11] <geser> ah, that FTBFS page
[20:12] <geser> Debian has a newer package which might (or might not) fix this problem (needs checking)
[20:18] <MTecknology> I'm trying to compile something before trying to package it; It's complaining about xft not being found and I can't figureout where to get it from, libxft2 is installed
[20:18] <ScottK> Is there a -dev package?
[20:19] <geser> MTecknology: have you the exact error message at hand?
[20:20] <MTecknology> geser: No package 'x11' found
[20:20] <MTecknology> ScottK: ya, it's a virt package, I'll try installing everything in it
[20:21] <geser> MTecknology: what has now "x11" to do with your problem that xft is not found?
[20:22] <MTecknology> geser: just comes up when I run make
[20:25] <MTecknology> That fixed; and now it won't build - with a great error this time - http://paste.ubuntu.com/362848/
[20:26] <MTecknology> I can tell I need X11/StringDefs.h; how can I figure out what provides that?
[20:27] <randomaction> MTecknology: http://packages.ubuntu.com/search?suite=lucid&arch=any&searchon=contents&keywords=X11%2FStringDefs.h
[20:27] <MTecknology> I installed libxt-dev...
[20:28] <MTecknology> oh...
[20:29] <geser> MTecknology: ah, "X11" was a library name it was looking for -> libX11.so -> libx11-dev (found with packages.ubuntu.com)
[20:30] <MTecknology> So to build this needs libxt-dev and libxft-dev; that'll be useful when I try to package this
[20:30] <randomaction> generally, when configure complains about "foo" missing, first package to check is libfoo-dev
[20:30] <geser> don't forget libx11-dev (for that -lX11 part)
[20:31] <MTecknology> I just ran make again; and now - make dies with no decent error
[20:32] <MTecknology> All I get is this - http://paste.ubuntu.com/362854/
[20:33] <randomaction> MTecknology: do you have ./configure script?
[20:33] <geser> what gived "ls -l lal"?
[20:33] <geser> s/gived/gives/
[20:33] <MTecknology> hrm... It was still able to build; just with that error
[20:34] <randomaction> geser: I'll leave eigenbase-resgen to java people, too complex to me :)
[20:34] <geser> it's a warning not an error :)
[20:34] <MTecknology> there isn't a ./configure script
[20:35] <geser> MTecknology: if you want you can fix this warning (the security guys would probably prefer it if you do it)
[20:35] <MTecknology> ok - I'll check it out
[20:36] <randomaction> so, is this some software with a single .c file? pretty simple to build it seems :)
[20:36] <MTecknology> now.. those are only build deps; right?
[20:36] <MTecknology> randomaction: It's not yet packaged - I figure it's a great one to learn on
[20:37] <randomaction> the best way to check correctness of build-deps is to build in a clean environment, such as pbuilder
[20:38] <MTecknology> ya, and then lintain to make sure I didn't screw up; then upload
[20:39] <MTecknology> I'll try to do this the right way :)
[20:56] <MTecknology> is it possible to get verbose output of the build process?
[20:56] <hyperair> export DH_VERBOSE=1
[20:57] <sebner> hola hyperair :D
[20:57] <hyperair> hola sebner :D
[21:01] <dupondje> dpkg-gencontrol: warning: unknown substitution variable ${python:Provides}
[21:01] <dupondje> ${python:Provides} is correct right ?
[21:03] <MTecknology> hyperair: sorry, I meant when I run make
[21:03] <MTecknology> I want to figure out what's causing something to be sent to the die function
[21:03] <hyperair> MTecknology: ah. try make V=1 (it effectively unsilences [is that a valid word?] automake, but i'm not sure if it does anything to make)
[21:04] <dupondje> ?
[21:05] <MTecknology> hyperair: nope, nothing - there's also almost no comments at all in this file
[21:05] <hyperair> MTecknology: hmmm. how bout make --debug =p
[21:08] <MTecknology> hyperair: there's --debug; the only error is "Updating goal targets...  File `all' does not exist. Must remake target `all'."
[21:08] <randomaction> MTecknology: if you want to fix that warning, the general idea is to change "printf(somestring)" to "printf("%s", somestring)"
[21:09] <MTecknology> randomaction: that line is fprintf(stderr, str);
[21:09] <dupondje> dpkg-gencontrol: warning: unknown substitution variable ${python:Provides} => whats wrong with ${python:Depends} ?
[21:10] <MTecknology> randomaction: I guess that is the only line causing issues. I comment it out and it's perfectly fine. So now I guess I need to learn enough C to fix that :P
[21:11] <randomaction> nope, don't comment it out, better leave it as it is
[21:12] <MTecknology> randomaction: I just tried it without to see what happened
[21:13]  * hyperair wonders what make has to do with fprintf
[21:13] <randomaction> never comment out code you don't understand: http://xkcd.com/424/
[21:16] <dupondje> geser: is there a bug created for every ftbfs?
[21:18] <geser> no, e.g. a MOTU or core-dev can fix it directly with an upload and doesn't need to file a bug first
[21:19] <dupondje> hmz ok, cause I fixed one error
[21:19] <geser> then the usual sponsoring process applies
[21:20] <dupondje> geser: ok, and what about dpkg-gencontrol: warning: unknown substitution variable ${python:Provides} ? does that needs to be fixed ? if so, how exactly ? cause I think that is correct ..
[21:22] <geser> no, it just a warning
[21:41] <ScottK> dupondje: It's a normal thing for Python packages, just dpkg-gencontrol doesn't know about it.
[21:45] <geser> ScottK: do you know if it is possible to configure LP that only the Kubuntu devs gets build logs for their PPA?
[21:46] <ScottK> No idea.
[21:46] <ScottK> I'm generally pretty unhappy with it's spammyness.
[21:47] <geser> I guess I've to live with it :/
[21:50]  * ajmitch hasn't seen any recent build logs in the lp catch-all mailbox here
[21:51] <deadwill> heya
[21:52] <geser> I just got a log about a FTBFS in the kubuntu-ppa-staging PPA a few minutes ago (thanks to indirect membership)
[22:04] <dupondje> https://bugs.launchpad.net/ubuntu/+source/burn/+bug/512509
[22:05] <dupondje> geser: the fix :)
[22:12] <geser> dupondje: looks good, can you please forward this change to Debian (so we can hopefully sync in future again)? and don't forget to subscribe ubuntu-universe-sponsors (or ubuntu-main-sponsors for packages in main) if you want your fix get sponsored :)
[23:04] <ari-tczew> if I'm doing a fakesync, do I need to change DebianMaintainerField?
[23:05] <ScottK> ari-tczew: No