[00:00] <directhex> meebey's got a 5 meg reduction sat in SVN. we'll roll it out before alpha 3
[00:01] <dcushman> How can a *NIX n00b developer with 20+ years of professional software development get up to speed and make a useful contribution?
[00:02] <directhex> dcushman, start by moving to #ubuntu-motu, which is the more beginner-oriented place to be
[00:02] <BUGabundo> !daily | directhex:
[00:02] <directhex> BUGabundo, i'm not rushing for the sake of dailies, not this early in the cycle
[00:02] <BUGabundo> directhex: won't those changes be there?
[00:02] <BUGabundo> ah ok
[00:24] <slangasek> superm1: mythbuntu-desktop Recommends: dvb-utils, which is NBS; I guess it should now Recommend: dvb-apps instead?
[00:51] <superm1> slangasek, i'll take a look and see
[00:54] <superm1> yeah that looks right. i'll make the changes
[02:47] <mib_hjyq55hr> heeeeeeeey
[02:47] <mib_hjyq55hr> can anybody help me ?
[02:49] <nellery> !ask
[02:49] <nellery> mib_hjyq55hr: ^^
[02:50] <mib_hjyq55hr> i cant see mikrotik os router Login page on firefox although it appear in vista
[02:50] <mib_hjyq55hr> r	i cant see mikrotik os router Login page on firefox in ubuntu  although it appear in vista
[03:00] <borrell> please ask in #ubuntu, thats the general support channel ;)
[06:49] <dholbach> good morning!
[07:01] <pitti> Good morning
[07:02] <ttx> Good morning :)
[07:02] <pitti> slangasek: /usr/share/doc/udev-extras/README.keymap.txt has debugging instructions and also shows how to use /lib/udev/keymap input/eventX to print the current map
[07:03] <oespirit> Can somebody help me out with this issue: https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654 ? I did an upgrade and my system wont boot anymore. I know this isnt the right channel, but noone in #ubuntu has a clue. Kees helped out many users in that thread on the lp link, but for me that option doesnt work, because cpio doesnt 'recognise' anything in /bin/*
[07:12] <TheMuso> Morning pitti.
[07:16] <slangasek> pitti: aaaah, thanks; that should go in Hotkeys/Troubleshooting, for sure
[07:23] <pitti> slangasek: yes, updating the wiki is on my TODO list
[07:23] <slangasek> \o/
[07:49] <jp_> auto-identify
[07:51] <jp_> hello all
[08:18] <pitti> TheMuso: next time, can you please use "build1" for fake syncs, so that it'll autosync automatically on the next upstream version?
[08:35] <ttx> doko: about bug 384739, let me know if it makes sense and I'll prepare an update
[08:38] <doko> ttx: no, updated the bug report
[08:39] <ttx> doko: works for me, thanks
[09:00] <mneptok> slangasek: if you just got the sensation that someone walked across your grave in the future ... i have landed in PDX.
[09:29] <ppawel> hey folks
[09:29] <ppawel> when was upstart dbus service added to ubuntu/upstart ?
[09:30] <ppawel> in latest ubuntu I only have upstart 0.3.9
[09:30] <ppawel> does it have dbus api exposed?
[09:35] <cjwatson> james_w: https://wiki.ubuntu.com/DistributedDevelopment/ImproveDebianImportSpecification says "The Debian Vcs-* headers are not present for every package, and even when they are not there they may be incorrect" - shouldn't that be "even when they are there"?
[09:36] <cjwatson> james_w: we should totally have a standard "Non-assumptions" section in specs ;-)
[09:47] <james_w> cjwatson: good catch
[09:47] <seb128> hum
[09:48] <seb128> why did I got 11 emails about lp:ubuntu/karmic/cairo etc on cairo bugs which are closed?
[09:48] <seb128> ie bug #211791
[09:49] <cjwatson> because somebody decided to push the branch to the ubuntu/karmic/ namespace
[09:49] <seb128> james_w, ^ is that due to some work of yours?
[09:49] <james_w> seb128: it is
[09:49] <seb128> hum
[09:49] <seb128> that seems buggy to me
[09:49] <james_w> we're looking in to it
[09:49] <seb128> which should it spam me about sponsoring request bugs closed for years?
[09:50] <seb128> thanks
[09:50] <cjwatson> it's because it has bug links and LP tells you about new ones :-/
[09:50] <seb128> define "new"?
[09:50] <cjwatson> in the "link between this bug and this branch was not previously in the database" sense
[09:51] <seb128> right now it's updating everybody bug listed in the changelog since warty?
[09:51] <seb128> everybody -> every
[09:51] <james_w> just sending them on bugs which still have a task open would be a good start
[09:51] <seb128> right
[09:51] <seb128> do you have a lp bug open about that that I can track?
[09:51] <james_w> not every bug, but quite a lot of them
[09:51] <james_w> no, I need to write one
[09:52] <seb128> ok, let me know if you open a bug, thanks
[09:56] <dholbach> pitti: do you know if there's any plans to get libchamplain* into ubuntu (maybe even main) this cycle?
[09:57] <pitti> dholbach: no idea what this is; if someone files an MIR, we'll review it
[09:57] <james_w> bug 387731
[09:57] <james_w> oh
[09:57] <james_w> dholbach: I thought it was already in universe
[09:58] <dholbach> james_w: you're right
[09:58] <dholbach> excusez-moi
[09:59] <dholbach> pitti_: http://projects.gnome.org/libchamplain/ - AFAIK eog and empathy can already be built with it (http://blog.pierlux.com/2009/06/15/geolocation-in-empathy-now-real/en/ for example)
[10:00] <pitti_> oh, geolocation? sweet
[10:01] <cjwatson> I don't see geolocation there, it's just map display?
[10:02] <geser> how often are MIRs looked at/processed?
[10:04] <pitti_> geser: irregularly, it helps to ping team members if something is urgent
[10:04] <pitti_> (please not me, I already did some 3 hours of MIR review in the last week)
[10:05] <geser> it's not urgent, so I'll wait
[10:07] <liw> does karmic have a known problem automatically mounting usb sticks?
[10:07] <borrell> yep
[10:08] <borrell> one sec
[10:08] <borrell> LP 376786
[10:09] <liw> thanks
[10:34] <maxb> huh, I have a different problem, it thinks my usb-sticks are internal drives, but otherwise works fine
[10:37] <mdz> mvo: lately, it seems like whenever I run apt-get dist-upgrade, I find myself going back and doing ionice -c3 on the dpkg and apt-get processes so that it doesn't bog my system down
[10:37] <mdz> mvo: I wonder if it would be useful to have a config option for that?
[10:37] <mvo> mdz: I can add a option for that
[10:38] <mdz> mvo: do you have the same experience?  I find that with modern kernels, interactive processes are severely affected by dpkg
[10:38] <mdz> I'm not sure it was always this way
[10:39] <pitti_> my system becomes very sluggish when there's even just a moderate amount of I/O, too
[10:40] <mvo> mdz: I have a similar experience - I don't ionice, I switch to my other computer and wait for it to finish :) I like the idea, I add it right away (should be easy)
[10:41] <mdz> mvo: no hurry :-)
[10:46] <ogra> pitti_, mdz, did you guys watch your RAM usage in case of sluggish I/O ? i noticed that my swap is often fully used (even though there is only xchat and a terminal open) if such a massive slowdown occurs ... i'm still trying to find out why though
[10:47] <pitti_> ogra: it became much better when I plugged in a second GB
[10:47] <pitti_> my HD is painfully slow, thus more ram helps a lot
[10:47] <ogra> well, i have 3GB RAM ... and 4G swap
[10:47] <mdz> ogra: no, I haven't noticed excessive swap usage at those times
[10:47] <mdz> I did see a lot of swap being used on my laptop this morning, which is new, but nothing to do with apt
[10:47] <ogra> after some days without reboot i notice my swap is fully used while the system only uses 100M of ram
[10:48] <pitti_> seb128 mentioned a major memleak on his intel 965
[10:48] <mdz> the system I'm on right now has only 1.5G of RAM and has only used tiny amounts of swap
[10:48] <lifeless> mine on my desktop leaks gigs
[10:48] <mdz> pitti_: that would explain it, my laptop is 865
[10:48] <mdz> er, 965
[10:48] <ogra> mdz, no, i'm not blamig apt here, the apt and I/O slowness just seems to be a sideeffect
[10:48] <pitti_> doesn't seem to happen on 945
[10:48] <ogra> ah, 965 here too
[10:49] <pitti_> lifeless: 965, too?
[10:49] <lifeless> pitti_: EFAILINGMEMORY
[10:49] <lifeless> my desktop is nvidida. And leaks gigs.
[10:49] <ogra> lspci ;)
[10:49] <lifeless> ogra: nah, just late enough I shouldn't be on IRC.
[10:49] <ogra> heh, go to bed then :)
[10:53] <wgrant> -intel seems to leak terribly at the moment - but it leaks GEM objects, so the used memory only manifests itself as other stuff eating into swap.
[10:54] <ogra> well, the fun stuff is that even if i kill everything the swap wont be freed
[10:55] <wgrant> ogra: You should be able to fix it by killing X, but you might have to swapoff to actually get the stuff out of swap.
[11:42] <RAOF> Why does my laptop have a monotonically increasing swap usage?  And... oh.  Backscroll.
[11:42] <RAOF> Gah.  Intel.
[11:44]  * soren is trying the desktop installer for the first time in years.
[11:44] <soren> Looks nice.
[11:45] <RAOF> Yes, it does.  Faster than the alternate CD, too.
[11:46]  * soren wouldn't know
[11:46] <soren> It's *lots* slower than the server install :)
[11:46] <RAOF> Really?
[11:46]  * soren can do 18 server installs in 25 minutes.
[11:47] <RAOF> Lately I've been doing nothing but netinst, myself.  None of this outdated cdimage crap :)
[11:47] <soren> Yeah, that's what I usually do.
[11:47] <soren> Unfortunately, the only way to get this box on the network was using the desktop cd apparantly.
[11:49] <RAOF> That's... odd.
[11:49] <RAOF> You don't have a 50" cat5 cable handy? :)
[11:52] <soren> Ethernet didn't work.
[11:52] <soren> Wifi did.
[11:52] <soren> Go figure.
[11:53] <soren> The box is 12cm (~5 inches) from my local mirror, actually :)
[11:53] <soren> No need for 50" cables (which by the way are a bad idea).
[11:53] <soren> Er..
[11:54] <soren> No, they're not. I'm an idiot.
[11:55] <RAOF> Difference between 50m and 50ft?
[11:55] <lifeless> 50m should be fine, if of the right type for your switch
[11:59] <soren> RAOF: No, really. I'm an idiot :)
[11:59] <soren> RAOF: I was waaaay off.
[11:59] <soren> RAOF: Ethernet cables shouldn't be longer than 92m, IIRC.
[12:00] <RAOF> I knew there was some maximum length, but I've never had a cable remotely long enough to trigger it.
[12:01]  * soren has a ~50m cable running from his office to a shed in his garden (i.e. "the server room")
[12:02] <soren> That's the longest I have (and have had).
[12:02] <wgrant> Isn't the limit actually 100m, with 92m suggested to allow for patch cables at both ends?
[12:03] <soren> wgrant: I'm not sure. I've never done the math.
[12:04] <soren> wgrant: Somehow 100m strikes me as odd. Why would it be such a neat, round number?
[12:05] <RAOF> Because people like engineering to neat, round numbers?
[12:09]  * wgrant leaves it for the hardware people.
[12:09] <pitti> why do I suddenly get tons of "branch linked" mails? is that due to james_w's imports?
[12:09] <pitti> ** Branch linked: lp:ubuntu/karmic/consolekit
[12:09] <pitti> looks like it, anyway
[12:09] <wgrant> pitti: Yep. Bug #387731
[12:09]  * ogra noticed that too
[12:10] <pitti> thanks
[12:11] <macvr> hi all... i did an inplace upgrade of the ext3 drive to ext4... but i'v noticed considerable drop in system performance... so inorder to refresh the ext3 files as ext4 would a reinstall of the packages do the trick or has anyone tried e4defrag? i do understand this isnt the help channel but was hoping to find someone with knowledge about this...
[12:17] <geser> soren: 100m is correct, see http://standards.ieee.org/getieee802/download/802.3-2005_section2.pdf the table on page 280
[12:19] <soren> geser: I'm not really in the mood to read the legalese required to download that pdf.. Is the table that just lists the maximum lengths for different types of cable or does it explain how those numbers came about?
[12:26] <geser> soren: it mentions that the max length is limited by the signal transmission characteristics for the specific cable. I guess there is a section describing this characteristics
[12:26] <soren> Ah, so they designed the cable specs to hit 100m? I guess that almost makes sense.
[13:08] <lamont> so... firefox starts to render a page, I shift focus off to another window, and then firefox finally finishes rendering the page and hijacks focus from where I'm now doing stuff (having finished with the page)...  is that just config, or do I fire a bug at firefox?
[13:09] <StevenK> lamont: Tasty!
[13:09] <lamont> StevenK: no, not so much.  dear gnome QUIT THINKING YOU KNOW WHERE I WANT FOCUS, DAMMIT
[13:10] <lamont> and worse, it's the app, not metacity
[13:10] <soren> lamont: I used to see that a lot, but I don't remember seeing it for a while. Is this Jaunty?
[13:10] <lamont> er, um, hardy on the machine in question (iz server that happens to have desktop love too)
[13:11] <lamont> though I'm near certain I've seen it on the jaunty box too
[13:11] <Pik0r> I just developed my own small binary application (I don't want to provide the source code yet). is checkinstall the way to go when creating cross-linux installation files I can offer for download? or does checkinstall include the source code?
[13:11] <StevenK> Pik0r: checkinstall is never, ever the way
[13:11] <Pik0r> StevenK: why not?
[13:12] <StevenK> Pik0r: Because checkinstall is effectively crack cut with arsenic and washing powder.
[13:13] <Pik0r> StevenK: do you have a more technical, understandable answer why I shouldn't use checkinstall?
[13:14] <RainCT> pitti, seb128: Any chance to get bug #386035 fixed in Jaunty?
[13:15] <seb128> RainCT: we could if it's considered important for users but we didn't get such indications so far about it
[13:15] <StevenK> Pik0r: It does not do dependancy resolution correctly, does not support upgrades, and it's generally better to provide a .deb for users of Debian/Ubuntu
[13:16] <Pik0r> StevenK: so the best thing would be to write my own little scripts which generate .deb and .rpm files separately and run them each time I want to create a new package?
[13:17] <StevenK> Pik0r: I'd suggest a .spec file for rpm packaging and a debian/ directory for .deb packaging.
[13:17] <Pik0r> alright thank you, StevenK.
[13:19] <cjwatson> Keybuk: regarding the foundations-karmic-swapfile spec, I was wondering if you'd put any thought into appropriate defaults for the swap file size; the spec handwaves over this a bit, I think :-)
[13:20] <cjwatson> Keybuk: there seems to be a tension between allocating excessive amounts of swap for people with plenty of RAM who never hibernate, and offering enough space for hibernation for those who want it
[13:20] <cjwatson> Keybuk: should we just allocate size-of-RAM and punt to a System -> Administration tool for fine control?
[13:26] <RainCT> (sorry, lost the wlan connection, if you said something I didn't get it :/)
[13:28] <jpds> RainCT: < seb256> RainCT: we could if it's considered important for users but we didn't get such indications so far about it
[13:29] <RainCT> >> (I don't know of it causing a problem with any program available in the repos, but we want to use this in Zeitgeist and the workaround is quite ugly so I wanted to try if we can get the fix pushed everywhere :P)
[13:29] <pitti> RainCT: doesn't look like a major bug to me?
[13:30] <RainCT> (anyway, I have a PPA with the fix so we can live without it)
[13:30] <seb128> RainCT: jaunty users will not run zeitgeist or if they do they will get it from a ppa which can get the fixed pygobject too
[13:30] <RainCT> pitti: The affected function is unusable
[13:31] <RainCT> Okay. Just wanted to ask :)
[14:01] <Keybuk> cjwatson: I don't think there's any sane default except the current default for swap partitions
[14:01] <Keybuk> I'm not convinced by the "I have hoojabytes of RAM, I don't need swap" argument
[14:01] <Keybuk> especially since I've got evidence Linux really doesn't cope in that situation :p
[14:01] <Keybuk> put hoojabytes of RAM in your PC
[14:02] <Keybuk> fill the page cache (untar some kernel images)
[14:02] <cjwatson> Keybuk: unfortunately we don't actually really have a current default :)
[14:02] <Keybuk> then start firefox
[14:02] <cjwatson> Keybuk: we have a set of heuristics
[14:02] <Keybuk> and watch your system performance go away for a while
[14:02] <cjwatson> which are vague and dependent on disk and RAM
[14:03] <cjwatson> in particular, the default size for swap is computed while setting automatic partition sizes
[14:03] <cjwatson> I'm not quite sure how that would work when swap creation is moved out of automatic partition computation
[14:03] <Keybuk> those heuristics should be still fine, no?
[14:03] <joaopinto> what's wrong with the old 2xRAM rule :) ?
[14:04] <cjwatson> our partitioner has never implemented a 2xRAM rule
[14:05] <cjwatson> I've changed partman-auto to support size declarations like "2500+100%" (= 2500MB + 100% of RAM)
[14:05] <cjwatson> but those are always balanced against other partition sizes in the recipe
[14:06] <cjwatson> i.e. you don't give partman-auto a size, you give it minimum and maximum sizes and a weighting
[14:06] <ivoks> 2xram was ok until ram went over 1024MB
[14:06] <Keybuk> ivoks: why?
[14:06] <Keybuk> disk space when over 1TB at roughly the same time ;)
[14:07] <joaopinto> ivoks, why is it not ok on that condition ?
[14:07] <ivoks> but it's just wasting space :)
[14:07] <Keybuk> ivoks: no it's not
[14:08] <cjwatson> so this sort of debate is exactly why partman-auto weights things, so that if disk *is* short for some reason then it can adjust sizes as need be
[14:08] <cjwatson> (frex you might have lots of RAM but be installing Ubuntu in a relatively small part of your disk that also has Windows on it
[14:08] <cjwatson> )
[14:08] <Keybuk> cjwatson: exactly, which is why I think we should just retain whatever algorithm or heuristic we have today
[14:08] <cjwatson> as I say that doesn't work terribly well once swap is no longer a partition
[14:09] <Keybuk> that's an implementation issue with your code ;)
[14:09] <cjwatson> I can't think how to retain it easily, although I'm willing to keep trying
[14:09] <cjwatson> I acknowledge that it is an implementation issue
[14:09] <cjwatson> that doesn't make it go away, sadly :)
[14:09] <Keybuk> well, at some point you must have <size of space available to Ubuntu>
[14:09] <Keybuk> and divide that into <size of space for disk> and <size of space for swap>
[14:09] <Keybuk> ?
[14:10] <cjwatson> according to a partitioning recipe that might well be considerably more complicated than that (and often is for people customising Ubuntu)
[14:10] <Keybuk> right
[14:10] <Keybuk> so instead of making a partition with the number, you just make a file
[14:11] <cjwatson> what, you're suggesting having a file declared in the recipe?
[14:11] <Keybuk> sure
[14:11] <Keybuk> it's a file that ends up in /etc/fstab after all
[14:11] <cjwatson> I suppose that might work but is probably no less effort :-)
[14:11] <Keybuk> and I suspect you write fstab from that bit of code as well
[14:11] <cjwatson> I'd been hoping to avoid that
[14:11] <cjwatson> sort of
[14:11] <Keybuk> of course, implementing file partitioning would allow you to do all sorts of things in the future
[14:11] <cjwatson> basically the recipe format is not very flexible right now and in particular has problems with the concept of nested devices
[14:11] <Keybuk> like encrypted files mounted somewhere and suchlike
[14:12] <cjwatson> well, we have a hacky approach to loop-mounts for wubi
[14:12] <cjwatson> but it isn't embedded in the same recipe format :(
[14:12] <cjwatson> it all needs to be reworked ...
[14:13] <cjwatson> I suppose we could do something like
[14:14] <cjwatson> 96 512 300% linux-swap method{ swap } format{ } file_name{ /swapfile } on_mountpoint{ / } .
[14:15] <cjwatson> and when creating partitions we add together the sizes for everything with matching on_mountpoint
[14:16] <TheMuso> pitti: The original tarballs are different, due to ubuntu moving to the new upstream version before Debian, and upstream using bz2 tarballs. Once Debian has a newer orig tarball, things will be synced.
[14:17] <pitti> TheMuso: right, I understand; just suggesting to call them build1, so that they'll get autosynced
[14:17] <pitti> TheMuso: just a nitpick, don't worry
[14:18] <TheMuso> pitti: Fair enough, point taken.
[14:18] <pitti> TheMuso: BTW, isn't it in the middle of the night for you?
[14:38] <RobertF> Hello
[14:40] <RobertF> Where can I ask a question about Ubuntu 9.10 (alpha2)?.
[14:40] <Pici> RobertF: #ubuntu+1
[15:22] <robbiew> whois pere
[15:22] <robbiew> whoops :P
[15:24] <mdz> Jun 16 10:35:47 mizar kernel: [1292114.416048] end_request: I/O error, dev fd0, sector 0
[15:24] <mdz> I wonder which process triggered that...
[15:28] <Pik0r> do you include MIT-licensed software in your repositories, too?
[15:28] <Pik0r> or only GPL'd?
[15:28] <pochu> MIT is fine
[15:30] <directhex> Pik0r, any license meeting the ubuntu free software guidelines, which are like the debian free software guidelines with with a less hard-line approach
[15:31] <hyperair> directhex: less hard-line approach how?
[15:32] <directhex> hyperair, afaik non-used non-free stuff in source tarballs can be gotten away with. but is frowned upon due to lack of synability
[15:33] <hyperair> directhex: i see. synability?
[15:34] <directhex> syncability
[15:36] <Pik0r> directhex: any place where I can read up on the  ubuntu free software guidelines? I searched google and the only thing I can find are the debian ones.
[15:36] <hyperair> ah
[15:36] <cjwatson> the main (possibly even only) difference between the DFSG and our guidelines is that we're more lax about non-code material
[15:36] <cjwatson> Pik0r: http://www.ubuntu.com/community/ubuntustory/licensing
[15:37] <cjwatson> Pik0r: it's also in the Ubuntu Policy Manual: http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/
[15:38] <Pik0r> thank you. flying over it, it looks like even closed source software is fine, as long as it can be freely distributed. is this assumption correct?
[15:38] <Pik0r> (would be placed in restricted then)
[15:39] <directhex> Pik0r, restricted or multiverse, yes
[15:39] <hyperair> i think you can ship stuff like that in debian under non-free
[15:39] <Laney> really?
[15:40] <hyperair> is it not?
[15:40] <Pik0r> any how is decided whether to include a closed/open source program or not? clearly you cannot include all software there is.
[15:40] <Pik0r> is this based on popularity?
[15:40] <Laney> I guess binary drivers
[15:41] <hyperair> Pik0r: popularity, and if you can package it.
[15:41] <Laney> Pik0r: Someone willing to maintain it
[15:42] <Laney> Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists).
[15:44] <cjwatson> Pik0r: restricted is only for non-free drivers
[15:44] <cjwatson> Pik0r: Mark has given us very clear guidance that non-free applications are not to be supported by Ubuntu
[15:44] <cjwatson> i.e. not in restricted and certainly not in main
[15:47] <seb128> cjwatson: do you know what 003_gdk.pc_privates does exactly in gtk?
[15:47] <seb128> cjwatson: I think you had installer issue when it was not used correctly previous cycle
[15:47] <seb128> I'm wondering if that's still required
[15:55] <mdz> aha
[15:55] <mdz> root      6987  0.0  0.0   3544  1024 ?        S    10:34   0:00 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled
[15:55] <mdz> root     29159  0.0  0.0   5724   760 ?        S    15:42   0:00 devkit-disks-daemon: polling /dev/sr0 /dev/sr1 /dev/fd0
[16:06] <pitti> mdz: bug 384469 ?
[16:07] <mdz> pitti: indeed, thanks
[16:15] <al-maisan> hmm .. building zsh on lpia fails due to the non-availability of libcap2-dev (http://launchpadlibrarian.net/27991987/buildlog_ubuntu-karmic-lpia.zsh_4.3.10-2ubuntu1_MANUALDEPWAIT.txt.gz)
[16:15] <al-maisan> how is something like this resolved?
[16:18] <dholbach> al-maisan: seems like the last upload of libcap2 failed on lpia: https://edge.launchpad.net/ubuntu/karmic/+source/libcap2/1:2.16-5
[16:18] <dholbach> http://launchpadlibrarian.net/27714759/buildlog_ubuntu-karmic-lpia.libcap2_1%3A2.16-5_FAILEDTOBUILD.txt.gz
[16:18] <superm1> slangasek, can you re-enable mythbuntu dailies?
[16:19] <al-maisan> dholbach: thanks for the info.
[16:25] <dholbach> al-maisan: TBH no idea why it breaks
[16:25] <directhex> congrats stgraber
[16:26] <al-maisan> yeah .. I had a brief look as well .. it looks like the /usr/include/asm/sigcontext.h file is broken ..
[16:26] <persia> al-maisan, Don't fuss about lpia failures.  Once the spec gets written up, lpia will get lots less well supported.
[16:27] <al-maisan> persia: good to know, thanks :)
[16:29] <cjwatson> seb128: the breakage was that the gtk directfb udeb was linked against cairo-xlib
[16:29] <cjwatson> which is incorrect
[16:30] <cjwatson> seb128: oh, or it may have been that other things built against gtk/gdk directfb linked against cairo-xlib - actually I think that's what it was
[16:30] <cjwatson> seb128: so build gtk, build cdebconf against new gtk, see what the linkage of stuff in cdebconf-gtk-udeb is
[16:30] <seb128> ok thanks
[16:30] <seb128> I think it's fixed in the new version
[16:31] <seb128> they build against cairo-$backend now
[16:31] <seb128> ie gtk-directfb depends on cairo-directfb
[16:31] <cjwatson> that wouldn't surprise me, I seem to remember that getting upstream activity
[16:31] <cjwatson> worth checking the output .pc files by hand though
[16:31] <seb128> yeah I will do that
[16:31] <cjwatson> cheers
[16:31] <seb128> +Requires: gdk-pixbuf-2.0 pango pangocairo gio-2.0 fontconfig cairo-directfb
[16:31] <seb128> is the new version gdk-directfb-2.0.pc
[16:31] <stgraber> directhex: thanks
[16:32] <seb128> which seems correct to me
[16:32] <seb128> lool: ^ if you want to double check after your meeting
[16:35] <cjwatson> seb128: *looks* ok
[16:41] <ogra> stgraber, hmm, looking at bug 357429, how do you make sure the dirs get deleted properly ?
[16:45] <slangasek> superm1: done
[16:45] <superm1> thanks
[16:53] <mterry> kees: When you get a sec, can you talk to me a bit about the details of bug 255635?  I don't quite get the changelog entry.  I'm working on rsyslog and want to make sure it's not affected
[16:56] <kees> mterry: sure!  basically, glibc and sysklogd fought with eachother over the definition of syslog()
[16:56] <kees> mterry: when compiling under Ubuntu, -D_FORTIFY_SOURCE=2 is defined, which causes glibc to add additional protective macros.
[16:57] <kees> mterry: one of those is for syslog(), so when klog.c compiled, it ended up getting its syslog calls redirected to glibc
[16:57] <kees> mterry: but it had it's own version of syslog() that allowed for kernel messages to be inserted.  the glibc one doesn't allow that.
[16:57] <kees> mterry: so, kernel messages went silent.
[16:57] <mterry> kees: I see...  So as long as rsyslog doesn't define its own syslog(), there shouldn't be that specific conflict
[16:58] <kees> mterry: right.  I would just carefully examine how kernel messages are handled, or at least verify they're still being reported at and after boot time.
[16:59] <mterry> kees: Right.  OK.  I'll play with it, but basically, at the end of the day, as long as kern.log is filling up, I'm happy, eh?
[16:59] <kees> mterry: yup
[16:59] <mterry> kees: Cool, thx
[17:00] <kees> mterry: though note that there might be a difference between "catch up"(flushing the ring-buffer from before syslog started) and "live" kernel log reporting.  testing both should be sufficient.
[17:01] <mterry> kees: OK
[17:08] <lool> seb128: I think the issue is with pango .pcs IIRC
[17:10] <seb128> lool: the patch I'm talking about is the gtk one though, do you think it's still required?
[17:10] <lool> I would patch the gtk+ configure script heavily to workaround the very specific namings of cairo .pcs in Debian in the past
[17:11] <cjwatson> mterry: I looked at the rsyslog source briefly during the UDS session, and it appeared that it might well have the same problem
[17:11] <lool> seb128: Hmm the part I'm talking about was dropped completely from the Gtk+ package (see 2.10.3-1), so that's probably something else
[17:11] <cjwatson> mterry: but I didn't actually try it, so I left that link in the spec as a warning
[17:12] <mterry> cjwatson: I'm thinking it may not have the same problem, but I'm not done investigating
[17:56] <Pik0r> cjwatson: " Mark has given us very clear guidance that non-free applications are not to be supported by Ubuntu" ... just not supported, or even not to be offered?
[17:57] <Pik0r> cjwatson: and do you mean by 'free' 'open source'?
[17:58] <pitti> Pik0r: making them available in multiverse is okay (as long as we are allowed to ship them), but not restricted (which is the supported subset of non-free sw)
[18:04] <slangasek> pitti: anacron postinst> doesn't this miss the case of reinstalling the package when it's in "config files" state, since then only the preinst is told the previous version number, not the postinst?
[18:04] <pitti> slangasek: oh, really? I didn't know that
[18:05] <mterry> cjwatson: Would the rsyslog change be affected by the FeatureDefinitionFreeze?  It needs an MIR still, so it seems like it fits the "updates to be landed in main" clause
[18:07] <pitti> slangasek: so most-recently-configured-version is empty if you reinstall a previously removed package?
[18:07] <slangasek> pitti: I believe so, yes
[18:09] <pitti> hm, so that stuff needs to move to preinst then, I figure (which is a bit ugly, but *shrug*)
[18:11] <cjwatson> Pik0r: not supported as in "not to be in the main or restricted components". And "free" is essentially synonymous with "open source" here, yes.
[18:11] <cjwatson> mterry: that means that the feature must be on the list, not that the package must be in main
[18:12] <cjwatson> I think I've mentioned rsyslog in a release meeting and nobody had a heartattack
[18:14] <mterry> cjwatson: OK, heartattacks may not be the best threshold, but I get ya.  ;)
[18:16] <tgpraveen1> why does jaunty ppa still have banshee 1.4.3
[18:16] <tgpraveen1> why isn't it upto 1.5 series
[18:24] <directhex> tgpraveen1, even numbered are stable releases, odd for unstable releases
[18:24] <directhex> tgpraveen1, i.e. banshee-unstable-ppa for 1.5 series
[18:24] <tgpraveen1> directhex: yeah I just found the unstable ppa
[18:24] <tgpraveen1> thanks
[18:45] <thebloggu>  Some time ago my ubuntu installation somewhere on boot jumps to verbose mode, as well as it is taking much longer to boot now than before. It doesnt seem there are any errors
[18:48] <cjwatson> thebloggu: usplash has a timeout - if something takes too long then it'll cancel the splash screen on the grounds that something is clearly weird and you might like to be able to see what
[18:50] <thebloggu> cjwatson, it seems (from my search on google) it has something to do with the size of swap partition
[18:50] <thebloggu> http://ubuntuforums.org/showthread.php?t=901254
[18:50] <thebloggu> it goes verbose exactly on "reading files needed to boot"
[18:50] <cjwatson> I don't think that's a sound inference
[18:51] <cjwatson> sure, it's worth checking, but that's not enough data to say that it's swap
[18:51] <cjwatson> and that forums post is about the swap partition's UUID, not its size
[18:51] <thebloggu> i upgraded xp to vista in the meantime, but didnt touch the ubuntu or the swap partition
[18:52] <cjwatson> type 'swapon -s' in a terminal
[18:52] <cjwatson> (incidentally why is this on #ubuntu-devel?)
[18:52] <cjwatson> if you see a line starting with /dev, then that forums post is unlikely to be your problem
[18:52] <thebloggu> Filename				Type		Size	Used	Priority
[18:54] <thebloggu> thought of asking here since the main ubuntu channel is too noisy and normally they help better with smaller/easier to solve problems
[18:56] <Chipzz> thebloggu: wrong reasoning; this channel is not an overflow channel for #ubuntu
[18:57] <thebloggu> Chipzz, i know, i'm sorry for that
[18:57] <thebloggu> the truth is here i could get someone to listen to me and help
[18:57] <thebloggu> and asked 4 times there
[18:57] <thebloggu> with no response whatsoever
[18:58] <stgraber> ogra: the exact same way we used to remove the ldm-xauth file
[19:03] <thebloggu> cjwatson, http://pastebin.com/mf6f9d6a should i edit the resume file to the swap uuid on top?
[19:04] <cjwatson> thebloggu: I'll help if you promise to use #ubuntu+1 in future ;-)
[19:05] <cjwatson> or #ubuntu, or some non-IRC forum
[19:05] <thebloggu> cjwatson, sorry but no :P i'm on jaunty not karmic
[19:05] <thebloggu> but yes
[19:05] <thebloggu> i'll do it
[19:05] <cjwatson> ok. yes, you need to change /etc/initramfs-tools/conf.d/resume, and you probably also need to change /etc/fstab.
[19:06] <thebloggu> cjwatson, once again, i'm sorry for the trouble, i know this channel is for development
[19:07] <thebloggu> cjwatson, thanks, i'll reboot to see if it works, i'll come back in a minute to tell you if it worked
[19:10] <cody-somerville> jcastro, ping
[19:11] <thebloggu> cjwatson, it worked
[19:11] <thebloggu> thank you very much
[19:12] <cjwatson> ok, good
[19:12] <cjwatson> it's a bug that swap resize changes the UUID
[19:12] <jcastro> cody-somerville: yo
[19:12] <Laney> Is there a wiki page on editing grub2 configurations? I need to add a devicemap to my windows line
[19:13] <thebloggu> cjwatson, that's one of the reasone i came here too, but after seeing that post thought it wasn't a bug
[19:13] <cody-somerville> jcastro, Is there any way Xubuntu could get in on your upstream bug reporting stuff?
[19:13] <thebloggu> cjwatson, should i submit a bug somewhere?
[19:13] <thebloggu> reasons*
[19:13] <jcastro> cody-somerville: yeah right now it's by open bug, so the buggier it is the better. People have been telling me they want it broken down by team level
[19:14] <jcastro> cody-somerville: which I think makes sense, depends on getting lp manhours on it
[19:14] <cody-somerville> jcastro, Would we just be able to add the xfce related packages to the report for now?
[19:14] <jcastro> cody-somerville: a motivated person could grab the links to the numbers (which are just lp queries) and make a page that is similar, which is what I would recommend
[19:15] <jcastro> cody-somerville: yeah just take an existing query (after you click on it) and replace it with the package you want
[19:15] <jcastro> cody-somerville: a seperate page with the same queries would probably be easier to do, the lp team are kind of booked for a while. :-/
[19:16] <cody-somerville> jcastro, I can make the necessary code changes if need be.
[19:16] <cody-somerville> jcastro, but you're saying I can make my own https://edge.launchpad.net/ubuntu/+upstreamreport ?
[19:17] <jcastro> cody-somerville: I am saying you can just make a people.u.c page or something if you want to whip it up.
[19:17] <jcastro> cody-somerville: but if you want to branch and fix +upstreamreport I won't complain!
[19:18] <jcastro> cody-somerville: gmb would be the person to talk to about that
[19:18] <jcastro> if there were a way to make it so we can have team-specifc ones (server, desktop, xubuntu, etc.) that would be much more useful
[19:19] <cody-somerville> jcastro, Where can I find the code if I wanted to setup a people.u.c page for Xubuntu packages?
[19:19] <jcastro> gmb would know
[19:20] <jcastro> I don't really know anything about lp or it's internals, I just tell gmb what we want and then he goes off and implements it.
[19:20] <jcastro> cody-somerville: mail him and CC me and I will help you with this
[19:25] <cjwatson> thebloggu: yeah, probably, on the parted package in Ubuntu
[19:25] <cjwatson> Laney: could just wait for the next update :)
[19:27] <AnAnt> will tomboy & fspot still be installed in Ubuntu desktop by default ? or will they be replaced with non-Mono alternatives ?
[19:28] <Laney> cjwatson: that's going to fix it? i.e. set the drivemap correctly or make the configuration easier to edit?
[19:29] <cjwatson> Laney: it'll set it correctly by default
[19:29] <Laney> ah fair enough
[19:29] <cjwatson> AnAnt: I don't know of any plan to remove them
[19:29] <Laney> I just edited it by now
[21:34] <ebroder> So anybody with main bits who could look at bug #362691?
[21:55] <cr3> how can I set the proxy for apt to access packages under https? it seems that Acquire::https::Proxy either doesn't exist or doesn't work
[22:04] <robbiew> Keybuk: did we ever get the benchmark results for the i586 rebuild for foundations-karmic-i586-support?
[22:28] <`26> glGetInfoLogARB omits line numbers and file name from error messages, am I doing something wrong? [platform: ubuntu 9.04 + Intel graphics card]
[23:12] <`26> Okay, xserver-xorg-driver-intel does NOT report GLSL compilation line numbers and file names, which makes debugging quite virtually impossible.
[23:13] <`26> I tested with a nearby computer who has a nVidia card, and at least their driver, although closed-source, reports line numbers.
[23:33] <TheMuso> pitti: I was just heading to bed at the time, and jumped on to check something. :)
[23:33] <Sarvatt> `26: i believe you mean mesa :D
[23:34] <`26> Sarvatt: yes, I just ran a search for string "Syntax error" and it's really in package libgl1-mesa-dri.
[23:35] <Sarvatt> you might want to try updating your mesa - https://launchpad.net/~xorg-edgers/+archive/ppa
[23:35] <`26> This is a pretty bad problem, since the GLSL specification document says that Implementation *must* provide line numbers and filenames in log.
[23:35] <`26> sure
[23:38] <Sarvatt> looks like it was fixed in mesa 7.4.3
[23:38] <`26> Sarvatt: good trying ppa right now
[23:40] <`26> Packages installing, /me is saying his prayer.
[23:41] <`26> be right back
[23:46] <cr3> if I run apt-get update on a sources.list containing https repositories on karmic, I get:  server certificate verification failed. when I try on jaunty, it works just fine. any ideas what might be wrong?
[23:51] <`26> Sarvatt: I installed all packages in the PPA you gave me. X wouldn't start anymore, so I downgraded xserver-xorg-* and left everything else the same. Problem was not fixed, still no line numbers in GLSL log output.
[23:53] <cr3> nevermind, the problem was that the clock on the client was offset by too long... I really need to run ntpdate
[23:54] <Sarvatt> do you have a 965 or newer?
[23:55] <`26> lsmod says i915, otherwise IDK
[23:56] <Sarvatt> what does glxinfo | grep Intel say?
[23:57] <`26> OpenGL renderer string: Software Rasterizer
[23:57] <`26> err that can't be right
[23:57] <`26> Should I downgrade everything to what it was?