[00:02] <asac> cjwatson: reconnect
[00:02] <asac> 00:56 < cjwatson> "Permission denied to call Location.toString" without any indication of an  associated website
[00:02] <asac> 00:56 < asac> cjwatson: any other extension installed? (besides from flashblock)
[00:04] <asac> cjwatson: maybe also check that you don't have a test version of ubufox installed in your profile (should be version 0.6 in tools -> addons)
[00:13] <cjwatson> 23:58 <cjwatson> disabling flashblock makes no difference
[00:13] <cjwatson> 23:56 <cjwatson> "Failed to load XPCOM component: /usr/lib/xulrunner-<IP_ADDRESS>/components/pyabout.py" (and libpyloader.so)
[00:14] <cjwatson> 23:58 <cjwatson> extensions: flashblock, greasemonkey, link widgets, nukeimage, ubufox, wiki auto-discovery button, and a usage viewer for my ISP (disabled)
[00:14] <cjwatson> asac: ubufox 0.6~a1 according to tools -> add-ons
[00:15] <cjwatson> oh, hmm, I do have a stray ubufox here
[00:15] <asac> cjwatson: i think you really have it installed in the profile then
[00:16]  * cjwatson nukes it
[00:16] <asac> cjwatson: try to uninstall it from there.
[00:16] <asac> good
[00:16] <cjwatson> asac: thanks! that was it
[00:16] <cjwatson> sorry for the newbie mistake
[00:16] <asac> cjwatson: hehe ... no problem.
[00:17] <asac> cjwatson: its not really obvious that firefox prefers profile even if version globally installed is higher ;)
[00:17] <cjwatson> that's a nice UI
[00:17] <cjwatson> (manage content plugins, now that I can see it!)
[00:18] <cjwatson> it doesn't get on with flashblock
[00:19] <asac> cjwatson: you mean when flashblock blocks the content?
[00:19] <cjwatson> even after unblocking it, manage content plug-ins isn't made available, and the plugin icon doesn't appear in the status bar
[00:20] <cjwatson> it works fine when disabling flashblock
[00:20] <cjwatson> I'll file a bug on ubufox
[00:20] <asac> cjwatson: hmm
[00:20] <asac> cjwatson: i thought that is fixed
[00:20] <asac> but yeah.
[00:21] <cjwatson> asac: filed bug 297427
[00:22] <cjwatson> anyway, bedtime I guess, thanks for the help
[00:22] <asac> cjwatson: thx.
[00:22] <asac> cjwatson: sleep well
[00:22] <cjwatson> oh, I will :)
[00:22] <cjwatson> *zonk*
[00:36] <directhex> kirkland, package info in MOTD: very cool
[01:09] <ScottK> kirkland: Thanks.
[02:38] <dmulholland> hey, which kernel is going to be used in the next ubuntu?
[06:49] <dholbach> good morning
[07:15] <pitti> Good morning
[07:15] <StevenK> Morning pitti
[07:16]  * bryce waves
[07:42] <viviersf> cjwatson, on the kickstart, to get the whole distro as is on the desktop cd, do i just install the ubuntu-desktop package, or must i add the recommended packages alsoed
[07:47] <pitti> liw: can you please reupload system-cleaner with correct bug closing syntax in the changelog? it's "LP: #xxx", not "LP: xxxx" or "LP# xxxx"
[07:51] <lool> hi all
[07:51] <pitti> lool: bonjour Loic!
[07:53] <dholbach> hi huats
[07:53] <huats> hey dholbach
[07:56] <tkamppeter_> hi pitti
[07:56] <pitti> hey tkamppeter_, guten Morgen
[07:58] <tkamppeter> I have seen that you have accepted my splix upload from yesterday. The maintainer scripts are not needed in Jaunty, as the conversion rules which I have added to Intrepid's SpliX will not be in Jaunty's.
[07:59] <tkamppeter> In Jaunty the Ghostscript-based pdftoraster is default and not part of SpliX.
[08:00] <tkamppeter> Only part of the Intrepid SpliX which has to go to Jaunty, too, is the patch for grayscale printing on color printers.
[08:04] <liw> pitti, fixed in bzr, now I need to find someone to sponsor another upload
[08:04] <pitti> liw: oh, I can do that for you
[08:05] <pitti> tkamppeter: ah, ok, I see
[08:05] <pitti> liw: do you have the dsc/diff.gz/source.changes somewhere?
[08:06] <liw> pitti, I can make a source package, just a minute
[08:08] <pitti> tkamppeter: www.cups.org got quite a redesign...
[08:09] <liw> pitti, http://files.liw.fi/temp/syscleaner/
[08:09] <liw> pitti, will that do?
[08:09] <pitti> liw: "Does not quite close" :)
[08:09] <pitti> liw: yes, that's fine; thanks
[08:10] <pitti> liw: note the Launchpad-Bugs-Fixed: line
[08:11] <pitti> liw: what does the release name mean?
[08:12] <liw> "last minute package additions are a bad idea"
[08:12] <pitti> haha
[08:12] <liw> (that bit is there only to see if people actually read the changelog)
[08:12] <pitti> just trawling through the debdiff
[08:12] <liw> that should keep you busy for the rest of the day...
[08:13] <tkamppeter> pitti, more Apple-like. Probably the web interface of CUPS 1.4 will look the same.
[08:13] <pitti> liw: I'm curious about license-exceptions; do you have some magic which goes through all the files and yells at you if you forgot a copyright header?
[08:14] <liw> pitti, yes; the license-check script, run from "make check"
[08:14] <tkamppeter> pitti, and by the way, CUPS can celebrate the 3000th upstream bug now: CUPS bug 3000
[08:15] <pitti> liw: uploaded
[08:15] <liw> pitti, thanks
[08:22] <tkamppeter> pitti, the new Jaunty package of SpliX is now uploaded. It contains only the grayscale patch.
[08:26] <pitti> tkamppeter: hm, new splix2 lsb package still doesn't work at all :(
[08:26] <pitti> tkamppeter: as for the splix package patch, I only see no-crash-on-bad-papersize.patch, which is an one-liner fixing the page height; however, the garbage is on the left border
[08:27] <pitti> tkamppeter: hm, did the reporter or me actually try to directly print a pdf with lp instead of evince? /me goes to try a test page
[08:34] <tkamppeter> pitti, the patch no-crash-on-bad-papersize.patch is perhaps incomplete and a minimum to avoid crashes caused by paper size mismatches. The patch can even be wrong.
[08:35] <pitti> tkamppeter: ok, done two more tests, bug updated
[08:35] <pitti> tkamppeter: ok, just for fun I'll drop that patch and try again
[08:37] <tkamppeter> pitti, can you give me a complete error_log of the failure of the OpenPrinting splix2 package? Are you sure that you have the newest version (2.0.0-0.rc2.2lsb3.2)? Did you also try the 1.1.1 package?
[08:37] <pitti> tkamppeter: I didn't try the 1.1.1 LSB package; the ubuntu 1.1.1 one works fine (see bug)
[08:38] <pitti> tkamppeter: error_log> can do; I go to the other room to do those new tests (patch removed and error_log)
[08:40] <tkamppeter> pitti, please also test the OpenPrinting 1.1.1 package to help me finding problems in the Openprinting packaging.
[08:50] <pitti> tkamppeter: bug updated for error_log and removed patch, testing openprinting 1.1.1 now
[08:58] <pitti> tkamppeter: error_log with lsb splix 1.1.1 attached as well
[09:02] <tkamppeter> pitti, can you do "ldd /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl"
[09:02] <pitti> tkamppeter: that's for splix2, right?
[09:03] <tkamppeter> yes. for splix1 you should try "ldd /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoslp2"
[09:03] <pitti> /usr/bin/ldd: line 117: /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl: No such file or directory
[09:03] <pitti> WTH?
[09:03] <pitti> $ file /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl
[09:03] <pitti> /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped
[09:03] <wgrant> Awesome.
[09:04] <pitti> that looks exactly like e. g. file /bin/dd
[09:04] <pitti> tkamppeter: directly running it in bash gives that, too
[09:05] <pitti> tkamppeter: how did you build that? looks like badly linked
[09:05] <pitti> nm -D works
[09:07] <tkamppeter> pitti, once it works on my box, and second, I have built it with the LSB SDK.
[09:07] <pitti> objdump -x /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl works, too, trawling through NEEDED
[09:07] <tkamppeter> pitti, can you do "dpkg -l | grep lsb"
[09:08] <pitti> tkamppeter: oh, *blush*, I don't have that installed
[09:09] <pitti> I have all the libraries, though, hmm
[09:10] <tkamppeter> pitti, the LSB packages require "lsb" of the appropriate version. But they are created as RPMs and converted to DEB with alien. Perhaps alien drops dependencies.
[09:11]  * wgrant shudders violently.
[09:11] <tkamppeter> Can you install the "lsb" package and try again?
[09:13] <pitti> tkamppeter: no, the package does depend on lsb; I --force-depends ignored it, because lsb pulls in so much crap
[09:13] <pitti> I don't need alien, rpm, qt, and postfix(!) on a client box just to run a printer driver...
[09:14] <pitti> argh, and build-essential and debhelper...
[09:15] <pitti> *nnnng* cluttering production desktop boxes; but well, I can purge it again
[09:15] <pitti> tkamppeter: I checked that all libs in rastertoqpdl's NEEDED sections are already there
[09:15] <mvo> Mirv: hello! thanks again for bug #295080 - I updated it and prepare a new export. I'm also in contact with the debian ddtp people to feed back rosetta translations
[09:16] <tkamppeter> pitti, that is true. The LSB does not provide only an environment for printer drivers, but generally for distro-independent packages. And in general these packages come RPM-only, as commercial app vendors do not provide an auto-download and -update service as OpenPrinting does.
[09:16] <pitti> maybe depending on lsb-printing would be enough? still pulls in postfix through -core, but at least not lsb-desktop and qt any more
[09:17] <pitti> well, let's find out what's missing first
[09:17] <tkamppeter> pitti, do you have /lib64/ld-lsb-x86-64.so.3
[09:17] <pitti> no, it's a 32 bit installation
[09:18] <pitti> tkamppeter: I installed "lsb", and still the same error
[09:18]  * pitti purges it again
[09:19] <Mithrandir> pitti: strace ldd on it, maybe?  Or strings on it?
[09:19] <tkamppeter> pitti, then do you have /lib/ld-lsb.so.3?
[09:19] <pitti> stat64("/opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl", 0xbf9bbc20) = -1 ENOENT (No such file or directory)
[09:20] <Mithrandir> special
[09:20] <pitti> sorry, ignore this
[09:20] <pitti> purging lsb also purged that splix driver
[09:20]  * pitti installs again
[09:21] <cjwatson> viviersf: @ubuntu-desktop in the %packages section will do the trick (note the @)
[09:22] <viviersf> cjwatson, what does the @ do ? install reccomends and all ?
[09:22] <cjwatson> viviersf: @ means install the task by that name
[09:23] <cjwatson> viviersf: and tasks are generated such that they include recommends
[09:23] <viviersf> cjwatson, cool thanks :)
[09:23] <cjwatson> viviersf: recommends are installed by default in 8.10 anyway, though, so you don't need to do anything explicit to get them
[09:23] <cjwatson> it's just that @ubuntu-desktop maps properly to how we normally install the desktop
[09:23] <tjaalton> cjwatson: not true if you preseed pkgsel/include
[09:24] <tjaalton> cjwatson: I mean, recommends are not installed
[09:24] <viviersf> thats awesome
[09:24] <cjwatson> tjaalton: oh, true
[09:25] <viviersf> makes my work at our client so much easier
[09:25] <cjwatson> yeah, and individual package installations in kickstart map to pkgsel/include
[09:25] <tjaalton> cjwatson: any way to work around that?
[09:25] <cjwatson> so ok, their recommends won't normally be included
[09:25] <pitti> tkamppeter, Mithrandir: weird: "/lib/ld-linux.so.2 /opt/OpenPrinting-SpliX/cups/lib/filter/rastertoqpdl" works
[09:25] <pitti> but calling it directly doesn't
[09:25] <cjwatson> tjaalton: pkgsel/late_command I guess
[09:25] <cjwatson> err, preseed/late_command
[09:25] <cjwatson> I suppose I should change that in pkgsel
[09:26] <tkamppeter> pitti, the ldd output of rastertoqpdl once from the Ubuntu package and once from the LSB package differs for me only by the lines
[09:26] <tjaalton> cjwatson: ok, works for now
[09:27] <viviersf> cjwatson, uhm ok, so does it install recommends by default or not ? your conversation confused me now
[09:27] <pitti> tkamppeter: right, with "lsb" installed it WFM
[09:27] <pitti> tkamppeter: I think it's due to /lib/ld-lsb.so.3
[09:27] <tkamppeter> "/lib/ld-linux.so.2 (...)" for Ubuntu and "/lib/ld-lsb.so.3 (...)" for LSB.
[09:28] <pitti> tkamppeter: which is just a symlink to ld-linux.so.2
[09:28] <tkamppeter> /lib/ld-lsb.so.3 is probably generated by a maintainer script of an lsb-... package.
[09:29] <pitti> tkamppeter: right, so just installing that symlink and installing the package, but not any lsb* stuff works
[09:29] <pitti> tkamppeter: okay, trying that driver now
[09:30] <tkamppeter> pitti, why did you not have this symlink? And what triggered that you get the symlink again?
[09:30] <pitti> tkamppeter: as I said, the symlink is created by some lsb-* package, which I didn't install because they pull in a lot of stuff which I don't want on that box
[09:31] <pitti> maybe adding that symlink would be a good idea for our lsb-base package or so
[09:33] <cjwatson> viviersf: tasks (or "groups" in kickstart, introduced by @) behave as I said; individual packages don't get recommends installed by default
[09:35] <viviersf> cjwatson, cool thanks
[09:36] <tkamppeter> pitti, the symlink is created by /var/lib/dpkg/info/lsb-core.postinst, so lsb-core and lsb-printing should be sufficient for printer driver packages.
[09:36] <pitti> tkamppeter: bug updated again; splix2 openprinting.org package has the same bug
[09:36] <pitti> tkamppeter: lsb-printing depends on lsb-core already
[09:36] <pitti> unfortunately lsb-core pulls in postfix
[09:38] <tkamppeter> pitti, and installing postfix wastes a lot of space and runs a daemon listening on port 25?
[09:40] <pitti> tkamppeter: debconf asks about it, but by default it does, yes
[09:41] <pitti> postfix itself doesn't need a lot of space, but you really shouldn't install an MTA without actually needing one and being aware of it
[09:41] <pitti> tkamppeter: but that's a bug in the LSB, not something in the printer drivers
[09:41] <pitti> tkamppeter: so don't worry for now, I'm just whining
[09:41] <tkamppeter> On my box postfix is installed and port 25 is not open.
[09:42] <pitti> tkamppeter: you probably chose "local delivery only" in debconf
[09:42] <pitti> but "internet site" is the debconf default
[09:43] <tkamppeter> pitti, perhaps we should change the default, so that the default is the least-impact one.
[09:44] <pitti> tkamppeter: for people who install postfix because they actually want postfix, it makes sense, though
[09:44] <pitti> same for apache, ssh-server, etc.
[09:45] <tkamppeter> pitti, can you report the "LSB pulls in postfix" bug to the LSB bug tracking system http://bugs.linuxbase.org/? Thanks.
[09:45] <pitti> "LSB mandates a local MTA" would be the bug, yes
[09:46] <pitti> tkamppeter: I created an account, once I get it I'll file the bug
[09:46] <NCommander> so the LSB is now going to be mandating java
[09:46] <NCommander> Wooo
[09:49] <tkamppeter> NCommander, did the installation of an OpenPrinting package pull Java for you?
[09:49] <NCommander> Install what package now?
[09:50] <pitti> tkamppeter: actually, LSB is just requiring /usr/bin/sendmail to exist
[09:50] <pitti> so if we had a simple local-only MTA, our lsb-core package should pull in that, instead of postfix
[09:50] <tkamppeter> NCommander, if you have a distribution-independent package based on the LSB, it pulls the meta-package "lsb", and that pulls all requirements of the LSB.
[09:50] <NCommander> oh yay, RPM :-P!
[09:52] <pitti> but I guess the most practical solution for now is to use distro packages instead of "LSB" alien'ed ones
[09:52] <tkamppeter> pitti, so it is perhaps only a bug in our lsb-core. It should prioritize the absolute minimum to get /usr/bin/sendmail.
[09:53] <infinity> Easily solved with "Depends: nullmailer | mail-transport-agent" or similar.
[09:53] <pitti> tkamppeter: it's about shipping something crippled by default in any case
[09:53] <ion_> I take it someone’s working on getting the firefox security update to Ubuntu?
[09:53] <pitti> infinity: right, except that nullmailer is specifically not a local-only MTA
[09:53] <infinity> pitti: And not LSB-compliant, even, according to the description.
[09:53] <infinity> pitti: But it was merely an example. :)
[09:53] <pitti> OTOH I'm convinced that *having* a local-only MTA would be even worse
[09:54] <pitti> since once programs see /usr/bin/sendmail, they might actually try to *use* it, you know
[09:54] <infinity> pitti: Then again, isn't our default postfix installation technically a local-only MTA anyway?
[09:54] <pitti> and send mail into oblivion, instead of saying "I need to send mail, dude"
[09:54] <infinity> (or close to)
[09:54] <pitti> infinity: no, not at all; we don't install postfix by default
[09:54] <pitti> infinity: and the debconf default is "internet site", the full thing
[09:54] <infinity> pitti: Right, we don't anymore.  I'm thinking about 17 releases ago.
[09:54] <pitti> which is the right thing
[09:55]  * infinity lives in the past.
[09:55] <infinity> Though, to be fair, I don't really see the "bug" that LSB mandates an MTA.
[09:55] <pitti> infinity: in the end, I think is is and remains a nonsensical LSB requirement which cannot sanely be implemented
[09:55] <infinity> UNIX-like systems are still kinda expected to have one, even if most desktops don't anymore.
[09:56] <pitti> right, and that expectation is the bug :)
[09:57] <tkamppeter> pitti, infinity, I hope we do not need a new lightweight project for making distro-independent binaries, only to make it easier for hardware manufacturers to provide drivers ...
[09:59] <tkamppeter> pitti, infinity, I think the LSB needs to be modularized and the distro-independent binaries should simply pull appropriate modules, for printer drivers for example lsb-printing and lsb-binary (the latter would provide everything to run generic, distro-independent binaries, likle this symlink).
[10:03] <pitti> ArneGoetje: hardy langpack updates finished building, so can get a CFT; what's the intrepid status?
[10:19] <pitti> tkamppeter, infinity: http://bugs.linuxbase.org/show_bug.cgi?id=2407
[10:23] <Hobbsee> Hmmm, how often is MoM actually running?
[10:24] <cjwatson> Hobbsee: hourly
[10:24] <cjwatson> Hobbsee: takes in the vicinity of an hour to run though due to the amount of churn, so sometimes it gets stuck on a lock and only ends up running every two hours in practice
[10:24] <Hobbsee> cjwatson: oh.  Hmm, I wonder hwy it hasn't picked up irssi's yet, when it was accepted 3 hours ago.
[10:24] <Hobbsee> cjwatson: ah, right
[10:25] <cjwatson> and when you factor in publisher cron times + delay into that, it can take a bit
[10:25] <Hobbsee> yup
[10:32] <directhex> coo, someone's packaged up xserver-xorg-video-spu, for great ps3 justice
[10:35] <tkamppeter> pitti, great bug report. I have also posted on the lsb-discuss mailing list about whether one could let LSB packages require only a part of the LSB, by requiring "lsb-printing" and not "lsb".
[10:40] <tkamppeter> pitti, if you get a clue on the page size calculation inside the SpliX code, I would be grateful if you could get it going. I cannot do much here without having the printer to test.
[10:40] <pitti> tkamppeter: yep, still on my list
[10:41] <NCommander> Does a package have to explicately depend on perl?
[10:41] <NCommander> Or more specifically perl-modules?
[10:43] <pitti> NCommander: on perl, yes
[10:43] <pitti> NCommander: perl-base is essential, so you don't need to depend on that
[10:43] <NCommander> ok
[10:43] <cjwatson> neither perl nor perl-modules is essential; generally dependencies should be on perl not perl-modules
[10:43]  * NCommander is fixing svk ATM
[10:44]  * NCommander fixes SVK
[10:44] <Hobbsee> errr... Now, are there *any* reasonable reasons I can have a suggests on build-essential?
[10:44] <Hobbsee> or is that just E,B&W no matter what the situation is?
[10:44] <pitti> Hobbsee: not EBW, but fairly useless?
[10:44] <NCommander> EBW?
[10:44] <cjwatson> Evil, Bad, and Wrong
[10:45] <pitti> Hobbsee: what's the package and rationale for it?
[10:45] <liw> unperish could reasonably suggest build-essential, I think
[10:45] <wgrant> Suggesting build-essential is fine.
[10:45] <Hobbsee> pitti: it's install-css.sh, where if it can't find a binary, i'tll try to build the source of the libdvdcss2
[10:45] <wgrant> build-suggesting build-essential would be wrong, if it were possible.
[10:45] <Hobbsee> it'll manually install it mid script, though, but the other bits are already a suggests
[10:45] <Hobbsee> wgrant: well, yeah...
[10:45] <pitti> Hobbsee: it still means that installing the package by any official means will fail by default
[10:46] <pitti> Hobbsee: if binaries aren't available
[10:46] <pitti> Hobbsee: so if the binaries are very likely to not be available, but the source is, a recommends: would make sense IMHO
[10:46] <Hobbsee> pitti: sorry, the actual package is libdvdread3, which contains the script.
[10:46] <pitti> but I don't see why that should be the case?
[10:47] <pitti> the hot thing is the CSS decryption, which is illegal in some countries no matter whether it's source or compiled?
[10:47] <Hobbsee> pitti: yes, which is why there's a script you can manually run to install it from medibuntu, rather than it being there itself.
[10:47] <pitti> Hobbsee: my general approach to that is to have a proper failure mode in the script itself
[10:48] <Hobbsee> pitti: (it does).  it's just done multiple times
[10:48] <pitti> Hobbsee: i. e. print out "packages not available, install build-essential and run me again"
[10:48] <pitti> suggests: aren't really "seen" by the casual user
[10:49] <Hobbsee> pitti: it does that.  So now i'm wondering why the other packages there (such as fakeroot) are suggests, as well as being attempted to be installed by the script, where the script bails out if they're not there.
[10:52]  * Hobbsee scratches head.  Since when did this script include such crack?
[10:53] <StevenK> Which script?
[10:53] <Hobbsee> install-css.sh
[10:54] <Hobbsee> it's relying on 'type', which is a bash builtin, and now doesn't do what it used to
[10:55] <StevenK> Maybe the script calls dash?
[10:55] <pitti> type works in dash, too
[10:56]  * Hobbsee tries to find a manpage for type, in dash.
[10:56] <liw> manpages document external commands, surely?
[10:56] <pitti> Hobbsee: man dash has it, yes
[10:56] <StevenK> Hobbsee: It takes no options, just the filename
[10:56] <cjwatson> type is technically not POSIX but it's one of those that has very good coverage among shells in practice
[10:57] <StevenK> What does it use type for, anyway?
[10:57] <cjwatson> which is theoretically more reliable but has its own portability problems
[10:57] <Hobbsee>      type [name ...]
[10:57] <Hobbsee>             Interpret each name as a command and print the resolution of the command search.  Possible resolutions are:
[10:57] <cjwatson> the usual use of type is for its exit code, to find out whether a command exists
[10:57] <Hobbsee>             shell keyword, alias, shell builtin, command, tracked alias and not found.  For aliases the alias expansion
[10:57] <Hobbsee>             is printed; for commands and tracked aliases the complete pathname of the command is printed.
[10:57] <Hobbsee> StevenK: to check if something's installed.
[10:57] <Hobbsee> So, it is there
[10:58] <Hobbsee> but that's a really bad way to check it.
[10:58] <cjwatson> I should get into the habit of using which instead, but it's an external command and therefore slower
[10:58] <cjwatson> Hobbsee: why? I do that often
[10:58] <cjwatson> it has its problems, but it isn't "really bad"
[10:58] <Hobbsee> if ! type dh_testdir > /dev/null || ! type fakeroot > /dev/null || ! type ; then
[10:59] <Hobbsee> cjwatson: because, unless i'm misreading it, if you do something like ^, even if you don't have fakeroot installed, it'll still bail.
[10:59] <Hobbsee> er, it'll still *pass*.
[10:59] <cjwatson> I don't know what type without arguments is supposed to achieve
[10:59] <cjwatson> looks like a mistake
[10:59] <Hobbsee> because '<packagename> not found' will be returned
[10:59] <Hobbsee> hmm, i'm starting to think so
[10:59] <pitti> it's essentially an "|| true"
[10:59] <cjwatson> the above checks exit code, not output on stdout
[11:00] <cjwatson> what it prints is entirely irrelevant
[11:00] <pitti> erm, || false
[11:00] <pitti> which is a no-op
[11:00] <Hobbsee> oh, right
[11:00] <Hobbsee> my bad, then.
[11:00] <cjwatson> (doing tests on the output of a command when exit status is available instead would generally be a mistake)
[11:00] <Hobbsee> cjwatson: thanks for hte help
[11:01] <cjwatson> no problem
[11:01] <cjwatson> I think you were thinking of ! [ "$(type fakeroot)" ] or some such wrongness
[11:01] <Hobbsee> ah yes, that would be it.
[11:01] <cjwatson> that mistake is more usually made with grep
[11:02] <cjwatson> i.e. 'if [ "$(thingy | grep foo)" ]; then ... fi' when 'if thingy | grep -q foo; then ... fi' would have done instead
[11:02] <cjwatson> or grep foo >/dev/null if you need non-POSIX portability
[11:03] <Hobbsee> ahhhhh
[11:03] <Hobbsee> right, got it.  Thanks again :)
[11:04] <liw> sh -- where everything you do that involves quotation marks is likely to a silly, difficult, or a security problem, unless you really, really know what you're doing
[11:04] <directhex> liw, got a better idea? :)
[11:05] <liw> directhex, sure: every time you're not sure whether you are quoting things properly, switch to perl or python
[11:05] <directhex> now, see, if install-css.sh were install-css.pl, Hobbsee wouldn't even be able to read it to find bugs. yay for write-only languages ;)
[11:06] <Hobbsee> directhex: well, i've never touched perl, so... :)
[11:06] <cjwatson> I would have phrased that the other way round; if your sh involves too few quotation marks, it's probably wrong
[11:06] <NCommander> jdong, ping
[11:06] <Hobbsee> directhex: how about install-css.bf, to go the whole way?
[11:06] <liw> cjwatson, that's also true
[11:06] <pitti> Hobbsee: I consider that steganography, not code
[11:06] <cjwatson> the rule of thumb I give people is that every $-expansion should always be enclosed in "", unless you know what you're doing and have a good reason not to do so
[11:06] <Hobbsee> pitti: haha :)
[11:06] <liw> directhex, I see no reason why Hobbsee couldn't learn Polish in a few afternoons
[11:07] <directhex> Hobbsee, i was messing around with bf -> .net compilers the other day, would you believe. i won't package one until there's a self-hosting compiler written in bf
[11:07] <directhex> liw, well, polish, that's easy. it's russian without the cyrillic. mostly
[11:07] <Hobbsee> directhex: hah
[11:34] <_StefanS_> any solutions for that issue with firefox3 and applets freezing ?
[11:35] <_StefanS_> other than installing icedtea6-plugin that is..
[12:25] <tkamppeter> pitti, will CUPS bug 3001 get a SRU?
[12:26] <pitti> tkamppeter: I want to wait for upstream's comment, and once Mike is happy, upload it to unstable, lenny, jaunty, and also SRU, yes
[12:26] <tkamppeter> http://www.cups.org/str.php?L3001
[12:26] <pitti> I know what you mean :)
[12:26] <tkamppeter> pitti, I am only testing ubottu, he stopped showing links on CUPS bugs.
[12:27] <tkamppeter> That is a regression, ubottu did it formerly.
[12:27] <tkamppeter> STR 3001
[12:28] <tkamppeter> CUPS STR 3001
[12:28] <Hobbsee> ubottu: ping
[12:28] <Hobbsee> hmm, it's alive.
[12:28] <NCommander> O_O;
[12:28] <tkamppeter> bug 1
[12:28] <NCommander> bug 123456
[12:28] <NCommander> bug 1 is a bad choice because it doesn't actually query LP
[12:29] <NCommander> ....
[12:29] <wgrant> Hmm.
[12:29] <wgrant> it normally says that it won't do anything.
[12:29] <NCommander> it was changed
[12:29] <wgrant> But it's timing out too quickly to be really timing out, so I presume they've just changed the message.
[12:30] <NCommander> yeah
[12:30] <tkamppeter> It returns an LP URL, or is this the default "Not found" one?
[12:30] <tkamppeter> https://bugs.edge.launchpad.net/ubuntu/+bug/1
[12:31] <tkamppeter> https://bugs.launchpad.net/ubuntu/+bug/1
[12:31] <NCommander> O__o;
[12:31] <wgrant> bug 1
[12:31] <wgrant> How odd.
[12:31] <lifeless> not really
[12:31] <lifeless> there is a metric shitload of comments
[12:31] <NCommander> bug 1 is over a megabyte in size
[12:32] <wgrant> lifeless: I mean the fact that only 'bug 1' seems to be blacklisted.
[12:32] <lifeless> I thought we had a static page for the web page, I wouldn't be surprised if ubottu is using api's now that api's are not protected
[12:32] <tkamppeter> A browser takes very long to reply to https://bugs.launchpad.net/ubuntu/+bug/1, but it replies the correct thing.
[12:32] <NCommander> we need to stop posting links to bug 1
[12:32] <NCommander> arhg
[12:32] <lifeless> tkamppeter: I believe it is a static page :) - its just big
[12:33] <cjwatson> I don't suppose there is some testing channel where ubottu hangs out, so that you guys don't have to play with the bot in here?
[12:33] <lifeless> sorry; I didn't mean to tweak it before
[12:33] <lifeless> at least it isn't talking to itself
[12:33] <Hobbsee> #ubuntu-bots?
[12:40] <Mirv> mvo: thanks, great that some problem points were found and fixed.
[12:41] <lifeless> mvo: ping; I know the Str problem fix
[12:41] <lifeless> mvo: api change in storm; its RawStr now
[12:41] <luli> hello
[12:41] <mvo> lifeless: right, I have a fix for this one in the bzr tree
[12:41] <mvo> lifeless: it breaks with that too unfortunately
[12:41] <luli> !list
[12:42] <lifeless> mvo: oh
[12:42] <lifeless> mvo: whats the next break?
[12:42] <mvo> lifeless: I need to run it again to get it
[12:42] <mvo> lifeless: give me a sec
[12:42] <mvo> (or two)
[12:43] <lifeless> mvo: nearly midnight
[12:43] <lifeless> mvo: don't stress now; I'm feeling guilty about it though
[12:44] <mvo> lifeless: no worries, I will sent it output by mail, ok?
[12:44] <mvo> netowrk is *very* slow for me right now anway :/
[12:45] <lifeless> mvo: please
[12:53] <lamont> why is it that everytime I restart squid, I find myself tempted to use 'killall -9 squid; /etc/init.d/squid start'?
[13:16] <NCommander> lamont, no idea, but on another topic, you have ia-64 hardware, right?
[13:25] <apachelogger> pitti: please take a look at bug 203349 once you get a chance
[13:26] <NCommander> DktrKranz, pinb
[13:26] <NCommander> ping even
[13:30] <lamont> NCommander: yeah
[13:31] <NCommander> lamont, could I convince you to test the ia64 kernel from jaunty?
[13:31] <lamont> the test box is currently intrepid, with (of course) a hardy kernel, since there isn't an intrepid one...
[13:31] <lamont> so sure, it'll be late tonight though
[13:32] <NCommander> lamont, great! I need to fix the HPPA kernel (it FTBFS on the builders, strangely enough)
[13:32] <lamont> thanks
[13:49] <pitti> argh, WTH? http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html is awful
[13:54]  * pitti creates jaunty chroot to debug
[13:54] <seb128> pitti: starting your archive day earlier? ;-)
[13:54] <pitti> seb128: no, wondering about my ekiga FTBFS
[13:55] <pitti> E: No such script: /usr/share/debootstrap/scripts/jaunty
[13:55] <NCommander> pitti, want a hand?
[13:55] <pitti> *nng*
[13:55] <pitti> NCommander: I suppose most of the list is a fallout of basic GNOME libs being uninstallable; if you can track it down, much appreciated
[13:55] <pitti> I already checked component-mismatches, nothing sticks out there
[13:55] <cjwatson> pitti: symlink, or I think there's something in intrepid-backports
[13:55] <NCommander> No, bunch of KDE stuff is broken
[13:55] <pitti> cjwatson: right
[13:57] <NCommander> I think the problem is Java isn't installable
[13:57] <pitti> I wouldn't like to upgrade to jaunty just yet, still too many intrepid SRUs going on which need testing
[13:57] <NCommander> ah
[13:57] <NCommander> Found it pitti
[13:57] <seb128> pitti: same for me
[13:57] <NCommander> libgnomevgs2-common is uninstallable
[13:57] <pitti> NCommander: not for ekiga and libgnome2-0
[13:57] <seb128> NCommander: good, now fix it ;-)
[13:57] <NCommander> pitti, I can debug that after I figure this out
[13:58] <pitti> likewise, I'll look into it once my chroot built
[13:58] <dholbach> hi nxvl
[13:58] <NCommander> seb128, oh, I see what happened. libgnomevgs2-common became a virtual package, and libgnomevgs2-0 has a versioned depends
[13:58] <seb128> NCommander: no it didn't?
[13:58] <NCommander>   libgnomevfs2-0: Depends: libgnomevfs2-common (>= 1:2.24) which is a virtual package.
[13:58] <seb128> wth?
[13:58] <NCommander> Ok, aptitude thinks it did :-)
[13:59] <NCommander> No candidate version found for libgnomevfs2-common
[13:59] <seb128> oh
[13:59] <pitti> indeed, it's not in jaunty
[13:59] <seb128> it's binary new
[13:59] <seb128> due to the new -dbg
[13:59] <nxvl> hi daniel!
[13:59] <NCommander> Well
[13:59] <NCommander> Mystery solved
[13:59] <NCommander> nxvl, I need you.
[13:59] <pitti> :)
[13:59] <nxvl> dholbach: how are you?
[13:59] <nxvl> NCommander: mmm
[13:59] <NCommander> Why do we require binary NEWing?
[13:59] <nxvl> NCommander: what for?
[14:00] <NCommander> nxvl, SRU
[14:00] <nxvl> oh
[14:00] <nxvl> shoot
[14:00] <seb128> NCommander: there is a new -dbg binary debian added
[14:00] <seb128> NCommander: all the binaries are hold when there is one change
[14:00] <pitti> seb128: did you already accept it? I don't see it
[14:00] <nxvl> NCommander: bug number
[14:00] <seb128> pitti: no, I was going to look at it the queue now
[14:00] <NCommander> nxvl, grabbing it
[14:00] <dholbach> nxvl: good good - how 'bout you?
[14:00] <NCommander> Bug 282793
[14:00] <nxvl> dholbach: having fun in Lexington with the crew
[14:01] <seb128> pitti: I did upload gnome-vfs yesterday and I know debian added a -dbg so that's guess work right now
[14:01] <NCommander> http://launchpadlibrarian.net/19612886/svk.debdiff
[14:02] <NCommander> pitti, if you point me to your build failure logs, I can help working on you on that FTBFS
[14:02] <NCommander> er, with you
[14:03] <seb128> pitti: it's not in new, hum
[14:03] <NCommander> seb128, has it built yet?
[14:03] <seb128> NCommander: yes, yesterday
[14:03] <NCommander> seb128, curious ...
[14:04] <seb128> don't tell me
[14:04] <NCommander> tell you what?
[14:04] <seb128> https://edge.launchpad.net/ubuntu/+source/gnome-vfs/1:2.24.0-1ubuntu1/+build/776352
[14:04] <NCommander> Ok, I give
[14:04] <NCommander> What am I supposed to be seeing?
[14:05] <seb128> where? on this url? that it built yesterday ;-)
[14:05] <seb128> and that the binary is listed
[14:05] <NCommander> and LP says its published
[14:05] <NCommander> Curious ....
[14:08] <seb128> NCommander: that seems to be a soyuz bug
[14:08] <cjwatson> NCommander: we're working on a similar problem with openjdk-6; I've mentioned that this is affected too
[14:09] <mvo> who is the archive-admin of the day?
[14:09] <seb128> mvo: StevenK
[14:09] <seb128> mvo: what do you need?
[14:09] <StevenK> It is?
[14:09] <StevenK> ArchiveAdministration disagrees :-P
[14:10] <seb128> StevenK: trying to chicken out now? ;-)
[14:10] <StevenK> seb128: It's 1am local, so yes.
[14:10] <StevenK> It's Friday here, pitti, la la la la
[14:10] <seb128> StevenK: I though thursday was your day, how come it's not written there? ;-)
[14:10] <\sh> soren: ping ubuntu-vm-builder...what will be installed as default user inside the guest when installing e.g. ubuntu?,-)
[14:10] <mvo> hm, I was just wondering if someone could do a bunch of syncs to cleanup the merge list a bit
[14:11]  * mvo wonders if he should apply for the job too
[14:11] <seb128> mvo: I can do syncs, I didn't do those yesterday
[14:11] <seb128> let me finish some srus first
[14:11] <mvo> seb128: that would be nice, the bugpackage of the team has a few that are also on the merges page
[14:11] <mvo> seb128: sure
[14:12] <NCommander> pitti, where are your FTBFS failure logs?
[14:13] <seb128> NCommander: those are due to libgnomevfs not being installable, don't bother
[14:13] <NCommander> ah, ok
[14:17]  * mvo wonders if anyone minds if I do the tracker merge
[14:18] <seb128> mvo: go for it
[14:19] <seb128> mvo: and please fix the bug which was fixed in hardy and has been dropped in intrepid too while doing that ;-)
[14:23] <mvo> seb128: hum, what bug is that?
[14:29] <seb128> re
[14:29] <seb128> mvo: bug #204770
[14:30] <\sh> soren: forget that...no man page for ubuntu-vm-builder but --help is very good ,-)
[14:33] <mvo> thanks seb
[14:33] <mvo> thanks seb128
[14:33] <seb128> mvo: you're welcome
[14:38] <lool> pitti: Looking at your ekiga patches (thanks!) I see:
[14:38] <lool> +       : # symlink identical Gnome help files within packages
[14:38] <lool> +       for p in $$(dh_listpackages); do \
[14:38] <lool> I wonder why the ":"
[14:47] <lool> pitti: Concerning glade, Debian #313520 and<EMAIL_ADDRESS>Debian completely dropped glade-2 / glade source (2.12), however I see the same issue is in glade-3
[14:47] <lool> Unless it's run during build, hmm
[15:03] <lool> It seems it's not
[15:31] <cjwatson> NCommander: libgnomevfs2-common (and a bunch of others) should be fixed in about 1.5 hours
[15:34] <pinchartl> hi
[15:36] <NCommander> cjwatson, wooo
[15:46] <mvo> doko: do you mind if I do the moin merge?
[15:46] <doko> mvo: not at all
[16:22] <pitti> NCommander: http://launchpadlibrarian.net/19614590/buildlog_ubuntu-jaunty-i386.ekiga_2.0.12-1%2Bnmu1ubuntu1_FAILEDTOBUILD.txt.gz
[16:22] <pitti> lool: the : is bogus, sorry
[16:23] <pitti> lool: it's just a no-op, but it doesn't need to be there
[16:23] <pitti> lool: glade-3 uses cdbs, so pot is built automatically
[16:26] <NCommander> pitti, I thought the gnome bug was resolved
[16:26] <pitti> NCommander: cjwatson said so, yes
[16:27] <pitti> NCommander: that's still the old FTBFS log from some 5 hours ago
[16:27] <NCommander> oh
[16:32] <lool> pitti: It doesn't use gnome.mk though
[16:32] <lool> pitti: But I just fixed that
[16:35] <pitti> lool: oh, sorry, it's actually done in debhelper.mk, not gnome.mk
[16:40] <lool> pitti: Ah is that new?  I see include $(_cdbs_rules_path)/langpack.mk$(_cdbs_makefile_suffix) in gnome.mk
[16:40] <lool> With cdbs 0.4.52ubuntu7
[16:40] <pitti> lool: neither is particularly new, since gutsy or so
[16:43] <lool> pitti: Hmm I see no intltool or langpack stuff in debhelper.mk
[16:43]  * lool is lost
[16:43] <pitti> /usr/share/cdbs/1/rules/debhelper.mk, lines 257..
[16:44] <lool> pitti: Oh wait, sorry, I'm discussing two things at once
[16:44] <lool> I was thinking about the langpack/intltool-update stuff
[16:44] <pitti> yes, that's in langpack.mk, included by gnome.mk and others
[16:45] <lool> Yeah, we were indeed discussing two different things; so are you saying I can drop the symlinking bits?
[16:45] <lool> I prefer having it in cdbs in Debian as well rather than duplicating that in all packages, but then cdbs maintenance has been quiet lately
[16:46] <pitti> lool: I'll send the POT and gnome help changes to Debian's cdbs bug list, but they won't be applied by lenny's release
[16:47] <lool> pitti: Ok; I'll leave it to the new ekiga maintainer then
[16:47] <lool> I wont minimize the diff by including that and it's not the goal on the long term, so it's not important to merge it now in ekiga
[16:49] <tkamppeter> pitti, I have some news about pdftoratser: See bug 294671
[16:51] <tkamppeter> pitti, a user complained about a color space problem and I asked him to use my Ghostscript-based pdftoraster instead of Intrepid's Poppler-based one. The problem went away.
[16:52] <tkamppeter> He is not using SpliX but Gutenprint. So the pdftoraster causes problems with many drivers. Perhaps we must really do an SRU of putting this pdftoraster into Intrepid.
[17:00] <spree> Hi ubuntu developers. Is CONFIG_MAGIC_SYSRQ enabled in the official release packages of the kernel?
[17:00] <spree> I want to know if the magic SysRq key works by default in ubuntu
[17:00] <cjwatson> spree: look in /boot/config-*
[17:01] <cjwatson> /boot/config-2.6.27-7-generic:CONFIG_MAGIC_SYSRQ=y
[17:08] <pitti> tkamppeter: hmkay; it should get some more testing, though
[17:10] <tkamppeter> hmkay?
[17:11] <cjwatson> "hmm, OK"
[17:11] <persia> hmkay : onomatopoeic representation of thoughtful acceptance
[17:11] <tkamppeter> pitti, so perhaps we should see for a certain time whether pdftoraster causes bug reports on Jaunty, and if not we SRU it into Intrepid for general use.
[17:13] <pitti> tkamppeter: yes
[17:13] <hyperair> jdong: bug 267922 still hasn't gotten attention
[17:16] <persia> hyperair, You might want #ubuntu-bugs, which is the main forum for bug discussion.
[17:17] <hyperair> persia: jdong asked me to ping him if there still wasn't any attention. he gave ack for sru, nobody's sponsored.
[17:18] <persia> hyperair, Ah.  I didn't have context.  This is the right place then.  Apologies.
[17:19] <hyperair> persia: no prob. there was no way you could have known without looking into the bug or digging through the logs anyway =)
[17:20] <jdong> hyperair: thanks, I'm on it.
[17:22] <hyperair> jdong: thanks
[17:23] <poningru> OMG thank you for the arm stuff I dont know who is working on that but I would LOOOVE to help
[17:23] <poningru> or ... I guess thats a canonical only thing right?
[17:24] <poningru> or can I work on that? anyone know?
[17:24] <pitti> poningru: now that it's public, everyone is welcome to help, I guess :)
[17:24] <poningru> awesome
[17:25] <poningru> will it be restricted to ubuntu-mobile?
[17:25] <pitti> poningru: AFAIK it will become a normal port, i. e. it'll build the entire archive
[17:25] <hyperair> what arm stuff?
[17:25] <pitti> whether that's sensible is a different question, of course, but lpia builds the entire archive, too
[17:26] <poningru> awesome!!!
[17:26] <poningru> hyperair, canonical and arm people have some deal going re: building ubuntu for arm arch
[17:26] <hyperair> interesting
[17:26] <persia> poningru, Probably the key bit, as with any new port, is chasing down build-failures at the start.
[17:26] <pitti> hyperair: http://arm.com/news/23761.html
[17:26] <hyperair> so is it in archive.ubuntu.com?
[17:26] <poningru> http://www.digitimes.com/news/a20081113VL204.html
[17:26] <persia> ports.ubuntu.com
[17:27] <hyperair> ah so it's not in the official archives then?
[17:27]  * hyperair breathes a sigh of relief
[17:27] <persia> hyperair, Well, it's as official as powerpc, lpia, ia64, hppa, and sparc.
[17:28] <hyperair> eh?
[17:28] <hyperair> so it will be in archive.ubuntu.com then?
[17:28] <hyperair> hmm
[17:28] <persia> None of those architectures are.  Dunno if armel will eventually get promoted.
[17:28] <hyperair> persia: sparc is
[17:29] <hyperair> for dapper at the very least
[17:29] <cjwatson> hyperair: not for current releases though
[17:29] <hyperair> and powerpc
[17:29] <poningru> http://ports.ubuntu.com/dists/intrepid/
[17:29] <persia> Oh, right.  The set of architectures on archive.ubuntu.com vs. ports.ubuntu.com is subject to change for each release.  I'm only speaking of Jaunty right now.
[17:29] <cjwatson> hyperair: ditto, not for current releases
[17:29] <hyperair> yeah
[17:29] <cjwatson> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/
[17:29] <hyperair> i would know, i maintain an archive mirror =)
[17:30] <NCommander> Its ports mirrored at all?
[17:30] <NCommander> s/Its/Is/g
[17:30] <cjwatson> NCommander: sporadically at best
[17:30]  * NCommander sighs
[17:30] <persia> Not generally, but there's no reason it couldn't be if someone was sufficiently interested.
[17:30]  * pitti tries to untangle his tongue after trying to pronounce the armel buildd names
[17:30] <hyperair> lol
[17:30] <cjwatson> pitti: all names of conifers, according to wikipedia
[17:31] <persia> pitti, The trick is to eat them first.  The astringency helps with pronunciation :)
[17:31] <poningru> rofl
[17:31]  * pitti pokes why ddebs.u.c. isn't picking up the armel ddebs
[17:32] <jdong> sigh, jdong of 10 months ago, why do you mock me?
[17:32]  * jdong upgraded pbuilder conveniently forgetting he hacked the tarball format to use lzop
[17:32] <hyperair> lol
[17:33] <LaserJock> jdong: that's what you get for all your mad-hacking
[17:33] <jdong> LaserJock: yeah all those couple seconds I saved gzipping are now wasted tracking down why input isnt in gzip format anymore ;-)
[17:42] <jdong> hyperair: tested and uploaded into intrepid-proposed
[17:42] <hyperair> jdong: thanks =)
[17:42] <jdong> no, thank you :)
[17:43] <hyperair> the bug would have stagnated if you ddn't pop in and ack as well as upload it ;)
[19:05] <fabio> sera a tutti c'è qualcuno con cui parlare??
[19:06] <ion_> Yes, everyone on the Intertubes speaks your language.
[19:08] <fabio> hi
[19:08] <fabio> i have installed eclipse on intrepi ibex
[19:09] <fabio> but i saw that he wants permission root...why??
[19:10] <fabio> idem for a program installed in opt..
[19:10] <fabio> why in intrepid now thera are this problems??
[19:11] <fabio> sorry for my bud english!!
[19:11] <hwilde> fabio,  /join #ubuntu-fr
[19:12] <ogra> hwilde, no -it ?
[19:12] <ogra> *not i mean
[19:12] <hwilde> oh is that italian
[19:12] <hwilde> looked french
[19:12] <fabio> yes i am italian!
[19:12] <hwilde> either way,   /join #ubuntu
[19:12] <ogra> i think parlare is italian :)
[19:12] <persia> !it
[19:13] <hwilde> !ot
[19:13] <persia> Well, yes, but #ubuntu is only English as well.
[19:13]  * ogra wonders if he can go on with that iteration ....
[19:13] <ogra> !at
[19:13] <ogra> bah
[19:15] <persia> ogra, If you speak !at, feel free to submit the right string :)
[19:15] <ogra> well, its largely german ...
[19:15] <ogra> i doubt there is an austrian support channel
[19:15] <persia> Wouldn't !de be more suitable for that?
[19:15]  * DktrKranz sees #ubuntu-at
[19:16] <persia> Well then, it needs a string :)
[19:16] <ogra> persia, !de wouldnt fit the scheme "!it !ot !at !et" :)
[19:16] <persia> heh
[19:16] <ogra> vowels ftw :)
[19:17] <ogra> does !et exist ?
[19:17] <ogra> !et
[19:17]  * ogra scratches head ?
[19:17] <persia> See, that's not the same thing.
[19:17] <DktrKranz> what is !et supposed to be?
[19:17] <persia> Anyway, for the real vowel win you'd need !aa
[19:18] <ogra> http://www.crowncombo.com/articles/2007/013_ETAtari/cart.jpg
[19:18] <ogra> :D
[19:18] <ogra> http://www.crowncombo.com/articles/2007/013_ETAtari/screenshot.jpg
[19:18] <ogra> et was the game atari went broke with
[19:19] <ogra> http://www.snopes.com/business/market/atari.asp ;)
[19:35] <spree> ogra: there was a video on youtube about that game, the E.T. for Atari 2600, and how it was the worst game ever made in the history of video games
[19:36] <ogra> yep
[19:37] <spree> http://www.youtube.com/watch?v=kMREImsJmuo
[19:38] <spree> the E. T. video game was so bad they recalled the game and buried it in the new mexico desert
[19:38] <spree> lol it was written in 6 weeks no wonder it was so bad
[19:55] <pwnguin> lots of games were
[19:58] <pwnguin> so what's the importance of armel in ports versus archive?
[20:02] <persia> pwnguin, Mostly just affects the preseeding on the install CDs, and the contents of sources.list for installed systems.  Also, doesn't show in rmadison.
[20:17] <Cloakey> Greetings.
[20:18] <Cloakey> I'd like to learn package maintenance.  I'm thinking whether it'd make sense for me to start over at Debian, because their sponsorship program and guidelines seem somewhat established, and I couldn't really find much on becoming a maintainer for Ubuntu.
[20:19] <sebner> !MOTU | Cloakey
[20:19] <sebner> and
[20:19] <sebner> !packaging | Cloakey
[20:21] <Cloakey> Wow, sebner, thanks.  Not a great sentiment to my Google skills.
[20:21] <sebner> heh, np
[20:21] <sebner> Cloakey: any questions about MOTU and packaging can be asked in #ubuntu-motu btw
[20:22] <Cloakey> sebner: Awesome!  Thanks.
[20:22] <jtisme> can anyone tell me if ubuntu is going to use alsa or oss in the future for sound
[20:23] <sebner> jtisme: pulseaudio ;)
[20:23] <sebner> jtisme: oss is obsolete btw
[20:23] <jtisme> seb128, ooh! thanks for in heads up
[20:23] <jtisme> sebner thanks for the heads up
[20:24] <sebner> np
[20:24] <peratu> Hi. Somebody know a solution for http://bugs.launchpad.net/ubuntu/+source/linux/+bug/291573 or http://ubuntuforums.org/showthread.php?t=968194   ?
[20:25] <liw> peratu, have you ran the cd checking option from the boot menu?
[20:26] <peratu> liw, the .iso pass the md5 test. And I have tried with the LiveCD and the Alternate CD. Both fails with same error.
[20:27] <peratu> I think that it is a problem with SATA drives... But, I haven't this problem with Ubuntu 8.04 :S
[20:27] <liw> peratu, checking the .iso does not check that the cd you have burned works; please boot into either cd, and choose the option to check the correctness of the cd
[20:28] <peratu> Ok, i'll check it, but this is not the problem, I'm sure :-)
[20:28] <pwnguin> do the ppas build on archs on ports.ubuntu.com? or just the official ones?
[20:30] <persia> sebner, Just as a note, there's lots of folks excited about the new OSS, although Ubuntu uses ALSA, and pulse on top of ALSA.
[20:32] <sebner> persia: Yeah, I've heard about OSS revival but I just want to results and I don't support Ubuntu changes to it in near future
[20:32]  * rlaager hopes for the day when Linux sound isn't a disaster.
[20:32] <persia> sebner, You suggest switching to pulseaudio.  If that happens for everything, the ALSA/OSS decision becomes moot.
[20:33] <sebner> persia: sure, but for now ALSA is a lot more around us than OSS
[20:34] <persia> sebner, Indeed.  The point is just that OSS isn't necessarily obsolete, although pulseaudio is the target for desktop sound.  Anyway, no point arguing.
[20:35] <sebner> persia: ok :) btw, any new from the MC regarding these many applications (including mine ^^)?
[20:57] <cjwatson> pwnguin: only architectures with Xen support
[20:58] <cjwatson> pwnguin: which at the moment, AFAIK, is just the x86en
[20:58] <pwnguin> is lpia xenlike?
[20:58] <cjwatson> lpia is perfectly runnable in a chroot from an i386 system ... so "yes"
[21:00] <hwilde> why would a configure script say "/usr/bin/ld: skipping incompatible ../Work/lib/libkartoMapperSDK.so when searching for -lkartoMapperSDK"
[21:00] <hwilde> what does this mean skipping incompatible :/
[21:01] <jcristau> hwilde: it means you can't link a 32bit object with a 64bit one
[21:02] <hwilde> jcristau, that is what I feared :(
[21:02] <hwilde> if I use ia32-libs does it defeat the purpose of using 64bit for more RAM ?
[21:07] <hwilde> eh ia32-libs doesn't help anyways
[21:17]  * calc hopes he doesn't kill his desktop by upgrading it to intrepid :)
[21:18]  * calc got bronchitis on his vacation :( so is sitting at home playing with ubuntu
[21:20] <fta> pochu, liferea is broken. bad MOZILLA_LIB_ROOT.
[21:20] <fta> MOZILLA_LIB_ROOT=`$PKG_CONFIG --libs-only-L $XULRUNNER_PROVIDER | awk '{print $1}' |  cut -c 3-` is wrong
[21:21] <fta> it gets the -devel path
[21:22] <pochu> fta: version/bug?
[21:22] <pochu> fta: what are the consequences of it?
[21:23] <fta> liferea_1.4.18-0ubuntu2
[21:23] <fta> it doesn't start
[21:23] <fta> fta@ix:~ $ liferea
[21:23] <fta> Abort
[21:24] <fta> the wrapper sets LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-<IP_ADDRESS>/lib which only exist when xulrunner-1.9-dev is installed, i.e. during build time
[21:25] <pochu> weird
[21:25] <pochu> I wonder why it worked for me
[21:25] <pochu> s/worked/works/ even
[21:25] <fta> $ pkg-config --libs-only-L libxul-embedding  | awk '{print $1}' |  cut -c 3-
[21:25] <fta> /usr/lib/xulrunner-devel-<IP_ADDRESS>/lib
[21:26] <fta> (in my chroot)
[21:26] <joaopinto> liferea works fine on a hardy minimal chroot
[21:26] <joaopinto> ops, i mean, intrepid
[21:27] <fta> yep, intrepid was fine, jaunty isn't
[21:27] <pochu> ah
[21:27] <pochu> phew
[21:27] <pochu> I was wondering why launchpad didn't get thousands of reports :)
[21:28] <fta> http://paste.ubuntu.com/71504/
[21:31] <fta> hard coding the result of pkg-config in a script is a bad idea
[21:32] <pochu> liferea 1.5/1.6 removes xulrunner support, btw
[21:32] <pochu> (1.6 when it's released)
[21:32] <fta> maybe but currently, it's still gecko and it's broken
[21:32] <pochu> sure
[21:33] <fta> it's easy enough to fix, drop the pkg-config call in that script and use /usr/lib/xulrunner-$(xulrunner-1.9 --gre-version)
[21:34] <pochu> fta: can you fix it? I don't have a jaunty chroot to test it yet...
[21:34] <pochu> Otherwise, I'll create one this WE and look at the bug
[21:34] <fta> sure
[21:34] <pochu> thanks :)
[21:34] <fta> pochu, do you have a branch ?
[21:42] <fta> pochu, bug 295490
[21:42] <pochu> fta: nope
[21:43] <pochu> fta: you can get it uploaded directly
[21:43] <fta> pochu, it's in main, i can't, i'm just motu
[21:44] <fta> i guess 295490 is the same bug
[21:48] <pochu> fta: sure 295490 and 295490 are the same bug :-)
[21:49] <fta> lol
[21:49] <fta> same as the one i described above
[21:51] <pochu> sure :)
[21:51] <pochu> ah, my "nope" was to your branch question :)
[22:08] <fta> pochu, should i post a debdiff on the bug and call for a sponsor or [cw]ould you do it using a the diff.gz/dsc ?
[22:09] <pochu> fta: I can't upload to main either :)
[22:09] <pochu> fta: please use the sponsors queue
[22:10] <fta> pochu, oh, I thought you were core-dev by now.
[22:11] <jwendell> hello, pochu
[22:12] <jwendell> pochu, that's why I used the term 'merge' in my email. I know that there will be many changes. Many parts of that man page is solaris specific
[22:13] <jwendell> pochu, so, feel free to use what you think it's good from it
[22:18] <pochu> jwendell: ok :) I didn't know it would need so many changes until I started reviewing it, after saying it would be better to completely replace it ;)
[22:18] <jwendell> hehe
[22:18] <pochu> jwendell: I'll do the work if Halton is fine with it
[22:19] <jwendell> pochu, it doesn't matter for him. That man page is solaris specific
[22:19] <jwendell> it's not supposed to be upstream
[22:19] <wasabi> Oh.  I'd sure like to see an official build setup for arm. That would be nice.
[22:20] <wasabi> Tired of building stuff by hand. :)
[22:20] <pochu> jwendell: oh, I thought that was proposed to be shipped upstream
[22:20] <jwendell> nope :)
[22:21] <pochu> jwendell: fine then, I'll clarify it in a mail and do it tomorrow
[22:21] <pochu> jwendell: thanks!
[22:21] <jwendell> pochu, thank you
[22:22] <fta> wasabi: i don't know how official it is but there are 4 builders at work for armel right now
[22:24] <wasabi> Hmm.
[22:24] <wasabi> Those are new, no? I don't remember seeing them.
[22:25] <fta> yep, i started to get buildlogs today
[22:25] <pochu> fta: if you have time, would be nice if you added this patch to liferea too, it adds Launchpad integration to the help menu: http://pfragoso.org/ubuntu/02_lpi
[22:25] <wasabi> Cool. Well that is super awesome. I remember talking with mark about this... what, 3 years now, at the first uds in mtv
[22:25] <wasabi> maybe 2 years? got me.
[22:25] <pochu> fta: credits to Pedro Fragoso (for the changelog entry)
[22:25] <wasabi> back then some of the nokia guys were floating the idea of rebasing their maemo distribution on ubuntu.
[22:26] <wasabi> thought it was a kick ass idea. we told them who to contact and who to push to get things going..... specifcally some builders for armel. And then never heard from them again.
[22:27] <pochu> fta: but there's no hurry for it... I can do it myself later when I do the update to the latest 1.4.x, or even to 1.5.x
[22:28]  * pochu waves good night
[22:28] <fta> pochu, the configure part of the patch is not needed as there's no version to test, d/control is enough. otherwise, it forces to regenerate autoconf.
[22:28] <fta> i mean to configure
[22:29] <fta> +regenerate
[22:29] <pochu> makes sense
[22:29] <pochu> hmm
[22:30] <pochu> will it compile fine?
[22:30] <pochu> if it does, I'm fine with it :)
[22:30] <pochu> ember_: ^
[22:30] <pochu> I'm away now, see you!
[22:39] <kees> evand: oh! you handled all the installer bits for bug 51551.  thanks!
[22:48] <calc> why is libneon27-dev in universe but libneon27 in main (that seems fubar)
[22:49] <calc> we support linking to the library but not building against it? :)
[22:52] <NIK> Hello... anybody here knows if the MOTU 896 woks on linux??
[23:07] <cjwatson> calc: funky; I don't know quite how that happened. I've promoted it back
[23:08] <slangasek> cody-somerville: why is dput in jaunty erroring out for me with a complaint about bzrlib and sftp when my config doesn't use sftp?
[23:08] <calc> cjwatson: ok
[23:14] <peratu> exit
[23:21] <cody-somerville> slangasek, is there a traceback?
[23:21] <slangasek> cody-somerville: um, there's an exception that you're throwing in sftp which immediately exits
[23:22] <slangasek> well, catching rather than throwing
[23:22] <slangasek> bug in LP shortly
[23:23] <cody-somerville> thanks
[23:24] <slangasek> bug #297851
[23:26] <slangasek> cody-somerville: ^^ and subscribed you


[07:51] <dholbach> good morning
[21:34] <Neo31> hello folks
[21:34] <Neo31> please someone point me to ubuntu global jam channels :)
[21:34] <skellat> There aren't any channels specific to Ubuntu Global Jam
[21:34] <skellat> Where are you located Neo31?
[21:36] <Neo31> we didn't organize a dedicated event this release in tunisia, there will be very few members online this time. I'm looking for other channels online to see if we can collaborate with others
[21:47]  * genii makes more coffee
[21:52] <skellat> Neo31: Check the list of teams participating here to see who you might collaborate with -- http://loco.ubuntu.com/events/global/2868/
[21:54] <Neo31> thanks skellat
[21:55] <skellat> No problem
[21:55] <shogundai> hi
[21:55] <shogundai> i'm new here
[21:58] <shogundai> please help...how to use garmin ant+


[02:49] <pitti> chrisccoulson: hey, thanks for pointing out the gconf problem!
[02:49] <pitti> chrisccoulson: fixing now
[02:49]  * pitti hugs chrisccoulson
[14:14] <kklimonda> pitti, ping
[14:16] <kklimonda> hmm, it's sunday so I can pinging him :)
[17:45] <Amaranth> compiz bugs apparently have no heat
[17:45] <Amaranth> told it to sort by heat and even the top one has no flames
[19:02] <geser> Amaranth: see bug #511382
[22:39] <pitti> kklimonda: pong (please don't send contentless pings; just ask, then I can more sensibly respond)
[22:39] <pitti> Amaranth: you have to enable the "flame menus" plugin first :)
[22:40] <kklimonda> right... do you know about this regression: http://syntaxhighlighted.com/media/regression.png after suspend&resume with nvidia?
[22:41] <kklimonda> I couldn't find it on the launchpad but decided to ask first (maybe it's not filled under nvidia driver)
[22:46] <pitti> kklimonda: no, I don't know about it; but it does look like a driver bug
[22:48] <kklimonda> ok, I'll report it then
[23:10] <chrisccoulson> hey pitti, how was your flight?
[23:10] <chrisccoulson> (thanks for sorting out the gconf issue btw)
[23:32] <Amaranth> kklimonda: go to the nvnews forums and tell nvidia about it
[23:32] <Amaranth> kklimonda: filing a bug in launchpad will basically accomplish nothing as far as getting it fixed


[02:10] <zooko> I am an administrator of a team on launchpad, and I would like to promote myself to owner and thus displace the current owner without bothering him about it/without waiting for him to do it. Is this possible?
[02:10] <zooko> Hm, I suppose I could remove him from the team...
[02:11] <zooko> But that might hurt his feelings.
[02:11] <zooko> Maybe I can remove him from the team and then put him back.
[02:11] <ajmitch> that won't change the owner of the team
[02:11] <zooko> Thus hurting and then unhurting his feelings.
[02:11] <zooko> Ah, nevermind then.
[02:12] <ajmitch> you'd need to ask #launchpad, who'd probably get you to put in a request on answers.launchpad.net/launchpad
[02:12] <ajmitch> you'd also need to justify why you could take over the team, I think
[02:15] <zooko> I'll try getting ahold of the current owner first.
[02:15] <zooko> Thanks!
[02:16] <lifeless> zooko: no, its not possible.
[02:16] <lifeless> zooko: administrators cannot privilege escalate.
[02:17] <lifeless> zooko: as ajmitch says you need an appeal to authority to do it. Either the owners, or lp support.
[02:17] <zooko> lifeless: thanks!
[03:46] <achiang> hello, can someone remind me of the sponsorship process? i've attached a patch for a FTBFS: LP: #770833
[03:47] <achiang> i now should subscribe ubuntu-sponsors (i think), but my question is more around how to properly forward to debian?
[03:47] <micahg> achiang: submittodebian in the new source dir
[03:48] <achiang> micahg: ok, thanks
[03:48] <achiang> micahg: hm, the "new" source dir? i only have an existing source directory
[03:48] <achiang> (after apt-get source <pkg>)
[03:48] <micahg> achiang: the one that you use to create the source package and subsequently the debdiff
[03:49] <achiang> micahg: ah, ok, thanks
[03:50] <achiang> micahg: for the current "cure the FTBFS plague", should i be trying to get the packages fixed in ubuntu first, or in debian first? my reading of the mail from this AM made it seem like "let's get oneiric fixed, and in parallel, forward to debian, let them fix at their own pace"
[03:50] <micahg> achiang: at this point in the cycle, oneiric first
[03:50] <broder> i think that's generally a good plan, especially at this point of the cycle
[03:50] <achiang> ok, thx
[04:12] <achiang> ah, submittodebian is quite nice, once one configures smtp correctly in reportbug. :)
[04:16] <achiang> micahg: if a package is patchless, and the fix can be trivial, is it worth adding a patch system to fix a FTBFS?
[05:03] <micahg> achiang: no, just patch the source
[05:05] <achiang> micahg: thanks
[05:05]  * achiang fixes 4 for today, but it's bed time now
[05:07] <micahg> achiang: awesome, thanks!
[06:28] <Rhonda> NCommander: Sure think, you know where the source code is? Actually it should be ready for that because I wouldn't expect it to be too much different than debports?
[07:39] <dholbach> good morning
[07:51] <micahg> http://qa.ubuntuwire.com/uehs/no_updated.html seems to be out of date, seems to be pointing to natty, can anyone check on this?
[09:28] <Laney> wgrant: ^ do you run that?
[09:29] <wgrant> Laney, micahg: Indeed. Thought I fixed that, but apparently not.
[09:29]  * wgrant fixes.
[09:52] <wgrant> Laney, micahg: Fixed and rerun.
[09:52] <Laney> cheers
[10:35]  * cjwatson wonders if he can displace james_w on http://udd.debian.org/cgi-bin/ubuntu_usertag.cgi by the end of the FTBFS-fixing project :-)
[10:51] <ricotz> debfx, hello :), do you know when virtualbox is coming with xserver 1.11 support?
[10:52] <Laney> oh, I never remember to use the usertags :(
[10:55] <debfx> ricotz: I assume you are using the xorg-edgers ppa? you'd have to ask them to put virtualbox into the ppa
[11:07] <thelinuxer> Hi, I need help verifying that my "debian/copyright" file is correct in regards to the file specs. Plz can anyone revise it ? Thankx. http://pastebin.com/2uLaFZiV
[16:17] <micahg> wgrant: awesome, thanks
[18:02] <NCommander> Rhonda: I do, but I don't know how in sync it is with Debian
[18:25] <Rhonda> NCommander: Quite. Most development happen on master branch and get merged both into debian-master and ubuntu-master
[18:26] <Rhonda> And if you are interested, I am still looking for someone who would apply the new ubuntu theme to the packages site  ;)
[18:42] <NCommander> Rhonda: I'm not much of a HTML guru or artist :-/
[18:42] <NCommander> Rhonda: that being said, if the codebases are more or less in sync with each other, it should be straightforward to add ports as Debian already has the necessary architecture to pull in d-ports.org into their codebase
[18:45] <Rhonda> Right.
[18:48] <zooko> Hello folks. Could someone volunteer to upgrade Tahoe-LAFS in Ubuntu to the latest release in order to fix a security bug?
[18:48] <zooko> If it were done, 'twere best done quickly.
[18:48] <NCommander> zooko: that sounds like somethingbest handled by the dsecurity team
[18:48] <micahg> NCommander: not for the devel release
[18:49] <zooko> Well, tahoe-lafs is community-supported, not core, so ... ?
[18:49] <micahg> zooko: I'd suggest asking Debian to upgrade and then use requestsync from ubuntu-dev-tolls
[18:49] <NCommander> zooko: does the security bug exist in previous releases of Ubuntu?
[18:49] <micahg> *ubuntu-dev-tools
[18:50] <zooko> NCommander: yes
[18:50] <zooko> micahg: I've sent email to the debian security team with GPG encryption but haven't heard back.
[18:50] <zooko> micahg: maybe I'll send another...
[18:50] <micahg> zooko: if you're asking for the latest version, that can only happen in the dev release
[18:50] <micahg> or unstable for Debian
[18:51] <jtaylor> zooko: is the bakport of the fix hard?
[18:51] <zooko> jtaylor: no, it is not.
[18:51] <zooko> jtaylor: what's your launchpad id again?
[18:51] <jtaylor> which versions are affected?
[18:51] <jtaylor> same as my nick here
[18:51] <zooko> Ah. :-)
[18:52] <zooko> jtaylor: I subscribed you to https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/848476 where you can see the patches.
[18:52] <Laney> tahoe-lafs isn't in stable so I don't see what the security team have to do
[18:52] <Laney> just get the fix into unstable and testing
[18:52] <micahg> right, it's just the maintainer uploading the latest release, then you can request a sync to Ubuntu
[18:52] <Laney> for ubuntu stable releases you need to follow the security sponsorship procedure yeah
[18:53] <Laney> micahg: can tell you all about that :-)
[18:53] <Laney> -:
[18:54]  * micahg guesses he didn't do such a good job with that last time since it was very late at night
[18:56] <zooko> So, I should write to<EMAIL_ADDRESS>again?
[18:57] <zooko> Maybe I should try<EMAIL_ADDRESS>instead.
[18:57] <micahg> zooko: no, ask the maintainer to upload the latest release with the fix
[18:57] <zooko> Ah.
[18:57] <Laney> the security team usually only gets involved for stable
[18:58] <zooko> Hey wait, *you* are listed as one of the maintainers!
[18:59] <zooko> I'll write to the other one. ;-)
[18:59] <micahg> zooko: sorry, wrong micah :)
[18:59] <jtaylor> no its a different micah
[18:59] <micahg> or rather that's micah, not micahg
[18:59] <jtaylor> I'll prepare some branches
[19:01] <zooko> micahg: oooh. :-)
[19:01] <zooko> Thanks.
[19:01] <zooko> jtaylor: sweet! Thank you!
[19:01]  * micahg looks forward to jtaylor's MOTU application
[19:02] <jtaylor> unfortunatly I've put than on hold for a while
[19:02] <jtaylor> just started a new job and don't know how much time I have
[19:02] <micahg> :(
[19:04] <micahg> jtaylor: well, whenever you're ready, good luck with the new job
[19:04] <jtaylor> thx
[19:06] <jtaylor> actually we don't really need to bother fixing tahoe in natty as its still broken
[19:07] <jtaylor> I should bug release about that at some point :/
[19:08] <micahg> jtaylor: well, is that just an rdepend that needs fixing?
[19:08] <micahg> s/rdepend/dependency/
[19:08] <jtaylor> yes but the ideal fix is to upgrade the version of that depend
[19:08] <micahg> that's a mess
[19:09] <micahg> but I guess that does make the task invalid for natty
[19:10] <Laney> not release, sru
[19:10] <jtaylor> yes meant that
[19:10] <zooko> Bah.
[19:10] <zooko> Is there something I could do to help with that?
[19:10] <micahg> jtaylor: actually, no the task should still be open...not sure about the whole thing
[19:14] <jtaylor> urg tahoes testsuite does not run
[19:15] <zooko> What's that you say.
[19:15] <jtaylor> 'module' object has no attribute 'bench_dirnode'
[19:15] <zooko> Run the test suite with "python setup.py test"
[19:16] <jtaylor> tried that
[19:16] <zooko> And is that the one with that attribute error?
[19:16] <jtaylor> yes
[19:16] <zooko> Is this with the upstream tarball or with patches?
[19:16] <zooko> Oh yes the patches change the setup.py so you should run the tests with trial instead.
[19:16] <jtaylor> ubuntu oneiric package
[19:17] <zooko> trial allmydata.test
[19:17] <zooko> But, I'm not sure if it will import a version that is installed in your system and run those tests instead of running the tests of the version in your current working directory.
[19:18] <zooko> In fact, "make test" might do the right thing...
[19:19] <zooko> Ah, no that runs python setup.py test
[19:19] <zooko> Oh, but there is "make quicktest".
[19:19] <zooko> That bypasses "python setup.py test" because it is slow to start up.
[19:19] <zooko> Fortunately that also means it will probably work even though "python setup.py test" doesn't work in that version.
[19:20] <jtaylor> all don't work
[19:20] <jtaylor> I'll try it in debian
[19:21] <jtaylor> no luck
[19:23] <zooko> What does "trial allmydata.test" do?
[19:23] <zooko> Let's see... What does "python setup.py build" do? In upstream, that builds a lot of things in ./support.
[19:23] <jtaylor> does not find allmydata.test even though I set pythonpath to pwd
[19:23] <zooko> Then you can do "PYTHONPATH=./support/lib/python2.7/site-packages trial allmydata.test"
[19:24] <zooko> It would be nice if we could get "python setup.py test" to work in the Ubuntu and Debian version...
[19:24] <jtaylor> does also not work, there is no support/.. in the tree after build
[19:25] <zooko> Okay, so that is changed too.\
[19:25] <zooko> How about PYTHONPATH=`pwd`/src trial allmydata.test
[19:25] <jtaylor> hm
[19:25] <jtaylor> there is some weird patch in the debian package
[19:26] <jtaylor> exclude_buildtest_package.patch, lets see what happens if I remove that
[19:26] <jtaylor> does not fix it
[19:28] <zooko> What happens with PYTHONPATH=`pwd`/src trial allmydata.test
[19:28] <zooko> The "allmydata" python packagedirectory is inside ./src/
[19:28] <jtaylor> a that works thx
[19:28] <zooko> Okay, good.
[19:28] <zooko> We should probably add a note to the Debian/Ubuntu packaging telling people how to run the tests.
[19:29] <jtaylor> setup.py test should get fixed
[19:29] <jtaylor> and the debian package use it during build
[19:29] <zooko> I would be willing to help with that.
[19:31] <jtaylor> is it sure no one uses the removed function?
[19:31] <zooko> jtaylor: yes
[19:32] <zooko> No one has *ever* used it, actually.
[19:32] <zooko> So it is a case of "YAGNI" which turned out to be part of a vulnerability. :-(
[19:33] <jtaylor> hurray maverick testsuite: errors=683, successes=457 :(
[19:33] <zooko> Hm.
[19:34] <jtaylor> and oneirics testsuite seems to have deadlocked
[19:34] <zooko> Is it possible that the Debian/Ubuntu patches actually cause the tests to fail?
[19:34] <zooko> That would be unfortunate.
[19:34] <zooko> Could you share the errors? Just email the whole test output to<EMAIL_ADDRESS>or pastebin some part of it...
[19:34] <jtaylor> in maverick there are no patches that change any code
[19:34] <jtaylor> only setup.cfg
[19:35] <zooko> Where can I see the patch?
[19:35] <jtaylor> oneiric is hanging in test_download_from_only_3_shares_with_good_crypttext_hash since ~ 10 minutes
[19:36] <zooko> Hm.
[19:36] <jtaylor> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/tahoe-lafs/maverick/view/head:/debian/patches/reduce_build_dependencies.patch
[19:36] <zooko> Well, please show me the test errors.
[19:36] <zooko> I don't immediately see why that reduce_build_dependencies.patch would lead to test failures.
[19:36] <jtaylor> no error displayed just hanging
[19:37] <jtaylor> let me test something with that version first
[19:37] <zooko> What about on Maverick -- there were errors there.
[19:37] <zooko> This reminds me that there was some movement on getting automated testing for Debian recently, wasn't there? That would be awesome.
[19:37] <jtaylor> yes there was some work done, dep8 I think
[19:38] <jtaylor> http://dep.debian.net/deps/dep8/
[19:38] <zooko> excellent
[19:39] <zooko> davidsarah: jtaylor volunteered to update debian/ubuntu Tahoe-LAFS v1.8.3.
[19:39] <zooko> And the test suite doesn't work!
[19:39] <zooko> I suspect that it doesn't work for the debian/ubuntu package of Tahoe-LAFS v1.8.2, either.
[19:39] <zooko> (Since nothing we've done for 1.8.3 is likely to change that behavior.)
[19:40] <zooko> davidsarah: http://codepad.org/JKdC0orz
[19:42] <jtaylor> ok it got past the deadlock test this time
[19:42] <zooko> What did you change?
[19:42] <davidsarah> oh, that's unfortunate
[19:42] <jtaylor> nothing just ran it again
[19:42] <zooko> That's the word I used.
[19:42] <zooko> "unfortunate"
[19:42] <davidsarah> I'm sure I've seen the tests pass using the Ubuntu package before now
[19:42] <jtaylor> yes me too
[19:42] <davidsarah> you have to run 'tahoe debug trial', though
[19:43] <davidsarah> so that you're using the correct installed tahoe
[19:43] <jtaylor> test ran this time on oneiric
[19:44] <zooko> What did you change on oneiric?
[19:44] <zooko> Oh, try "tahoe debug trial".
[19:44] <jtaylor> nothing
[19:44] <jtaylor> maverick rerun (in maverick instead of oneiric....): errors=7, successes=727
[19:44] <davidsarah> paste the errors?
[19:44] <jtaylor> http://paste.ubuntu.com/688581/
[19:44] <zooko> Oh yeah, I really want tahoe-lafs (and all other software I contribute to) to integrate with this: http://dep.debian.net/deps/dep8/
[19:45] <jtaylor> one of them due to a missing dep I forgot
[19:45] <davidsarah> hmm, must be an incompatibility with the installed simplejson
[19:45] <zooko> It isn't necessarily json related.
[19:46] <zooko> The error message should print out the thing that it failed to decode as json.
[19:46] <zooko> I'll bet it is an HTTP error message or something.
[19:46] <jtaylor> do the tests need internet acccess?
[19:46] <zooko> No.
[19:46] <davidsarah> what does 'python -c "import simplejson; print simplejson.__version__" say?
[19:46] <jtaylor> 2.1.1
[19:50] <jtaylor> it gets 403 Prohibited port (configure Remap-...) instead of a json
[19:50] <davidsarah> ah
[19:51] <davidsarah> I think the tests only try to listen on a kernel-assigned port, no?
[19:51] <davidsarah> i.e. "port 0"
[19:52] <jtaylor> port 57639
[19:52] <zooko> jtaylor: after this is fixed, tell me how to make tahoe-lafs work with http://dep.debian.net/deps/dep8/ . :-)
[19:53] <davidsarah> so, there's an error-reporting bug there in the CLI, we should print the thing we failed to decode
[19:54] <jtaylor> its probably unrelated to the security fix
[19:54] <jtaylor> so I'll ignore it for now
[19:55] <jtaylor> but it also affects the version in lucid
[19:56] <jtaylor> lol unexpectedSuccesses=1
[19:59] <zooko> Heh heh
[20:00] <davidsarah> what was the unexpected success?
[20:00] <jtaylor> allmydata.test.test_cli.Cp.test_unicode_filename
[20:01] <davidsarah> ah. can you paste the output so I can fix it?
[20:02] <jtaylor> there was no output only the reason
[20:03] <jtaylor> See issue ticket #534
[20:03] <davidsarah> ok, thanks
[20:04] <zooko> Hee's a patch against 1.7.1 which makes tahoe_mv tell what it got that failed to decode.
[20:04] <zooko> http://codepad.org/PVOSm0B2
[20:05] <jtaylor> ok good the patch applies with fuzz on maverick and lucid and the testsuite gives the same result
[20:05] <jtaylor>  (= same number of errors)
[20:05] <jtaylor> I guess that can be uploaded, the testsuite seems very thourough
[20:06] <zooko> Bah!
[20:06] <zooko> Errors!
[20:06] <zooko> Down with test suite errors.
[20:06] <zooko> But yeah maybe upload the safer version first then fix test suite errors.
[20:07] <jtaylor> if you come up with a fix and its worth an SRU please come back, for now only the sru is on my agenda
[20:07] <jtaylor> sru=sec-fix
[20:08] <jtaylor> the testsuite in oneiric works (although apparently not always, I'll rerun it a few times later)
[20:13] <jtaylor> zooko: when did you inform the debian maintainers?
[20:16] <Laney> devfil: do you plan on fixing fillmore-lombard?
[20:17]  * Laney has a patch that at least makes it build (for Oneiric), but you should just upgrade it in Debian
[20:17] <zooko> jtaylor: I wrote to the security team (at least to one address that I got from a debian.org web page that said it was the security team) yesterday.
[20:17] <zooko> I wrote to the maintainers -- bertagaz and micah -- today about 4 or so hours ago.
[20:17] <jtaylor> k
[20:18] <devfil> Laney: nope, I have to orphan it
[20:18] <Laney> oh
[20:19] <Laney> well please do so then, I'll probably do a QA upload at least
[20:50] <jtaylor> zooko: pushed branches for lucid maverick and natty, it would be great if you could check if they are correct
[20:51] <jtaylor> bzr branch lp:~jtaylor/ubuntu/natty/tahoe-lafs/fix-848476  in debian/patches
[20:52] <zooko> Thanks!
[20:53] <zooko> I was just wondering today what it would take to get automated import of our patches from our darcs repository into bzr.
[20:56] <jtaylor> I only know those tricks for git :/
[20:57] <zooko> Hm, how about darcs -> git -> bzr...
[20:57] <jtaylor> anyway I removed all the doc updates, they just increase the diff and make applying it to older versions harder
[20:57] <zooko> Ok.
[20:58] <zooko> How do I view your patch using bzr?
[21:00] <jtaylor> its in debian/patches
[21:01] <jtaylor> http://bazaar.launchpad.net/~jtaylor/ubuntu/lucid/tahoe-lafs/fix-848476/revision/6
[21:02] <jtaylor> ups there is still some doc diff in it
[21:12] <jtaylor> zooko: I have to leave, please try to get it fixed in debian via the maintainers and ask here to get it synced to oneiric when thats done
[21:13] <zooko> jtaylor: thanks! Will do.
[21:14] <davidsarah> jtaylor: which doc diffs did you remove precisely?
[21:14] <davidsarah> I think the diff to known_issues.rst should be kept
[21:15] <jtaylor> it does not affect the patched version so its no known issue
[21:15] <davidsarah> (known_issues.rst hasn't changed very much since 1.6.1, so it should be easy to apply to older versions)
[21:15] <davidsarah> hmm
[21:15] <jtaylor> CREDITS, NEWS , docs/garbage-collection.rst, docs/quickstart.html,  relnotes.txt, docs/known_issues.rst
[21:16] <davidsarah> docs/quickstart.html will point to a .zip of an unpatched release, in that case
[21:16] <davidsarah> I'm not seeing why doc changes are difficult to backport
[21:17] <davidsarah> surely they're the easiest things to backport, since you can't get it wrong in the sense of breaking code
[21:17] <jtaylor> they aren't I just didn't care fixing them all up to match the correct versions
[21:18] <jtaylor> the link in quickstart points to an old version in all packages, maybe you should put some latest link in that folder and point quickstart to that
[21:18] <jtaylor> or just point to the folder and let the user figure that out themself
[21:18] <davidsarah> but that leaves the package with incorrect documentation :-(
[21:19] <jtaylor> yes that could be fixed, but I doubt many read that without checking if what is linked there is really the newest
[21:19] <jtaylor> the reason for people following the link is to get the newest because the package is too old
[21:20] <davidsarah> it's not just quickstart; the docs in each version are supposed to document *that version*
[21:20] <jtaylor> yes so a naive backport is wrong
[21:20] <jtaylor> they hen document the wrong version
[21:20] <jtaylor> the only difference is the sec backport which is documented in changelog.Debian
[21:21]  * davidsarah feels as though we are talking at cross-purposes
[21:21] <jtaylor> lucid has 1.6, you can't patch the doc to at once talk about 1.8 in some parts
[21:22] <davidsarah> take the change in garbage-collection.rst, for example. if you don't backport that change, then the doc is incorrect because it says that you can cancel leases, when you can't in the patched version
[21:23] <davidsarah> in the case of quickstart.html, that says what the latest stable upstream version was at the time of the release you're looking at
[21:23] <jtaylor> yes that I should ahve left in
[21:24] <jtaylor> I'll not patch quistart as it will be outdated on 1.9 release again anyway ...
[21:24] <davidsarah> the change to CREDITS is not important
[21:25] <davidsarah> but it makes sense to change NEWS so that it describes the version you're looking at
[21:25] <davidsarah> isn't that the normal policy for changelogs (which is what NEWS is) in security releases?
[21:26] <davidsarah> similarly, relnotes.rst describes the current version, so to have it describe some different version is just wrong
[21:27] <jtaylor> news describes what upstream says, changelog.Debian describes what is different
[21:27] <jtaylor> or README.Debian
[21:28] <Laney> why is it a problem to update the documentation? because you're not making all of the changes therein?
[21:28] <jtaylor> because I'm lazy
[21:28] <davidsarah> I guess I have some pretty strong philosophical disagreements with some of the Debian/Ubuntu packaging policies
[21:28] <Laney> erm, this isn't a policy
[21:28] <davidsarah> Laney: true, in this case
[21:29] <davidsarah> more generally I think debian/ubuntu packages are unnecessarily different from upstream in many cases
[21:29] <davidsarah> which increases the support burden
[21:31] <Laney> yeah, that's unfortunate -maintainers shouldn't be making unnecessary changes (patches should be forwarded back)
[21:31] <Laney> (debian social contract #2)
[21:32] <davidsarah> perhaps I should have said "practices" rather than "policies" (the policies certainly allow you to produce a package that is very close to upstream)
[21:34] <Laney> but I doubt it's the intention of any maintainer to cause upstreams more work, and a little bit of communication can often resolve problems
[21:34] <Laney> "your patch foo-bar is changing behaviour and causing x y z effects, plz kill it"
[21:35] <jtaylor> davidsarah: updated garbage-collection docs
[21:36] <jtaylor> please update the link in qickstart to something more distribution friendly or bug the debian maintainers about patching it
[21:37] <davidsarah> ok, I'll open a ticket for that
[21:39] <jtaylor> just linking to http://tahoe-lafs.org/source/tahoe-lafs/releases/ should be enough
[21:39] <jtaylor> anyone able to use tahoe hould be able to find the latest version himself
[21:40] <davidsarah> there's a usability issue of needing to wade through a directory listing and possibly getting the wrong file...
[21:41] <davidsarah> but that's something we can discuss on the ticket
[21:41] <jtaylor> better than having a link to an outdated version there
[21:42] <davidsarah> I agree, but possibly better still would be to have a stable URL that points to the zipfile for the latest release
[21:42] <Laney> symlink?
[21:42] <Laney> / redirect
[21:42] <davidsarah> that's just an implementation detail
[21:43] <Laney> I mean that I don't see why it's a problem at all
[21:43] <davidsarah> it isn't, but our practice is to discuss these things on tickets
[21:44] <Laney> righto
[23:53] <NCommander> Rhonda: poking the packages.git the config files are MIA


[06:13] <ducasse> morning all
[09:46] <EriC^^> afternoon all
[09:49] <ducasse> hi EriC^^
[09:50] <EriC^^> hi ducasse how are you?
[09:50] <ducasse> good thanks. you?
[10:30] <BluesKaj> Hiyas all
[10:31] <ducasse> hi BluesKaj, did you get the new gpu working?
[10:34] <BluesKaj> Hi ducasse, yes, it's working great
[10:35] <ducasse> good :) which driver are you using?
[10:52] <BluesKaj> ducasse, nvidia-340
[10:53] <BluesKaj> it's the same gpu as previous card, it just has more memory and is supposed to run much cooler , which it does
[10:55] <BluesKaj> 50-55C during idle vs 75-80C with the previous
[10:55] <ducasse> again, good. so you can actually transfer files now? :)
[15:26] <baizon> wow, im trying to set up a smb share for 2 hours now
[15:26] <baizon> that sucks :/
[15:29] <ducasse> oh, samba is *so* much fun...
[15:31] <lotuspsychje> good evening to all
[15:31] <lotuspsychje> sysinfo the beast to us baizon :p
[15:32] <baizon> hi lotuspsychje
[15:32] <baizon> no new cpu im sorry :(
[15:32] <baizon> monday :(
[15:33] <baizon> or tuesday
[15:33] <lotuspsychje> kk
[15:33] <lotuspsychje> baizon: one day mate :p
[15:33] <baizon> Livraison estimée le 9 mai
[15:33] <lotuspsychje> ah oui
[15:36] <baizon> god damn it
[15:36] <baizon> this stupid smb
[15:36] <baizon> i cant connect
[15:36] <lotuspsychje> whats going on baizon
[15:37] <baizon> cant connect to my smb share
[15:37] <baizon> it asks for a username and password
[15:37] <baizon> but i havent created one
[15:37] <lotuspsychje> baizon: isnt there like a default l:p or so?
[15:37] <lotuspsychje> admin:1234 ?
[15:38] <baizon> nope
[15:38] <lotuspsychje> hmm
[15:38] <ducasse> baizon: set one up with smbpasswd?
[15:39] <lotuspsychje> !info smbpasswd
[15:39] <ubot5`> Package smbpasswd does not exist in xenial
[15:40] <ducasse> !find smbpasswd
[15:40] <ubot5`> Found: python-smbpasswd
[15:40] <ducasse> it's in samba-common-bin
[15:51] <baizon> ive created a share without a password but got a password window
[16:26] <lotuspsychje> bbl guys
[16:27] <baizon> its working! :D
[16:27] <baizon> i hate samba so much
[18:08] <immu> hi ducasse
[18:08] <immu> lordievader, hi
[19:51] <Bashing-om> !esb
[19:51] <Bashing-om> What is the new trigger for 12.104 extended support ?
[19:55] <ducasse> !esm
[19:55] <ubot5`> Canonical offers paid extended security support for 12.04 through the Ubuntu Advantage program. For more information, see https://ubuntu.com/esm . ESM is not an Ubuntu community offering; please direct questions about it to Canonical directly.
[19:55] <ducasse> hah! got it on the first guess :)
[19:56] <Bashing-om> Naw .. ya just good is all ducasse :)