[00:06] <slangasek> bryceh: ok, the fglrx package appears to check out as DTRT, I think the submitter of that bug simply didn't use the Ubuntu fglrx package
[00:07] <bryceh> slangasek, yep, that's what I thought.  It's sort of a known donut hole.  I put it in our spec and test plans to try to handle the corner case better but I think tseliot had too many other tasks to juggle
[00:08] <superm1> the problem is that the changes for the fglrx packaging don't trickle into AMD's releases for 2-3 releases
[02:40] <psusi> hrm... seems the disk UUID mapping gives preference to the snapshot over the original volume.... not good.
[03:34] <soren> psusi: What, still?!?
[03:35]  * soren facepalms
[03:38] <soren> kees: Would you say bug 460906 is important enough to be fixed this late in the cycle?
[03:38]  * soren thinks so
[03:40] <hyperair> that suonds like a potentially problematic bug
[03:41] <soren> Indeed. I spotted it quite late in the karmic cycle (a few days before release, apparantly) and then forgot all about until just now.
[04:39] <kees> soren: I still don't have much of an opinion about it.  I think by-uuid for a snapshot is kind of meaningless (i.e. the lv name is the unique part)
[04:39] <kees> soren: there is logic for the link either direction.
[05:22] <slangasek> doko_: I've confirmed that bug #417757 *is* still present in lucid
[07:03] <twb> Can I make pbuilder automatically run lintian on the .changes file it generates?  If so, how?
[07:09] <pitti> Good morning
[07:09] <pitti> beuno: aptitude> hm, not sure; mvo?
[08:19] <dholbach> good morning
[08:22] <[reed]> anybody know why Ubuntu's apache2 doesn't link against libssl like Debian's does?
[08:36] <twb> [reed]: from the PTS page (http://packages.qa.debian.org/a/apache2.html) you can find a link to the patch between Debian and Ubuntu.  That usually explains why.
[08:37] <twb> I can't see anything obvious there, so maybe you misdiagnosed it?
[09:00] <primes2h> pitti: Hello, please wait a moment before closing bug 536914. I found out there are other few keys that needs fixing (<255) I'll tell you when I finish.
[09:02] <pitti> primes2h: hm, I thought I reopened it already?
[09:02] <pitti> ah, I did
[09:03] <pitti> primes2h: ok, waitin gthen
[09:03] <primes2h> pitti: Yes, I mean, there is still other 2 keys  I have to triage
[09:03] <primes2h> pitti: thanks
[09:06] <primes2h> pitti: I also sent a message to our Italian Testing ML asking Simona (Aspire 1640) to tell me about her full keyboard layout.
[09:06] <primes2h> pitti: I'll let you know ASAP
[09:10] <TheMuso> pitti: Would I break anything if I were to include the checking of hd[a-z] in the 60-cdrom_id.rules udev rule? This is needed for lucid only, as there is no libata version of powerpc/mac's IDE driver. A driver is supposedly in 2.6.33, so this rule change is only needed till lucid+1, and its safer than backporting a driver in the kernel.
[09:10] <mkarnicki> lwindow 1
[09:11] <mkarnicki> oops sry guys ;)
[09:11] <pitti> TheMuso: this sounds very similar to what Debian has to do; I thought mbiebl already had a patch for IDE CD-ROMs, let me check
[09:13] <pitti> TheMuso: http://git.debian.org/?p=pkg-utopia/udisks.git;a=blob;f=debian/patches/10-ide-cd-support.patch;h=59a19e4eaf414b9b8bdf0588898d964ff95613f3;hb=HEAD
[09:13] <pitti> TheMuso: it basically adds the blkid call for ID_CDROM_MEDIA hd*
[09:13] <pitti> TheMuso: is that what you need?
[09:14] <TheMuso> pitti: No, I mean actually editing 60-cdrom_id.rules to check for add|change nodes on hd[a-z] for IDE CD devices that are on the pmac driver in 2.6.32 and below, which doesn't have a libata equivalent.
[09:14] <TheMuso> I'm just wondring whether checking those nodes shoudl they exist will break anything.
[09:15] <TheMuso> so the change is in udev itself.
[09:15] <pitti> ah, I see
[09:15] <pitti> TheMuso: hm, Debian should have that change as well then, otherwise mbiebl's udisks patch couldn't work at all
[09:16] <TheMuso> true
[09:16]  * TheMuso checks sid's udev.
[09:16] <pitti> TheMuso: so, I don't think it would hurt at all, but it'd be the first and only delta to upstream that we have in udev, and I don't think Keybuk will like it a lot
[09:16] <pitti> TheMuso: OTOH there's nothing wrong with shipping a 60-cdrom_id-ide.rules in a powerpc specific package :)
[09:16] <TheMuso> pitti: RIght, I can understand that.
[09:17] <TheMuso> pitti: There is that too. I'll have to see how that could be included in d-i, as d-i installation from alternates on powerpc are broken due to this issue.
[09:18] <pitti> TheMuso: oh, right, I could just stuff the new rule into debian/ in udev
[09:18] <pitti> TheMuso: and only install it on powerpc, to be on the safe side
[09:18] <TheMuso> pitti: that works
[09:18] <TheMuso> pitti: there is an LP bug for this, reported by someone else. I'll fetch the number.
[09:19] <pitti> TheMuso: confirmed, sid's udev has the rule like that
[09:19] <TheMuso> pitti: oh ok you beat me to it.
[09:19] <pitti> TheMuso: ok, please assing it to me; I'll have a quick discussion with Keybuk about how he wants this packaged, and get to it
[09:19] <TheMuso> bug 534912
[09:20] <TheMuso> pitti: ok thanks.
[10:33] <mvo> cjwatson: hi, are you ok with the name "SUPPORTED_OVERWRITES.hints" for the fine-tuning file for lucid-support-timeframe? I will put it in lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid - I'm happy about better matching names
[10:39] <mvo> cjwatson: or maybe SUPPORT_TIME_OVERWRITES.hints ?
[11:00] <pecisk> kenvandine: hi, are you here? :)
[11:01] <jibel> mvo, hey, I need advice to fix bug 130289
[11:01] <mvo> jibel: let me have a look
[11:02] <jibel> mvo, the problem is with the way apt reads it's configuration and parse encoded characters.
[11:02] <jibel> e.g %40 is stored internally as @
[11:02] <jibel> It's then really difficult to parse an URI with password containing these characters
[11:02] <jibel> mvo, Is there any way to read the raw value of a configuration item ?
[11:03] <jibel> If there's no trivial solution I'll update the URI parser.
[11:06] <mvo> jibel: something like QuoteString etc from apt-pkg/contrib/strutils.cc does not help I assume?
[11:08] <jibel> mvo, no it will quote the whole string. if there something like Acquire::http::Proxy "http://user2:p%40s%2Fs%3Aword@localhost:3128";
[11:09] <jibel> mvo, I need the value http://user2:p%40s%2Fs%3Aword@localhost:3128 not user2:p@s/:word or worse user2:p%40s%2Fs%3Aword%40localhost%3A3128
[11:10] <mvo> jibel: could we read the string from the config, use the URI class to convert it, and then QuoteString/UnQuoteString only on URI.User, URI.Password?
[11:11] <mvo> jibel: I guess it would make a lot of sense to add a GetRaw to the configuration class in apt itself, let me have a look
[11:13] <ion> I love seeing fixes for race conditions by adding ‘sleep 3’. :-) (foo2zjs changelog)
[11:13] <jibel> mvo, That's what I was thinking too. Add a FindR method and a RawValue member to the Item struct
[11:23] <ion> tkamppeter: Isn’t having a udev script call sleep EBW?
[11:23] <pecisk> kenvandine: so far I couldn't get libproxy to recognise different server for https, and also it ignores auth. user and password in GNOME proxy settings
[11:23] <slangasek> ion: elephantine beyond words?
[11:23] <slangasek> oh, "evil bad wrong"?
[11:23] <ion> bingo
[11:24] <slangasek> yes, udev doesn't allow long-lived child processes
[11:27] <jibel> mvo, the problem is elsewhere. apt reads and stores its configuration correctly but it converts and stores the string a second time.
[11:30] <pecisk> kenvandine: seems like we will have to patch libproxy to support more than simple proxy handling to have proper support.
[11:38] <cjwatson> mvo: all-caps is reasonable to avoid clashes - how about SUPPORTED-HINTS?
[11:39] <cjwatson> EBW> I like "B&R" (Bad and Rong)
[11:46] <mvo> cjwatson: thanks, SUPPORTED_HINTS is fine, I will use that
[11:58] <lamont> asac/ogra: http://launchpad.net/builders/gourd
[11:58] <lamont> this will especially be a win if eglibc is FTBFS on imbe
[11:59] <jibel> mvo, the problem is in  pkgAcqMethod::Configuration where all the config items are "dequoted" I guess
[11:59] <mvo> jibel: ohh, that makes sense
[12:00] <lamont> asac/ogra: since my testbuild of that version of eglibc on gourd resulted in bug 546808
[12:01] <kenvandine> pecisk, can you check in #libproxy first?
[12:01] <kenvandine> pecisk, i would be surprised if that was the case
[12:01] <kenvandine> pecisk, nevermind... i see you did
[12:01] <kenvandine> rock on :)
[12:01] <pecisk> kenvandine: i run trough code, it is very simple, they handle only http now
[12:02] <tjaalton> is there a long backlog of builds or other problems, since ppa packages seem to take many hours before getting built
[12:02] <pecisk> problem is - if you want to use libproxy in Lucid, it would have rather large feature set to add, and it is kinda no no as far as I know
[12:02] <pecisk> nevermind that code is kinda simple
[12:02] <mvo> jibel: apt-get update -o Debug::pkgAcquire::worker=true will show you the configuration messages that are send
[12:02] <pecisk> run/ran/s
[12:03] <lamont> tjaalton: lots of uploads, and the extra machines that we generally steal to be ppas are being used for their primary role atm, it would appear
[12:03] <lamont> at least "many of"
[12:03] <tjaalton> lamont: ok, I'll wait then
[12:06] <tjaalton> though at least i386/amd64 buildd's don't have any "'currently building' build records"
[12:07] <lamont> https://edge.launchpad.net/builders
[12:07] <jibel> mvo, that's it. I removed the DeQuoteString and the password is ok.
[12:07] <tjaalton> hah, a lot accurate it seems :)
[12:07] <tjaalton> +more
[12:08]  * tjaalton bookmarks
[12:08] <tjaalton> damn daily/nightly builds ;)
[12:11] <jibel> cjwatson, hi, could you have a look at bug 545790, 545738, 454354. This is an odd error and there's an increasing number of reports since a few days.
[12:12] <jibel> cjwatson, there error is triggered when dpkg fflush an error message but the fflush fails.
[12:12] <jibel> cjwatson, The scenario seems to be: user run update-manager, system crash, reboot, apport triggers and report those errors.
[12:13] <ogra> lamalex, i dont think the test is a HW specific failure (fails on pegatron as well as on babbage afaik)
[12:13] <ogra> lamont, ^^^
[12:13] <jibel> mvo, do you think adding an untouched raw config value is the right solution ?
[12:16] <cjwatson> jibel: any idea when it started appearing?
[12:16] <cjwatson> jibel: (BTW I really appreciate this sort of active triage/collation work and direct contact with developers on the hot bugs - it's invaluable)
[12:17] <cjwatson> $ wcgrep 'm_output.*standard output' | wc -l
[12:17] <cjwatson> 35
[12:17] <cjwatson> oh dear
[12:18] <jibel> cjwatson, in karmic, but the rate is higher since the latest beta
[12:18] <cjwatson> could just be increasing number of upgrades, then
[12:18] <mvo> jibel: you removed the UnQuoteString in ::Configuration ? or where?
[12:20] <mvo> jibel: there was a crash bug for a couple of hours in update-manager that may have triggered this
[12:20] <jibel> mvo, yes, but that's definitely not the right solution ;)
[12:20] <mvo> jibel: that is why I asked :)
[12:21] <jibel> mvo, but that confirms that's the problem since there's no more 407 from the proxy.
[12:21] <mvo> jibel: hm, hm, tircky to solve
[12:21] <lamont> ogra: hence the bonus points if it does fail on pegatron
[12:21] <mvo> jibel: but great that we know excactly what the problem is now
[12:22] <jibel> mvo, have some lunch. cu
[12:22] <mvo> jibel: see you (and thanks!)
[12:26] <asac> lamont: can you try to build libplist on one of the newer builders?
[12:28] <lamont> asac: assuming it builds, how long does it run?
[12:30] <asac> lamont: really quick
[12:30] <asac> a couple of minutes
[12:31] <asac> lamont: its the one that failed because of thumb2 instructions in the test binaries
[12:31] <lamont>  /home/buildd/libplist-1.1/obj-arm-linux-gnueabi/swig/plistPYTHON_wrap.cxx:9369: warning: deprecated conversion from string constant to 'char*'
[12:31] <lamont> giggle
[12:31] <lamont> ah, cool
[12:32] <lamont> tests 100% passed.
[12:32]  * asac happy!
[12:32] <asac> lamont: was that a real archive build? or just a test build?
[12:32] <asac> e.g. are the bits now in ?
[12:32] <lamont> just a test
[12:32] <asac> ah ok
[12:33] <lamont> forcing the build to happen there requires, um, more work
[12:33] <asac> heh
[12:33]  * lamont goes to throw it against the wall a little
[12:35] <ogra> but that smells very good already :)
[12:51] <ion> keybuk: You might find a udev script doing ‘sleep 3’ interesting. Oh, and the ‘sleep 3’ is a also ‘fix’ for a race condition. ;-) The package is foo2zjs.
[12:51] <Keybuk> *shrug*
[12:51] <Keybuk> probably works just fine in mandriva
[13:17] <pecisk> libparted segfaults in daily lucid server cd when trying to get partition tables from hard drives
[13:23] <cjwatson> pecisk: please submit a bug report with full logs
[13:39] <pecisk> c
[13:40] <pecisk> will do
[14:06] <mvo> jibel: I updated bug #130289 with a possible solution, I would be interessted if it helps
[14:07] <tkamppeter> ion, the sleep is called in a script which the udev rule starts in the background. The udev rule exits while the script is still running.
[14:07] <Keybuk> tkamppeter: why does it sleep though?
[14:08] <cjwatson> pitti: what's the easiest way for me to test that new ntfs-3g still works with udisks?
[14:09] <pitti> cjwatson: create an USB stick with an NTFS partition, plug it in, and see if it automounts?
[14:09] <pitti> cjwatson: I also have a test suite for udisks, which covers NTFS as well
[14:10] <pitti> http://cgit.freedesktop.org/udisks/tree/tests/run
[14:10] <pitti> you can just run that
[14:11] <pitti> cjwatson: but if an NTFS usb stick automounts, it should be okay; I don't suppose it changed the mount.ntfs-3g CLI, did it?
[14:13] <cjwatson> shouldn't think so
[14:18] <xnox> Please sponsor sync Bug #546482. It's bugfix & translation lucid-special LTS upstream release.
[14:24] <mvo> Riddell: I attached a patch to bug #546024, you may want to check if the version is correct and commit to bzr (I don't think I have commit access to the relevant branch)
[14:29] <lemsx1> Please see bug # 546929 as this affect new installations in today's netboot installer
[14:29] <cjwatson> pitti: thanks, ntfs test passes, uploading
[14:29] <pitti> \o/ thanks
[14:29] <cjwatson> didn't have a handy USB stick but I guess "fs: NTFS ... [cli] [ud] ok" is good enough
[14:30] <cjwatson> lemsx1: *please* don't file bugs against the 'lucid' project
[14:30] <pitti> cjwatson: right
[14:30] <pitti> cjwatson: out of interest, how much of the tests passed for you?
[14:30] <cjwatson> lemsx1: read the text in ALL CAPS on https://launchpad.net/lucid
[14:30] <pitti> s/much/many/
[14:30] <cjwatson> pitti: oh, I just did './run FS.test_ntfs'
[14:30] <pitti> cjwatson: ah, fair enough
[14:31] <pitti> cjwatson: I was just curious, since I didn't get a lot of feedback from other people/distros about it yet (except from mbiebl)
[14:31] <pitti> but nevermind
[14:31] <cjwatson> lemsx1: I've reassigned your bug to the proper place
[14:32] <cjwatson> lemsx1: of course the developers of that text editor will keep on getting mailed about it, but ...
[14:35] <ScottK> mvo: We get phonon from qt4-x11 now.  I moved the bug to the right package.
[14:35] <mvo> ScottK: thanks
[14:35] <ScottK> doko_: Does your gcc4.4 ia64 fix mean we can drop the ia64 specific work around in our next qt4-x11 upload?
[14:36] <pecisk> hi people, if I configure GNOME proxy settings with auth. user and password, I can't get http_proxy as http://user:password@host:port, but simply as http://host:port. It is intentional?
[14:36] <doko_> ScottK: yes
[14:36] <ScottK> doko_: Thanks.
[14:38] <jibel> mvo, it doesn't help. the problem is really with the global dequotestring in pkgAcqMethod::Configuration
[14:39] <jibel> mvo, we want some config vars to be unquoted and some other not to be.
[14:40] <jibel> mvo, more precisely, not dequoted at this moment.
[14:44] <jibel> mvo, couldn't we had an exclusion list of config vars ? And do not apply the DeQuoteString in the Cnf.Set call for those parameters ?
[14:46] <jibel> pecisk, hi, I can't reproduce.
[14:48] <mvo> jibel: I think that will work, could you attach a dump of the debug output please to the bugreport (from the pkgworker). I wonder if we can not quote some stuff specially so that on unquote its fully restored or have a different unquoe that ensures only what was quoted before gets unquoted. it sounds like this really what we want, that quote/unquote are fully reversible
[14:49] <pecisk> jibel: proxy problem?
[14:50] <jibel> pecisk, sorry, I cannot reproduce the proxy problem
[14:50] <pecisk> jibel: it gives you correct http_proxy value?
[14:51] <jibel> pecisk, set a proxy with user/pass. Open a new terminal and echo $http_proxy -> http://user2:p%40ssword@localhost:3128/
[14:51] <pecisk> strange
[14:51] <pecisk> doesn't work for me
[14:52] <jibel> pecisk, file a report, I'll have a look. ubuntu-bug gnome-control-center. Thanks.
[14:53] <tseliot> PlyBuk, err... Keybuk, how are things going with plymouth?
[14:56] <Keybuk> tseliot: stalled for the moment
[14:57] <tseliot> Keybuk: can I have access to that patch/commit of yours which makes sure that deactivate and quit work correctly (just for testing locally), please?
[14:57] <Keybuk> tseliot: why not just pull from the branch and build that?
[14:58] <tseliot> Keybuk: well, what kind of problems are you facing (so that I can be prepared)?
[14:59] <Keybuk> oh, just irritating messages on boot ;-)
[14:59] <tseliot> I think I can deal with that
[14:59] <tseliot> ;)
[14:59] <Keybuk> it may not show a splash screen also
[15:00] <tseliot> now you're making it too easy for me to blame it on your work if my patch messes things up
[15:00] <tseliot> :-D
[15:00] <mvo> jibel: could you please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/apt/+bug/130289/comments/4 ?
[15:01] <mvo> jibel: unless I'm missing something it should help
[15:02] <mvo> jibel: actually I guess QuoteString() should always quote % to ensure its reversible on DeQuoteString()
[15:05] <jibel> mvo, log attached to the bug report.
[15:05] <cjwatson> lemsx1: thanks, this looks pretty widespread, I've cranked up the priority
[15:09] <lemsx1> cjwatson: thnx
[15:10] <mvo> jibel: thanks! with or without the patch
[15:10] <mvo> ?
[15:10] <lemsx1> cjwatson: sorry. i didn't see the text about the Lucid project... I'll follow that next time ;-)
[15:11] <lemsx1> cjwatson: wtf is Lucid editor... lol good one
[15:12] <lemsx1> cjwatson: I have another system that I ran into issues and I was able to fix the problem. it's an OQO (mobile device). I needed to blacklist the viafb driver. Is this something that I should file as a bug too? (hardware specific issue)
[15:12] <cjwatson> lemsx1: err, I'm not a kernel hacker so I don't know
[15:12] <cjwatson> lemsx1: I imagine you should file a bug if you're having problems
[15:13] <zul> pitti: when you get a chance can you review 522509 please? thanks
[15:14] <lemsx1> cjwatson: against what package? or just Lucid in general?
[15:14] <cjwatson> lemsx1: the linux package in Ubuntu I assume, since it sounds like a kernel bug
[15:40] <sebner> bdrung: I think java is b0rken and that breaks eclipse: http://pastebin.com/9D3VEsXD  (Just started a new project, wrote 1 line of code, pressed ENTER, crash)
[15:42] <bdrung> sebner: result of "xulrunner --gre-version"?
[15:42] <sebner> bdrung: 1.9.1.8 , I read the bug report but it doesn't crash at startup, I can create a new project without problems, it crashes when writing code
[15:43] <bdrung> sebner: it crash only on startup if the welcome page should be loaded, but it's the same issue
[15:44] <sebner> bdrung: aye, I'm seeing you are already working on it?! It's not urgent so I can wait some hours/days for the update. Else I would just have to use new xulrunner right?
[15:46] <bdrung> sebner: launch eclipse with "eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2"
[15:49] <sebner> bdrung: works :)
[15:49] <bdrung> sebner: k, i was right :)
[15:51] <sebner> bdrung: :) I guess you just need to change xulrunner-dev (>= 1.9.1.3-2) ?
[15:52] <bdrung> sebner: nope. it was build against xulrunner-1.9.2.
[15:52] <sebner> bdrung: ohohoho
[15:53] <sebner> bdrung: so you have to hardcode xulrunner 1.9.2 in Depends?
[15:54] <pitti> seb128, kees: mind eyeballing http://bazaar.launchpad.net/%7Eubuntu-desktop/gnome-keyring/ubuntu/annotate/head%3A/debian/patches/04_clean_session_keyring.patch ?
[15:54] <bdrung> sebner: nope - we B-D on xulrunner-dev, which pulls xulrunner-1.9.2 in lucid.
[15:55] <bdrung> it's dynamically
[15:55] <sebner> bdrung: oh, Ic. Sorry for the noise, I'm not really up to date what uses and pulls in what :D
[15:55] <pitti> seb128, kees: I don't have a session.keyring, so I created a fake one, and tested in various situations (within session so far; building package and doing end-to-end testing with a full reboot now)
[15:56] <bdrung> sebner: eclipse's xulrunner detection is totally fucked up. so we have to set it in our wrapper script.
[15:57] <sebner> bdrung: heh, wondering, how xulrunner can break eclipse when writing java code O_o
[15:57] <seb128> pitti, ok, will have a look in a few minutes when I'm done with what I'm doing now
[15:58] <pitti> seb128: cheers (not that urgent, I'll do more tests and then do other stuff)
[15:59] <bdrung> sebner: type "System." and a dropdown list will open and a "tooltip" (rendered with xulrunner) will explain its details
[15:59] <sebner> bdrung: ah. now I understand, thx :)
[16:00] <sebner> bdrung: maybe they should switch to webkit :P
[16:00] <Keybuk> slangasek: so, I'm thinking, let's ship lucid without a splash screen?  what do you think :p
[16:00] <bdrung> sebner: i doubt that this will help
[16:01] <sebner> heh
[16:01] <tseliot> Keybuk: +1 :-P
[16:02] <bdrung> sebner: except webkit will be rewritten in java :P
[16:03] <sebner> bdrung: urgh, java ...  xulrunner != java too
[16:03] <directhex> bdrung, http://twitter.com/migueldeicaza/status/10930739689
[16:03] <slangasek> Keybuk: well, at least I'll be in London for the release sprint already and will be able to attend your funeral :)
[16:05] <sebner> directhex: hää? webkit-sharp!?!
[16:06] <bdrung> webkit-sharp and then jwebkit :D Eclipse 6 with jwebkit
[16:06] <Keybuk> slangasek: I think that, ultimately, as Release Manager, all failures are your fault
[16:06] <Keybuk> Captain is responsible for the actions of his Crew, and all that :p
[16:07] <sebner> Keybuk: may the grass be green above and the worms not that hungry beneath :)
[16:08] <jcastro> Keybuk: needs to go down with the ship also iirc
[16:09] <sebner> The Captain goes down with the ship!
[16:09] <sebner> Vice-captain (Keybuk) too of course :P
[16:10] <slangasek> Keybuk: I don't think I'm cut out for the navy :P
[16:10] <Keybuk> I'm just the cabin boy
[16:10] <bdrung> is it a release goal to let the ship go down in ten seconds? ;)
[16:10] <cjwatson> Keybuk: roger that
[16:18] <Keybuk> cjwatson: I'm having a dpkg-source failure
[16:18] <Keybuk> and it keeps whining to me about v3
[16:19] <Keybuk> dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1)
[16:19] <Keybuk> dpkg-source: unrepresentable changes to source
[16:19] <Keybuk> etc.
[16:19] <hyperair> Keybuk: it means you've modified a binary file.
[16:19] <Keybuk> hyperair: how does v3 help here?
[16:19] <hyperair> Keybuk: 1.0 only supports textual changes
[16:19] <hyperair> Keybuk: v3 consists of multiple tarballs.
[16:20] <hyperair> debian.tar.gz, orig.tar.gz
[16:20] <hyperair> v1 consists of diff.gz, orig.tar.gz
[16:20] <hyperair> the diff.gz can't contain binary changes
[16:20] <hyperair> so you'll have to uuencode whatever it is you're doing
[16:20] <Keybuk> right
[16:20] <hyperair> or use 3.0
[16:20] <Keybuk> how can debian.tar.gz contain binary changes
[16:20] <Keybuk> is it just unpacked over the top?
[16:20] <hyperair> i think so
[16:20] <hyperair> not sure
[16:20] <Laney> it can't
[16:20] <hyperair> oh it can't?
[16:20] <Laney> it only touches stuff in debian/
[16:20] <hyperair> well at least debian/ can contain a binary file
[16:20] <Laney> you can have binaries in there though
[16:20] <hyperair> unlike in v1
[16:21] <Keybuk>  Note that the debian tar‐
[16:21] <Keybuk>        ball must contain a debian sub-directory but it can also contain binary
[16:21] <Keybuk>        files outside of that directory (see --include-binaries option).
[16:21] <Laney> oh, cool
[16:21] <Keybuk> Laney: dpkg-source(1) disagrees with you
[16:21] <Keybuk> ok...
[16:21] <Keybuk> so how do I make one of these source packages?
[16:21] <cjwatson> Keybuk: debian/source/include-binaries is your friend
[16:21] <hyperair> echo "3.0 (quilt)" > debian/source/format
[16:21] <hyperair> and dpkg-source handles the rest
[16:22] <hyperair> oh you'll have to disconnect your patch system from rules
[16:22] <hyperair> and control
[16:22] <hyperair> dpkg-source will take care of that
[16:22]  * cjwatson digs up an example
[16:22] <hyperair> and only uses quilt
[16:22] <Keybuk> I don't have a patch system
[16:22] <cr3> is there an equivalent to lshal -m (for monitor) since the halsectomy?
[16:22] <Keybuk> (there is no debian/patches)
[16:22] <Keybuk> cr3: udevadm monitor
[16:22] <cjwatson> you don't need one
[16:22] <Laney> looks like you just put the filename of the binary in debian/source/include-binaries
[16:22] <cr3> Keybuk: thanks
[16:22] <cjwatson> so, for openssh
[16:23] <cjwatson> $ cat debian/source/format
[16:23] <cjwatson> 3.0 (quilt)
[16:23] <cjwatson> $ cat debian/source/include-binaries
[16:23] <cjwatson> debian/ssh-askpass-gnome.png
[16:23] <cjwatson> that's only in bzr, I haven't uploaded that yet
[16:23] <Keybuk> can I put wildcards in there? :p
[16:23] <cjwatson> browser-history has one too
[16:24] <hyperair> Keybuk: try it and see =p
[16:24] <Keybuk> :D
[16:24] <cjwatson> I don't think so
[16:24] <cjwatson> you can build with --include-binaries once, and it'll dump them all in there
[16:24] <cjwatson> you can probably even put that in debian/source/options
[16:25] <Keybuk> any idea how to make pristine-tar not convert the bz2 to tar.gz ?
[16:25] <cjwatson> if you're completely confident that your clean rule works :)
[16:27] <cr3> I used to be able to troubleshoot brightness issues by echoing 50 (for example) into /proc/acpi/video/.../brightness, but one netbook on which the brightness keys don't work returns: write error: invalid argument
[16:29] <Keybuk> that's probably why the brightness keys don't work, then
[16:29] <cr3> Keybuk: I'll try to rebout with noacpi
[16:30] <jibel> mvo, with the patch
[16:42] <\sh> UDS-M approved by company , means we are coming :)
[16:44] <cody-somerville> w00t
[16:46] <\sh> well...one week sponsored by our employer
[16:52] <kees> pitti: reading it now...
[16:54] <kees> pitti: looks good to me.
[17:00] <pitti> kees: thanks
[17:08] <tseliot> pitti: is there a bug report about fglrx and jockey already?
[17:08] <pitti> tseliot: for what?
[17:08] <tseliot> pitti: to be able to install it again
[17:08] <pitti> tseliot: ah; I'm not aware of one
[17:08] <Keybuk> do we care about fglrx anymore?
[17:09] <tseliot> Keybuk: yes, in some cases we do
[17:10] <tseliot> pitti: ok, I'll look for it and file a new one if necessary (and assign it to me) just to keep track of things
[17:10] <pitti> tseliot: thanks
[17:10] <tseliot> np
[17:11] <kees> pitti: re bug 546436, it's esata (I commented on the bug too)
[17:11] <pitti> kees: ah; itz kernel bug then; AFAIR I saw a similar one, I'll dupe it
[17:12] <kees> pitti: how is it a kernel bug?  I didn't think it could distinguish between "internal" and "external" for esata, so it was simply the sudden appearance that should trigger the mount?
[17:12] <primes2h> tseliot: you mean this?  bu 494699
[17:12] <primes2h> bug 494699
[17:13] <primes2h> tseliot: ups, sorry
[17:13] <primes2h> tseliot: misunderstand
[17:13] <pitti> ah, that was bug 153768
[17:13] <tseliot> primes2h: I guess this one would be more like it: bug #496225
[17:13] <pitti> kees: well, what is "sudden"?
[17:13] <primes2h> tseliot: sure ;-)
[17:14] <pitti> kees: did that ever work? the original bug (153768) is ancient
[17:15] <pitti> kees: so, I don't think we'll ever be able to automount esata drives which are already plugged in during boot, but I think we can do something in udisks for stuff that got plugged in at runtime
[17:17] <psusi> does it matter when it is detected?  either way it should show on the places menu shouldn't it?
[17:17] <tseliot> Keybuk: any ideas on this? bug #532436
[17:17] <tseliot> or can I assign it to plymouth?
[17:18] <kees> pitti: yes, worked in jaunty and karmic fine
[17:18] <kees> pitti: right, I'm plugging it in at run time
[17:18] <pitti> kees: I'd really be interested in a devkit-disks --monitor-detail and udevadm monitor -e --udev logs from karmic when you plug in an esata drive
[17:19] <pitti> I don't see how this should ever have worked, TBH, but maybe there was something funky
[17:21] <Keybuk> tseliot: sounds like a kernel issue
[17:21] <Keybuk> "driver does not load" => linux
[17:22] <tseliot> Keybuk: driver loads if plymouth is uninstalled => plymouth, no?
[17:22] <Keybuk> no
[17:22] <Keybuk> still linux
[17:22] <tseliot> heh
[17:23] <tseliot> Keybuk: can you comment on that in the bug report, please?
[17:23] <Keybuk> if it's the glx driver, it's in the right place
[17:23] <kees> pitti: hm, will that work off a karmic liveCD?
[17:23] <pitti> kees: yes, it should
[17:23] <tseliot> Keybuk: ok, thanks
[17:23] <kees> pitti: okay, I'll give it a shot.
[17:23] <pitti> kees: cheers
[17:23] <Keybuk> all he's done by uninstalling plymouth is change a race
[17:24] <Keybuk> what he's describing is "driver doesn't load sometimes, but does if I restart sometimes, add sleep, etc."
[17:24] <Keybuk> and
[17:24] <Keybuk> more to the point
[17:24] <Keybuk> The problem is still happening at random, but not at frequently since I uninstalled plymouth.
[17:24] <Keybuk> DkmsStatus:
[17:24] <Keybuk>  nvidia-current, 195.36.03, 2.6.32-15-generic, i686: installed
[17:24] <Keybuk>  nvidia-173, 173.14.22, 2.6.32-15-generic, i686: installed
[17:24] <Keybuk> he should stop hating freedom and use nouveau <g>
[17:25]  * psusi has been very pleased with the mesa drivers on his radeon these days
[17:28] <tseliot> Keybuk: oh, I misread what he said. You're definitely right
[17:28]  * tseliot -> off for the night
[17:33] <psusi> Keybuk: my initial tests using e2defrag to pack the ureadahead file list at the start of the disk showed a few seconds shaved off the boot time and a moderate increase in peak disk throughput under karmic... need to test on lucid next since karmic appeared to still spend a lot of time doing things other than read the disk during boot
[17:38] <pitti> slangasek, cjwatson, Keybuk: so, I completely read bug 445852 now, including the upstream linux/atasmart bugs; I have some things I'd like to try now, but given how much this wreaks havoc, what would you think about disabling dk-disks-probe-ata-smart in the udev rules for now in a karmic update? (then people can turn it on again if they want, but it'd be on the safe side); we only use it for
[17:38] <pitti> monitoring SMART status and failures (which would then stop working, of course)
[17:39] <pitti> but at least we can investigate and test solutions in lucid a bit more thoroughly
[17:40] <bdrung> where is the best place for asking question about developing a C library?
[17:41] <slangasek> pitti: that sounds suitable for SRU to me
[17:41] <pitti> we could then consider re-enabling it in karmic later on, once we have a suitable fix in libatasmart
[17:42] <Keybuk> slangasek: btw, you still haven't sent your plymouth enter patch upstream
[17:42] <slangasek> Keybuk: right - what's the recommended method of forwarding it to upstream?
[17:42] <Keybuk> slangasek: git format-patch usually
[17:42] <slangasek> oh hey, life on #plymouth, that's different
[17:43] <slangasek> Keybuk: and send it where?
[17:43] <Keybuk> plymouth@lists.freedesktop.org
[17:43] <slangasek> thanks, that was the bit I was missing :)
[17:43] <slangasek> ok, will send that off today/tomorrow
[17:44] <Keybuk> I have a couple of bug fixes to send too
[17:44]  * Keybuk wonders what the right term for a double-brown-paper-bag is
[17:46] <slangasek> "double-bagging" doesn't quite encompass it
[17:46] <Keybuk> hey, if it keeps you safe ...
[17:55] <pitti> slangasek: uploaded to karmic-proposed queue; do you have a minute to review? (it's just commenting out the udev rule, should be fairly safe)
[17:55] <slangasek> pitti: ok, checking
[18:02] <slangasek> pitti: should there be a task on this bug against devicekit-disks for tracking?
[18:03] <pitti> slangasek: there is
[18:03] <pitti> slangasek: but for karmic only
[18:03] <pitti> slangasek: for lucid I'd rather fix it in libatasmart, and dk-disks doesn't exist in lucid
[18:03] <slangasek> pitti: oh, so there is; having trouble seeing it through all those declines, heh
[18:03] <pitti> yeah, smart probing was new in karmic, so I declined all the ealier requests
[18:05] <slangasek> pitti: ok, accepted
[18:05] <pitti> slangasek: thanks
[18:05] <slangasek> yes, it would be nice if people wouldn't randomly nominate bugs for series where it didn't exist
[18:08] <kees> cjwatson: heh, we collided on bug 547016.
[18:17] <Keba1> hi there
[18:17] <Keba1> how many bug jams have been partipicated (including the one starting tomorrow)?
[18:30] <_lemsx1_> launchpad appears to be having problems? I can't report a bug
[18:30] <ScottK> _lemsx1_: #launchpad is the place to complain about that.
[18:31] <_lemsx1_> should I post error IDs and stuff like that here or this is not the right place to talk about launchpad :-)
[18:31] <_lemsx1_> ScottK: ah, thanks
[18:33] <kees> pitti: hrm, karmic didn't automount either.  I wonder if I'm remembering this from my laptop where the drive is USB.  trying on jaunty now...
[18:35] <pitti> kees: jaunty had hal, and that didn't see them as hotpluggable either
[18:35] <pitti> the bug was originally filed against hal
[18:37] <kees> hmpf
[18:38] <kees> pitti: yeah, jaunty doesn't even see it appear.
[18:39] <pitti> kees: so it's evolution in the sense that karmic sees it but requires a password, lucid sees it and requires no password
[18:39] <kees> well, it does require the password -- I just still had the session.keyring on disk.  ;)
[18:39] <pitti> kees: well, the encryption password, yes
[18:39] <kees> so, I simply misremembered since this drive has both eSATA and USB interfaces
[18:39] <pitti> kees: I mean the policykit authorization
[18:40] <pitti> kees: I'll talk to davidz if he agrees on considering such devices non-system internal if they appeared much later than the system boot
[18:40] <kees> oh, okay.  well, lucid is clearly better than before since the drive is there, and if I click on it, it prompts for the encryption password.  it just doesn't _auto_ mount it.
[18:40] <kees> which I can live with.
[18:57]  * psusi wonders why gparted stopped seeing his dmraid disks in lucid
[19:41]  * ccheney thinks apt-get should be a bit more verbose on downloading new multi tar sources
[19:41] <ccheney> it currently says stuff like the following:
[19:41] <ccheney> Get:2 http://approx/ubuntu/ lucid/main openoffice.org 1:3.2.0-4ubuntu1 (tar) [14.6MB]
[19:41] <ccheney> Get:3 http://approx/ubuntu/ lucid/main openoffice.org 1:3.2.0-4ubuntu1 (tar) [13.2MB]
[19:43] <YokoZar> Is there another mesa update coming soon?  It's been a while and there's a "fix committed" but I'm waiting on
[20:00] <crimsun> NCommander: please provide the necessary amixer output for bug 451635 to be fixed
[20:01] <crimsun> I'm currently blocked on someone with access to the hardware to actually provide the info in the bug report...
[20:03] <NCommander> crimsun: ah, I got it right here
[20:05] <iscape> hi there, tangogps and probably some other apps broke due to the upgrade of gpsd to 2.92. anything i can do to fix this?
[20:05] <iscape> i am the dev of tangogps
[20:06] <NCommander> crimsun: attached, does that help?
[20:06] <NCommander> (oh, amixer, I might have given you the wrong file)
[20:06] <iscape> debian has a fix already in, but it needs to propagate
[20:07] <ScottK> iscape: If you can file bug(s) with patch(es) to fix the problem, we can get them sponsored into Ubuntu.
[20:07] <ScottK> iscape: Or if just syncing an update from Debian makes more sense, that's good to know too.
[20:07] <crimsun> NCommander: yeah, that asoundrc snippet is not useful, unfortunately. Specifically what will help is your specific mixer settings for all devices.
[20:07] <iscape> ScottK: just syncing
[20:08] <NCommander> crimsun: ugh, I might need to do a clean reinstall, I *really* mucked around with my setup. How can I dump amixer settings?
[20:08] <iscape> I'll file a bug against tangogps then. do i need to put some keyword in to trigger syncing?
[20:09] <crimsun> NCommander: also, that user-specific asoundrc bypasses PA completely - the implication is that any verification you've done won't apply at all to PA, which I presume is part of the equation if PA is being used
[20:09] <crimsun> NCommander: amixer > txt
[20:09] <ScottK> iscape: You needs to say it needs syncing and then subsrcribe the ubuntu-sponsors team to the bug for review.
[20:10] <NCommander> crimsun: I removed pulseaudio to get sound working
[20:10] <crimsun> NCommander: booting from a live image and dumping amixer after you've made whatever necessary changes will help, too
[20:10] <NCommander> crimsun: I've not been able ot get sound working short of removing pulse :-/
[20:11] <crimsun> NCommander: err, there are two separate parts, though the bug report doesn't make that clear
[20:11] <crimsun> that bug seems titled to deal only with alsa-utils portion
[20:11] <NCommander> crimsun: ok, what do you need specifically, I *really* want this fixed :-)
[20:11] <crimsun> NCommander: what I've requested above regarding amixer
[20:12] <NCommander> crimsun: I may need some helpin trying to get this to work, I am not had any luck with ALSA configurations in the past :-/
[20:14] <crimsun> NCommander: which part specifically? 'cat /proc/asound/cards' should show the specific card, which you can then use with 'amixer' or 'amixer -Dhw:X' (where X is denoted in brackets from /proc/asound/cards)
[20:14] <NCommander> crimsun: does that change the default? The problem is that audio tries to go out something that doesn't appear to be pinned out on our SoC
[20:15] <crimsun> NCommander: amixer by itself (with no addition parameters beyond -Dfoo) does not change the default
[20:15] <NCommander> crimsun: right, the problem her eis I just need the default changed (and MAYBE HW switch, not sure yet)
[20:16] <crimsun> NCommander: are you implying that hw:0,0 is not correct but that hw:0,2 is?
[20:16] <NCommander> crimsun: yes, I am
[20:16] <crimsun> ugh, that's a completely different bug :(
[20:17] <NCommander> crimsun: welcome to the world of ARM sound
[20:17] <crimsun> ok, I've opened an alsa-lib task for the necessary addition
[20:17] <NCommander> crimsun: your santiy may be left at the door
[20:17] <GrueMaster> NCommander: crimsun:  Thought I'd pop over and see what trouble I can cause with dove as well.
[20:18] <NCommander> crimsun: there are two different sound out devices on this board that hang off DoveDB. Analog Out, and Headphone Out
[20:18] <crimsun> NCommander: so, in short, for your particular Dove board (and it isn't Y0, I presume?), the control has nothing to do with ...
[20:18] <NCommander> crimsun: pulse sees these, but I can't get either to work through pavucontrol
[20:18] <NCommander> crimsun: this effects Y0->X0
[20:18] <NCommander> We only care about X0 however
[20:19] <crimsun> NCommander: can you please attach your amixer dump?
[20:19] <NCommander> crimsun: stand by, I'm rebooting off a clean livefs so you can see how it is "out of the box"
[20:19] <crimsun> NCommander: thanks
[20:21] <GrueMaster> NCommander: You are not entirely accurate with your HW description.  There are two devices, DoveDB and mv_i2s1.
[20:21] <NCommander> asac__: *sigh*, looks like something we broke
[20:21] <NCommander> asac__: works properly with pre-compiled Marvell kernel
[20:21] <GrueMaster> The DoveDB has 5.1 on the RCA jacks, and a separate HP & Mic jack.
[20:22] <NCommander> er, EWRONGCHANNEL
[20:22] <asac> NCommander: bcc_test works?
[20:22] <asac> wow
[20:22] <NCommander> asac: no, the dmesg isn't crack
[20:22] <asac> ah
[20:22] <asac> try bmm_test
[20:22] <asac> not sure if i put that in the -dev package
[20:22] <asac> otherwise just spin locally and run
[20:22] <asac> oh
[20:23] <crimsun> GrueMaster: does X0 still need 'Line HP Swap' unmuted?
[20:23] <GrueMaster> yes, for the HP jack to work.
[20:24] <GrueMaster> It is a simple toggle.  No volume control.
[20:24] <crimsun> ok, that change is queued already in the linked bzr branch. I'm waiting to see if anything else needs to be set for alsa-utils. Now, does the default device also need to be set to hw:0,2?
[20:25] <crimsun> for reference, that's the conversation above with NCommander and in https://bugs.edge.launchpad.net/ubuntu/+source/alsa-lib/+bug/451635/comments/12
[20:25] <GrueMaster> Not sure.  Where would I set that? (note - it's been a while since I worked on alsa).
[20:26] <crimsun> GrueMaster: NCommander mentioned that he had to create an ~/.asoundrc with the contents in https://bugs.edge.launchpad.net/ubuntu/+source/alsa-lib/+bug/451635/comments/12
[20:26] <iscape> ScottK: bug filed - https://bugs.launchpad.net/ubuntu/+source/tangogps/+bug/547228
[20:26] <GrueMaster> I'm looking at it.
[20:26] <NCommander> crimsun: booting up clean now
[20:27] <GrueMaster> crimsun: Here's the amixer output.  http://pastebin.ubuntu.com/401357/
[20:30] <crimsun> GrueMaster: right, so that's 1) without ~/.asoundrc or /etc/asound.conf, and 2) muted, correct?
[20:30] <crimsun> (at least the latter is implied by 'Line HP Swap' being muted)
[20:30] <GrueMaster> correct an all accounts.
[20:30] <crimsun> GrueMaster: great. And unmuting 'Line HP Swap' results in audible sound through the hp jack next to the serial port, correct?
[20:31] <GrueMaster> I am currently getting audio through the rear RCA jacks (which would be the normal speaker out on an Intel board).
[20:31] <GrueMaster> yes
[20:31] <crimsun> GrueMaster: all right, so which is considered the "default" desired output jack?
[20:31] <GrueMaster> It also mutes the rear "front speakers" ports.
[20:31] <NCommander> crimsun: http://paste.ubuntu.com/401359
[20:32] <GrueMaster> That I don't know.  I guess the hp since most people in the group don't have rca to 3.5mm hp converters like I do.
[20:33] <crimsun> asac: any guidance on ^^ ?
[20:33] <NCommander> GrueMaster: I can test here, I have a TV at Lex I can plug the dove in
[20:33] <GrueMaster> NCommander: I can test all plugs.
[20:33] <GrueMaster> (and have been since Y0).
[20:38] <NCommander> crimsun: so does that help at all?
[20:38] <crimsun> plars: ping, which of the rear rca and hp jacks should be considered 'default'?
[20:38] <NCommander> crimsun: there's only one HP jack
[20:38] <crimsun> NCommander: yes, it corroborates GrueMaster's earlier statement here and in the other bug report
[20:39] <ccheney> grr checking extracted OOo into bzr takes forever :-\
[20:39] <plars> crimsun: right, only one hp jack, not sure on the RCA, I don't have proper cables to check those  but I know GrueMaster has looked at it before
[20:40] <crimsun> plars: ok, so the necessary change for that on the alsa task is already queued, and I'll upload that momentarily. It doesn't look to need an alsa-lib task, then.
[20:40] <GrueMaster> crimsun: The board layout is "similar" to a standard 3stack, except instead of 3 mini plugs in the back, there are 3 pairs of RCA jacks for Front, Surround, and Center/LFE
[20:41] <crimsun> GrueMaster: ah
[20:46] <asac> crimsun: so you got all info you needed?
[20:46] <asac> doko_: does icetea need to link against libxul.so?
[20:46] <crimsun> asac: presuming that the hp jack is the desired default, yes
[20:46] <asac> doko_: maybe we should try to use mozilla-plugin.pc now that they redid stuff for 3.6?
[20:47] <asac> crimsun: yeah. i think thats a reasonable choice. thanks for your help.
[20:50] <NCommander> crimsun: if you have a patch today, I'd be glad to test it
[20:56] <crimsun> NCommander: I just uploaded alsa-utils 1.0.22-0ubuntu4 for that
[20:57] <crimsun> NCommander: note that it's effected on a fresh install/live image boot. Otherwise you'll need to nuke /var/lib/alsa/asound.state first
[21:00] <NCommander> crimsun: WIN
[21:01] <GrueMaster> crimsun: what change to asound.state was made?
[21:02] <GrueMaster> Just for quick sanity testing.
[21:03] <iscape> ScottK: thanks
[21:03] <ScottK> iscape: You're welcome.  Thanks for letting us know.
[21:04] <iscape> ScottK: it was an ubuntu user who notified me :)
[21:05] <crimsun> GrueMaster: I don't have a machine to generate one, but the value for that switch should be true instead of false
[21:05] <GrueMaster> got it.  That's what I thought.
[21:32] <pitti> kees: wrt. bug 542372, are you okay with python3.1 in main? (it doesn't seem very security prone to me)
[21:36] <kees> pitti: bleh.  why so late?  what needs it?
[21:37] <kees> pitti: python gets a fair share of updates, so having lots of copies gets unhappy.
[22:31] <robert_ancell> mdke, do you know about the state of gnome-user-docs?  Should it be updated to 2.29.2 or does it need patching for Ubuntu?
[22:46] <nixternal> is jockey broken for everyone?
[23:05] <psusi> Keybuk,  in bug #460906 it seems that you and Kees Cook are saying that the real fs should have the link so won't change, but they don't... I made a snapshot of my root and when I rebooted, was running off the snapshot instead of the original and this is not supposed to happen
[23:10] <doko_> asac: $ ldd /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so |grep libx.*found
[23:10] <doko_> 	libxul.so => not found
[23:10] <doko_> 	libxpcom.so => not found
[23:13] <asac__> doko_: you tried initially to build with just mozilla-plugin, right?
[23:14] <doko_> asac: I think so. it's in the configure.ac (or acinclude.ac)
[23:19] <psusi> soren, actually seems you said you were going to fix this... but still is doing the wrong thing in lucid
[23:52] <snow_ru> hi
[23:52] <snow_ru> How can the developer  add his program to ubuntu repository so that other people can use it ?
[23:53] <micahg> snow_ru: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[23:55] <snow_ru> thanks
[23:57] <snow_ru> micahg, should all packages in MAIN be compatible with 64Bit system ?
[23:57] <RAOF> Almost certainly, yes.
[23:57] <nixternal> superm1: b43 or sta for the mini 10v?
[23:58] <micahg> snow_ru: doesn't work like that...main means supported free software
[23:58] <RAOF> Failing to build on amd64, or failing to work on amd64 is generally indicative of stupid code :)
[23:58] <snow_ru> it implies that the package may not work for 64 bit system ;)
[23:59] <snow_ru> RAOF, built and worked are two different things ;)