[00:04] <wamty> Shortly after starting the install I get "Call Trace:" and then "Code: e6 01 00 90 etc"
[00:06] <wamty> any ideas?
[00:06] <TheMuso> wamty: I suggest you file a bug against ubiquity in launchpad.
[00:06] <wamty> ?
[00:06] <TheMuso> As the people who are most likely to be able to help you are not likely to be around at the moment.
[00:06] <wamty> what do u mean
[00:07] <wamty> why not
[00:07] <TheMuso> Well for one thing, its almost midnight where the installer maintainers live.
[00:07] <wgrant> Because it was Sunday for them until 7 minutes ago.
[00:11] <TheMuso> wamty: /c
[00:11] <wamty> what does that mean?
[00:11] <TheMuso> wamty: sorry that was a typo
[00:12] <TheMuso> wamty: To file a bug, I suggest you have a read here. https://help.ubuntu.com/community/ReportingBugs
[00:12] <wamty> maybe its not a bug
[00:12] <wamty> i dont know wha it is
[00:12] <wamty> s
[00:13] <TheMuso> wamty: A call trace sounds like a bug to me.
[00:15] <Chipzz> call trace sounds like a kernel oops to me
[00:15] <Chipzz> especially with teh "Code: ..." after it
[00:28] <superm1> pitti, ping.  i wanted to ask you about letting users report bugs for packages from PPAs that are very close to upstream code, so that apport doesn't complain about them being non-genuine packages.  we recently (today) switched one of the mythtv trunk PPAs to build in debug mode, so between the dropping of optimizations and the dh_strip not doing any stripping for PPA builds, I think these should be pretty useful to upstream
[00:51] <apw> anyone know what injects dbus messages for new devices ?
[00:53] <lifeless> udev?
[00:54] <Amaranth> lifeless: I thought udev had its own protocol
[00:55] <ScottK> superm1: Where would they be filed?
[00:55] <apw> lifeless, maybe, maybe, or do you _know_ its that
[00:55] <lifeless> Amaranth: so udev listens to the kernel; the get-rid-of-hal work consists of udev events that translate and broadcast to dbus
[00:55] <lifeless> apw: I'm 95% sure
[00:55] <superm1> ScottK, against the same source package in the archive
[00:55]  * Amaranth checks code
[00:55] <apw> in jaunty it looks like its hal
[00:55] <superm1> i think for some projects it makes a lot of sense still
[00:56] <ScottK> superm1: I think that's horribly inappropriate.
[00:56] <lifeless> apw: in jaunty it is hal
[00:56] <apw> in karmic it is _noone_ for me
[00:56] <superm1> ScottK, i'd be fine with a whitelist, or drop a file in place to make it activated for any particular blessed package
[00:56] <lifeless> there was a massive thread on d-d recently about this in the context of systems with /usr on separate fs's.
[00:56] <Amaranth> apw: hal should still be around to do that, it is used for xorg still
[00:57] <superm1> ScottK, but i'm sure that other projects with daily builds can get the same kind of benefits like this too then
[00:57] <ScottK> superm1: I think what it needs is a different place to land non-ubuntu bugs.
[00:57] <apw> hal is seeing the new devices i insert, just nolonger am i seeing dbus events, therefore gnome doesn't do it
[00:57] <ScottK> superm1: I think it's great, just not against Ubuntu.
[00:57] <Amaranth> apw: gnome uses udev
[00:58] <apw> Amaranth, 'used' udev .. how is it plumbed in?  do you know?
[00:58] <apw> uses even
[00:58] <Amaranth> lifeless: it looks like udev doesn't have a dbus dependency
[00:58] <Amaranth> apw: via libgudev?
[00:58] <apw> Amaranth, hrm, thanks will look at that
[00:58] <Amaranth> apw: yeah, gvfs depends on libgudev
[00:59] <lifeless> Amaranth: I likely have the fine detail wrong; I do recall the transition and that its udev's problem now ;)
[00:59] <Amaranth> so nautilus uses gio which uses gvfs which uses libgudev which is actually a wrapper around libudev which uses udevd
[00:59] <Amaranth> Wow I would hate to debug that
[01:00] <apw> so we might not expect to see dbus events now then
[01:00] <apw> i do have udev events for the new devices
[01:00] <Amaranth> apw: Well like I said we still have hal around for xorg so hal should still be reporting device connections
[01:00] <apw> it maybe meant to be, but its not
[01:01] <Amaranth> maybe it was crippled somehow *shrug*
[01:01] <apw> i have the problem that i know whats not happening, but not whats normal
[01:01] <apw> yeah half finished sometrhing i expect
[01:06] <james_w> apw: devicekit-disks
[01:06] <james_w> for disks
[01:06] <james_w> other things for other types of hardware
[01:06] <james_w> there's no single thing like hal anymore
[01:07] <james_w> if there is a daemon corresponding to what you are trying to do then using the DBus connection to that works
[01:07] <Amaranth> ah, right, forgot devicekit-disks is still around
[01:07] <james_w> otherwise libgudev or similar to listen to udev events would work
[01:07] <james_w> if it has to be DBus then a devicekit-* for the class of hardware that translates from udev to DBus would be needed
[01:08] <Amaranth> devicekit-disks and devicekit-power are the only ones
[01:08] <james_w> yep
[01:17] <apw> james_w, thanks for the info
[01:18] <apw> it appears that /usr/lib/gvfs/gvfs-gdu-volume-monitor is finding out about it directly from udev
[01:18] <apw> i wonder what that actually does
[01:19] <apw> but gvfs itself does not appear to get told
[01:32] <sladen> fatal: I had/have the ultimate blackness too
[01:34] <sladen> fatal: if fsck is running, it could be 10 minutes+ of blackness before xsplash+gdm start
[01:34] <sladen> fatal: and (recovery mode) doesn't do anything
[03:38] <jdong> directhex: heh just noticed the nspluginwrapper bug too
[03:51] <the_dark_warrio> What are the kernel modules that control webcams?
[03:51] <jdong> many.... uvcvideo is one of the more common ones
[03:52] <the_dark_warrio> I was wondering if it is possible to control exposure time
[03:52] <jdong> I thought typically that's something automatically controlled by the camera
[03:53] <the_dark_warrio> indeed it is
[03:53] <jdong> typically exposure time increases with the decrease of ambient light :)
[03:54] <the_dark_warrio> but I'm doing some science experiments, and the autoexposure is screwing everything ;)
[03:54] <jdong> probably a webcam isn't your best tool in that case
[03:54] <the_dark_warrio> I see
[03:54] <jdong> here in our MIT intro biophysics classes we use a firewire fancy module
[03:54] <jdong> which does allow every capture parameter to be controlled by software
[03:54] <the_dark_warrio> nice
[03:55] <the_dark_warrio> you mean a firewire camera?
[03:56] <jdong> yeah, some sort of firewire connected camera
[03:56] <jdong> interfacing with a Ubuntu UI
[03:56] <jdong> I'm only a customer of the setup so to speak, though :)
[03:57] <the_dark_warrio> ;)
[03:57] <the_dark_warrio> thanks for the hints! I will research more
[03:57] <the_dark_warrio> cya
[03:57] <jdong> sure thing
[05:04] <TheMuso> c
[06:26] <Vantrax> anyone here have experience with kerberos and capaths?
[06:29] <glicks> excuse me, im trying to compile a vanilla kernel in ubuntu, whats the command to make a .config file from the current running kernel?
[07:11] <pitti> Good morning
[07:14] <pitti> superm1: you can ship a small code snippet which makes them being reported against the product (see /usr/share/doc/apport/crashdb-conf.txt); is that what you need?
[07:15] <superm1> pitti, interesting, that looks like it would do the trick
[07:16] <superm1> just need to find a way to integrate it without disturbing standard packages (they use the same bzr branch)
[07:16] <pitti> superm1: perhaps like this:
[07:17] <pitti> superm1: ship a crashdb.conf.d/mythtv.conf with a "mythtv" db (use launchpad_impl and set 'product': 'mythtv')
[07:17] <pitti> superm1: and then ship a package hook which checks the version (ppa or not) and sets report['CrashDB'] = 'mythtv' for PPA packages
[07:18] <superm1> pitti, ah yeah, that sounds like the perfect way to do it. thanks!
[07:18] <pitti> superm1: please let me know about troubles; crashdb-conf.txt and package-hooks.txt.gz aren't very verbose about this yet
[07:19] <superm1> pitti, will do.  i'll try'n sort out the details for it this week
[07:21] <dholbach> good morning
[07:29]  * pitti hugs dholbach
[07:30]  * dholbach hugs pitti back
[07:32] <wgrant> pitti: Do you have a few minutes to talk about the archive administration side of Soyuz ddeb support?
[07:32] <pitti> wgrant: sure
[07:33] <wgrant> pitti: So, ddebs are represented in Soyuz just like normal debs. This means that at the moment they don't follow their debs around, so removals/overrides/copies of a binary will not drag along the ddeb. This seems like it could get pretty tedious.
[07:34] <wgrant> So I'm going to implement some improvements which will cause overrides/removals of a deb to also detect and operate on the deb.
[07:34] <wgrant> Sounds sane?
[07:34] <pitti> absolutely
[07:34] <pitti> I don't see why we should have the ddeb in a different component
[07:35] <wgrant> Right. It'll also need some tricks to automatically inherit the deb's overrides at upload-time, to avoid pushing *every* binary through new once we hit the button.
[07:35] <wgrant> Now, ddebs will be removed from the archive indices as soon as they're superseded. That's not a good thing for the retracers, is it?
[07:37] <pitti> wgrant: it's what we currently have
[07:37] <pitti> wgrant: I think it's fine for the Packages.gz files
[07:37] <pitti> wgrant: they don't disappear from LP, I recently learned how to retrieve all files from any build through launchpadlib
[07:37] <pitti> so if we wanted to make the retracers more clever about older versions, we could still do it
[07:38] <wgrant> pitti: OK. They'll be removed from the archive disk immediately, but will still be available from the librarian.
[07:38] <pitti> *nod*
[07:38] <wgrant> You'll probably need to manually NBS out ddebs, unfortunately.
[07:39] <pitti> wgrant: that sounds scriptable, though
[07:39] <wgrant> I can't think of a way around that, so I hope it's OK.
[07:40] <pitti> wgrant: where will they land? not on archive.u.c., I hope?
[07:40] <wgrant> pitti: No. They will exist in an entirely separate archive.
[07:40] <pitti> wgrant: it would be great if we could just move ddebs.u.c. to point to that archive
[07:40] <wgrant> Otherwise it would be really easy.
[07:41] <wgrant> pitti: That would be good, although there is the slight problem that none of the old ddebs will be in the new archive.
[07:41] <pitti> ah, bummer; we can't 'seed' them?
[07:42] <wgrant> Not exactly. While it's probably technically possible, it seems like a pretty awful thing to do (inject binaries into builds).
[07:43] <wgrant> You might just have to leave the retraces also pointing at the old archive for a while. Or convince somebody that the evil required to do the import is justified.
[07:43] <pitti> wgrant: ok, so I propose we keep ddebs.ubuntu.com/old/ around on macaroni, and point the main ddebs.u.c. to the new archive
[07:43] <pitti> so for a while we use both
[07:44] <wgrant> pitti: Sounds sane.
[07:45] <wgrant> I think that's probably it. Let me think....
[08:14] <tseliot> pitti: where's the jockey handler for bcmwl?
[08:20] <tseliot> pitti: aah, it's only in the ubuntu branch. Never mind
[08:58] <ManDay> Hello have been told to come here as I ve got a problem with glibc. Upon fatal runtime errors the backtrace is written to the tty directly rather than stderr, which renders it impossible to redirect the error to something like less in order to read it. Is that a well known problem with the runtime of glibc or just my specific problem?
[09:06] <tseliot> pitti: if I (successfully) install the broadcom driver in Jockey, Jockey's interface doesn't refresh and it looks like it wasn't installed: http://paste.ubuntu.com/275109
[09:07] <tseliot> (the module is loaded)
[09:18] <pitti> tseliot: "unbind/rebind on driver /sys/module/wl/drivers/pci:wl: device 0000:03:00.0", nice so that actually works?
[09:19] <pitti> tseliot: the handler doesn't rmmod b43 and friends, do you still have any of those loaded?
[09:19] <pitti> tseliot: oh, wait, it does
[09:19] <tseliot> pitti: no b43, etc. module is loaded
[09:19] <pitti> tseliot: does 'lsmod | egrep '43|ssb' still show anything?
[09:21] <pitti> tseliot: ah, I think I know what's going on; could you test something for me?
[09:21] <tseliot> pitti: http://paste.ubuntu.com/275115
[09:21] <tseliot> pitti: sure
[09:22] <pitti> tseliot: in broadcom_wl.py, enable(), after KernelModuleHandler.enable(self) (i. e. very last line)
[09:22] <pitti> OSLib.__load_module_blacklist()
[09:22] <pitti> append this
[09:22] <pitti> KMH.enable() will install the package, which installs the blacklist
[09:23] <pitti> but jockey doesn't update its blacklist cache
[09:24] <tseliot> pitti: wouldn't it be something to add to enabled() instead (which I assume you call after enable() to make sure that it worked)?
[09:24] <tseliot> just asking
[09:25] <pitti> tseliot: I think enable() is better, enabled() is called much more often, and is only a read operation
[09:26] <tseliot> pitti: ok, let me try
[09:51] <tseliot> pitti: it complains that class OSLib has no attribute '_BroadcomWLHandler__load_module_blacklist or, if I remove the 1st underscore, TypeError: unbound method _load_module_blacklist() must be called with OSLib instance as a first argument (got nothing instead)
[09:52] <pitti> tseliot: oops, sorry; it's just a single _, not two __
[09:53] <tseliot> pitti: which gives me the 2nd part of my previous message
[09:53] <pitti> tseliot: so, it's correctly:
[09:53] <pitti> OSLib.inst._load_module_blacklist()
[09:53] <pitti> (forgot the .inst as well)
[09:53] <tseliot> ok, let me try again
[10:02] <tseliot> pitti: that seems to work
[10:11] <evand> pitti: any further thoughts on bug 432542?
[10:12] <evand> also, do you think a new upload of devicekit-disks is warranted for 007, or should we just cherry pick the crucial patches from it?
[10:20] <pitti> evand: hi
[10:20] <pitti> tseliot: great, will commit
[10:20] <evand> hi pitti
[10:20] <tseliot> pitti: thanks
[10:21] <pitti> tseliot: in fact, I should commit that to trunk to the generic Handler, since other packages could install blacklist files as well
[10:21] <pitti> evand: DK-disks 007 is in karmic, needed by new gnome
[10:22] <pitti> evand: usb-creator> I'll do a quick review of the PK backend, still on my todo list
[10:22] <evand> ah, I didn't think to check this morning
[10:22] <evand> good deal
[10:22] <evand> thanks a bunch!
[10:22] <tseliot> pitti: right, even better
[12:05] <wgrant> cjwatson: Can you try newComponentUploader again and get an OOPS ID at some point, please?
[12:10] <cjwatson> wgrant: remind me how I get the OOPS ID out of the API?
[12:11] <wgrant> cjwatson: Try catching the exception and check the 'content' attribute.
[12:14] <pitti_> tkamppeter: hi! did you recently reorganize openprinting.org? my jockey test suite fails now, it doesn't find the "openprinting-ppds-postscript-hp" package for 'MFG:Hewlett-Packard;MDL:HP LaserJet 3020' any more
[12:18] <cjwatson> wgrant: confused; e.content is (<Archive at 0xbd1f490>, 'newComponentUploader', 'launchpad.Edit')
[12:18] <cjwatson> wgrant: and the HTTP code is 401 unauthorized
[12:19] <cjwatson> so no longer an internal server error, which IIRC it was over the erweekend
[12:19] <pitti_> tkamppeter: I change the tests to "DesignJet 3500CP" now, according to http://www.openprinting.org/show_printer.cgi?recnum=HP-DesignJet_3500CP
[12:19] <wgrant> cjwatson: You gave launchpadlib full write access? Because... you own the archive.
[12:20] <cjwatson> I *think* so, but I'll try again
[12:20] <pitti_> DrPepperKid: hey Mirco :)
[12:21] <MacSlow> pitti_, I'm here in my "alter ego" form just for debugging :)
[12:21] <ogra> cjwatson, whats up with your locales today ? its the second time i see weirtd cahrs from you
[12:21] <ogra> *weird
[12:21] <soren> ogra: I don't see anything weird?
[12:22]  * pitti_ doesn't either
[12:22] <ogra> the erweekend
[12:22]  * wgrant neither.
[12:22] <ogra> i see er, then two squares and then weekend attached to it
[12:22] <pitti_> just a normal '.' here
[12:22] <soren> I don't see the two squares.
[12:22] <ogra> strange
[12:22] <cjwatson> it's not locales, it's that my network is ridiculously laggy and so irssi/ssh is exhibiting some weird knock-on effects from typeahead
[12:23] <ogra> well, but i see stuf interpreted others dont, must be me then
[12:23] <ogra> *stuff
[12:23]  * sistpoty|work sees it two (running debian/stable here at work)
[12:23] <pitti_> weechat might just filter it out
[12:23] <cjwatson> wgrant: my bad - that seems to have worked fine now. I think I had two oauth tokens with the same identifier but different privilege levels and was therefore confused. :(
[12:23] <sistpoty|work> too
[12:23] <cjwatson> the squares were probably raw backspace characters or something
[12:23] <wgrant> cjwatson: So it didn't even 500 this time?
[12:23] <cjwatson> wgrant: apparently all good now ...
[12:24] <wgrant> cjwatson: Strange, but great!
[12:24] <cjwatson> ubuntu-dev should have give-back access to that archive now, then
[12:24] <wgrant> cjwatson: Thanks.
[12:37] <zul> morning
[12:51] <doko> asac: time to fix the xulrunner-1.9.1 build on sparc, powerpc, ia64?
[12:52] <sistpoty|work> doko: mind to take a look at bug #433368? (if you want, I can try to provide a minimal test case)
[12:53] <doko> sistpoty|work: gcc-snapshot results?
[12:54] <sistpoty|work> doko: haven't checked with gcc-snapshot yet
[12:55] <sistpoty|work> doko: will do (but only an half an hour or so... must leave for a meeting in 5 minutes)
[12:57] <doko> sistpoty|work: hmm, we had something similiar, 4.4 only reserves storage so that all values of the enum fit. does adding an UINTMAX value in the enum type help?
[12:58] <sistpoty|work> doko: I haven't checked that yet, but I'd think so.
[13:11] <asac> doko: ia64:
[13:11] <asac> The following packages have unmet dependencies: cdbs: Depends: intltool but it is not going to be installed mozilla-devscripts: Depends: libxml-xpath-perl but it is not going to be installed
[13:12] <asac> xpidl crashes on ppc
[13:12] <asac> sparc i have a fix for
[13:13] <cjwatson> asac: retry ia64
[13:13] <cjwatson> it was broken, it should be somewhat better now
[13:14] <cjwatson> in fact, I'm on the page anyway, I've retried it
[13:16] <doko> sistpoty|work: then it's a bug in the code ... see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
[13:18] <asac> thx
[13:18] <sianis> mpt_: hi! at bug #433838 only Get Free Software menu item needs the icon on the location bar?
[13:19] <sianis> or Installed, etc, etc?
[13:20] <mpt> sianis, *if* we did it, we should do it for all sections that have a path button, i.e. currently both "Get Free Software" and "Installed Software".
[13:21] <sianis> mpt: right, I am posting a patch ...
[13:23] <doko> asac: would you mind uploading the fix? you did tell me having the fix weeks ago ;p
[13:23]  * asac checks powerpc porter machine
[13:32] <sianis> mpt: patch's attached
[13:33] <mpt> Thanks sianis. I'll put it on the list of things to user-test. :-)
[13:42] <sistpoty|work> doko: ah thanks, that 36917 matches my observations. Just wasn't sure if it's legal to reduce the size of an enum. Thanks for looking!
[13:45] <asac> doko: http://paste.ubuntu.com/275224/
[13:45] <asac> doko: maybe libidl needs to be rebuild?
[13:46] <asac> or any idea why something might crash in _savegpr_14 ?
[13:48] <doko> asac: ENOCLUE. but why not check it on the porter box?
[13:48] <asac> doko: I am on the porter box
[13:48] <asac> doko: i cannot install libidl i locally built
[13:48] <asac> at least not easily
[13:48] <doko> and LD_LIBRARY_PATH doesn't work?
[13:49] <asac> probably would
[13:49] <asac> trying something else now
[13:52] <asac> gcc-4.3 works
[14:10] <tkamppeter> pitti, yes I did a change on OpenPrinting.org. I removed most HP PPDs, as they are maintained by HP in HPLIP but not any more on OpenPrinting.
[14:10] <pitti> tkamppeter: ah, ok; thanks
[14:11] <tkamppeter> The recommended driver for the LJ 3020 is HPLIP now as the appropriate PostScript PPD is part of HPLIP.\
[14:19] <asac> doko: seems to a compiler bug or something further down. -Os makes it crash like the paste above ... -O2 and -O0 seem to work
[14:19] <asac> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg17189.html
[14:20] <doko> asac: and -Os is turned on by default?
[14:20] <asac> yes
[14:20] <asac> gcc 4.3 works
[14:21] <doko> why do people turn it on on archs they don't use/test ...
[14:21] <asac> at best we would just disable whatever feature triggers this
[14:21] <asac> it worked before and noone complained. we can use -O2 on ppc, but that hides the problem imho
[14:34] <hdon> hi everyone. i18n question. i have written a very basic gettext(3) test program. it calls setlocale(), bindtextdomain(), textdomain(), and then gettext() on commandline arguments, and prints the results to stdout. i have straced my program, and i see glibc looking in /usr/lib/locale and /usr/share/locale-langpack, but *not* in the directory i have specified to bindtextdomain(). is this some kind of ubuntu gettext caveat?
[14:38] <doko> asac: yes, but extracting a test case takes time ...
[14:38] <hdon> please help! i have spent way too much time on this already... :(
[14:38] <mattn> hdon: is the path relative?
[14:38] <cjwatson> hdon: I can't reproduce this with a trivial test program. Can you post your source code?
[14:39] <hdon> mattn: it may be in the future, but at the moment i am specifying a relative path. are absolute paths not allowed?
[14:39] <hdon> sure, one sec..
[14:39] <pitti> hdon: it's supposed to work; it will fallback looking into .../locale-langpack/, but it's supposed to respect bindtextdomain
[14:39] <cjwatson> http://paste.ubuntu.com/275270/ is my test
[14:40] <mattn> it works here, too
[14:40] <hdon> http://paste.ubuntu.com/275272/
[14:40] <cjwatson> relative paths work for me too
[14:41] <cjwatson> although I don't know that I'd expect them to be reliable
[14:41] <hdon> cjwatson: thank you for experimenting with me. i wonder why i can't get this to work..
[14:41] <cjwatson> calling setlocale on both LC_ALL and LC_MESSAGES is weird
[14:42] <hdon> cjwatson: i know, i was just a little exasperated and added LC_ALL even though i am trying to use an LC_MESSAGES file
[14:42] <mattn> hdon: what is the output of "locale"
[14:42] <mattn> do you have that locale installed on your system?
[14:43] <hdon> mattn: all en_US.UTF-8
[14:43] <mattn> and you have fr_WHATEVER.UTF-8 installed on your system, too?
[14:43] <hdon> mattn: see this:
[14:43] <hdon> donny@pacemates:~/gpsee/gt$ dpkg -S /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo
[14:43] <hdon> python-django: /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo
[14:43] <mattn> nono, the system locale
[14:43] <seb128> locale -a | grep fr
[14:43] <mattn> i had to install e.g. russian to text our game with a russion translation
[14:44] <mattn> s/text/test
[14:44] <cjwatson> that's odd, your program is only triviallly different from mine but doesn't work
[14:44] <hdon> nonetheless, i should be able to load this .mo file
[14:44] <mattn> maybe - but it won't do anything with it if you don't have that locale
[14:44] <cjwatson> mattn: I don't think this is relevant - it's failing for me even if I ditch the fr
[14:44] <mattn> that's indeed strange
[14:45] <hdon> mattn: hmm, ok, which package(s) do you think i should install to make my test program work?
[14:45] <hdon> if your theory seems to work, then that will at least give me a direction to go
[14:45] <hdon> cjwatson: have you tried watching in strace?
[14:46] <mattn> hdon: language-pack-fr
[14:46] <james_w> ttx: any reason for libgnumail-java-doc to be in main? It's trying to pull in classpath for just classpath-doc, and that pulls in a lot of other things
[14:46] <mattn> not sure whether it's all needed - maybe there is a separate locale package, too
[14:46] <hdon> cjwatson: here are the locations my glibc on Jaunty searches for the "fr" locale:
[14:46] <hdon> /usr/lib/locale/fr/LC_IDENTIFICATION /usr/share/locale-langpack/fr/LC_IDENTIFICATION /usr/lib/locale/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES/SYS_LC_MESSAGES
[14:47] <james_w> ttx: though I'm having a bit of trouble even finding what is keeping the -doc package in main.
[14:47] <hdon> i generated that list with this command: donny@pacemates:~/gpsee/gt$ strace ./a.out Yes 2> log && echo `grep -o '[^"]*fr[^"]*' log`
[14:47] <cjwatson> forget that, it doesn't matter
[14:47] <hdon> mattn: incidentally i did install that package for kicks
[14:48] <cjwatson> so the problem is that there is no such locale as "fr" *at all*, no matter what package you install
[14:48] <cjwatson> it's not a valid locale name
[14:48] <cjwatson> instead, you should just do setlocale(LC_MESSAGES, "") up top, and that will use the current locale
[14:49] <cjwatson> (actually most internationalised programs just do setlocale(LC_ALL, "") up top)
[14:49] <mattn> and maybe add LANG=fr ./yourApp
[14:49] <cjwatson> no, LANG=fr is an invalid locale
[14:49] <cjwatson> LANG=fr_FR>UTF-8
[14:49] <cjwatson> err, LANG=fr_FR.UTF-8
[14:50] <hdon> but i *do* have an fr locale. in fact i don't have an fr_FR locale. not in /usr/share/locale, nor in /usr/share/python-support/python-django/django/conf/locale
[14:50] <cjwatson> no, you don't
[14:50] <cjwatson> valid locales are those listed in the first column of /usr/share/i18n/SUPPORTED
[14:50] <hdon> ah, hmm
[14:50] <cjwatson> not subdirectories of /usr/lib/locale or whatever
[14:51] <pitti> hdon: you have "fr" translations
[14:51] <hdon> that is not mentioned in the gettext(3) manual
[14:51] <hdon> pitti: ah, thanks. i was using the wrong term entirely then :)
[14:51] <cjwatson> it's mentioned in locale(1)
[14:51] <cjwatson> in the FILES section
[14:52] <pitti> hdon: a translation is done for a language in most cases ("fr"); exceptions are countries with similar, but sufficiently differing languages such as Portugese and Brazilian Portugese, or British and American English
[14:52] <hdon> cjwatson: thanks, i'll read that now
[14:52] <james_w> checkrdepends knows about seeds doesn't it?
[14:52] <james_w> is a "Suggests:" enough to stop something showing up on component-mismatches?
[14:53] <rgreening> mpt, mvo: can we chat about software-store and kde frontend? evand suggested I chat with one or both on this...
[14:54] <mpt> rgreening, sure, though I don't know how much help I would be. I are just the designer.
[14:54] <cjwatson> james_w: no
[14:55] <hdon> ok, if my program only calls setlocale() with setlocale(LC_ALL, ""), then it appears i can control where libintl/glibc looks for translation files with the LANG environment variable. however, it still does not look in the path that i provide to bindtextdomain() :(
[14:55]  * hdon sighs
[14:55] <hdon> thanks for the help btw. i realize this is probably not really a developer support channel
[14:57] <cjwatson> hdon: it worked for me as long as I actually had a valid LANG
[14:57] <rgreening> mpt: well, I am interested in eith developing the KDE front-end or assisting in developing it.
[14:57] <hdon> cjwatson: where did you get your translation file?
[14:57] <hdon> cjwatson: i would like to try to duplicate your success
[14:57] <cjwatson> who cares, it was looking in the right places as seen by strace
[14:57] <rgreening> mpt: I recently developed the kde front-end to usb-creator, so I figured I could help with the new software-store.
[14:58] <hdon> cjwatson: oh, ok, fair enough
[14:58] <cjwatson> try it with LC_ALL=en_US.UTF-8 or something like that that's guaranteed to exist
[14:58] <ttx> james_w: no, no reason.
[14:58] <cjwatson> open("/usr/share/python-support/python-django/django/conf/locale/en_GB.UTF-8/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
[14:58] <james_w> ttx: do you know what is keeping it in?
[14:58] <cjwatson> ...
[14:58] <cjwatson> open("/usr/share/python-support/python-django/django/conf/locale/en/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
[14:59] <ttx> james_w: no, I'm going to have a look.
[14:59] <rgreening> mpt: basically, if we develop it correctly, it should be a backend with one or more frontends. Untying GTK from the backend so any interface could be written on top of it.
[14:59] <james_w> ttx: the only rdepend I can find is libgnumail-java suggesting it
[15:00] <cjwatson> actually, I stand corrected, mattn did have a point - the locale does actually need to be installed, but if you installed language-pack-fr already then LC_ALL=fr_FR.UTF-8 should make it work
[15:00] <mpt> rgreening, there already is a back end, it's called Aptdaemon. <http://launchpad.net/aptdaemon>
[15:00] <rgreening> mpt: there was a packagekit spec I helped write to cover some of what would need to be done with packagekit for a backend
[15:00] <rgreening> cool
[15:00] <mattn> why is libg3d in ubuntu repos but not g3dviewer and the thumbnailer? are there even any other applications that are using libg3d?
[15:00] <mattn> strange
[15:01] <rgreening> mpt: awesome, then presumably, writing a frontend should be trivial...
[15:01] <rgreening> mpt: is there a spec for UDS-L for this? If so, I'll write a KDE frontend spec and link to the other...
[15:05] <ttx> james_w: same here
[15:06] <james_w> ttx: ok, I'll demote it as we probably don't want it, and we can see if anything complains?
[15:06] <ttx> james_w: nothing should :)
[15:06] <mpt> rgreening, writing a good front end is always the hard part.
[15:07] <mpt> rgreening, I'm not aware of a spec for it. This is the first time I've heard of the possibility of a Kubuntu equivalent.
[15:10] <rgreening> mpt: I'm the kubuntu ninja concerned with making the Ubuntu-->Kubuntu transistions when everyone else has forgotten ;) haha
[15:12] <mpt> rgreening, good for you. What do Kubuntu users think of KPackageKit, do you know?
[15:16] <rgreening> kpackagekit is good and bad... some missing bits and not having an Applications VIew is bad (IMO), as packagekit shows all packages/debs and cannot filter to show just applications like from within app-install-data. Though I helped write the spec to make that work in packagekit.. we can probably work on the spec and implementing it...
[15:17] <nh2> mpt: hi, tseliot told me I could ask you to take a short look at https://bugs.launchpad.net/hundredpapercuts/+bug/386017 - I created two checkboxes for enabling/disabling corner tapping
[15:17] <pitti> jdstrand: good morning! do I need to do anything further on bug 430544?
[15:18] <rgreening> mpt: http://cgit.freedesktop.org/packagekit/plain/docs/app-install-v1.draft
[15:19] <jdstrand> pitti: hi! (reading)
[15:19] <maxb> Where was the LL codename announcement? I can't find it in ubuntu-devel-announce archives.
[15:21] <jdstrand> pitti: nothing further required, I'll publish this. thanks for your work on it!
[15:21] <soren> maxb: Yeah, that's the thing... The announcement e-mail hasn't gone out yet. Mark revealed it at Atlanta Linux Fest.
[15:21] <maxb> ohhhh right
[15:21] <maxb> Good old verbal communication :-)
[15:22] <mpt> nh2, hi
[15:22] <mpt> nh2, the first thing to learn is that any checkbox label that starts with "Enable" probably isn't direct enough.
[15:23] <pitti> jdstrand: thanks
[15:23] <mpt> nh2, for example, "Enable right clicks with the bottom right corner of the touchpad" could be shortened to "Rght-click by tapping the bottom right corner of the touchpad"
[15:24] <mpt> nh2, and similar for the other new checkbox.
[15:26] <mpt> nh2, another thing to consider is that if someone sets up all the mice they ever use with left-handed orientation, secondary click is left click, not "right-click". So you may be better referring to "secondary click" rather than "right click".
[15:26] <nh2> mpt: ah ok, I just saw "Enable mouse clicks with touchpad" and so also used "enable"
[15:27] <mpt> nh2, yes, that will be fixed in my large-scale redesign of the touchpad settings :-)
[15:27] <cjwatson> will people understand secondary click?
[15:27] <nh2> mpt, cjwatson: I'm not sure a regular user can imagine that
[15:27] <davmor2> mdz: did the additions I put into bug 43706 cover what you needed?
[15:27] <nh2> s/imagine/understand
[15:29] <nh2> mpt, cjwatson: perhaps "clicks" and "context menu clicks" as the secondary click is often a context menu click?
[15:29] <glatzor> mpt, rgreening: richard is no longer working on app-install
[15:30] <glatzor> the infrastructure changes have not been accepted by Fedora
[15:30] <glatzor> but see you
[15:30] <mpt> cjwatson, I haven't been able to find a screenshot of what Windows calls it -- the interface seems to be up to the device <http://farm4.static.flickr.com/3154/2879987137_4ca67c9133_o.jpg>. Mac OS X calls it secondary click, though. <http://www.winandmac.com/wp-content/uploads/2009/08/snowleopard-final08.png>
[15:30] <mpt> (up to the device vendor, I mean)
[15:31] <mpt> Though that might just be because Mac mice don't often have buttons with visible sides
[15:31] <cjwatson> I was just about to say
[15:31] <cjwatson> Mac hardware users seem less likely to talk casually about left/right clicks
[15:32] <cjwatson> another option would be to have the dialog text conditional on which way round the mouse buttons are configured, though I'm not sure how confusing that would be
[15:32] <mpt> That Windows screenshot does specifically mention "Left Button Action" and "Right Button Action", but I suspect that's referring to the actual hardware orientation rather than colloquial use.
[15:34] <mpt> glatzor, sorry, what infrastructure changes?
[15:34] <soren> Now that lucid has been announced, is there any reason to not update vim, devscripts, and lintian to recognise it?
[15:35] <soren> And is there anything else that needs updating? I had a list at some point, but I think it's on another laptop.
[15:35] <ogra> soren, do you read -changes?
[15:35] <soren> ogra: I don't, but I'm guessing that I should?
[15:35] <ogra> soren, lool uploaded vim hours ago ;)
[15:36] <soren> ogra: Ah. devscripts and lintian as well?
[15:36] <ogra> i think only vim syntax scripts
[15:36] <jono> seb128, btw, the gnome panels and compiz bugs have gone away in my recent dist-upgrade - thanks!
[15:36] <seb128> jono, oh, good to know, not sure it's due to me but you're welcome ;-)
[15:36] <lool> there's devscripts and pbuilder too
[15:36] <lool> I'm working on both to have them use `lsb_release -cs`
[15:37] <jono> seb128, you deserve more thanks anyway for your Ubuntu work, so it seems fitting :)
[15:37] <lool> soren: Ah lintian is a good one too
[15:37] <seb128> jon;-)
[15:37] <seb128> jono, ;-)
[15:38] <soren> lool: right, pbuilder is the one I always forget :)
[15:38] <soren> lool: vim, devscripts, lintian, and pbuilder.
[15:38] <soren> That's my list. :)
[15:39] <mpt> nh2, <https://wiki.ubuntu.com/TouchpadSettings> is my work-in-progress for the big redesign, if you're interested.
[15:39] <mpt> nh2, though at the moment I don't have anything for simulating middle-click.
[15:40] <nh2> mpt: yes, tseliot told me there was work in progress
[15:42] <nh2> mpt: my suggestion was, just in case the redesign is not going into karmic, we could add those checkboxes so the user has an option to at least turn tapping on/off it it annoys him in karmic (I'm very open for any labelling suggestions ;-) )
[15:44] <mpt> nh2, that's fine, I've put suggested labelling into the bug report.
[16:06] <tseliot> superm1: is changelog.in meant to be used in fglrx-install or can I just modify the changelog?
[16:06] <tseliot> fglrx-installer
[16:06] <superm1> tseliot, you can just modify changelog.  changelog.in is intended to be modified if you are committing to the git tree
[16:07] <superm1> it's used when building debs or dsc's directly from the .run file
[16:08] <tseliot> superm1: ah, ok, thanks. I only need to make a trivial change to fix bug #429153
[16:08] <superm1> isn't that an archive administration problem?
[16:08] <tseliot> which affects fglrx-installer too
[16:08] <hdon> cjwatson: thanks for your help earlier, i think i have everything i need now. do you think libintl's behavior of bailing out if it decides the requested locale is not provided by the system is the appropriate behavior? do you think there's any chance to persuade GNU that gettext should trust that an application knows what translations it provides and not assume it can't translate what the application asks just because the system ma
[16:08] <hdon> intainer hasn't made a locale available for the entire system?
[16:09] <tseliot> superm1: no, just a matter of specifying the section for the modalias package
[16:09] <tseliot> superm1: in debian/control
[16:09] <superm1> tseliot, I thought that stuff gets overridden by soyuz though anyway?
[16:10] <tseliot> pitti ^^
[16:10] <cjwatson> hdon: I think the current behaviour is appropriate
[16:10] <pitti> superm1: yes, the overrides and components in soyuz are correct
[16:10] <pitti> superm1: but mdz pointed out that some other packages doesn't check the actual values in apt, but the values in debian/control
[16:10] <cjwatson> hdon: the system is responsible for defining the meaning of locales; there are lots of things relevant there besides translations
[16:11] <pitti> superm1: and thus it would be nice to change debian/control to reflect actual reality
[16:11] <superm1> pitti, ah i see
[16:11] <cjwatson> hdon: for example, unless the system has defined what the locale means, you cannot know the appropriate character encoding for printed messages
[16:11] <cjwatson> hdon: and again, this is not a matter of libc lagging behind somehow, this is just a matter of using a mistaken locale name, easily corrected by using the correct one instead
[16:12] <hdon> cjwatson: hmm, i think i can see what you mean. my perspective on it is a little different because i'm working with web-based systems, so whereas most programs want their messages displayed by the system on which they run, we display our messages on a remote piece of software (web browser)
[16:12] <cjwatson> then I think it's reasonable to ask that your application does a little bit more work to find the right locale name, to be honest
[16:12] <cjwatson> or else that your application uses localedef to define its own locales (I wouldn't recommend that, but it's possible)
[16:13] <cjwatson> the gettext library function does need to know the encoding somehow, though
[16:13] <hdon> cjwatson: yeah, it's silly of me to assume that my application will need a locale that hasn't already been defined for us
[16:13] <cjwatson> I don't know that I said it was silly
[16:13] <cjwatson> but I do think you can declare it to be the system's problem
[16:13] <lool> soren: there's debootstrap too of course
[16:13] <cjwatson> and if that's really unacceptable, localedef is avaialble
[16:13] <cjwatson> available
[16:14] <hdon> cjwatson: ok, thanks. i'll evaluate localedef if we need to support any locales that won't or can't be installed on our target systems.
[16:15] <lool> cjwatson: BTW I think we had a chat about preparing for karmic+1 in karmic a while ago and ISTR you indicated there was no particular issue in doing that, just that we didn't think of doing that before release; do you think you'd have time to prepare a debian upload of debootstrap with a new symlink for lucid?
[16:15] <lool> We often tell people to install the debootstrap from the devel release; that's probably more solid and it's usually easy to do but perhaps we can avoid that most of the time
[16:23] <cjwatson> lool: sure
[16:23] <lool> cjwatson: thanks
[16:43] <ogra> urgh
[16:44] <ogra> the new xsplash graphics look horrid on 16bpp displays
[16:44] <ogra> way worse than the former
[16:51] <ebroder> Has anybody seen a segfault like this before: http://paste.ubuntu.com/275342/ ?
[17:25] <lool> james_w, slangasek: Would be cool to get linux-mvl-dove binaries NEWed if you have some time (mostly adds udebs)
[17:30] <slangasek> lool: yep, will be working through NEW this morning
[17:32] <lool> slangasek: Cool thanks
[17:32] <lool> slangasek: Did you have any concern on the UNR seed changes?  (apart of us being oversize again)
[17:32] <slangasek> lool: no, being oversized was my main concern :)
[17:33] <lool> Eh ok  :-)
[17:33] <pitti> they looked fine to me
[17:33] <lool> I just seeded usb-creator at the req of the dux team too
[17:34] <lool> pitti: thanks
[17:43] <hdon> hi all. what package contains the debugging symbols needed to peek at the arguments given to glibc functions using gdb?
[17:45] <hdon> ah, lib6-dbg i guess
[17:59] <smoser> slangasek, did you do an MIR for libc6-xen ?
[18:00] <cjwatson> smoser: MIRs are needed when moving source packages to main, not when moving binary packages generated by source packages that are already in main
[18:00] <smoser> ah. ok. so what needs to be done for that? anything ?
[18:02] <cjwatson> smoser: no paperwork is needed. I've promoted it - it'll be visible in main in an hour or two
[18:02] <smoser> thank you.
[18:04] <slangasek> smoser: right, what cjwatson said :)
[18:13] <jdstrand> jpds: When I click the link to the PDF you provided in your description with firefox, evince opens in its own window and does not seem to load from cache. Are there other steps I should take to reproduce the bug?
[18:13] <jdstrand> jpds: bug #433316
[18:13] <jpds> jdstrand: No... that's the problem, PDFs just don't load.
[18:14] <jdstrand> jpds: what I'm saying is they *do* load fine here. I'd like to know what I need to do differently to reproduce the bug
[18:14] <jpds> Hmm, not sure what I could of done to change the apparmor profiles, I reinstalled Karmic last week.
[18:15] <jdstrand> ps auxww|grep evince
[18:15] <jdstrand> jamie    27573 14.0  0.6 385680 26180 ?        Sl   12:14   0:03 evince file:///tmp/eu_map-3.pdf
[18:15] <jdstrand> jpds: ie, it isn't loading from cache
[18:16] <jdstrand> jpds: let me rephrase
[18:16] <jpds> jdstrand: I see.
[18:16] <jpds> jdstrand: I'll go and check what's wrong with my config.
[18:16] <jdstrand> jpds: the file seems to be copied from cache, into /tmp, and then loaded
[18:17] <jdstrand> jpds: yeah, I just removed all the pdfs in /tmp, then clicked on the link, it opened instantly (ie, I didn't have to redownload it) and it worked fine
[18:19] <slangasek> kenvandine: why does xsplash need > 500k of images?  shouldn't xsplash be able to scale these backgrounds at runtime, particularly given that the 3 largest all have the same aspect ratio?
[18:26] <kenvandine> slangasek, i would think so
[18:26] <kenvandine> slangasek, i will talk to cody about that
[18:27] <slangasek> kenvandine: ok, thanks
[18:30] <superm1> kenvandine, if you do make such a change can you try to remember to file a bug against mythbuntu-gdm-theme so that we can make adjustments relative to that?
[18:30] <kenvandine> superm1, sure
[18:30] <superm1> thanks
[18:30] <kenvandine> np
[18:30]  * kenvandine makes a tomboy note
[18:30] <kenvandine> :)
[18:42] <kenvandine> slangasek, the DX guys say it would look bad... or at least not as good as our requirements
[18:43] <slangasek> kenvandine: er, what's wrong with xsplash's scaling support then? :P
[18:43] <kenvandine> hehe...
[18:44] <slangasek> same aspect ratio + downscaling shouldn't give any noticeable degradation in the appearance
[18:44] <slangasek> and we don't *have* 500K+ to spare on the CDs
[18:45] <slangasek> (i.e., this change has pushed amd64 alternate oversized in the dailies)
[18:45] <smoser> how can I get list build dependencies for a package ?
[18:46] <smoser> i can *get* them with apt-get build-dep, but how can i list ?
[18:46] <slangasek> smoser: 'apt-cache showsrc <package>' | grep Build-Depends
[18:46] <smoser> thanks
[18:58] <ltrager> I would like to create an init script which will be interactive. I'm using the read command but its not working, how can I get this to work?
[18:58] <slangasek> ltrager: "don't"
[18:59] <slangasek> ltrager: init scripts *must* run noninteractively at boot
[18:59] <ltrager> slacker_nl: then how would you suggest to run a script at boot-up?
[18:59] <ltrager> in my case it asks the user if they would like to image a machine
[18:59] <ltrager> and which image to use
[19:00] <slangasek> you cannot assume that the user is anywhere near the console at a reboot, and you shouldn't block the booting waiting for your answer
[19:00] <ltrager> slacker_nl: I can this is for a custom usb key that I'm giving out to people that I know will have a console
[19:01] <dashua> Amaranth, http://www.ubuntu-pics.de/bild/25364/screenshot_001_59EQJ2.png
[19:01] <ltrager> slacker_nl: so I guess I should just tell getty to auto login and for roots .bash file set to run a script?
[19:01] <dashua> Is this a known bug when closing clock?
[19:02] <Amaranth> dashua: Known, pretty sure my patch to change dock shadows caused it
[19:02] <Amaranth> since that is technically a dock shadow
[19:02] <dashua> Amaranth, Ok cool.
[19:03] <Amaranth> dashua: please tell me you're seeing bug 430981 too :)
[19:04] <slangasek> ltrager: oh; then your question is off-topic here, since it's not about Ubuntu development. :)  Anyway, you would probably have to manually attach to the tty to be able to prompt the user.
[19:06] <Rasteiro> can anybody help me with partner program??
[19:06] <Rasteiro> sds...
[19:07] <slangasek> ltrager: an autologin would be another option, yes
[19:07] <dashua> Amaranth, All of my keyboard short cuts seem to work.
[19:08] <Amaranth> dang
[19:08] <Amaranth> everyone who has the bug is doing the workaround
[19:09] <dashua> I just did a clean install yesterday, but did not notice it prior.
[19:16] <kees> zul: erlang is in main, so does the MIR wiki need to be updated?  I think all the deps are in main now?
[19:17] <zul> kees: it wasnt when I did the MIR do you want me to update the MIR now?
[19:17] <kees> zul: nah, just wanted to check
[19:17] <zul> k
[19:21] <mangr3n> Anyone know where I can find a discussion of groups/users/permissions for the Jaunty standard install?
[19:22] <mangr3n> trying to find the groups needed to run the update manager, seems like the admin and root groups aren't all that's necessary
[19:24] <davmor2> mangr3n: check they user is a member of sudoers
[19:24] <mangr3n> I did that already, that was the first problem
[19:25] <mangr3n> Is apt-get upgrade the same as the update install?
[19:25] <mangr3n> sudoers points at root
[19:25] <nh2> mpt: great. Should I create a new patch or will the one who patches the package just change those strings?
[19:26] <mangr3n> and %admin, which my user is a member of
[19:27] <mangr3n> I'll do this in the #ubuntu room, I was just wondering if there was documentation on the default/standard groups that were added to ubuntu and what they were associated with, I'm missing some groups, and I don't know what they were
[19:28] <mangr3n> found it missing group mlocate...
[19:34] <mpt> nh2, I don't know, sorry.
[19:37] <nh2> mpt: ok
[19:43] <kees> zul: what would it take to enable to testsuite in rabbitmq?
[19:43] <kees> there is a "run-tests" makefile target
[19:44] <zul> kees: i would have to see
[20:12] <jcastro> are the moblin images on cdimage supposed to work?
[20:24] <Martyn> Alpha-6 using grub2 still total fail on the Precision T7400/T7500 series from dell
[20:24] <Martyn> no boot .. had to install then upgrade
[20:24] <Martyn> Is there a gcc 3.6 toolchain available for karmic koala somewhere?  I have a lot of software that has it as a build dependency.
[20:25] <Martyn> I noticed all the gcc-3.6 packages were dropped from being built, and there's no mention on launchpad as to why
[20:31] <danage> kirkland: sorry for bugging you, but i have a very bad and i think thus very serious bug to report. i'm not sure what package to attach it to. it has to do with home folder encryption, you seem to be part in the project (i saw your blog post)?
[21:03] <soren> I know that for udev, it's rather well documented what sort of things you can expect to have available in rules files numbered in the 20's, the 30's, etc.. Do we have something similar for rc2.d/S?? scripts (other than looking at the directory on a reasonably rich system)?
[21:18] <ScottK> Martyn: gcc3.6 is pretty ancient.  We try to get rid of old gcc versions when nothing in the archive requires them.
[21:26] <Martyn> ScootK : That's the funny thing .. there is a LOT of g++ software in the archive that just won't compile under 4.4
[21:26] <Martyn> (or 4.3)
[21:27] <Martyn> because of the new template library enforcement of something that USED to be a warning, is now an error
[21:27] <Martyn> and not all the libraries are editable.  It's a quandry
[21:28] <Martyn> ScottK : What is the probability I can convince someone to bring the 3.6 package over from Jaunty to Karmic?
[21:28] <Martyn> and at least keep one creaky compiler running?
[21:28] <ScottK> Martyn: Probably close to zero.  You'd need to make a really good case why it's essential.
[21:28] <ScottK> I don't think "My non-free software that I can't modify won't work with a newer gcc" will work.
[21:29] <Martyn> ScottK : That becomes a philosophy problem then .. the main packages that I need it for, in any case, are ThirdParty commercial software (nonfree) that use gcc 3.6 as the compiler for the environments
[21:29] <Martyn> yes, but ubuntu != debian in the server market
[21:29] <Martyn> and I hate to get stuck with Redhat's pile of fail
[21:30] <Martyn> because they are one of the only linux companies that at least acknowledge that commercial software exists and is useful to the business sector using linux for development
[21:30] <Martyn> but centOS and RedHat are so hopelessly mired right now.  What a mess.
[21:39] <ScottK> Martyn: I understand the problem, but there's really no will for community support of such old things.
[21:39] <ScottK> If there were an active Ubuntu developer that were interested to support it, it might be different.
[21:44] <NCommander> Martyn, GCC 3.6?!
[21:46] <Martyn> NCommander: Yep
[21:47] <Martyn> NCommander: I hate to say it, but ARM's FastModel tools, and RealView -depend- on fucking gcc-3.6
[21:47] <NCommander> Martyn, I didn't even realize GCC 3 went that long
[21:47] <NCommander> *twiches*
[21:47] <Martyn> it's hitting the wall for development on ARM dude.
[21:47] <Martyn> that's why I need it.
[21:48] <Martyn> What can you do, when the MANUFACTURER of the architecture we're trying to port to .. has tools that depend on old buildchains?
[21:48] <Martyn> Arm RealView 5.0 / FastModel 5.0 both depend on 3.6, and 32 bit at that
[21:48] <NCommander> Martyn, well, you can get 32-bit compat easily enough
[21:48] <NCommander> Martyn, but I don't remember ever seeing GCC 3.6 in the archive
[21:48] <Martyn> so if you do development on a 64 bit platform (which of course I am using) .. I need to use the 32bit compiler or multilib
[21:48] <Martyn> NCommander: jaunty
[21:49] <Martyn> Sorry .. gcc 3.4.6
[21:49] <NCommander> Martyn, packages.u.c doesn't turn it up
[21:49] <NCommander> Martyn, oh, 3.4.6!
[21:49] <NCommander> :-P
[21:49] <Martyn> I transposed the numbers
[21:50] <Martyn> Good call on the version number
[21:50] <Martyn> but yeah, I need 3.4.6 in order to use those tools .. and it gets WORSE with the RTL validation tools
[21:50] <Martyn> some of those need older binutils
[21:51] <NCommander> Martyn, hrm, i didn't realize we dropped it completely
[21:52] <ScottK> Martyn: Run in it a chroot of an older release that has it is my advice.
[21:52] <NCommander> Martyn, talk to doko, he's the one who would know the most on this situation.
[21:53] <NCommander> Martyn, otherwise, what ScottK said :-)
[21:53] <Martyn> yeah *grump*
[21:54] <Martyn> I really don't want to try running in a mixed condition
[21:54] <NCommander> Martyn, the other choice is grab the old source packages, and try building GCC 3.4 under karmic
[21:54] <ScottK> Convince Canonical they want it in the partner repo might be another option.  It wouldn't be the first time they'd put obsolete stuff back in there.
[22:20] <LIB53> alpha 6 is supposed to have a brownish xsplash right?
[22:24] <LIB53> i was just asking because i don't get that xsplash, but i can't stick around forever for a reply so nvm
[22:24] <ion> Wow, almost five minutes of patience.
[22:26] <Madkiss>  miaow