[01:45] <gnutun> hey all; is this an appropriate place to ask about using debuild to create ubuntu packages? should i ask in debian help?
[01:47] <highvoltage> gnutun: not in this channel, but there will be many people willing to help in #ubuntu-packaging and #ubuntu-motu
[01:48] <gnutun> ok thanks highvoltage
[01:48] <highvoltage> (it's night time in a lot of europe/us right now so you might want to hang around a bit for a response)
[01:48] <RAOF> gnutun: Depending on what your goal is - if it's a PPA or third party deb you want to make, #ubuntu-packaging is the right place.  If you want to get a new package into Ubuntu, or update an existing package, #ubuntu-motu.
[01:48] <gnutun> ok cool
[01:48] <gnutun> thx RAOF, its the former, so ill head over there
[04:55] <pitti> Good morning
[04:55] <pitti> directhex: if it has a considerably different name, I'd copy the file, so that it looks better in the UI
[04:55] <faina> good morning
[04:55] <pitti> apw: ah, thanks; will upload the udev branch
[05:52] <micahg> pitti: so, do you have a minute to chat about Maverick and the final langpack run?
[05:53] <pitti> micahg: sure
[05:53] <micahg> pitti: ok, so, what do you need from me, just a new Firefox in -proposed?
[05:54] <pitti> micahg: yes, that would do; that will also build firefox-locale-XX, right?
[05:54] <micahg> pitti: yes
[05:54] <pitti> micahg: with more effort I can also prepare the new langpacks against a PPA, but -proposed would be perfect
[05:55] <micahg> pitti: ok, so I'm off until Thursday, I can get it built and copied then, so Friday morning you should be able to kick off the translations builds
[05:55] <pitti> sounds good
[05:56] <micahg> then Monday, I figure I can put out a call for testing for Firefox + rdepends?
[05:56] <pitti> yes, it should have plenty of time for building over the weekend
[05:56] <micahg> ok, that gives us 1 wk in -proposed + 3 weeks in -updates before the next release, should be good
[05:58] <micahg> pitti: so, I'm going to build everything in one of the security PPAs, so I can pocket copy the stuff that won't need any changes for 7 to -security w/out needing to rebuild, sound ok?
[05:58] <pitti> oh, sure
[05:59] <micahg> but that copy won't happen until we release 7 :)
[05:59] <micahg> pitti: thanks, will be in touch later in the week then
[06:02] <andy753421> Is it too late to get a new package included 11.10? (it was just recently included in debian unstable)
[06:03] <micahg> andy753421: you need a freeze exception
[06:03] <micahg> !ffe | andy753421
[06:09] <andy753421> micahg: thanks, are exceptions generally granted? (It looks like I would need to have it all done by the 25th which is the BetaFreeze?)
[06:10] <micahg> andy753421: depends on the possible impact on the rest of the archive
[06:10] <micahg> andy753421: if minimal, generally yes
[06:11] <andy753421> micahg: i don't think there really would be, it's one package plus two dependencies, none of which were previously in ubuntu/debian
[06:11] <andy753421> so i don't think it would be likely to break anyting
[07:20] <dholbach> good morning
[07:46] <directhex> pitti, well, there's a Palm Pre entry, but the HP Pre 3 has a different usb id
[07:55] <smb> @pilot-in
[07:55] <udevbot> Error: "pilot-in" is not a valid command.
[07:55] <pitti> smb: <at> pilot in
[07:56] <smb> pitti, thanks
[07:56] <pitti> smb: <at>pilot in
[07:56] <smb> @pilot in
[07:56] <pitti> sorry
[07:56] <pitti> apparently smoser forgot to check out :)
[07:56] <smb> pitti, Its just that it seems to slip my memory every time
[07:59] <apw> pitti, man you get up early :)  thanks
[08:00] <pitti> apw: in fact I got up almost an hour later than usual :)
[08:00] <pitti> I slept in a bit, couldn't sleep well last night (way too hot..)
[08:01] <apw> pitti, heh, i'll have to start calling you pp (in honour of jj's mad time keeping)
[08:02] <soren> pitti: Is there a heat wave in Germany or are you somewhere else these days?
[08:03] <pitti> soren: south Germany, yes
[08:03] <pitti> well, I don't want to complain; until now we had a very cold and wet summer
[08:04] <soren> pitti: Yeah, same here.
[08:04] <soren> pitti: The cold and wet summer, that is. Not the heat wave :)
[08:04] <soren> pitti: It's been a steady 19-20 degrees here for a while.
[08:33] <ttx> it's been a steady 38-40 degrees here for a while.
[08:52] <hdmueller> hi there, could annyone please point me to a channel where to ask questions about packaging ?
[08:53] <tumbleweed> hdmueller: #ubuntu-packaging
[08:54] <hdmueller> thanks !
[08:54] <cjwatson> rsalveti: do you know what the right way to fix https://launchpadlibrarian.net/75657935/buildlog_ubuntu-oneiric-armel.openscenegraph_3.0.0-2ubuntu1_FAILEDTOBUILD.txt.gz is likely to be?
[08:57] <cjwatson> hm, possibly define OSG_GLES2_AVAILABLE on armel, shame it takes forever to build
[09:09] <cjwatson> jbicha: is https://code.launchpad.net/~jbicha/ubiquity/allow-user-entries-in-PartAdv/+merge/72525 intended to fix bug 831431, by any chance?  it would be nice if you could add a debian/changelog entry
[09:34] <jbicha> cjwatson: thanks, I neglected to look for a bug before finding a fix for it, added the changelog entry
[09:35] <cjwatson> rsalveti: (no rush, I've just removed it for now as investigation suggests that this needs non-trivial porting and I can't imagine it being very important)
[09:35] <cjwatson> jbicha: cool, will review, thanks
[09:58] <diwic> how does one reboot in Ubuntu 11.10?
[09:58] <diwic> (from the GUI)
[09:58] <doko> ev, good/bad missing replaces
[09:59] <tumbleweed> diwic: button in the shut down dialog
[09:59] <nigelb> I'm glad its hapening to a lot more people :)
[10:00] <diwic> tumbleweed, thanks. This does not seem to work from LightDM though?
[10:07] <ev> doko: I'm not seeing it. gstreamer0.10-plugins-good: Replaces: gstreamer0.10-plugins-bad (<< 0.10.22-2ubuntu3)
[10:09] <doko> ev: hmm, don't have the log anymore, just had a compiz crash and rebooted. but it was there :/
[10:10] <ev> doko: okay, I'll dig into it
[10:10] <ev> thanks for the heads up
[10:13] <Quintasan> Ehh. Can anyone tell me if I can stay within borders of USA without a guardian if I am 18 years old?
[10:14]  * Quintasan tried to call his embassy but he infoline is not working
[10:15] <nigelb> You should be. As long as you have a visa. (Obviously I'm not a lawyer)
[10:15] <nigelb> *valid visa
[10:15] <tumbleweed> Quintasan: I was in the US on my own, >18, <21, without issues, but no clue on the law here
[10:15] <Quintasan> nigelb: Cool, well, I wonder if I can even schedule a meeting for visa
[10:16] <Quintasan> First steps involve filling in some documents over the internet
[10:16] <Quintasan> But then you have to call them and schedule a metting with consul.
[10:16] <Quintasan> But guess what, the number is not working
[10:16] <Quintasan> :/
[10:17] <tumbleweed> Quintasan: check the website. Our US embassy doesn't answer their phones, web only
[10:19] <nigelb> Quintasan: you have to pay somewhere in between there
[10:19] <Quintasan> tumbleweed: Did you get touristic or work-related visa?
[10:19] <nigelb> Quintasan: attending a conf?
[10:19] <Quintasan> nigelb: UDS most likley
[10:19] <Quintasan> If I get sponsorship and visa -_-
[10:19] <nigelb> heh
[10:20] <nigelb> the second one is more worrysome.
[10:20] <Quintasan> Indeed
[10:20]  * nigelb got visa for Budapest the day before first flight.
[10:20] <tumbleweed> Quintasan: work
[10:22]  * Laney wonders where he put the ESTA information
[10:25] <directhex> you can re-print it if you re-log-in
[10:25] <Laney> that requires the number
[10:25] <Laney> ah, there's a button
[10:32] <doko> Laney, how much do you care about mono/dlr-languages?
[10:36] <Laney> doko: personally, not so much
[10:37] <Laney> doko: directhex had a look at the new upstream though
[10:37] <doko> ahh, ok. if nobody is interested in debian, then I maybe would package ironpython separately again
[10:38] <directhex> doko, it's an easy build from a clean source tree. what's on github is far from clean. basically, someone needs to spin up a distributable tarball - one without chunks of silverlight in it, for example - from there it's an easy xbuild
[10:38] <directhex> i don't plan to maintain it without sponsorship
[10:38] <doko> directhex, join the group ;)
[10:46] <jjardon> Hi, my oneiric box stop booting today. Seems that lightdm is restarting all the time. CTRL+ALT+Fx doesnt work. Any idea about what can be the problem?
[11:05] <Laney> can someone look at mono.reflection in NEW?
[11:11] <cjwatson> Laney: accepted
[11:12] <Laney> cheers
[11:12] <Laney> db4o is the last package for the mono transition, modulo some source and binary removals
[11:12] <Laney> :-)
[11:13]  * Laney really goes to lunch
[11:14]  * directhex is sitting & being twitchy, waiting for touchpad related news
[11:15] <akarsh> Hello everyone...I am new to ubuntu development. I needed some help
[11:16] <akarsh> any developers here?
[11:17] <jelmer> hi akarsh
[11:18] <jelmer> akarsh: please ask your question - if there's somebody around who can help they'll reply
[11:20] <akarsh> hello
[11:21] <akarsh> i am palnning to start with ubuntu development. I need to know where to start.
[11:22] <jelmer> akarsh, https://wiki.ubuntu.com/ContributeToUbuntu is a good start
[11:22] <akarsh> well i have gone through it i have setup my system with everything also i have stup my launchpad account
[11:23] <akarsh> i need to know the way forward.
[11:24] <jelmer> akarsh: What would you like to work on, what are your skills?
[11:24] <akarsh> well i know c,c++,java,python But i would prefer to work on Python.
[11:25] <akarsh> Mainly my intentions are to understand the way linux works by this process. Pleas suggest which way to procede
[11:26] <cjwatson> most people simply start by finding something that annoys them that they want to fix, fixing it, sending the fix to wherever's appropriate (bug report, upstream mailing list, whatever), and repeating
[11:27] <cjwatson> there is no master task list from which people will assign you things to work on - it all works much better if you find things that interest you
[11:28] <akarsh> okay thanks.  I was going through a beginners project
[11:28] <akarsh> (Stipple)....can i just start looking into the code and maybe change the code
[11:29] <cjwatson> that's how it usually works, yes :)
[11:30] <akarsh> okay cool. thanks for your suggestions. will try to do that.
[11:30]  * cjwatson is pretty sure that e.g. jelmer and me started in completely different places given different interests
[11:31] <cjwatson> remember you can run 'apt-get source' any package name and look at its code
[11:32] <akarsh> okay...thats a great start. i wanted to know if what i was doing was right. so will start looking into code for starters now. Thanks for you suggestion
[12:15] <smoser> @pilot out
[12:19] <Daviey> doko: Can you give back https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2699238 ?  It built fine locally.. :/
[12:20] <doko> Daviey, could you save the build log first?
[12:20] <ahasenack> so by convention packaging-only branches have the debian directory with its files, and not just the files directly?
[12:20] <Daviey> doko: done, will attach to bug
[12:21] <ahasenack> i.e., a packaging-only branch will have "debian/rules", and not just "rules"?
[12:22] <Daviey> ahasenack: no, packaging-only normally has ./debian/rules
[12:22] <ahasenack> Daviey: ok, so "debian/" is included
[12:22] <Daviey> ahasenack: normally, but note that you cannot currently make it a UDD branch.
[12:23] <ahasenack> Daviey: I wonder how that works with nesting in launchpad recipes, i.e., "nest packaging lp:~foo/bar/packaging-only debian"
[12:23] <ahasenack> Daviey: would that create "debian/debian/rules"?
[12:23] <doko> Daviey, given back
[12:23] <ahasenack> maybe I need nest-part, hmm
[12:24] <Daviey> doko: thanks
[12:27] <Daviey> ahasenack: yeah, see the nest-part at https://help.launchpad.net/Packaging/SourceBuilds/Recipes ?
[12:27] <ahasenack> Daviey: ok, thanks
[12:28] <ahasenack> Daviey: fwiw, I have been omitting the debian/ directory in my packaging branches, I thought it was superfluous
[12:31] <Daviey> ahasenack: I think it's a convention rather than a rule.
[13:05] <RawChid> Hello, anyone here who I can talk to about OneConf?
[13:09] <RawChid> I'm looking at the strings of oneconf. And see a lot of sentences don't begin with a  capital. Some of them are shown in --help, and some of them are just "print"  messages.   I think about translating them all Capitalized. What do you think?
[13:10] <RawChid> I can contribute by "improving" the original strings if you want.
[13:11] <RawChid> I see pitti has done a commit :P
[13:11] <pitti> to oneconf? I don't remember, and I don't really know anything about it, I'm afraid
[13:11] <pitti> ah, I might have done a GI fix
[13:13] <seb128> ev, can you handle bug #831897
[13:13] <seb128> ?
[13:14] <seb128> oneconf> open a bug, didrocks will be back next week
[13:14] <RawChid> Okay seb128
[13:16] <smb> @pilot out
[13:19] <ev> seb128: yes, will do
[13:19] <seb128> ev, thanks
[13:20] <doko> Sweetshark, what are you trying to do with libgcc_s.so.1 on armel? the .so file is a linker script, not a symlink
[13:20] <doko> lo ...
[13:41] <ogasawara> @pilot in
[13:51] <Sweetshark> doko: since we are searching for libgcc_s.so not libgcc_s.so.1 in the system that might be a nonissue.
[13:53] <doko> Sweetshark, yes, and apparently you do *copy* the .so, which is wrong
[13:57] <Sweetshark> doko: how so?
[13:57] <doko> Sweetshark, look at the linker script
[15:56] <doko> Sweetshark, see bug #832121, somebody did "cleanup" too much in 3.4.x ;p
[16:04] <Sweetshark> doko: no, the root cause is a change in our gcc -- elsewhere (RHEL, SUSE) there is no symlink and no filename versioned libgcc file
[16:04] <Sweetshark> doko: that still worked fine on natty IIRC.
[16:08] <doko> (natty)doko@kakadu:~/gcc/4.6$ ls -l /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.5/ | grep libgcc_s
[16:08] <doko> -rw-r--r-- 1 root root     135 Apr  2 20:49 libgcc_s.so
[16:08] <doko> lrwxrwxrwx 1 root root      36 Apr  9 13:55 libgcc_s.so.1 -> /lib/arm-linux-gnueabi/libgcc_s.so.1
[16:08] <doko> Sweetshark, nice try, but please try harder next time ;p
[16:18] <Sweetshark> doko: http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=aff9db4f58e6cd1015866e169a1a909fd6f31590
[16:25] <doko> Sweetshark, don't see a relevant thing there, but in this case, if libgcc_s.so is a file and *not* a symlink, it should copy the file, and not automagically symlink
[16:26] <doko> Sweetshark, and for the powerpc build failure it would be nice to have the command line for the ld call
[17:01] <SpamapS> slangasek: FYI, upstart branch back in sync w/ archive.
[17:02] <slangasek> SpamapS: huzzah, thanks :)
[17:37] <doko> Sweetshark, is it intended to build lo with -Os on ix86?
[18:29] <mdeslaur> slangasek: can a amd64 package depend on i386 packages?
[18:30] <infinity> mdeslaur: Implicitely, not explicitely.
[18:31] <mdeslaur> infinity: what do you mean by that?
[18:31] <infinity> mdeslaur: As in, you can depend on a package that only exists on i386, and it'll work out, but you can't explicitely depend on package:i386
[18:31] <mdeslaur> infinity: hmm...not exactly the answer I wanted
[18:31] <mdeslaur> infinity: so, I need flashplugin-installer to depend on nspluginwrapper on amd64 only
[18:32] <mdeslaur> infinity: so either I get rid of the amd64 package, and figure out a way to have an arch-specific depends
[18:32] <infinity> mdeslaur: Which, in turn, depends on nspluginviewer, which is i386 only.
[18:33] <mdeslaur> infinity: or I keep the amd64 package, depend on nspluginwrapper, but need a way to specify :i386 depends
[18:33] <infinity> No you don't...
[18:34] <chrisccoulson> mdeslaur, infinity - that bit seems to work already (ie, installing flashplugin-installer pulls in nspluginwrapper, which pulls in nspluginviewer:i386 and all of it's i386 dependencies)
[18:34] <infinity> If you keep the amd64 package, it depends on nspluginwrapper, and you're done.
[18:34] <infinity> chrisccoulson: Indeed.
[18:34] <mdeslaur> infinity: no, because the amd64 package won't pull in all the required i386 libraries
[18:34] <chrisccoulson> what's broken is that flashplugin-installer needs to pull in libnss3:i386
[18:34] <chrisccoulson> ^^infinity
[18:34] <chrisccoulson> that used to be shipped in ia32-libs
[18:35] <chrisccoulson> and now flash is broken on amd64, because nothing pulls it in
[18:35] <chrisccoulson> which i s breaking firefox ;)
[18:35] <infinity> Perhaps nspluginviewer needs to depend on libnss3?
[18:35] <chrisccoulson> infinity, not really. that's technically incorrect, as it doesn't need it
[18:35] <chrisccoulson> the flash plugin does though
[18:35] <infinity> Fair enough.
[18:35] <chrisccoulson> flashplugin-installer:i386 does pull it in though
[18:36] <mdeslaur> infinity: any ideas?
[18:36] <infinity> Well, then.  flashplugin-amd64 depends flashplugin-installer (>= [version where you stop building it on amd64], nspluginwrapper
[18:36] <infinity> And then you die a little inside.
[18:36] <infinity> And try to figure out an upgrade path.
[18:37]  * mdeslaur dies a little inside
[18:38] <mdeslaur> ideally, the flashplugin-installer package would go away completely, and we would only keep adobe-flashplugin in partner
[18:39] <infinity> Ideally, sure.
[18:39] <mdeslaur> chrisccoulson: I know! make firefox amd64 depend on nspluginwrapper :P
[18:39] <chrisccoulson> lol
[18:39] <infinity> Is there a reason we don't just ship the actual amd64 build of flash?  Just fear of unsupported betas, I guess? :/
[18:39] <chrisccoulson> over my cold hard dead body ;)
[18:39] <chrisccoulson> (to firefox depending on nspluginwrapper)
[18:39] <mdeslaur> infinity: it's not updated for security fixes, and I'm pretty sure adobe won't let us redistribute it
[18:39] <infinity> Fair on both counts.
[18:40] <mdeslaur> hopefully they'll ship flash 11 before we release oneiric
[18:40] <infinity> But yeah, given the current wrapper/viewer situation, something evil's going to happen to transition flash to multiarch.
[18:41] <chrisccoulson> i've subscribed you both to bug 830802
[18:42] <chrisccoulson> the freezing is a symptom of flash going crazy ;)
[18:42] <infinity> I guess if you don't want the above evil situation, you could create a "flashplugin-installer-noreally-we-mean-it-this-time" cause there aren't enough flash packages depending on flash packages already.
[18:43] <infinity> Then you can keep -installer on both arches, have both depend on the (i386-only) new package, and make it work.
[18:43] <mdeslaur> I need to think about that a minute
[18:43] <mdeslaur> you're confusing my feeble brain
[18:44] <mdeslaur> infinity: oh, interesting
[18:44] <infinity> mdeslaur: Basically, move the current installer code from -installer to -downloader (or something) and make it i386-only, with correct dependencies.  Then turn -installer (on both arches) into a metapackage that just depends on -downloader and (on amd64) wrapper.
[18:44] <infinity> mdeslaur: That gets you a smooth upgrade path on both arches.
[18:45] <mdeslaur> infinity: yes, very interesting...that would do the trick
[18:45] <mdeslaur> infinity: thanks!
[19:15] <micahg> mdeslaur: I think slangasek has a test version of the fixed installer with dependencies in his multiarch PPA
[19:16] <mdeslaur> micahg: oh? thanks, I'll go take a look
[19:20] <mdeslaur> micahg: wow, that's a creative way of solving it :P
[19:21] <mdeslaur> slangasek: any plans on releasing that package to the archive?
[19:21] <mdeslaur> micahg: thanks for pointing that out, I was about to work on it
[19:25] <infinity> mdeslaur: More or less the same as my solution, I guess, but without adding (yet) another package. :)
[19:26] <mdeslaur> infinity: yeah, slightly more twisted, but no extra package
[19:54] <cjwatson> #copy-package.py -y -b -s maverick-security --to-suite maverick-updates -e 1.2.11-6+squeeze2build0.10.10.1 wireshark  # maverick-updates: 1.2.11-6+squeeze1build0.10.10.1
[19:54] <cjwatson> #copy-package.py -y -b -s natty-security --to-suite natty-updates -e 1.1.1-0ubuntu1~11.04.1 icedtea-web  # natty-updates: 1.1~20110420-0ubuntu1.1
[19:54] <cjwatson> jdstrand: ^- do you know what should be done with those?  I've been seeing that for a while
[19:56] <jdstrand> cjwatson: the former, yes-- it should definitely be copied
[19:56] <jdstrand> cjwatson: the latter I will defer to sbeattie. istr a new package needing to be created, but will let him comment
[19:57] <jdstrand> cjwatson: I just took care of wireshark
[19:57] <cjwatson> thanks
[19:57] <sbeattie> yes, icedtea-web should go to natty-updates.
[19:58] <jdstrand> I'm right there
[19:58] <jdstrand> I'll do that too
[19:58] <sbeattie> jdstrand: thanks!
[19:58] <jdstrand> cjwatson: thanks for bringing it up. maybe I should run a similar cron job :)
[19:58] <cjwatson> excellent, less mail for meeeeeee
[19:58] <jdstrand> :)
[19:59] <cjwatson> 5 * * * *       /home/lp_archive/bin/copy-report 2>/dev/null
[19:59] <cjwatson> FWIW
[19:59] <jdstrand> cool, thanks
[20:03] <ogasawara> @pilot out
[20:14] <statik> hey there smoser, https://bugs.launchpad.net/ubuntu/+source/euca2ools/+bug/826022 doesn't seem to be fixed for me. I added a comment to the bug; any other info I could provide for you?
[20:15] <sgnb> infinity: how is ocaml stuff going on?
[20:16] <Daviey> statik: confirmed.
[20:17] <smoser> statik, checking
[20:17] <Daviey> smoser: I confirmed rev454 upstream fixed it for me, either the archive snapshot is not >454, or upstream reintroduced it.
[20:18] <smoser> its probably a freaking quilt issue
[20:18] <infinity> sgnb: I was planning to finish it today, but am/was off sick.  Feeling a bit better though, so I might do it anyway. :P
[20:18] <statik> Daviey, smoser: thanks for confirming. i didn't flip the bug back to open, don't hesitate to ping me if you want me to test it later
[20:18] <Daviey> smoser: debian-changes-2.0.0~bzr464-0ubuntu1
[20:18] <smoser> its fixed locally
[20:19] <smoser> you just need my version
[20:19] <smoser> euca2ools (2.0.0~bzr464-0ubuntu2) UNRELEASED; urgency=low
[20:19] <smoser>   * fix bad upload that had patch a debian-changes patch which reverted
[20:19] <smoser>     the intended changes
[20:19] <smoser> :-(
[20:20] <cr3> smoser: a patch of a patch? :)
[20:20] <smoser> yeah, bad grammer there (and i fixed that, am uploading now)
[20:21] <Daviey> automatically generating debian-changes-* without a loud warning was not the brightest idea.
[20:21] <Daviey> I think doing that has bitten too many peope.
[20:21] <cjwatson> dpkg-dev is gradually moving away from that practice I think
[20:21] <cjwatson> there are at least now options you can set to make it not do that
[20:22] <Daviey> dave@voodoo:~$ cat ~/.devscripts
[20:22] <Daviey> DEBUILD_DPKG_BUILDPACKAGE_OPTS="--source-option=--abort-on-upstream-changes"
[20:23] <smoser> yeah, i used to have that... unfortunately i had to diable it at some point i forget why
[20:23]  * smoser adds it back
[20:30] <Laney> at least lintian issues a warning now
[20:31] <seb128> Laney, hey
[20:31] <seb128> Laney, will you do the tomboy update? ;-)
[20:32] <Daviey> Laney: Who looks at lintian warnings anyway?! :)
[20:36] <faina> --abort-on-upstream-changes will keep a package from dropping a debian-changes-* into debian/patches/?
[20:49] <Laney> me...
[20:49] <slangasek> mdeslaur, infinity: unfortunately, that twisted way of solving it doesn't actually *work*; apt-gets confused and won't let the packages be installed together
[20:49] <slangasek> er
[20:49] <slangasek> apt gets confused
[20:49] <slangasek> :)
[20:49] <Laney> seb128: and yes
[20:49] <seb128> Laney, thanks ;-)
[20:49] <Laney> maybe tomorrow, maybe tonight, who knows ...
[20:50] <mdeslaur> slangasek: oh, :(
[20:50] <seb128> no hurry
[20:52] <Laney> bdrung: cody-somerville: dmb vote ping
[20:53] <infinity> slangasek: So, my slightly-less-twisted-but-similar method might do the trick better?
[20:53] <slangasek> might, though I'd like to get to the bottom of what apt's thinking
[20:54] <slangasek> it just means I'm not going to upload it to the archive yet :)
[20:54] <slangasek> what was your method?
[20:55] <infinity> slangasek: Moving the installer/downloader code to flashplugin-downloader:i386, and making -installer be a metapackage that depends on that, plus in nspluginwrapper on amd64.
[20:55] <infinity> s/plus on/plus in/
[20:55] <infinity> Err.
[20:55] <infinity> I can't brain today.
[20:55] <infinity> I have the sick.
[20:57] <infinity> slangasek: Pretty much the same/similar idea to yours, but without reusing the old -nonfree packages for nefarious purposes and (I suspect) creating dependency loops that make apt shoot itself.
[20:58] <slangasek> infinity: right.  that should do the job then