=== dendrobates is now known as dendro-afk
=== d1b_ is now known as d1b
=== apachelogger_ is now known as apachelogger
=== asac_ is now known as asac
=== dendro-afk is now known as dendrobates
=== bjf is now known as bjf[afk]
=== dendrobates is now known as dendro-afk
=== Hobbsee` is now known as Hobbsee
=== Hobbsee is now known as Guest83930
=== Guest83930 is now known as Hobbsee
[08:11] <pitti> Good morning
[08:11] <ion> that.
[08:11] <pitti> kees: in yesterday evening's SRU meeting I got the confirmation that karmic was tested, and marked it as v-done; I'll move it to -updates today
[08:12] <didrocks> good morning pitti
[08:12] <pitti> bonjour didrocks, ca va?
[08:13] <didrocks> pitti: I'm fine thanks, just received my bed yesterday evening and glued piece together :) and you?
[08:13] <JackyAlcine> Morning, guys.
[08:13] <pitti> didrocks: nice! feels better than a sleeping bag :)
[08:14] <pitti> didrocks: bit tired, but I'm good, thanks
[08:14] <pitti> hello JackyAlcine
[08:14] <StevenK> didrocks: You shouldn't need to do that in Dallas, at least  :-)
=== almaisan-away is now known as al-maisan
[08:23] <didrocks> StevenK: hehe, right :) I'm still happy to have a real bed again and don't have to wait for Dallas to have this feeling :)
=== Tm_Tr is now known as 50UAAE4PK
=== smb` is now known as smb
=== 50UAAE4PK is now known as Tm_Tr
[08:59] <Guest17443> where i can discuss about ubuntu amazon or UCE images - any idea - is it the right room?
=== akshatj is now known as akshat
=== akshat is now known as akshatj
=== JackyAlcine_ is now known as JackyAlcine
[09:24] <siretart> Guest17443: try #ubuntu-server
=== akshatj is now known as akshat
=== akshat is now known as akshatj
[09:42] <Chipzz> mvo: ping?
[09:43]  * Chipzz slaps himself for contentless ping
[09:44] <Chipzz> mvo: how does apt determine, for a given deb line in sources.list, which of Packages/Packages.gz/Packages.bz2 it should try to fetch?
[09:45] <Chipzz> or are all three tried (in some sort of fixed order)?
[09:49] <apw> Chipzz, perhaps it uses content negociation on 'Packages'
[09:50] <smb> pitti, Morning, do you know about gnome-system-tools not being installed by default. Is this intended to save cd space?
[09:51] <soren> Chipzz: It says in the Releases file.
[09:51] <soren> Err... "Release", I mean.
[09:52] <smb> pitti, I did a Natty install of a daily image over the weekend and not having gnome-system-tools prevents you from accessing the time and date settings at least, which is kind of annoying.
[09:53] <soren> Chipzz: Hm... Or maybe not.
[09:53] <pitti> smb: I put it back in the seeds
[09:53] <pitti> smb: it needs a -meta upload; I'll change something else today, and do that
[09:53] <pitti> smb: we originally meant to replace it with a new user admin tooll, but it didn't work out yet
[09:53] <G> soren: I always thought it went on most likely to least likely
[09:53] <pitti> smb: so alpha-2 will have it
[09:54] <soren> Chipzz, G: My bad.
[09:54] <soren> Chipzz, G: Acquire::CompressionTypes::Order defines it.
[09:55] <smb> pitti, Ah ok. Will have a look for it when looking at alpha-2 then
[09:55] <soren> Chipzz, G: The Release file just gives the md5sums for verification purposes.
[09:55] <smb> pitti, thanks
[09:55] <Chipzz> soren: thx
[09:55] <Chipzz> apw: I have a problem with apt-proxy giving me the following errors:
[09:55] <Chipzz> W: Failed to fetch http://192.168.1.249:8080/security/dists/lenny/updates/non-free/binary-i386/Packages  404 file not found on backend
[09:56] <Chipzz> which is correct given that http://security.debian.org/debian-security/dists/lenny/updates/non-free/binary-i386/ doesn't contain a Packages file
[09:56] <Chipzz> if you look at the gzip file that just uncompresses to a 0 byte file
[09:57] <Chipzz> so maybe the archive tools used on security.debian.org prune empty files
[09:57] <Chipzz> *prunes
[09:58] <mvo> Chipzz: hey, it uses acquire::compressionTypes::order
[09:58] <Chipzz> now I'm not sure if apt-proxy is at fault for not supporting content negotation
[09:58] <Chipzz> mvo: ^^^
[09:59] <Chipzz> (actually it's apt giving me those errors, but the backend uses apt-proxy; that's more correct)
[09:59] <Chipzz> mvo: what's your take on this?
[10:00] <G> Chipzz: sounds like your apt-proxy is sending a 404 for all of the options of Packages
[10:01] <Chipzz> or it only tries the literal file requested, not sure
[10:01] <soren> mvo: apt.conf(5) says "It is not needed to add bz2 explicit to the list as it will be added automatic.". I don't see where that happens, though? getCompressionTypes seems to just return what is in the configuration.
[10:02] <G> Chipzz: the client should try the next on each 404 though
[10:02] <Chipzz> G: the client is apt-get
[10:02] <Chipzz> so I'm wondering if apt-get is at fault, or what exactly is going wrong here
[10:02] <Chipzz> most likely it's apt-proxy though
[10:03] <G> Chipzz: pump up the debugging/output and see exactly whats it's requesting
[10:03] <mvo> Chipzz: could you run with -o debug::acquire::http=true and see what apt-proxy returns and what it tries to fetch? might be that apt-proxy returns?
[10:04] <Chipzz> mvo: will do
[10:04] <Chipzz> the thing is, for some reason it has to time-out too
[10:04] <Chipzz> which takes a while
=== dbarth__ is now known as dbarth
[10:05] <Chipzz> apt hangs at: 82% [Waiting for headers]
[10:05] <Chipzz> probably apt-proxy b0rkedness
[10:06] <mvo> soren: it will do a second pass in Configuration::getCompressionTypes() and append all the compression types availalbe via Acquire::CompressionTypes that are not in the override order (yes, its a bit complicated the code)
[10:06] <mvo> Chipzz: what version of apt is this?
[10:06] <Chipzz> mvo: debian lenny, with all updates (security/updates/volatile)
[10:07] <soren> mvo: Oh.. Ok, I was looking specifically for something about bz2, but actually it adds any new compression type. Ok, that makes sense.
[10:07] <mvo> Chipzz: aha, ok. that is really a bit older, the compression order does not apply here, the order is hardcoded in that version iirc
[10:07] <Chipzz> mvo: 0.7.20.2+lenny2
[10:07]  * mvo nods
[10:08] <Chipzz> mvo: I really suspect apt-proxy to be at fault here though; it's a broken piece of software. unfortunately, the alternatives are not a lot better
[10:09] <Chipzz> and I don't think I really want to run squid instead
[10:09] <mvo> you know about squid-deb-proxy :) ?
[10:09] <Chipzz> hrrrm no?
[10:10] <ion> I’m using apt-cacher-ng
[10:11] <Chipzz> mvo: doesn't look like it's packaged for debian yet though?
[10:11] <mvo> Chipzz: its a squid with a config optimized for caching debs, if you install squid-deb-proxy and squid-deb-proxy-client (the later only on the client) it will work automatically, i.e. no need to configure anything
[10:11] <mvo> Chipzz: thats possible :/
[10:12] <mvo> Chipzz: it uses avahi to advertise its support and is configured to server all local networks by default
[10:12] <Chipzz> mvo: sounds nice, but not really something I need ;)
[10:13] <Chipzz> I populate my sources.list at install time with debian-installer options
[10:14] <Chipzz> mvo: is it valid for the archive tools to prune empty Packages files though?
[10:17] <mvo> Chipzz: not really, a empty file is fine, it means there might be packages in the future. but no file is bad because that will result in a 404
[10:18] <Chipzz> so I should poke the administrator of security.debian.org? ;P
[10:21] <mvo> Chipzz: well, thats fine what security.d.o is doing because it keeps a empty Package.gz
[10:21] <mvo> Chipzz: hopefully the -o debug::acquire::http=true output helps
[10:22] <Chipzz> still waiting until it has timed out completely
[10:22] <Chipzz> ^^
[10:22] <apw> against what would i file a bug wherein dispite chromium being my default browser, opening links in xchat etc open firefox ?
[10:22] <Chipzz> at least it's hanging at 89% now
[10:23] <apw> mvo, actually it will only work if avahi works right?  and as thats not working in natty ...
[10:23] <ion> Avahi’s not working in natty? At least host name resolution works for me, FWIW.
[10:24] <apw> ion, i find it works about 1/5 boots
[10:26] <apw> ion, it seems that the machine is in its own little world, thinks it is advertising its name, and indeed can resolve its own name but is not visible to other machines nor can see them
[10:30] <mvo> apw: thats true, but I hope we will not realse without a broken avahi ;)
[10:31] <mvo> apw: one nasty issue is that avahi-browse reports ipv6 addresses sometimes when its asked for ipv4
[10:31] <Chipzz> mvo: http://chipzz.safehex.be/apt-log
[10:31] <Chipzz> it seems to be doing multiple requests for the same file
[10:34] <Chipzz> does 2 requests for Packages.bz2 and Packages.gz
[10:34] <Chipzz> only one for the other types
[10:34] <seb128> apw, the default browser thing is a known bug
[10:34] <apw> mvo, so it does ... very odd indeed
[10:34] <seb128> apw, gnome-control-center one
[10:35] <seb128> apw, the capplet needs an update for the new default handler system
[10:35] <apw> mvo, OH and if you ask for the address of 'self' a few times, that fixes the response to be ipv4, _and_ the machine is then advertised correctly remotly
[10:36] <seb128> apw, you can workaround locally by editing /usr/share/applications/defaults.list
[10:36] <seb128> apw, set x-scheme-handler/http to what you use
[10:36] <seb128> apw, then sudo update-mime-database /usr/share/applications
[10:36] <apw> seb128, perhaps i'll leave it be and use the machine as confirmation the bug fixes
[10:37] <seb128> update-desktop-database rather
[10:37] <seb128> apw, your call, we will test the fix for sure since it's an issue quite some users reported and obviously broken
[10:43] <pitti> apw: ah, udev bug gone together with the old year?
[10:44] <zyga> pitti: hi
[10:44] <pitti> hey zyga, happy new year!
[10:44] <apw> pitti, yep, completely bizarre, i did a dozen up/down graded to confirm it was udev only that triggered it... and decided to upgrade everything today expecting to have to downgrade udev ... and its fine.  most odd
[10:46] <pitti> apw: the udevadm trigger test didn't reveal anything at the time when you still could reproduce it?
[10:47] <apw> pitti, nothing no
[10:48] <apw> i'll keep monitoring it, and if it comes back i'll have the box with me next week
[10:51] <pitti> zyga: do you see my replies in privmsg?
[10:51] <zyga> pitti: I can see you type but I cannot even see my messages
[10:52] <zyga> just a second
[10:59] <soren> cjwatson: No problem. We turned out to be quorate, so it was fine.  All of us except bdrung will expire in two weeks, though. I forget if we've addressed that at all?
[11:00] <cjwatson> I don't know
[11:00] <pitti> hey cjwatson, happy new year! had some nice holidays?
[11:05] <cjwatson> pitti: yeah, they were fine thanks :)
=== diwic is now known as diwic_afk
=== diwic_afk is now known as diwci
=== diwci is now known as diwic
=== al-maisan is now known as almaisan-away
[11:40] <MacSlow> tseliot, hey there
[11:40] <tseliot> hi MacSlow
[11:40] <MacSlow> tseliot, happy new year btw :)
[11:40] <tseliot> MacSlow: thanks and happy new year to you :)
[11:41] <MacSlow> tseliot, do you know how during the login-procedure (from gdm to desktop-session) the resolution is switched on nvidia?
[11:42] <MacSlow> tseliot, I mean... where is the setting for this stored and which tool triggers the switch?
[11:42] <tseliot> MacSlow: it depends. Did you change it from nvidia-settings?
[11:42] <MacSlow> tseliot, on the gdm-screen I still have the correct native resolution
[11:43] <bdrung> cody-somerville: can you add angelabad to the motu team?
[11:43] <tseliot> MacSlow: if you didn't use nvidia-settings, try to remove the ~/.monitors.xml, just in case the gnome-settings-daemon is applying the wrong resolution
[11:43] <MacSlow> tseliot, well I've to change it in nvidia-settings if I want to get back to the native one.... but I rather prefer the resolution not to change at all... I mean it's ok during gdm... so no need to change it.
[11:43] <seb128> MacSlow, did you check .config/monitors.xml?
[11:44] <apw> seb128, ok i've switched over, and your instructions work just fine (firefox -> chromium)
[11:44] <MacSlow> tseliot, seb128: no... didn't know about that file... will check now
[11:44] <seb128> apw, great! ;-)
[11:44] <seb128> MacSlow, that's what gnome-display-properties writes
[11:45]  * tseliot nods
[11:46] <MacSlow> seb128, tseliot: ~/.config/monitors.xml states the wrong resolution... so I just fix that and should be all good?!
[11:46] <seb128> MacSlow, rm the file
[11:46] <tseliot> MacSlow: yes, either fix that or remove it
[11:46] <seb128> so it will just use the xorg config
[11:46] <MacSlow> seb128, tseliot: ok... trying out the result now... brb
[11:46] <MacSlow> I hope :)
[11:49] <MacSlow> tseliot, seb128: ok that worked... thanks!
[11:49] <tseliot> np
[11:50] <seb128> MacSlow, you're welcome
[11:56] <ScottK> doko: I couldn't reproduce your KDE related libreoffice build failure, but I'm not sure the chroot I used was completely clean.  Could I get the package install part of the build log so I can check what got pulled in by your build versus what I've got installed and see if there's a dependency missing as an explanation?
[11:58] <doko> ScottK: I don't have the log
[11:59] <pitti> tkamppeter: I just reported bug 697190, this is a prerequisite
[11:59] <ubottu> Launchpad bug 697190 in system-config-printer (Ubuntu) "cupshelpers.openprinting.OpenPrinting.listDrivers() does not include fingerprints" [Undecided,New] https://launchpad.net/bugs/697190
[12:00] <pitti> tkamppeter: I guess it's easy to fix, do you want me to look at it, or do you want to?
[12:04] <cjwatson> lool: I'd appreciate it if you could look at bug 694772, since it's a regression caused by your recent eglibc upload
[12:04] <ubottu> Launchpad bug 694772 in eglibc (Ubuntu) "Sudden reboot during server ISO install" [Critical,Triaged] https://launchpad.net/bugs/694772
[12:19] <doko> ScottK: could you recheck with a PPA upload?
[12:19] <ScottK> doko: I'm redoing it now locally.  I think I may have not re-enabled all the KDE bits.
[12:20] <doko> ScottK: it should be just the one line in rules, then rebuilding the control file
[12:20] <ScottK> There's also the one above the configure flag that I missed the first time.
[12:21] <ScottK> I didn't have BUILD_KDE=y
[12:21] <ScottK> So I think it didn't build the bit that fails.
[12:23] <doko> ahh, ok
=== MacSlow is now known as MacSlow|lunch
[12:31] <tkamppeter> pitti, I will fix bug 697190.
[12:31] <ubottu> Launchpad bug 697190 in system-config-printer (Ubuntu) "cupshelpers.openprinting.OpenPrinting.listDrivers() does not include fingerprints" [Undecided,Triaged] https://launchpad.net/bugs/697190
[12:32] <pitti> tkamppeter: thanks; I'm currently figuring out how to do SSL cert verification in python
[12:32] <pitti> tkamppeter: that are the two main building stones that I'll need :)
[13:06] <elif> Preseed can use a partiotion (not try to make one, but just use one that was there already) ?
[13:10] <cjwatson> unfortunately not
[13:11] <ScottK> Welcome back cjwatson.  I hope you had a pleasant holiday.
[13:11] <elif> cjwatson: thks.
[13:11] <cjwatson> ScottK: not bad, thanks
=== oubiwann is now known as oubiwann_
=== almaisan-away is now known as al-maisan
=== oubiwann_ is now known as oubiwann
[13:26] <stefano-palazzo> building gtk fails with "Gdk-2.0.gir: error: Type reference 'GdkPixbuf' not found" - can anybody help?
[13:31] <Chipzz> stefano-palazzo: this is not the place for these kind of questions; you should try on #gtk+ on irc.gnome.org instead
[13:33] <stefano-palazzo> Chipzz, Oh I see, thanks anyway.
[13:44] <cdbs> I can't get any python distutils-using app to build on my pbuilder, it appears that the python2.7 package isn't installed properly in it.
=== hunger_ is now known as hunger
[13:47] <cdbs> How do I fix it? I don't want to go and re build my chroot tarball
[13:48] <hmca> hello, greetings and happy new year 2 all!.
[13:49] <hmca> !php5
[13:49] <hmca> !php
[13:49] <ubottu> PHP is an HTML-embedded scripting language. A command-line only version can be installed in Ubuntu with the "php5-cli" package. See also !lamp for integrated server PHP. The Ubuntu server PHP5 guide is found at https://help.ubuntu.com/10.04/serverguide/C/php5.html
[13:49] <cdbs> !msgthebot | hmca
[13:49] <ubottu> hmca: Please investigate with me only with "/msg ubottu Bot" or in #ubuntu-bots.  Search for factoids with "/msg ubottu !search factoid".
=== MacSlow|lunch is now known as MacSlow
=== sanchaz is now known as sanchaz-away
[14:23] <micahg> janimo_: sorry about that, this was my first time using a real mozconfig, I'll test the build tonight before uploading again
[14:24] <janimo_> micahg, np at all
[14:24] <janimo_> micahg, I thin just modifying mozconfig.in w/o debian rules should work
[14:25] <janimo_> you can test on x86 and see wether it is affected by --enable-thumb2 - I thinknot
[14:25] <janimo_> it suffices if you let the configure step run, so about 2-3 minutes
[14:25] <lool> cjwatson: Hey; sorry, there was a small network outage for the machine hosting this IRC session; I think you wanted me to poke the eglibc reboot; I've attached a couple of untested debdiffs and would be happy to get your feedback while they build in my PPA
[14:27] <tkamppeter> pitti, corrected s-c-p uploaded to natty.
[14:32] <cjwatson> lool: thanks, followed up in the bug
[14:34] <lool> cjwatson: Will test an upgrade of libc6 on my system and if that doesn't cause any error or reboot, I will upload this debdiff
=== tkamppeter_ is now known as tkamppeter
=== smb` is now known as smb
[14:59] <pitti> tkamppeter: cheers!
=== diwic is now known as diwic_afk
=== smoser` is now known as smoser
[15:07] <tkamppeter> pitti, does it work for you now?
[15:08] <pitti> tkamppeter: haven't tried yet, still buried in SSL stuff
=== dendro-afk is now known as dendrobates
[15:25] <ev> I don't suppose anyone has experience automating uploading and watching for finished binaries in a PPA using launchpadlib? I'd rather not reinvent the wheel, should one exist.
[15:26] <elmo> ev: lamont's done something like that - it may predate launchpadlib though, but you could ask him
[15:26] <mvo> ev: something vaguely similar is lp:~mvo/%2Bjunk/lp-changelogs-crawler/
=== bjf[afk] is now known as bjf
[15:27] <mvo> ev: but I guess its just too different to be useful
[15:27] <ev> elmo, mvo: thanks
[15:28] <ogra> doko, shadow fixed and uploaded
[15:29] <doko> \o/
=== zyga is now known as zyga_food
[15:38] <om26er> there are two commits to fix a bug, should i merge those commits into one patch or two seperate patches should be added for a backport?
[15:39] <seb128> om26er, either way works
[15:39] <om26er> seb128, alright, thank you.
[15:39] <seb128> om26er, if those are different changesets better to keep them as two commits
[15:40] <seb128> if the second is a fix to the first commit you can as well do a diff with both revisions
[15:40] <jdstrand> pitti: hi! I'd like to get bug #690040 fixed in maverick soon. are you working on this or shall I?
[15:40] <ubottu> Launchpad bug 690040 in cups (Ubuntu Maverick) "no longer confined by AppArmor" [Undecided,Triaged] https://launchpad.net/bugs/690040
[15:40] <pitti> jdstrand: if you have the time, please go ahead
[15:41] <jdstrand> pitti: ok. I will just update the job file like we did for other things in maverick
=== deryck is now known as deryck[lunch]
=== zyga_food is now known as zyga
=== al-maisan is now known as almaisan-away
[16:15] <wildfire> I've uploaded something to my PPA - is there a way I can check the status of the build?
[16:15] <seb128> wildfire, on your ppa page
[16:16] <wildfire> seb128: nothing seems to be there (uploaded about 6 hours ago), and dput says I can't upload since I already have
[16:16] <wildfire> suggestions?
[16:17] <seb128> wildfire, dput says that because of the .upload
[16:17] <seb128> you probably have a .upload in your directory
[16:17] <Laney> dput -f ...changes
[16:17] <seb128> the upload probably got rejected, you should have received an email
[16:18] <wildfire> seb128: yup, I did, and then I uploaded a revised version
[16:18] <seb128> did you upload to the right ppa with a correct changelog target?
[16:18] <wildfire> seb128: the first time, no, I set the distribution to 'unstable', the second time I think I got it right but have had no feedback
[16:18] <seb128> wildfire, well rm the .upload and dput again
[16:19] <wildfire> seb128: OK, will do
[16:19] <seb128> wildfire, well if you used the same version the .upload probably blocked the dput saying you already uploaded
[16:20] <wildfire> I updated the version and appended ~lucid to the end
[16:20] <wildfire> sorry, ~lucid~0
[16:21] <wildfire> seb128: the full version string is yate_3.0.0-0~ubuntu~lucid~0.dsc
[16:21] <wildfire> does that look reasonable?
[16:22] <seb128> wildfire, yes
[16:22] <seb128> just rm the .upload and dput again
[16:22] <wildfire> have done
[16:32] <wildfire> hmm, noothing much appearing
=== beuno is now known as beuno-lunch
[16:37] <lool> SpamapS: Hey
[16:38] <lool> SpamapS: upstart / libc6: IIUC, trying to properly call telinit in libc6 wouldn't do anything anyway, as it's currently broken, and I should be looking at touch /var/run/init.upgraded rather than telinit; would you like me to prepare, test, and upload such an eglibc change?
=== njpatel is now known as njpatel|away
[16:40] <SpamapS> lool: actually I just built a package last night that does it.. its a very tiny change...
[16:40] <SpamapS> lool: let me push the branch.. and if you want to sponsor it/run with it, that would be awesome. :)
[16:40] <lool> SpamapS: Given that the package importer had issues with it yesterday, I'd rather have a debdiff in the bug if that's ok with you
[16:40] <lool> SpamapS: I would basically remove: telinit u 2> /dev/null || true ; sleep 1
[16:41] <lool> and use touch instead
[16:41] <lool> SpamapS: Debian folks told me this wouldn't work with some FS if the machine is not shutdown properly
[16:41] <lool> I think they are correct, but I wonder how much this can be blamed on these filesystems
[16:43] <SpamapS> lool: just pushed to lp:~clint-fewbar/ubuntu/natty/eglibc/no-telinit-u  ..
[16:43] <SpamapS> lool: ahh right package import..
[16:45] <Verminator> I hope this is the correct place to ask this.  I am a MS Windows C++/MFC programmer.  I want to start exploring Linux development.  Is there a good web community to get involved with or some good tutorials I can use to get up to speed?  I have already found started looking at the link given in the topic of this channel.  TIA
[16:46] <SpamapS> lool: I will put a debdiff into the bug report in a bit..
=== njpatel|away is now known as njpatel
[16:53] <janimo> micahg, you're right, the --enable-thumb2 flag is not filtered out in mozilla build script so needs to be done as you have in debian/rules
[16:55] <micahg> janimo: ok, now that my arm box is working I can actually test before I upload, so I'll add the DEB_DEFINES and see if that does it
[16:57] <SEJeff> I was wondering if someone could help me track down a tricky dbus / xfce4-terminal bug
[16:58] <SEJeff> xfce4-terminal hangs. I straced it and it is returning: EAGAIN (Resource temporarily unavailable) on a recvmsg call in what is a dbus call
[16:59] <SEJeff> There is 1.2G of memory free
[17:01] <wildfire> seb128: hmm - any other tips?
=== deryck[lunch] is now known as deryck
[17:06] <seb128> wildfire, you didn't get any email about the upload? how did you upload?
[17:06] <seb128> can you copy your .changes online somewhere?
[17:11] <hallyn> grrr.  natty kernel doesn't have sysfs tagging support.
[17:11] <SEJeff> hallyn, Is that a feature that lxc will use?
[17:12] <hallyn> yes, it lets containers see their network interfaces in /sys/class/net
[17:12] <wildfire> seb128: via dput and sure, any suggested place?
[17:13] <hallyn> but actually, i dont' seem able to pass veths into a network namespace by hand in maverick at all...  hmmm
[17:13] <SEJeff> Oh yuck
[17:13] <sivang> hi all
[17:13] <seb128> wildfire, can you give the dput line you used?
[17:13] <sivang> whom do I contact to remove a paste from paste.poco.org?
[17:13] <wildfire> seb128: dput yate_3.0.0-0\~ubuntu\~lucid\~0_amd64.changes
[17:14] <wildfire> seb128: I'll pastebin the rest, one sec.
[17:14] <SEJeff> sivang, Go to that website and click about. This isn't an ubuntu question
[17:14] <wildfire> seb128: http://pastebin.com/EJ0XyynX
[17:14] <micahg> sivang: poco.org?
[17:14] <wildfire> seb128: AHH! I think I see the problem
[17:14] <wildfire> signed with wrong key.
[17:15] <sivang> micahg: indeed
[17:15] <micahg> sivang: why not contact them?
[17:15]  * wildfire tries a re-build and re-upload
[17:15] <sivang> micahg: the post is going to cost me my job, so it'd be nice to do it assap :)
[17:15] <sivang> micahg: what's the contact address?
[17:16] <seb128> wildfire, ok, you have a dput config to upload to your ppa right?
[17:16] <sivang> micahg: there's no where on the site where to contact them
[17:16] <seb128> wildfire, because by default otherwise it will try to upload to ubuntu
[17:16] <micahg> sivang: what does it have to do with Ubuntu?
[17:16] <wildfire> seb128: nope, well I am trying to upload to ubuntu
[17:16] <seb128> wildfire, you said to a ppa before?
[17:16] <SEJeff> sivang, Go to paste.pocoo.org and click about. Just like I already said.
[17:16] <wildfire> seb128: yes, an ubuntu PPA - am following: https://help.launchpad.net/Packaging/PPA/Uploading
[17:16] <seb128> wildfire, you are trying to upload to the ubuntu archive there, not to a ppa
[17:16] <SEJeff> It has info about the guy who runs it. Look up up and send him an email
[17:16] <wildfire> which says to just use dput without doing anything
[17:17] <seb128> wildfire, well you didn't use "dput your-ppa"
[17:17] <seb128> wildfire, well you didn't use "dput yourppa"
[17:17] <seb128> wildfire, if you don't specify a config to use it uploads to ubuntu
[17:17] <sivang> SEJeff: thanks dude, sorry for the noise
[17:17] <wildfire> seb128: ahh - bug #2; thanks!
[17:17] <ubottu> Error: Could not parse data returned by Launchpad: 2 (https://launchpad.net/bugs/2)
[17:18]  * wildfire tries once more
[17:18] <ogra> does a non *_source.changes upload even work ?
[17:18] <ogra> looks like you are uploading a .changes file from a binary build
[17:19] <hallyn> well now... notworking in natty either
[17:19] <seb128> ogra, that as well, I didn't open the pastbin before
[17:19] <seb128> wildfire, ^
[17:19] <seb128> wildfire, you need to do a source build to upload
[17:20] <ogra> well, it might work (after all the soucre files are included) i just never tested that
[17:20] <Laney> i think it rejects
[17:23] <wildfire> seb128: dpkg-buildpackage -S ?
[17:25] <seb128> wildfire, correct
=== beuno-lunch is now known as beuno
[17:30] <lool> SpamapS: I am not sure I will check the bug again tonight; this sounds urgent though; should I upload my debdiff for now?  I can definitely take another look tomorrow morning if you prefer
[17:33] <SpamapS> lool: I'll add the debdiff in just a moment
[17:38] <SpamapS> lool uploaded to the bug report.
[17:47] <wildfire> seb128: hurrah!
[17:47] <seb128> wildfire, worked?
[17:47] <wildfire> seb128: well, upload accepted and building
[17:49] <seb128> wildfire, great
[17:56] <geser> any ubuntu-devel-announce moderator around to moderate my mails?
[17:56] <cjwatson> yes
=== vorian is now known as stalcup
[18:13] <kees> pitti: kernels> okay, thanks.
=== yofel_ is now known as yofel
[18:39] <janimo> kees, hi, do you keep a list of packages which are built without FORTIFY_SOURCE  ? If so, in case you missed it the latest pth upload does that
[18:46] <jdstrand> jhunt: hi! I am looking to backport the fix in bug #689892 to maverick and lucid. is there anything in this patch: http://launchpadlibrarian.net/60617190/ifupdown_0.6.10ubuntu4.debdiff that would cause problems with upstart 0.6.5-7 or 0.6.6-3 in lucid and maverick (respectively)
[18:46] <ubottu> Launchpad bug 689892 in ifupdown (Ubuntu Maverick) "[SRU] race condition bringing up interfaces with AppArmor" [Undecided,Confirmed] https://launchpad.net/bugs/689892
[18:47] <jdstrand> jhunt: I'm thinking no, but thought I'd ask to be doubly sure
[18:58] <kees> janimo: yeah, it's on the wiki under CompilerFlags
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[18:59] <janimo> kees, thanks, checking it out
[19:03] <kees> doko: btw, did you see my update for the gcc-4.6 hardening patches? I solve the FORTIFY issue, I think
[19:07] <doko> kees: yes, checked in. will upload a gcc-snapshot build later
[19:07] <janimo> doko, I have tried an armel built of libo from ppa out of curiosity. It ERRORS with a segfault at the install step
[19:08] <janimo> had to disable smoketest first
[19:10] <doko> janimo: ahh, ok. same on i386
[19:11] <janimo> doko, the smoketest you mean? as the package itself seemed to build on i386, unlike on arm
[19:11] <janimo> it crashed on installing uno components to a 'registry' file
[19:12] <doko> janimo: which package do you try to build?
[19:12] <janimo> I'll check again in after the next uploads
[19:12] <janimo> doko from libo ppa
[19:12] <janimo> natty
[19:13] <doko> janimo: hmm, is this related to the smoektest?
[19:13] <doko> it's rather the same thing I see for the karmic-proposed OOo build
[19:14] <janimo> doko, no, Idisabled the smoketest just as it is done for i386, so it is skipped, but it fails after that anyway
[19:15] <doko> janimo: right, that is the problem =)
[19:15] <janimo> ok, so nothing new
[19:15] <janimo> did the arm port always have this issue?
[19:16] <doko> janimo: https://launchpad.net/ubuntu/+bugs?field.tag=lo33
[19:16] <doko> no, starting with lucid-proposed (not karmic), and now natty
[19:16] <bdmurray> pitti: could you look at https://code.launchpad.net/~brian-murray/ubuntu/natty/apport/natty-regression-tags/
[19:17] <janimo> doko, thanks, I tried searching lp for lo330 today with no results
[19:17] <bdmurray> I thought it was just lo33
[19:17] <doko> it is
[19:20] <janimo> doko, I saw that in the LP changelog "Launchpad bug tracker for issues tagged with `lo330', "
[19:20] <janimo> and did overlook the direct link in your mail to u-d
[19:20] <janimo> which was correct
[19:21] <doko> oops, wrong changelog
[19:23] <elif> cjwatson: using kickstart support can I install a ubuntu using a partition previously made ??? (early I asked if that was possible in preseed you said it is not), I think there's no way because ks support depends on preseed, but is that possible somehow ?
=== allison_ is now known as wendar
=== dnielsen is now known as HTF
=== HTF is now known as dnielsen
=== sforshee_ is now known as sforshee
=== zyga is now known as zyga-off
[20:20] <doko> janimo: now just find out *why* it segfaults ;)
[20:21] <doko> welcome to one of the most ugly parts of the package
[20:24] <janimo> doko, I tried a gdb backtrace this morning but it was incomplete, no symbols and corrupted frame
[20:24] <janimo> but I'll keep poking at it while other stuff builds these days
[21:19] <hallyn> cjwatson: did you have any comments or any plans to look further at the multipath-tools proposed package I emailed (syncing from debian)?
[21:22] <hallyn> <shrug> should I simply do a merge request of https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/debe1 into multipath-tools?
[21:27] <hallyn> hm, i'll do that.
[21:29] <hallyn> ivoks: cmagina: any comments you can give on my attempt to sync multipath-tools from debian (https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/debe1/+merge/45177) greatly appreciated
[21:37] <cjwatson> hallyn: well, if you wait until I'm next actually at work then I can certainly look at it.
[21:38] <cjwatson> if it's a verbatim sync then a merge request is a funny way to go about it.
[21:38] <cjwatson> (if it's not a verbatim sync, but a merge, please don't call it a sync :))
[21:40] <ivoks> hallyn: this requires review before 11PM :)
[21:43] <hallyn> it's definately not a verbatim sync
[21:44] <cjwatson> ivoks: hm?
[21:44] <hallyn> anyway i wanted to get on with getting the knows bugfixes into lucid+maverick but couldn't get myself to do those until i felt like i'd done the last step in getting natty fixed through upgrade...
[21:44] <cjwatson> I'll look first thing tomorrow
[21:44] <hallyn> ivoks: or after 9am is fine too :)
[21:45] <hallyn> cjwatson: thanks!
[21:46] <hallyn> ivoks: you never created a bug for the modprobe -Q right?
[21:49] <ivoks> hallyn: i don't think so, no... i don't lhave much time :(
[21:51] <hallyn> ivoks: thanks, just making sure - i'll create one
[21:52] <hallyn> oh, there is one
[22:07] <siretart> my x264 upload to maverick-proposed has been rejected. Can someone please assist me to find out whom to ask why?
[22:13] <siretart> Riddell: according to the https://wiki.ubuntu.com/ArchiveAdministration, that would be you. is that correct?
[22:17] <iitg-cs-grad> hi ... I am have compiled kernel 2.6.35.4
[22:18] <iitg-cs-grad> and am trying to boot from it
[22:18] <iitg-cs-grad>  it says device / not found or not ready after booting into it
[22:18] <iitg-cs-grad> when i skip it says /tmp not found or not ready after booting into it
[22:19] <iitg-cs-grad> I am using a wubi over win
[22:19] <iitg-cs-grad> I saw on the forums mentioning something about giving UUID to the boot parameters
[22:19] <iitg-cs-grad> I dont seem to proceed after that...
[22:20] <iitg-cs-grad> ne1?
[22:21] <siretart> !offtopic | iitg-cs-grad
[22:21] <ubottu> iitg-cs-grad: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
[22:21] <iitg-cs-grad> ty!
=== dendrobates is now known as dendro-afk
[22:41] <lifeless> barry: hey
=== JackyAlcine_ is now known as JackyAlcine
=== dendro-afk is now known as dendrobates
[22:46] <barry> lifeless: hi
[22:47] <lifeless> would love feedback in the concurrent package thread :)
[22:49] <barry> lifeless: tbh, i've been ignoring it ;)  i got swamped during the break and just deleted the thread.  maybe i should go to gmane and read up on it?
[22:49] <lifeless> barry: Well I need to know if my proposal will work
[22:50] <lifeless> and then to figure out the setuptools invocation magic to make it happen
[22:50] <barry> let me take a quick look
[22:50] <lifeless> and finally what dh python changes to make
[22:50] <lifeless> the last seems easiest to me ;)
[22:51] <barry> lifeless: oops, you don't mean the futures package thread on python-dev, right?
[22:51] <lifeless> barry: god no
[22:51] <lifeless> barry: thats a train wreck
[22:52] <lifeless> also I would have asked on #python-dev about that one :)
[22:56] <barry> lifeless: hang on...
=== sconklin is now known as sconklin-afk
=== JanC_ is now known as JanC
=== bjf is now known as bjf[afk]
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates