[00:54] <lfaraone> If the same package has a different name in Debian and Ubuntu, and it has no rdepends, do I need a FFe to rename it?
[00:54] <lfaraone> (rename it from its Ubuntu to Debian version)
[00:56] <micahg> lfaraone: rename?  wouldn't you just add conflicts/replaces in the debian package on teh ubuntu one and drop the ubuntu one?
[00:56] <persia> No, but you *do* need to have transition packages to handle that, for upgrades from all supported upgrade paths (for maverick, only lucid, which makes this easy)
[00:56] <persia> micahg, No.  That breaks upgrades.
[00:56] <micahg> persia: oh, right...
[00:57] <persia> lfaraone, And given that this would hit NEW, you would benefit from an FFe to ease the discussion with the archive-admin.
[00:57]  * micahg should know already
[00:57] <persia> But don't be surprised if the release team decides to ignore/reject the FFE (not refuse, just say "pointless"), as adding transition support packages isn't technically a new feature.
[00:58] <lfaraone> persia: mk. right now we have sugar-pollbuilder-activity 26+git20100521.d4def0b6-0ubuntu1 in Ubuntu. In Debian, we have sugar-poll-activity 26+git20100521.d4def0b6-1, which is *identical* to the Ubuntu version.
[00:59]  * persia doesn't even want to think about how that happened
[00:59] <persia> Did Ubuntu already sync that from Debian?
[00:59] <lfaraone> persia: we intend to just call it -poll- going forward. Should we go ahead and make the change now? (it was in hardy and lucid under the old name, so we're going to have to carry a delta forward until the next LTS)
[00:59] <lfaraone> persia: well, identical other than having a different release number.
[01:00] <persia> Since sugar-poll-activity isn't in Ubuntu yet, I'd do it in natty (since you have to carry to next LTS anyway)
[01:00] <persia> Easier, and less fuss.
[01:02] <persia> Otherwise, you need 1) an FFe for NEW of sugar-poll-activity, 2) a transition package (creating Ubuntu/Debian delta for debian/control, which requires messing with control.in or manual munging), 3) some significant discussion with the currently fairly busy release managers and archive-admins about getting your packages sorted, and 4) a removal for sugar-pollbuilder-activity
[01:02] <persia> For natty, you just need 2)
[01:03] <persia> (unless you want to introduce a dummy transitional package in Debian, but it is useless there)
[01:03] <micahg> and 4 :)
[01:03] <persia> Oh, right :)
[01:04] <persia> Still, half as much work.
[01:04] <micahg> persia: have time to ack a sync request?
[01:04]  * micahg doesn't expect it to go in until after beta freeze
[01:04] <persia> Not now, maybe later.  Stick it in the sponsors queue.
[01:05] <micahg> persia: it's there, but the main core-dev sponsor is on vacation :)
[01:05] <persia> Oh, if it's seeded, I don't have authority to ack it anyway.  If it's not seeded, Beta Freeze doesn't mean much.
[01:05]  * persia isn't core-dev
[01:05] <micahg> oh...
[01:05]  * micahg thought for some reason...
[01:05] <ajmitch> you need to find a core-dev with spare time to build it?
[01:06]  * persia points at suspiciously alert core-devs in New Zealand
[01:06] <micahg> ajmitch: it's sqlite3
[01:06] <ajmitch> oh dear
[01:06] <micahg> already got the FFe
[01:06]  * ajmitch looks around for Laney 
[01:08] <ajmitch> micahg: this really really fixes all reported slowness issues? :)
[01:08] <micahg> ajmitch: 3.7.1 supposedly did, 3.7.2 is one extra data munging bug fix
[01:08] <ajmitch> looks important
[01:08]  * ajmitch fetches
[01:09] <micahg> ajmitch: bug 623722
[01:09] <ajmitch> yeah I was on the bug
[01:09] <micahg> ajmitch: thanks
[03:40] <lfaraone> Can packages in Universe depend on packages in Multiverse?
[03:41] <micahg> lfaraone: no
[03:42] <lfaraone> huh. requestsync will grab a new package from contrib and try to put it in universe...
[03:42] <lfaraone> micahg: byg 625026
[03:42] <lfaraone> micahg: bug 625026
[03:43] <micahg> lfaraone: k, you should probably file a bug against requestsync
[03:44] <micahg> lfaraone: I would think the AA would catch that when syncing though and throw it in multiverse
[03:44] <persia> Not necessarily.
[03:44] <persia> Many packages in contrib qualify for universe
[03:44] <persia> UFSG != DFSG
[03:44] <micahg> oh, I guess no bug then :)
[03:44] <persia> Right.  archive-admins review in source NEW.
[03:45] <micahg> but the package in question should still go in multiverse since etoys which is a dependency is in multiverse
[03:45] <persia> When copyright changes, it's up to all of us to make sure we file bugs to move things.
[03:45] <persia> Right.
[03:45] <lfaraone> micahg: yeah, but etoys is free, just not something the ftpmasters wanted to include in main for technical reasons.
[03:45] <micahg> lfaraone: k, well why is it in multiverse?
[03:46] <lfaraone> micahg: the "source code" is a virtual machine that isn't trivially diffable.
[03:46] <micahg> lfaraone: free is relative
[03:46] <persia> lfaraone, And we don't have source to build the virtual machine?
[03:46] <lfaraone> micahg: it's like if we couldn't bootstrap C, and could only edit C code using C code.
[03:46] <lfaraone> micahg: yes, we have the VM source.
[03:47] <lfaraone> micahg: however, nobody has bootstrapped Squeak Smalltalk since the 1970s or so.
[03:47] <micahg> lfaraone: are we building the vm from source?
[03:47]  * persia thought LaserJock did it a couple years ago
[03:47] <lfaraone> micahg: sorry, the virtual machine has source, but we don't have source for the VM image.
[03:47] <lfaraone> persia: news to me.
[03:47] <micahg> lfaraone: then multiverse sounds right
[03:47] <persia> yeah.
[03:47] <lfaraone> micahg: well, you can edit the VM image, and modify it.
[03:48] <lfaraone> micahg: but you just have to do that inside the VM image itself.
[03:48] <micahg> lfaraone: right, but anything in main/universe needs to be built fro source in the archive
[03:48] <persia> If it was written in a self-hosting language that generated machine-code that was the VM, and we bootstrapped off the last good build for each upload, it could be universe.
[03:48] <persia> But we need to build the machine-code on the buildds to qualify for universe.
[03:49] <lfaraone> persia: something that was talked about several years ago was to have a single "base squeak image" and just have everything else built as .changes off that.
[03:49] <persia> Doesn't work.
[03:49] <lfaraone> it's something dfarning is going to takle for natty.
[03:50] <persia> We need source code (can be smalltalk) that generates machine code that processes the source code...
[03:50] <lfaraone> "How can I bootstrap a Squeak image?"…"You don't. Some bits in this Squeak are descended from Smalltalk-76. They have been loaded and saved in a 'core image' many times. It is, theoretically possible to start from nothing (since it has been done in the past, back before the earth cooled), but it is not easy."
[03:50] <persia> LaserJock is emeritus, but maybe drop him an email, and see if he remembers anything.
[03:51] <persia> We don't need to start from nothing.  If you get a source package that build-depends on a binary package that had source with binary blobs, and that generates a binary package that can be used to rebuild the same source package, the buildd admins can iterate it a couple times, and put it in universe.
[03:52] <persia> The key is that we need to be able to build it once we have it, not that we need to bootstrap from scratch.
[03:52] <persia> (recent example was getting fpc working on powerpc and armel)
[03:52] <lfaraone> persia: "build"? the image doesn't really need to be "compiled", it's modified when you're working on it.
[03:53] <persia> lfaraone, Is it theoretically possible to write smalltalk code that would generate the image as a *separate* external binary blob?
[03:54] <persia> And could it be said that such an external binary blob was a representation of that source?
[03:55] <lfaraone> persia: Sure, there's SystemTracer. But from what I understand, people dislike it for some reason.
[03:55] <persia> Find out why :)
[03:55] <persia> Basically, you need some way to convert some body of text into the VM (this process may require the VM to be present, if you need).
[03:56] <persia> Once you achieve that level, you can get into universe.
[03:56] <lfaraone> persia: well, sure, you can merge in a .changes file (sort of texty) into an existing VM.
[03:56] <persia> Before that, you can7t, because there's no documentation of the contents of the VM.
[03:56] <persia> lfaraone, Except I want to generate a *new* external binary blob that happens to be a VM, rather than modify the VM.
[03:57] <lfaraone> persia: so merge in the changes in RAM and then run SystemTracer to generate a new blog?
[03:57] <lfaraone> *blob
[03:58] <persia> Well, kinda, except you need a set of changes that starts from nothing.
[03:58] <persia> Because we can't know that the binary VM hasn't been compromised.
[04:01] <lfaraone> persia: sandbox it to hell and hope that nobody's too smart :)
[04:01] <persia> https://forum.defcon.org/archive/index.php/t-8111.html
[07:50] <Zombie> Hello, anyone living?
[07:51] <persia> bundles of folks
[07:52] <Zombie> I'nm interested in d2x-xl Builds for Mandriva.
[07:52] <Zombie> er
[07:52] <Zombie> I'nm interested in d2x-xl Builds for Ubuntu.
[07:52] <Zombie> Let me explain.
[07:52] <Zombie> Most of my build machines are Mandriva, and I can transplant that build from Mandriva to Ubuntu, and it will be okay.
[07:53] <persia> d2x-xl ?
[07:55] <Zombie> Its a source port of the DOS Game.
[07:56] <Zombie> Descent 2/
[07:57] <persia> OK.  And you want to build it on Ubuntu?
[07:57] <Zombie> Yes.
[07:57] <Zombie> My Mandriva builds crash. Badly.
[07:57] <persia> So, you *could* do something with alien on the rpm, but we generally recommend that you add separate packaging metadata for Debian-format packages (which are used in Ubuntu)
[07:59] <persia> there was a recent excellent blog entry detailing a fairly lightweight step-by-step process to accomplish this: http://ubuntulinuxtipstricks.blogspot.com/2010/08/is-packaging-new-software-hard.html
[08:00] <persia> You might want to stick it in a PPA, or you might want to work with the Debian Games team (#debian-games on OFTC) to get it into Debian and all derivatives (including Ubuntu)
[08:04] <Laney> ajmitch and micahg: I don't think all of the slowness bugs are done yet
[08:05] <micahg> Laney: :(, even with 3.72
[08:05] <Laney> right
[08:05] <Laney> there's a problem with ORDER BY RANDOM() that I'm aware of
[08:05] <micahg> Laney: is it better than 3.7.0.1?
[08:07] <Laney> sure, it fixes integrity problems
[08:07] <micahg> Laney: k, well, we still have time before release if it can be tracked down...
[08:25] <\sh> micahg, will come in just a few hours :)
[08:41] <geser> persia: a rebuild of missingh is waiting in the upload queue. once it got accepted and build, your haskell-{configglue,hsh} rebuilds should be ready for a give-back
[08:42]  * persia doesn't understand why things are failing in the DC that worked just fine 15 minutes before upload.
[08:45] <Laney> persia and geser; You'll probably see some ftbfsen on armel that are just because ghc6 hasn't yet built there, should be good to give-back after that
[08:46] <persia> armel worked for me: my issues are i386/amd64 (and I did my build-testing on amd64, making it extra confusing)
[08:46] <Laney> hmm
[08:47] <geser> Laney: do you know how many ABI provides have changed in the ghc6 package with the recent upload?
[08:47] <Laney> geser: Just one (unix)
[08:47] <Laney> http://orangesquash.org.uk/~laney/haskell-installability/amd64.png the graph isn't so bad
[08:47] <Laney> darcs is the strangest failure, and that has been happening for a while
[08:48] <Laney> micahg: Actually I just got an email that it might indeed be fixed after all in .2
[08:48] <geser> is there an explanation for the colours? green = ok, red = failure, light red = ?, purple = ?
[08:49] <Laney> geser: There's a README
[08:49] <Laney> It's FTBFS and FTBFS+uninstallable
[08:49] <Laney> probably not the most advisable colours
[10:21] <jmehdi> hi, I'm interesting in packaging a mono app, where could I find some good tutorial?
[10:25] <persia> directhex, Laney ^^
[10:25] <directhex> jmehdi, #debian-cli on oftc is a good place to be
[10:25] <Laney> yeehaw
[10:25] <jmehdi> directhex: ok, thanks
[10:30] <Laney> as for a tutorial, looking at another mono app is probably the best documentation
[10:30] <Laney> f-spot tomboy banshee tasque muine (did we RM that?)
[10:31] <directhex> Laney, those are pretty complex examples aren't they? it'd help to know which app jmehdi has his eye on
[10:31] <Laney> actually the packaging is usually pretty simple
[10:31] <Laney> at least if I can understand it anyway…
[10:31] <directhex> heh
[10:31] <directhex> i think some of sebner's packages have ultra-minimal dh7 don't they?
[10:32] <Laney> pinta might be a good one
[10:32]  * Laney forgets
[10:32] <sebner> directhex: ultra minimal?
[10:33] <sebner> directhex: *how* minimal=
[10:33] <persia> rules.tiny
[10:33] <directhex> rules.tiny, or as close as can be achieved
[10:33]  * sebner looks
[10:34] <Laney> I can't remember the name of that video editing one
[10:34] <sebner> Laney: longomatch but it has clean and install overrides
[10:34] <Laney> :(
[10:35] <sebner> hmm, everwhere at least install/clean/configure overrides
[10:36] <Laney> oh well
[10:36] <persia> You guys should create some addons so you can use rules.tiny
[10:36] <Laney> there is one
[10:36] <Laney> pinta is as close to rules.tiny as I've found
[10:37] <sebner> Laney: definately
[10:39] <directhex> persia, we get fairly close... but sometimes you need hax.
[10:40] <Laney> it should be genuinely rules.tiny at the next release
[10:40] <Laney> modulo the include
[10:41] <persia> Why include?  Shouldn't it be --with-mono or something?
[10:41] <directhex> i thought joeyh was breaking includes
[10:41] <Laney> compat 8 does indeed
[10:41] <directhex> because he hates us. sniff
[10:42] <persia> No, he just prefers integration to includes
[10:42] <Laney> the include does export DH_OPTIONS += --with=cli
[10:42] <Laney> and MONO_DISABLE_SHM
[10:44] <directhex> yeah, it's the MONO_DISABLE_SHM one that annoys me
[12:35] <smallfoot-> where can i get a list of software in the multiverse channel in repo?
[12:36] <persia> http://archive.ubuntu.com/ubuntu/dists/maverick/multiverse/source/Sources.bz2
[12:36] <persia> (replace "maverick" with other releases for those)
[12:38] <smallfoot-> oh, i noticed you could view it in Synaptic too
[12:38] <smallfoot-> put Spotify in multiverse
[12:39] <smallfoot-> opera isnt in multiverse either
[12:58] <jpds> smallfoot-: bug #386919
[12:59] <smallfoot-> despotify is open source command-line client and library
[12:59] <smallfoot-> but they should put official proprietary client too, cuz its easier for most ppl to use
[12:59] <smallfoot-> despotify only work with premium acc
[12:59] <jpds> 'they' could be you.
[13:00] <persia> Indeed, it's much more likely if "they" is you :)
[13:00] <smallfoot-> package thing is very difficult
[13:02] <persia> http://ubuntulinuxtipstricks.blogspot.com/2010/08/is-packaging-new-software-hard.html suggests not so much
[13:06] <directhex> i agree with a couple of bits & pieces in maco's guide, but it's not a bad summary overall
[13:06]  * persia would have s/but/and/ in that sentence
[13:12] <Laney> it's easy with an easy upstream
[13:13] <directhex> and it's hellish with messy upstreams
[13:13] <directhex> don't stare too closely at OOo, you might go mad
[13:13] <persia> No.  it's can reach impossible.
[13:13] <persia> OOo isn't the worst thing out there.
[13:14] <directhex> OOo has the worst build system i've worked on
[13:14] <directhex> in the archive, anyway
[13:17] <persia> You've done well then :)
[13:19] <smallfoot-> http://www.spotify.com/se/download/previews/
[13:19] <smallfoot->  http://repository.spotify.com/pool/non-free/s/spotify/ <-- .deb files here
[13:19] <smallfoot-> you guys can copy those .deb files and put them in multiverse repo?
[13:19] <persia> We can't use .deb files.
[13:19] <directhex> smallfoot-, no.
[13:19] <smallfoot-> oh
[13:19] <persia> We need source packages.
[13:19] <smallfoot-> but multiverse is non-free
[13:20] <smallfoot-> spotify doesnt release source code for spotify, cuz its proprietary non-free software
[13:20] <Laney> Spotify could potentially get a partner agreement with Canonical to have it in that repository, but it can't go into Ubuntu.
[13:20] <persia> multiverse is *not* non-free
[13:20] <persia> multiverse is less-free.
[13:22] <directhex> hm, they actually have a repo for their packages, not just random debs
[13:22] <persia> Laney, commercial agreements with arbitrary firms (including Canonical) do not waive the license restrictions on the archive (unless you refer to Canonical's partner archive, in which case you should be explicit: that's no more part of Ubuntu than Sharp's jaunty application service center).
[13:22] <Laney> persia: That's what I meant by partner agreement
[13:22] <persia> Ah, OK.  Canonical confusingly has several different "partner" things.
[13:23] <Laney> Yeah, for avoidance I meant archive.c.c/ubuntu
[16:36] <ScottK> lucas_: With maverick in freeze for beta, this would be a really nice time for another archive rebuild, if you're up for it.
[16:57] <lucas_> ScottK: will try to do it next week
[16:58] <ScottK> lucas_: Great.  Thanks.
[17:15] <micahg> Laney: that's good news
[17:15] <micahg> \sh: I wanted to ask you if the Zend_Twitter thing was worth an SRU?
[17:17] <kklimonda> hmm.. is pbuilder-satisfydepends broken in Maverick? or at least has been modified? I've used it to install dependencies on my system (and then uninstall them by purging dummy pbuilder package) but that doesn't seem to work now :/
[17:17] <ari-tczew> kklimonda: universe enabled?
[17:18] <kklimonda> yeah, my bad - I've used it in a wrong folder.. I could swear it didn't work before, when I were in the right one but now it works as expected..
[17:38] <ari-tczew> kirkland: can we sync package libjibx1.1-java? the Conflicts: field is not the same
[17:39] <kirkland> ari-tczew: yes, we can sync it;  Debian's is "more correct", per email conversation
[17:40] <ari-tczew> kirkland: ok thanks :)
[17:40] <kirkland> ari-tczew: ack
[17:44] <ari-tczew> kirkland: could you check this bug 618752 ? why is it commited not released?
[18:10] <kirkland> ari-tczew: i just lost a race at upload time
[18:10] <kirkland> ari-tczew: i meant to mark fix-committed, and then upload, and have LP mark it fix-released
[18:11] <kirkland> ari-tczew: but my fix-committed change got applied seconds after LP marked it fix-released apparently
[18:11] <kirkland> ari-tczew: i just updated it
[18:11] <ari-tczew> kirkland: thanks
[18:27] <vish> tumbleweed: i'll close some of the bugs, no need for uploading them directly in Ubuntu. :)
[18:47] <ari-tczew> Daviey: ping
[18:49] <Daviey> ari-tczew, o/
[18:49] <ari-tczew> Daviey: did you saw discussion with kirkland? ^
[18:50] <Daviey> no :S
[18:51] <ari-tczew> Daviey: I'll send you it on private message
[18:52] <Daviey> ari-tczew / kirkland: i'm confused :S
[18:52] <ari-tczew> Daviey: what's your problem?
[18:52] <ari-tczew> where do you see new upstream release?
[18:52] <ari-tczew> please show me, perhaps I;m blind
[18:54] <Daviey> ari-tczew, erm.. you want to sync libjibx1.2-java (1.2.1-1) unstable right?
[18:55] <Daviey> Maverick = 1.1.6a-1ubuntu1
[18:55] <Daviey> "  * New upstream release (Closes: #526611)."
[18:56] <Daviey> http://bugs.debian.org/526611
[18:57] <ari-tczew> Daviey: no, there are no new upstream release
[18:57] <Daviey> it looks like a massive sync
[18:58] <ari-tczew> Daviey: please get a source of existing ubuntu package libjibx1.1-java and look in debian/changelog
[18:58] <ari-tczew> command: apt-get source libjibx1.1-java
[18:59] <Daviey> ari-tczew, I synced the current Maverick upstream version in.. i have it :)
[18:59] <Daviey> changelog skewing, looks like
[18:59] <ari-tczew> Daviey: perhaps. well, now it's ok?
[19:01] <Daviey> I guess so.. I haven't looked at the delta.. but it still needs a beta freeze exception and ideally kirkland to ack the sync.
[19:08] <ari-tczew> Daviey: are you in motu?
[19:10] <Daviey> ari-tczew, no.. but that is irrelevant for this package - it's in main.
[19:11] <ari-tczew> Daviey: bugfixes and improvements without new features (like in new upstreams) can go.
[19:11] <Daviey> ari-tczew, That's fine.. but it still needs an ack from a core-dev.
[19:12] <ari-tczew> Daviey: yes, I know about it :]
[19:13] <ari-tczew> Daviey: if I would be impatient, I'd ask kirkland for ACK through launchpad (he gave ACK here 1,5 ~hour ago)
[19:16] <Daviey> ari-tczew, Ok, great... I won't involved myself in the discussion further.
[19:17] <Daviey>  libjibx caused me a day of pain a few weeks ago, as it was simply dropped from the archive.. Which is why i care about it.
[19:21] <tumbleweed> vish: thanks :)
[19:28] <ari-tczew> Daviey: no problem, feel free to ask. anyone who asks, do not wander
[19:49] <ari-tczew> what is a sense of existing file *.1 in debian/changelog?
[20:50] <ScottK> sistpoty: Would you be up for looking at http://launchpadlibrarian.net/54505066/buildlog_ubuntu-maverick-armel.hdf5_1.8.4-patch1-2_FAILEDTOBUILD.txt.gz - I think getting that fixed would unlock a fair number of armel build failures.
[20:55] <sistpoty> ScottK: sorry, looks to be out of my range, since I lack armel hw (which makes it quite hard to find the reason for a SIGILL)
[20:55] <ScottK> OK.
[20:55] <ScottK> dyfet: ^^^ Could you take a stab at it?
[20:56] <dyfet> right now everything I build at least for kde for armel is crashing in build :(
[21:05] <ScottK> This isn't KDE, so it ought to be a chance for a fresh start.
[21:07] <dyfet> Hmm...illegal instruction...
[21:08] <directhex> illegal instruction - building for the wrong ARM version?
[21:09] <dyfet> This is whats also happening to all my kde builds on arm today, either happens in mock or cmake...hmm...
[21:10] <ScottK> dyfet: What are you working on?
[21:10] <sistpoty> dyfet: if you can trace down the illegal instruction in question (e.g. using gdb), I'm quite sure that would help to lock down the problem
[21:10] <dyfet> I have a beagle board...it is very slow.  I am going to try that next though.
[21:28] <ScottK> sistpoty: osgal currently FTBFS in Debian and Ubuntu due to autoreconf stuff not working.  We need to rebuild it for NBS.  Care to take a stab at that one (no special hardware required)?
[21:29] <sistpoty> ScottK: on my list :). (still fighting with the wiki)
[21:29] <ScottK> sistpoty: Thanks.
[21:46] <AnAnt> Hello
[22:04] <sistpoty> oh, nice, found the bug in osgal. it's of course a bug in cdbs (changing it's API). So a) the cause is simple to solve apart from b) cdbs is evil *g*
[22:39] <sistpoty> oh, osgal is harder than I thought, cdbs has totally gone nuts, as far as I can tell it so far (though it never was sane in the first place *g*)
[23:15] <ScottK> sistpoty: I didn't get beyond if I manually autoreconf and then don't let clean run first it would build.  Then I noticed it was CDBS and gave up.
[23:17] <sistpoty> ScottK: actually I just managed to get it built (still with cdbs, and using pbuilder for unstable)... still trying to carve out minimal changes
[23:17] <ScottK> Excellent.
[23:17] <ScottK> You want to NMU it in Debian (along with our armel build patch) and then sync?
[23:18] <sistpoty> ScottK: that would be my next question, once I sorted building straight from unstable sources out :)
[23:19] <ScottK> Same RC bug exists in Debian, so if you're comfortable you have a sufficiently correct solution, I think it would be the way to go.
[23:19] <sistpoty> ScottK: actually I'm working only from unstable sources right now :)
[23:20] <ScottK> Great.