[11:00] <dholbach> mdz: my take too.
[11:00] <dholbach> So I'll just clean up the init script.
[11:01] <sivang> hey mdz
[11:01] <Nafallo> daniels: thanks! :-)
[11:01] <daniels> Nafallo: hm?
[11:01] <Nafallo> daniels: re #28911 ;-)
[11:01] <daniels> oh, no worries
[11:03] <mvo> anyone interessted in testing the dist-upgrade feature of update-manager for the breezy->dapper upgrade? add "deb http://people.ubuntu.com/~mvo/update-manager /" to your sources.list and install update-manager then. it will offer you a dist-upgrade to dapper then.
[11:04] <seb128> mdz: do we want gaim 2.0 for dapper? They should have the 2.0 beta 2 out soon but no fixed calendar afaik (they planned 2.0 for december but delayed after feedback from beta 1)
[11:04] <seb128> s/calendar/schedule
[11:04] <ogra> soounds risky ...
[11:05] <Burgwork> mvo, anything we should be watching for in particular?
[11:05] <Nafallo> let's put gajim in main ;-)
[11:05] <Burgwork> shipping without it means bad PR
[11:05] <jdub> seb128: as gaim2 maybe :-)
[11:05] <ogra> jdub, in universe ?
[11:05] <dholbach> ogra: in dapper-backports :)
[11:06] <ogra> lol
[11:06] <mvo> Burgwork: it should (hopefuly) be self-explained. you can back-out, no worries :)
[11:06] <Burgwork> mvo, no, in a testing sense. Any place where you think it might break
[11:07] <seb128> jdub: hum, could do that ... but there is still the question to know if that's an UVF potential exception
[11:07] <mvo> Burgwork: I'm mostly interessted in seeing how it copes with "real" systems, not my test-systems (where it does a pretty good job calculating the upgrade)
[11:07] <OpsVentus> Right now I'm using Qt3 for GUI (in combination with c++) but now I'm thinking about updating to Qt4 but this is a large change, so I want to check if Qt4 is the way to go or if there's a better cross-platform(mainly KDE/GNOME/Windows/OSX) toolkit for small programs?
[11:08] <OpsVentus> So what's everybody's opinion?
[11:08] <Burgwork> mvo, ok
[11:08] <dholbach> OpsVentus: You'd better ask in #kubuntu.
[11:09] <OpsVentus> dholbach: but I program in GNOME and want the program's to work good in GNOME, still #kubuntu?
[11:09] <spacey> OpsVentus, wxwindows?
[11:10] <OpsVentus> spacey: why's wxWindows better?
[11:10] <dholbach> OpsVentus: If you ask about QT4, they might have more expertise with it.
[11:10] <OpsVentus> ok, gonna go there
[11:11] <spacey> OpsVentus, no idea, just know its crossplatform :p
[11:11] <mdz> doko: why internal neon for openoffice.org?
[11:11] <OpsVentus> yeah, so is qt
[11:11] <ogra> or gtk
[11:12] <mdz> doko: is it a big project to update it for new libneon?
[11:14] <mdz> seb128: if it doesn't have a credible schedule, I think we probably shouldn't
[11:14] <doko> mdz: it's temporary, just wanted OOo to be installable again
[11:15] <seb128> mdz: should we package it as gaim2 and switch it 2.0 comes soon?
[11:15] <seb128> s/it/if
[11:16] <mdz> seb128: if you have time to do the extra work, sure
[11:16] <Nafallo> gaim2 would have the benefits of testing and community love (atleast in #ubuntu.se).
[11:17] <seb128> mdz: hum, good point. I'll try to find somebody motivated to do it if possible ... :)
[11:18] <ogra> sivang, thanks i need it ..
[11:19] <sivang> ogra: you're welcome, always.
[11:19] <ogra> :)
[11:30] <Nafallo> daniels: did you ever upload the fixed x11-common? I can't see it on dapper-changes.
[11:32] <OpsVentus> I wrote a Sudoku game, any intressed to include this in (K)Ubuntu?
[11:32] <ogra> OpsVentus, #ubuntu-motu
[11:32] <OpsVentus> ok
[11:33] <ogra> but given the fact that we have UVF tomorrow, its unlikely that you can get it in in time
[11:33] <daniels> Nafallo: 'fix committed', not 'fix released' ;) just sorting out clean chroot testing
[11:34] <OpsVentus> then next release or something
[11:35] <Nafallo> daniels: oh. I thought committed was uploaded :-P. but okey :-).
[11:36] <daniels> aiui, bugzilla -> malone terminology is PENDINGUPLOAD -> Fix Committed, RESOLVED/FIXED -> Fix Committed
[11:36] <daniels> er
[11:36] <daniels> the latter should be Fix Released
[11:36] <ogra> uploaded :)
[11:36] <daniels> i guess it assumes we're all using version control
[11:36] <lucas> problem is that malone sometimes considers that fix commited bugs are "fixed"
[11:36] <lucas> and doesn't display them in normal listings
[11:37] <lucas> (I opened a bug about this)
[11:37] <daniels> oh, cool
[11:38] <Nafallo> hehe, go bzr! :-)
[11:47] <theine> Are there any guide lines on when a certain bug is to be specified as minor,normal,major,etc...?
[11:48] <theine> I mean classified...
[11:49] <infinity> theine: If it's a small annoyance or typo or something, it's minor, if it's like 99% of most bugs, it's normal, if it seems like a bug that would affect EVERYONE and be a big hindrance, it's major, if it's OH MY GOD, THE WORLD IS CRASHING IN AROUND US, IF IT'S NOT FIXED, NO ONE CAN USE THEIR COMPUTERS, it's critical.
[11:49] <dooglus> sivang: I am.
[11:50] <dooglus> sivang: (in response to "14:54 < sivang> dooglus: are you Chris Moore ?")
[11:50] <theine> infinity, thanks, I didn't expect the bar for critical to be that high
[11:51] <daniels> theine: critical is HOLY SHIT YOU MUST DROP EVERYTHING NOW TO FIX THIS
[11:51] <theine> So a reproducible bug that leads to a system freezy every time on certain hardware is to be clasified as normal?
[11:51] <theine> daniels, ok, good to know...
[11:51] <daniels> theine: it's the bug equivalent of your boss calling you at 3am because a fortune 50 customer's site is down
[11:51] <Kamion> generally people shouldn't report bugs at critical; leave it to developers to do that triage
[11:51] <daniels> theine: probably major there
[11:51] <Kamion> otherwise we just get into the habit of downgrading critical bugs at sight, which of course has its own problems :)
[11:52] <infinity> theine: Depends on the popularity of the hardware and the driver in question, really.  If it's, say, a very common IDE controller, and it happens for everyone, that's major.  If it's an obscure USB wireless dongle that you and one other guy own, it's probably normal.
[11:53] <sivang> dooglus: oh hi :) I already updated the bug report, as you might have already seen
[11:53] <theine> infinity, I'm actually refererring to this: https://launchpad.net/malone/bugs/28544
[11:53] <Ubugtu> Malone bug 28544: "kernel BUG at net/ieee80211/ieee80211_geo.c:81! (2.6.15-12.17)" Fix req. for: network-manager (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[11:53] <ogra> lol
[11:54] <ogra> we just discussed this one in #ubuntu-bugs :)
[11:54] <infinity> Well, it would be helpful if that wasn't filed against network-manager. :)
[11:55] <ogra> yup :)
[11:55] <theine> infinity, exactly, that leads me to my next question. How does one go about transferring the bug to linux-source or whatever?
[11:56] <theine> ogra, and I guess it was decided to classify it as having normal severity?
[11:56] <ogra> yes
[11:56] <sivang> dooglus: thanks for the patch. programs should never exit with a segfault/coredump.
[11:57] <theine> ogra, but the reason is not that network-manager is not in main, is it?
[11:58] <ogra> theine, the reason is that network-manager breakage is no reason to classify anything as critical
[11:58] <ogra> or major ...
[11:58] <infinity> theine: What version does your ipw2100 driver report in dmesg when it's loaded?
[11:58] <theine> ogra, well, it's actually linux kernel breakage
[11:58] <dooglus> sivang: yes, I saw thanks.
[11:58] <ogra> theine, thats the prob ...
[11:58] <theine> infinity, 1.1.3 and I guess that's the problem. it should be 1.1.4
[11:59] <infinity> theine: Yup.  1.1.4 resyncs with ieee80211-1.1.7
[12:00] <infinity> theine: Bugged BenC about it.  Should be fixed in the next kernel upload.
[12:00] <dooglus> sivang: it was a strange one.  I hadn't looked into glib before, but the memory allocation is strange.  the call to "free" actually changes the contents of the memory it's freeing.
[12:00] <theine> infinity, cool, thanks
[12:01] <ogra> theine, change the bug to fix pending ;)
[12:01] <theine> ogra, okidoki
[12:01] <Burgwork> theine, transfering a bug is a beast in LP
[12:02] <ogra> ARGH....


[11:12] <mamarley> ricotz: 375.26 is in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages :)
[11:17] <ricotz> mamarley, currently running it ;)
[11:18] <mamarley> Any reason not to copy it to the main PPA then?
[11:31] <ricotz> mamarley, looks good, so no
[11:31] <mamarley> OK, I will do that.
[12:41] <ricotz> mamarley, thx
[12:46] <mamarley> No problem


[11:41] <Dori922> hey, is it possible to have the front end, internet and NC all connected to a single switch and use DHCP?
[14:40] <Dori922> why is this room here :/ questions are never asked/answered and even fun chit chat isnt around :(
[15:11] <koolhead17> Dori922, its friday
[15:12] <Dori922> koolhead17: is there much slowdown on weekends? :o ive popped here a few times.. always mega quiet compared to #ubuntu
[15:13] <koolhead17> Dori922, i would agree. its 2 quite compared to Ubuntu :)
[15:14] <Dori922> koolhead17:  we'll have to fix that!! :D right now the idlers will see people talking here and be like "OMG That looks fun!! i wanna join in!!!!!" :P
[15:15] <koolhead17> Dori922, its ubuntu-cloud bit different
[15:15] <koolhead17> :P
[15:15] <koolhead17> we all are surfing cloud
[15:15] <koolhead17> :)
[15:18] <Dori922> what do ya mean :O *only learning UEC this past week so not much to surf yet*
[15:43] <Dori922> hey dudes run into a snag, i've installed UEC on a machine without VT so im installing XEN using this guide
[15:43] <Dori922> https://help.ubuntu.com/community/Xen#Install%20from%20packages%20%28recommended%29
[15:44] <Dori922> im at step 2 now and it says "cd <src> #check out the 'xen/master' default branch #check out the latest xen/stable branch"
[15:44] <Dori922> not seeing those files
[15:51] <Dori922> koolhead17:  <3 your the only one who has spoken  here :P
[16:19] <koolhead17> Dori922, better would be asking questionin the mailing list
[16:20] <Dori922> mailing list?
[16:20] <Dori922> ahh ui see topic
[17:58] <smoser> RoAkSoAx, so do you want to switch time slots with me ?
[17:59] <smoser> i can primarily do 19:00 utc on monday and you can primarily do 17:00 utc tuesday
[17:59] <smoser> as it makes sense for dev-env to go before ensemble deployment
[18:00] <RoAkSoAx> smoser: let me check schedule
[18:01] <smoser> yeah, i see in -server
[18:04] <adam_g> is xvda vs xvde on m1.small a natty vs oneiric thing?
[18:11] <kim0|vacation> smoser: RoAkSoAx I just edited the schedule .. feel free to re-edit
[18:11] <kim0|vacation> might be better to be one big session though
[18:27] <smoser> SpamapS, would it be ok with you if i open a bug 810044 task against upstart and assign you?
[18:27] <uvirtbot`> Launchpad bug 810044 in cloud-init "cloud-init will have race conditions for cloud-config with multiple network adapters" [Medium,Confirmed] https://launchpad.net/bugs/810044
[18:29] <smoser> https://plus.google.com/102150693225130002912/posts/CJpyYdCqBL8 is messed up.
[18:29] <SpamapS> smoser: the actual problem is in ifupdown
[18:30] <SpamapS> smoser: and if I didn't have slides to finish by the end of today, I'd have uploaded a version of ifupdown which produces a 'static-network-up' event which means all auto interfaces in /etc/network/interfaces are up
[18:31] <smoser> SpamapS, have a branch with that?
[18:32] <SpamapS> why yes I do..
[18:32]  * SpamapS digs it back out
[18:33] <SpamapS> smoser: I've been thinking about what to do on the down event..
[18:36] <SpamapS> smoser: lp:~clint-fewbar/ubuntu/oneiric/ifupdown/static-network-up
[18:36] <SpamapS> smoser: only moderately tested (on my laptop and a vm)
[19:45] <hallyn> jamespage: hey, i was trying last night to fire off jenkins formulas, but it never would let me relate jenkins to jenkins-slave.  AFAIK nothing should have changed since the last time i tried (successfully) with your packages - other than ensemble package itself being updated
[19:45] <hallyn> jamespage: have you tried in the last few days?
[22:41] <SpamapS> hallyn: what was the error?
[23:09] <hallyn> SpamapS: something about relation endpoints not existing
[23:09]  * hallyn retries
[23:11] <hallyn> and then sometimes it gets the wrong key
[23:35] <SpamapS> hallyn: I believe you have to be more explicit ..   servicename:relation-name


[01:00] <datagen24> trying to find a solution to no sound in recordings, my backend(s) are HP dl380s with no sound a 3 tuners each. my front ends are apple mac minis. some recordings have sound others do not, i have not found a rhyme or reason to which ones have sound and which ones do not, any ideas?
[01:00] <qwebirc57882> Hello, I've just done a fresh install of Mythbuntu 11.04 x64.  It is a remote frontend and is perfect except for one thing.  When I attempt to enter the Watch Videos Section It immediately crashes the frontend.  Terminal output is as follows "ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/qt4/QtCore/qlist.h, line 464 Aborted "  I'm pretty sure this started happening immediately after enab
[01:01] <qwebirc57882> Datagen, on the ones that work, is the sound lower than you would expect?
[01:02] <datagen24> nope sound levels are normal
[01:02] <datagen24> if you looks at the mpeg file it has audio tracks of nothing but silence
[01:03] <qwebirc57882> yikes, sorry that's out of my league :)
[01:04] <datagen24> it has me and all my buddies stumped, only thing we see online is alsamixer is muted
[01:04] <datagen24> on the backend
[01:04] <datagen24> in this case there is no sound device for alsamixer to use as the 380s have no sound output
[02:35] <fizy[droid]> is there any way to launch the mythbuntu  front end from the live cd without having a back end set up?
[02:36] <fizy[droid]> well, live usb to be more specific
[02:38] <tgm4883> fizy[droid], what is your desired outcome?
[02:39] <fizy[droid]> to test the front end before I install the OS.. I already installed it on a VM, and it loaded up there, but it needs a back end from the live boot
[02:40] <tgm4883> fizy[droid], do you have a backend somewhere else in your environment?
[02:42] <fizy[droid]> no. and I have no intention of doing so. I have a network drive with about a hundred ISOs on it. I'm setting up a media computer
[02:42] <tgm4883> fizy[droid], then you likely don't want mythtv
[02:42] <tgm4883> have you looked at XBMC?
[02:46] <fizy[droid]> I believe so. but the vm can connect to the network drive, and mythbuntu on the vm can list the iss just fine. plus, I like the look and feel of mythbuntu. it feels like a dvd player, not a computer
[02:47] <tgm4883> well XBMC doesn't look like a computer either. That said, if you really want to use MythTV then you might be able to launch the frontend straight into the video plugin. I'd have to look up the command
[02:49] <Araya213> Hello, I've just done a fresh install of Mythbuntu 11.04 x64.  It is a remote frontend and is perfect except for one thing.  When I attempt to enter the Watch Videos Section It immediately crashes the frontend.  Terminal output is as follows "ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/qt4/QtCore/qlist.h, line 464 Aborted "  I'm pretty sure this started happening immediately after enabling
[02:50] <tgm4883> fizy[droid], looks like it is just mythfrontend mythvideo
[02:50] <tgm4883> err, "mythfrontend mythvideo"
[02:51] <tgm4883> Araya213, after enabling what?
[02:54] <tgm4883> What theme?
[02:54] <Araya213> Mythbuntu 1.0 and MythCenter 1.1 both do it
[02:55] <Araya213> And it happens regardless of the menu theme
[03:04] <tgm4883> Araya213, you will probably need to use --override-setting KEY=VALUE when starting mythfrontend. I've not heard of that issue, or the KEY that you would need so I would ask in #mythtv-users if I were you
[03:09] <Araya213> alright, checking there
[03:41] <Araya213> tgm4883 hey thanks man got it worked out now!
[07:46] <lapion> okay this is really annoying now I have reconfigured from scratch a framegrabber and when scanning mythtv 0.25 locks at every channel in the list even if it doesn't have signal on it.
[07:47] <lapion> oops sorry, at least now it doesn't have that reaction to each channel, now it detects none at all..
[07:48] <lapion> while in vlc I can connect to any channel and watch it..
[07:54] <lapion> nvm stupid me not setting groups for mythsetup running user


[00:00] <slangasek> (and has to, because /etc/init/networking always races /etc/init/network-interface)
[00:01] <stgraber> ok, so the problem is the second interface trying to join the bond before it's done being brought up by the ifup triggered by the first interface (when both eth0 and eth1 appear at the exact same time)
[00:08] <slangasek> stgraber: yeah, that's probably one of the problems, at least
[00:15] <haakon_n> So do all new packages in Debian get automatically attempted to be added to universe in ubuntu, or do they need to be requested to be synced? It was a little foggy on the matter on the ubuntu wiki.
[00:17] <tumbleweed> haakon_n: They don't need to be requested, but they do need manual review by the archive-admins. If they are lagging on the review, or it's urgent, they can be poked, or a sync can be requsted.
[00:18] <haakon_n> so they do automatically get reviewed just from being in debian?
[00:18] <tumbleweed> if they make it to testing (because it's an LTS, so we are syncing from testing), yes
[00:18] <haakon_n> get to be reviewd, that is
[00:18] <haakon_n> ok
[00:19] <haakon_n> So is there a public page where you can follow the current state of pending packages, etc?
[00:21] <tumbleweed> No, unless it's been synced by a developer, in which case it shows up in the NEW queue
[00:21] <haakon_n> ok :)
[00:26] <slangasek> pitti: why did udev move to /lib/udev?
[00:39] <slangasek> stgraber: so now that I've isolated a udev upgrade bug here (udevd not actually running), I do get udev events when bond0 is brought up
[00:39] <slangasek> s/brought up/created/
[00:41] <stgraber> slangasek: ok, so I guess we could do 'echo +bond0 > /sys/class/net/bonding_masters' which should create the bond and trigger udev
[00:44] <slangasek> stgraber: yep
[00:54] <SpamapS> slangasek: I'm putting forth a plan to drop mysql 5.1 entirely as soon as we've transitioned to libmysqlclient18 entirely.. do I need to even bother uploading a new mysql-5.1 that does not build libmysqlclient-dev (and the other bits) ?
[01:00] <slangasek> SpamapS: I wouldn't bother unless you think you're going to need to upload it in the meantime for other reasons
[01:00] <slangasek> the package would simply not be uploadable without that change, which isn't a major problem if you're not uploading it :)
[01:00] <SpamapS> slangasek: right, thats what I was thinking. I've got a branch with it on deck if the need arrises.
[01:02] <stgraber> slangasek: so current plan sounds like: http://paste.ubuntu.com/738823/
[01:03] <stgraber> slangasek: should be doable with only limited changes to the current scripts so we don't divert too much from Debian
[01:04] <slangasek> stgraber: "wait for" - that implies polling...
[01:04] <slangasek> if you have to poll, you might as well just call ifup instead
[01:05] <slangasek> but you might be able to have the slave added from the pre-up master when triggered?
[01:07] <stgraber> well, I'd have to call ifup + poll anyway as in my tests, the second NIC comes up before ifup is done loading the kernel module and preparing bond0
[01:07] <stgraber> I'd rather not have a different code path for the first interface and for the second, trying to keep things simple :)
[01:13] <slangasek> stgraber: wouldn't both slaves end up waiting for ifup in that case?
[01:15] <stgraber> slangasek: yes, whichever gets to the ifup part first actually starts it (the second one will just fail doing so), then they both wait for /sys/class/net/bond0 to appear and then add themselves to the list of slaves (that part shouldn't be racy, so it's fine having both doing it at the same time)
[01:15] <slangasek> ah, I didn't think it would fail, I thought it would wait for the lock
[01:15] <slangasek> you've tested this?
[01:17] <stgraber> I'm getting a:
[01:17] <stgraber> ifup: interface br0 already configured
[01:17] <stgraber> (tested with a bridge instead of bond because I'm on my laptop :))
[01:17] <stgraber> that's while another ifup br0 is running waiting for 10s (sleep in the pre-up script)
[01:19] <slangasek> stgraber: ah, that's pretty conclusive then :)
[02:30] <hallyn> SpamapS, so to fix my bad upload of libvirt that ftbfs for lucid-proposed;  should i push fix with incremented version # ?  Or can I just as well push with same version # since it failed to build anyway?
[02:31] <slangasek> hallyn: new version number needed, launchpad already knows about that source version
[02:36] <hallyn> slangasek, thanks
[02:37] <hallyn> slangasek, one more q though :)
[02:37] <slangasek> shoot
[02:37] <hallyn> does that mean that I should do -v<version-2> ?
[02:37] <hallyn> so that if/when it goes to -updates, launchpad catches the '(LP: #xxxxxx)' from the previous commit msg?
[02:37] <slangasek> hallyn: preferably, yes
[02:37] <hallyn> cool, thanks
[05:19] <pitti> good morning
[05:20] <pitti> cjwatson: haskell-dummy> whoa, I'll have a look at that one
[05:23] <pitti> cjwatson: rather, it should just operate on the current binary, as it's called through dpkg-deb; there used to be a reason why it does that double interation, though
[05:23] <pitti> slangasek: I'm not sure, upstream decision; but I figure they wanted to have the daemon out of $PATH
[05:24] <slangasek> pitti: upstreams frequently get the FHS wrong; I would suggest we put it back in sbin
[05:24] <slangasek> (udev upstream in particular is clue-impaired where the FHS is concerned ;)
[05:25] <slangasek> pitti: I noticed this because of bug #889226, fwiw
[05:25] <pitti> oh, does it say that daemons should be in $PATH?
[05:26] <slangasek> pitti: sbin is "system binaries", which certainly covers udev
[05:27] <pitti> so, I don't mind much where it lives; we can just revert the commit that changed the path and change the .install
[05:27] <pitti> but AFAICS bug 889226 needs to be fixed anyway
[05:27] <slangasek> agreed on both counts
[05:28] <pitti> okay, will do today
[05:28] <slangasek> pitti: ok, cheers :)
[06:16] <broder> can i get an archive admin to run the backport-helper script? we've had a bunch of pending backports for a little while now
[06:59] <pitti> slangasek: I'm not actually sure why Keybuk added "restart udev || true", i. e. whether it was expected to fail sometimes; but I guess it really shouldn't fail
[07:00] <pitti> and why it's using --no-start with dh_installinit
[07:00] <slangasek> pitti: probably to work around the behavior when trying to call 'restart' in a chroot
[07:00] <slangasek> (but this is the wrong solution; chroots that shouldn't have services started inside of them should have a policy-rc.d, or a diversion)
[07:01] <pitti> *nod*
[07:02] <pitti> slangasek: so invoke-rc.d is still the right thing to call, despite it's verbose "this is not the script you are looking for" warning?
[07:02] <slangasek> that warning isn't from invoke-rc.d itself, and yes it is the right thing to call :)
[07:03] <slangasek> (the warning is from /lib/upstart-job, and is explicitly suppressed when called from maintainer scripts)
[07:03] <slangasek> /lib/init/upstart-job, even
[07:05] <pitti> slangasek: something like http://paste.ubuntu.com/738960/ ?
[07:05] <slangasek> pitti: no
[07:05] <slangasek> lose the conditional
[07:05] <slangasek> invoke-rc.d is always present, and is always the right interface
[07:05] <pitti> . o O { checking for -x invoke-rc.d really seems antique, but is still common pracice in Debian }
[07:06] <pitti> slangasek: okay (also, s/rsync/udev/ of course)
[07:06] <slangasek> heh, right :)
[07:07] <slangasek> as for it being common practice in Debian, I'm pretty sure I chased that out of policy and debhelper a little while ago ;
[07:07] <slangasek> )
[07:07] <slangasek> yeah, February of this year, Debian bug #610340
[07:07] <slangasek> :)
[07:07] <pitti> ah, so the existing scripts like rsync's just haven't been rebuilt since then
[07:08] <pitti> slangasek: thanks; building/testing now, will upload in a bit
[07:09] <slangasek> pitti: yay, thanks :)
[08:02] <dholbach> good morning
[09:12] <pitti> cjwatson: I filed the "too many iterations" part as bug 890595
[09:17] <pitti> and the FTBFS part as bug 890596
[09:17] <pitti> Laney: ^ FYI, if you got spammed with the haskell-dummy FTBFS log; I'll fix this in pkgbinarymangler and retry
[09:26] <cjwatson> pitti: I started out saying "it should just operate on the current binary" but I assumed that it was operating on all of them because it wanted to produce a single tarball
[09:27] <pitti> cjwatson: right, it should merge them together if it already exists; it already does that with the _translations_static.tar.gz stuff
[09:27] <cjwatson> ok, if you think that'd be reasonably performant :)
[09:27] <pitti> but anyway, it's producing a lot of output, but that's not what's breaking the build, and if the translations tarball already exists it doesn't do much
[09:27] <pitti> (that's why I set it as "low")
[09:45] <brendand> anyone know how to make python look in a particular location for a module before looking in /usr/lib/python2.x/dist-packages ?
[09:45] <cjwatson> sys.path.insert(0, ...)
[09:47] <brendand> ah, yeah - i saw that somewhere before. thanks
[09:47] <nigelb> Alternatively, try virtualenv if the package is available in PyPI.
[09:49] <pitti> brendand: or call the program with $PYTHONPATH if it's temporary and you don't want to modify the source
[09:50] <cjwatson> Although I'm currently converting a package from using private modules to using public modules, because it's more useful that way.
[09:50] <brendand> pitti - so if a module is on the PYTHONPATH it should be taken from there first?
[09:50] <pitti> yes
[09:51] <pitti> brendand: cjwatson's suggestion is the right one if you want to use private modules in your project
[09:51] <pitti> $PYTHONPATH is right if you want to test somethign with a local version of a system module
[09:52] <pitti> I often do things like "PYTHONPATH=. ./gtk/apport-gtk" to test the apport modules from trunk
[09:53] <brendand> pitti - my problem is solved now. but it seemed like my script was using the system version of lazr.restfulclient even though i had a local version in the PYTHONPATH.
[09:54] <brendand> which i thought was strange
[10:00] <Laney> pitti: ah, hadn't noticed — actually, how can I subscribe to build failure notifications? I only know how to get bug mail.
[10:01] <pitti> Laney: usually it mails the uploader and the Maintainer:, but perhaps not for Debian syncs
[10:01] <Laney> maintainer will be the team
[10:01] <Laney> (and I've never seen a mail like that for a sync, indeed)
[10:05] <cjwatson> there's a bug about that I think
[10:05] <Laney> or even a manual upload (to the maintainer), I don't think?
[10:05] <Laney> I suppose the lists swallow them though
[10:07] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/876594 is basically the same
[10:07] <cjwatson> I definitely get notifications for failed builds that I've uploaded ordinarily
[10:08] <Laney> as /uploader/, yes
[10:08] <Laney> but I do not think I have ever seen anything as Maintainer except from MoM
[10:08] <cjwatson> generally it's complicated by the need to avoid spamming Debian developers with Ubuntu build failures
[10:09] <Laney> right, it is probably the right thing to do. I was after a way to explicitly subscribe to build failures :-)
[12:10] <pitti> cjwatson: argh, xubuntu failed to build, sorry about that; I'll fix the seeds to drop gnome-codec-installer (same like ubuntu)
[12:11] <pitti> cjwatson: oh, seems you beat me to it, thanks
[12:12] <cjwatson> pitti: yep, already done, also ubuntustudio
[13:38] <jcastro> slangasek: do you have old-powertop in a PPA somewhere?
[13:52] <cjwatson> perl busted on amd64, my fault, I'm working on it as top priority
[14:45] <kirkland> mvo: ping
[14:47] <mvo> kirkland: pong
[14:48] <kirkland> mvo: howdy!  mtaylor just noticed a really nasty new behavior with apt-add-repository
[14:48] <Daviey> bug 890708
[14:48] <kirkland> mvo: it appears to always require an interactive confirmation
[14:48] <kirkland> mvo: it's breaking all automated scripts and utilities that test from a PPA
[14:49] <Daviey> it seems that -y isn't silently ignored pre-oneiric.
[14:49] <kirkland> mvo: is this just a benign regression, or some new behavior we're going to have to work around?
[14:50] <mvo> kirkland: hm, so it does check is sys.stdin.isatty() - in what env do the scripts run?
[14:51] <mvo> Daviey: indeed, the fact that the old scripts do not have it is pretty nasty
[14:52] <kirkland> mvo: well that depends... juju runs in a tty env, i think :-(
[14:52] <mordred_> kirkland: hey. I'm here
[14:53] <kirkland> mtaylor-xchat: howdy :-)
[14:53] <kirkland> mtaylor-xchat: what env did you notice this in?  juju?  or something else?
[14:53]  * mtaylor-xchat punches smuxi
[14:53] <Daviey> mvo: I think the following should be expected to work:
[14:53] <Daviey> #!/bin/sh
[14:53] <Daviey> add-apt-repository ppa:davewalker/ifupdown
[14:53] <Daviey> :)
[14:53] <mtaylor-xchat> yes
[14:53] <mtaylor-xchat> that's kindof how I noticed it.
[14:53] <mtaylor-xchat> for instance:
[14:53] <mtaylor-xchat> http://www.yorba.org/shotwell/install/
[14:54] <mtaylor-xchat> shows how to get the latest shotwell
[14:54] <mtaylor-xchat> if you cut and paste those commands as a sequence, it won't work (ok, bad example - there are $'s there) ... I could find another example though
[14:55] <mvo> mtaylor-xchat: well, I think its fine that it asks you in a interactive scenario, we do want to ensure that people have a vague idea what they are adding and that they thing about it. I do agree that in a script env this is bad though
[14:56] <mtaylor-xchat> mvo: it's the script env I'm most concerned about, tbh
[14:56] <mtaylor-xchat> mtaylor-xchat: but I personally find the interactive prompt quite intrusive and would love a systemic config way to disable it
[14:57] <mtaylor-xchat> wow. I'm bad with tab completion :)
[14:57] <mtaylor-xchat> mvo: I'm open to and will be happy with anything that solves Daviey's use-case above though :)
[14:57] <Daviey> mvo: I suggested perhaps have an env variable to have the old behaviour?
[14:58] <mvo> ok, let me think about it for a second, if a env var works fine, then I'm happy to add it
[14:59] <mtaylor-xchat> mvo: I could live with env var ... I'd personally LOVE something in a config file that could be driven by debconf questions so it could be preseeded
[15:00] <mtaylor-xchat> mvo: and would be happy to help do some of that work if we could get it landed in updates
[15:02] <hallyn> hm, help2man is unintallable on (my) precise (schroot) because of perl-base version mismatches?
[15:02] <hallyn>  liblocale-gettext-perl : PreDepends: perl-base (>= 5.14.2-3) but 5.12.4-6 is to be installed
[15:04] <cjwatson> hallyn: yes, working on it
[15:04] <cjwatson> I tried to avoid this but got something wrong
[15:04] <hallyn> cjwatson, cool, thanks.  just making sure i didn't mess something up
[15:04] <cjwatson> I bet you're on amd64?
[15:04] <hallyn> yup
[15:04] <hallyn> woudl it work on i386?
[15:04] <cjwatson> yes
[15:05] <hallyn> cool, that might tide me over, thanks
[15:05] <cjwatson> although some other things might break, it's a big transition and it wasn't practical to stage it all
[15:05] <cjwatson> precise/amd64 will be very broken for about the next hour
[15:07] <hallyn> cjwatson, thanks for the info
[15:18] <mvo> mtaylor-xchat: http://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/oneiric/revision/729 <- this is what I can offer right away, let me ponder a bit about Daviey example, it would be ideal if the a-a-r would detect that its run inside a script
[15:19] <Daviey> mvo: hah, linaro are disucssing the same issue right now, bug 886209
[15:28] <mtaylor-xchat> mvo: awesome
[15:30] <mvo> Daviey: :/ but their </dev/null seems to be a good workaround, I'm a bit anoyed that there is no better way to detect if run from a script or not, in shell I could (ab)use $- I guess, but not from within the a-a-r context
[15:31] <Daviey> mvo: Well the mtaylor-xchat use-case is using the same script on pre-oneiric and oneiric, and it seems adding -y breaks pre-Oneiric
[15:34] <mvo> Daviey: yeah, so the force environment or < /dev/null will both fix the problem. I'm sorry for the trouble this change is causing, we did it because it seems like the recommended way in a lot of blogs and we want people to be aware what its doing
[15:35] <stgraber> slangasek, Daviey: Updated patch for ifenslave, works great on my system here: http://paste.ubuntu.com/739257/
[15:35] <Daviey> mvo: Oh, don't be sorry - i thought it was a logical change.
[15:35] <stgraber> so that should work even if some slaves don't come up or come up really late in the boot sequence
[15:35] <stgraber> it also properly removes the bond interface when running ifdown (for some reason the older code didn't do that at all, basically leaving unused interfaces...)
[15:36] <Daviey> stgraber: More stuff had to be migrated to the function fired earlier?
[15:37] <Daviey> stgraber: TREllis would be happy to validate an SRU for Oneiric btw.
[15:37] <stgraber> Daviey: nope, I actually moved a big chunk of code to a function that's called after enslavement
[15:37] <Daviey> oh!
[15:38] <stgraber> the old code expected all the slaves to be ready before setting up the master, we can't guarantee that with our event based system
[15:38] <stgraber> so instead I moved that code to a function that's fired every time we add a slave
[15:38] <stgraber> also, there was a race condition where slaves would be added before all the sysctl were done running on the master
[15:39] <stgraber> caused by ifupdown not tracking "starting to configure" and "done configuring" separately
[15:39] <stgraber> so I had to add a /run/network/ifenslave.* file for each bond, that I can check before trying to add a slave
[15:39] <stgraber> (that "race condition" was basically happening every time I was booting my server here, with the kernel deciding to just block all the trafic on the bond :))
[15:40] <Daviey> stgraber: Is that a local server, or the one you were on yesterday?
[15:40] <stgraber> local server
[15:40] <stgraber> DELL 750 (dual intel gigabit) and a cisco switch with a 802.3ad setup
[15:42] <stgraber> I'll just wait for slangasek to have a look and test in his VM setup (using some non-802.3ad bonding), if that works there too, I'll push to precise first, then look into SRUing for >= lucid (anything that uses the event-based interface setup jobs)
[15:42] <Daviey> groovy
[15:43] <stgraber> I was hoping ifstate would actually save the state of the interface, but apparently it's just storing the interface name as soon as it's done anything
[15:43] <stgraber> so I had to implement an ugly "touch" to track when it's actually done configuring the interface...
[16:04] <slangasek> jcastro: old-powertop is in a precise somewhere; powertop-1.13
[16:04] <jcastro> ta
[16:04] <mterry> Riddell, heyo.  Would you mind processing precise NEW a bit?  trying to fix some FTBFS that are waiting on packages (notably libbison-dev and python-scikits.statsmodels)
[16:13] <jelmer> slangasek: hi
[16:14] <slangasek> jelmer: heya
[16:14] <jelmer> slangasek: I was wondering if you'd seen my comment on bug 890529 ?
[16:14] <slangasek> jelmer: hmm, I replied, didn't I?
[16:14] <slangasek> jelmer: it's an issue with the repository perms
[16:14] <slangasek> so we just don't get a very friendly error message when that happens
[16:14] <jelmer> slangasek: you adjusted the importance to low, but didn't reply to my comment with a traceback
[16:15] <jelmer> slangasek: which is what I'm after mostly :)
[16:15] <slangasek> jelmer: oh, well, I can provide the traceback if you still need that, I just thought "server perms screwed" would be sufficient :)
[16:17] <jelmer> slangasek: if you can, that would be useful. I'm curious about the code path - we should already be handling permission dnied errors
[16:20] <slangasek> jelmer: no traceback now, just an error message - posted to the bug
[16:23] <jelmer> slangasek: thanks
[16:30] <stgraber> slangasek: did you have a chance to look at the diff I posted earlier?
[16:32] <slangasek> stgraber: not yet, sorry
[16:32] <slangasek> it's still pre-coffee-AM here :)
[16:33] <stgraber> hehe
[16:35] <slangasek> mr_pouit: have you seen the xubuntu build failures?  sessioninstaller now conflicts/replaces/provides gnome-codec-install, so gnome-codec-install will need unseeded
[16:37] <smoser> http://paste.ubuntu.com/739317/ build failure make sense to anyone ?
[16:40] <smoser> hm.. i guess we need a newer libc6  maybe for perl-base which provides perlapi.
[16:42] <cjwatson> smoser: that should be fixed once the archive mirrors
[16:42] <cjwatson> smoser: don't worry about the build failures, I'll fix them all up in bulk
[16:42] <cjwatson> slangasek,mr_pouit: I fixed that this morning
[16:42] <cjwatson> oh, not a live-build failure I won't ...
[16:42] <smoser> cjwatson, no problem. just wanted to let someone know if it was the first report.
[16:42] <smoser> it'll get sorted out once you sort out packages.
[16:42] <cjwatson> smoser: we're in the middle of the perl transition, see ubuntu-devel.  I'll let you know once it's a bit further along for you
[16:43] <smoser> cjwatson, nightly will just keep trying and succeed at some point
[16:43] <smoser> :)
[16:43] <cjwatson> we don't need a newer libc6, that was my screwup while staging the first step of the transition
[16:44] <mr_pouit> cjwatson: yep, I saw the change, thanks :)
[16:52] <pitti> ah, seems packages gradually get installable again, thanks cjwatson
[16:52]  * pitti re-retries pkgbinarymangler
[16:57] <stokachu> has anyone seen this type of error when attempting to build a deb package? http://dpaste.com/656897/
[16:57] <infinity> stokachu: See the file it points you to.
[16:58] <stokachu> on reporting the bug?
[16:59] <stokachu> infinity, ^
[16:59] <infinity> stokachu: Yes.
[16:59] <stokachu> ok i did that and it's not a common error with gcc
[17:00] <infinity> stokachu: Unless you feel the urge to diagnose and fix the segfault yourself, in which case, thanks. ;)
[17:00] <stokachu> not exactly , didnt know if anyone has run into this issue before
[17:01] <infinity> stokachu: "this issue" is a segfault in the compiler.  There are many.
[17:01] <stokachu> ok so no you haven't run into this issue
[17:01] <stokachu> thanks
[17:01] <infinity> stokachu: On the other hand, you're using gcc-4.4, it may well be fixed in 4.6.
[17:02] <stokachu> im building for 10.04
[17:02] <infinity> stokachu: I run into GCC ICEs all the time.  I don't know if I've seen yours. :P
[17:02] <infinity> stokachu: What you can do to perhaps work around your specific issue is try different optimisation levels (-O1 or -O0, assuming you were building with -O2 before)
[17:03] <stokachu> ok ill try that
[17:05] <mterry> wgrant, hello!  do you know where the source for the ftbfs page is?
[17:05] <stokachu> vanhoof, im staring through your window, put some pants back on
[17:12] <cjwatson> pitti: yeah, making decent progress now
[17:15] <mterry> bdmurray, can you look at bug 459730?  i just had a user bug me about it
[17:17] <bdmurray> mterry: yes
[17:17] <mterry> bdmurray, thanks!
[17:20] <smoser> mterry, does someone actually want xconsole entry ?
[17:20] <smoser> or are they just annoyed at the warning
[17:21] <mterry> smoser, they seem to actually want it?
[17:21] <seb128> speaking about rsyslog: https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/841085
[17:21] <seb128> if anyone feels like working on that ;-)
[17:21] <mterry> seb128, if it builds, I don't care about it this month  ;)
[17:22] <mterry> seb128, find a way to break the build such that I'd have to display the logs to fix it
[17:22] <seb128> mterry, I can break the build for you if that helps :p
[17:22] <seb128> ok
[17:22] <seb128> mterry, yes sir! ;-)
[17:22] <mterry> seb128, this team isn't having the effect we'd hoped  ;)
[17:22] <seb128> hehe
[17:22] <seb128> mterry, you exercice other people creativity toward bug fixing, that's good as well ;-)
[17:23] <seb128> mterry, I've a new theory "given time any bug can be turned into a build issue", I need to verify if it's true ;-)
[17:24] <mterry> hehe
[17:24] <vanhoof> stokachu: :)
[17:25] <gmargo> I've noticed a problem on the packages.ubuntu.com site.  Someone on #ubuntu-website suggested I ask here.  The problem is that package descriptions are not provided for the Oneiric (or Precise) packages.  For instance, compare http://packages.ubuntu.com/oneiric/coreutils against http://packages.ubuntu.com/natty/coreutils and the omission is immediately obvious.
[17:26] <slangasek> gmargo: yes, this is because we now ship package descriptions in separate files on the server; please see the contact link on packages.ubuntu.com
[17:27] <slangasek> (I don't know if this has been reported to the maintainer of that site yet at all; I know the issue is being discussed for packages.debian.org)
[17:29] <gmargo> I have tried to contact<EMAIL_ADDRESS>(listed address on packages.ubuntu.com) a few weeks back but no reply.  And I don't know about packaging the descriptions - it just simply doesn't make any sense to _not_ describe a package on that package's page.
[17:31] <slangasek> gmargo: yes, it's a bug not by design
[17:31] <slangasek> contact> good to know; let me see what I can figure out
[17:34] <dobey> is the perl brokenness in P fixed up now?
[17:35] <slangasek> dobey: it's going to take some time before it's fully fixed, because it's a rolling rebuild
[17:35] <slangasek> it's fixed to the point that the autobuilders can continue making progress, at least
[17:36] <dobey> slangasek: ok; i uploaded an ubuntuone-client this morning, apparently right as it broke, and it failed to build. was wondering if i could tell it to rebuild, but i don't see how to do that on LP
[17:36] <micahg> there's also the ubuntu-build utility in ubuntu-dev-tools
[17:36] <slangasek> I presume there'll be a mass-giveback for packages having ftbfs during the critical window, but let me have a look
[17:37] <slangasek> micahg: what's that?
[17:37] <micahg> you can give back builds with it
[17:37] <slangasek> micahg: presumably only if you also have access to do so from the website, dunno if dobey has that and if that's why he's not seeing the button
[17:37] <micahg> well, it should work as long as you can upload it
[17:37] <micahg> if it doesn't, that's a bug
[17:38] <slangasek> dobey: intltool is known to still be broken AIUI
[17:38] <micahg> same for th eretry button
[17:38] <micahg> *retry
[17:38] <dobey> slangasek: ah, ok
[17:38] <slangasek> though I've entirely lost the reference to this
[17:38] <dobey> micahg: i don't have the retry button; i also have issues with edit buttons not appearing next to upstream series links on packages
[17:38] <slangasek> ah no, found now
[17:38] <slangasek> dobey: you don't have the retry button here? https://launchpad.net/ubuntu/+source/ubuntuone-client/2.0.0-0ubuntu3/+build/2927706
[17:39] <slangasek> dobey: but you do have upload rights?
[17:39] <dobey> yes
[17:39] <slangasek> dobey: bug in launchpad, please file
[17:39] <dobey> oh
[17:39] <dobey> on each arch there is a retry button
[17:39] <slangasek> ah, yes :)
[17:40] <micahg> right, since each arch is a separate build
[17:40] <dobey> there isn't one to rebuild on all archs though :(
[17:40] <micahg> dobey: ubuntu-build from ubuntu-dev-tools :)
[17:40] <dobey> micahg: ok, i'll try that
[17:40] <dobey> but i guess i still have to wait for intltool to be fixed
[17:40] <slangasek> dobey: oh, it looks like intltool is fixed now after all, so I think you should go ahead and give them back for building
[17:40] <dobey> oh ok
[17:41] <slangasek> (tested in a chroot, apt says I can install intltool+perl; that cjwatson works fast)
[17:42] <slangasek> ok, so what bloated my /usr by 200MB in the last week in precise?
[17:42] <slangasek> probably something that's not good for the CDs
[17:43] <dobey> you didn't install the webkit debug lib did you? :)
[17:43] <slangasek> pitti: ^^ do you happen to know of any major package size increases?  I did see some printing-related package upgrades in the run that ate the space
[17:44] <slangasek> cups, ghostscript, PPD updates
[17:45] <slangasek> dobey: webkit debug> heh, certainly not
[18:21] <dobey> yay, u1client built
[18:24] <dobey> slangasek: can you accept ubuntuone-client into oneiric-proposed? :)
[18:28] <cjwatson> dobey: I will be doing mass-retries once I get far enough, yes
[18:29] <dobey> cjwatson: ubuntuone-client is built successfully in precise now. i already retried it. but thanks, and thanks for fixing the breakage :)
[18:33] <slangasek> dobey: looking
[18:34] <slangasek> dobey: no, not possible, you need a different version number for the upload to oneiric-proposed than was used for precise; rejecting instead
[18:34] <dobey> slangasek: oh really?
[18:34] <slangasek> dobey: please reupload as ubuntuone-client 2.0.0-0ubuntu2.1
[18:34] <slangasek> yes, each upload accepted into the archive has to have a unique version number
[18:34] <dobey> bugger. ok, 2.1 it is
[18:36] <dobey> slangasek: 2.1 uploaded
[18:36] <slangasek> ok
[18:39] <slangasek> bryceh, doko: surely someone else can reproduce bug #863761 without me having to use my primary laptop for it? ;)  From what I can see, it should be reproducible on any system with a sufficiently recent processor and an intel graphics chip
[18:43] <SpamapS> slangasek: so, I was looking at but 440179 .. and thinking that there is a simple solutoin.
[18:43] <SpamapS> solution even
[18:44] <slangasek> SpamapS: if we want the semantics of 'service $foo restart' to be the same as 'invoke-rc.d $foo restart' wrt job start/stop, I'm ok with that
[18:45] <slangasek> though it seems low priority to me, since 'service' is a user interface rather than a programmatic one
[18:45] <SpamapS> slangasek: I think that would help quiet a lot of the "WTF" we see from automated systems.
[18:45] <slangasek> and users can well do "service $foo stop; service $foo start"
[18:45] <SpamapS> slangasek: that was going to be my next question. Should we be making 'invoke-rc.d' the recommended automation tool?
[18:46] <SpamapS> slangasek: many users seem unsatisfied with the "just use stop ; start" answer.
[18:46] <SpamapS> which has been my default as well
[18:46] <slangasek> there are times when invoke-rc.d should be used and times that it shouldn't
[18:46] <SpamapS> so
[18:46] <SpamapS> we need to have one place to recommend that an automated system use
[18:46] <SpamapS> /etc/init.d/xxx was that place before
[18:47] <slangasek> I think you need to clarify what you mean by "automated system"
[18:47] <slangasek> maintainer scripts are automated; they must use invoke-rc.d
[18:47] <SpamapS> puppet, chef, cfengine, my wonky bash scripts
[18:47] <juliank> AFAIK; invoke-rc.d blocks scripts from being run in the chroot, the others don't
[18:47] <slangasek> /etc/logrotate.d is automated, and must not use invoke-rc.d
[18:47] <slangasek> juliank: invoke-rc.d doesn't block chroot execution unless you've set it up to do so
[18:48] <juliank> slangasek: Yes, you can set it up like this. You can't do the same for the rest, right?
[18:48] <slangasek> standard chroot setup should involve creating /usr/sbin/policy-rc.d that returns 101, and diverting initctl and start-stop-daemon
[18:48] <slangasek> there's no reason you can't reroute all of these interfaces
[18:48] <SpamapS> can we ignore chroots for now?
[18:48] <slangasek> but in general there's nothing running in your chroot that will try to use any of them besides invoke-rc.d *anyway*, so that's sufficient
[18:49] <slangasek> SpamapS: definitely
[18:49] <SpamapS> There was a time where puppet could reliably expect that a service named "foo" would be controlled only by /etc/init.d/foo
[18:49] <juliank> slangasek: With "can" I mean in normal cases. You can obviously do it, but that's not the expected way to do it.
[18:50] <slangasek> yes it is ;)
[18:50] <SpamapS> And in turn, that /etc/init.d/foo restart would lead to a service that had just been started (whether by stop/start or by just failing to stop, then starting)
[18:50] <SpamapS> That is still true for anything carrying the /etc/init.d/foo symlink to upstart-job
[18:50] <slangasek> others expectations may be flawed in various ways, but if you expect services to be guaranteed not to start in your chroot, you should touch all three of those points
[18:51] <SpamapS> I had hoped that the service command would be suitable as a place to focus all future service control around.. automated or user-driven.
[18:51] <SpamapS> With the exception of maintainer scripts which are special.
[18:51] <slangasek> SpamapS: I think it's right to make /etc/init.d an implementation detail and move this up to the 'service' abstraction
[18:52] <slangasek> SpamapS: so please go ahead :)
[18:52] <SpamapS> alright, cool. :)
[18:52] <SpamapS> I think I'll do some man page tweaking too.
[18:52] <SpamapS>        service runs a System V init script in as predictable environment as possible, removing most envi‐
[18:52] <SpamapS> thats not exactly true. :)
[18:55] <stokachu> how does a deb package build without placing any files in the packages even though they were defined in their respective install files?
[18:55] <SpamapS> slangasek: assuming we'll skip the merges with Debian for now since they're all related to kfreebsd?
[18:55] <stokachu> so it sees the files or it would've errored saying so
[18:57] <mterry> doko, mind if I grab ocaml merge?
[19:06] <bryceh> slangasek, I'll give it a try once I get a couple of my intel systems on precise.  got a few other things to take care of first
[19:17] <slangasek> SpamapS: merges of what? sysvinit?
[19:17] <slangasek> SpamapS: I'm deferring sysvinit merges until I finish my own NMU of it (upstart support in Debian)
[19:17] <slangasek> SpamapS: you're still on point for the lvm merge, right?
[19:17] <slangasek> bryceh: ok, no hurry from my side :)
[19:29] <SpamapS> slangasek: yes, still assigned. :)
[19:31] <slangasek> SpamapS: ok.  I'm sitting on my hands, but would really like a version of lvm that doesn't complain about /proc/misc on every invocation :)
[19:35] <SpamapS> slangasek: I'll push the lvm merge up a bit on the stack then. :)
[19:35] <slangasek> ta :)
[20:31] <apw> cjwatson, pitti, it seems that some of our kernel binaries are in universe again, at least 2.6.38-13.52 for amd64 and i386
[20:37] <slangasek> apw: should all the binaries from that version (all flavors, all archs) go to main?
[20:37] <slangasek> if you don't know, I can work it out
[20:38] <apw> slangasek, from linux yes all are the same currently
[20:38] <slangasek> apw: fixing
[20:39] <apw> slangasek, i am a little confused as i thought rmadison listed /universe aginst things in the wrong place, yet they are in the wrong place in the pool
[20:39] <slangasek> apw: I can't speak to rmadison's behavior here
[20:41] <cjwatson> rmadison will reflect what's in dists/
[20:41] <cjwatson> (by definition; that's its data source)
[20:41] <apw> slangasek, i suspect this error may be systemic as 2.6.35-31.62 also seem to be over in universe in the pool
[20:42] <cjwatson> pool/ may contain symlinks between components so you shouldn't treat it as authoritative for this purpose)
[20:42] <cjwatson> it is systemic, it's a problem with copying out of PPAs
[20:42] <cjwatson> somebody has to override them into main afterwards :-/
[20:42]  * micahg thought there was a kernel helper for publishing
[20:43] <apw> cjwatson, i thought that the helper did that now, clearly not
[20:43] <apw> looks like 2.6.32-36.79 has fallen in there too
[20:43] <apw> and 2.6.24-30.96
[20:44] <apw> no scratch that i think 2.6.24 is ok, as we do have odd ones in there
[20:45] <apw> bah now i am unsure, i think 2.6.24-30.96 may be wrong for the generics at least, but there are some which belong there
[20:50]  * slangasek also wishes we had better cleanup of stale binary packages from -proposed
[20:51] <slangasek> cjwatson: shall I get those other versions as well?
[20:51] <slangasek> micahg: the kernel helper for publishing set the overrides when we used to send them through the unapproved queue - I don't think we have a new helper that handles the ppa copying
[20:51] <cjwatson> slangasek: please
[20:52] <micahg> slangasek: ah, I thought pitti had something for that
[20:52] <slangasek> well, maybe he does
[20:52] <slangasek> hasn't been shared with me :)
[20:53] <micahg> slangasek: copy-proposed-kernel.py in ubuntu-archive-tools
[20:53] <slangasek> micahg: I don't see anything in that script that fixes the component
[20:53] <micahg> ah, ok
[20:53] <Randolph> hi all
[20:54] <slangasek> Randolph: hello
[20:59]  * SpamapS takes the plunge and upgrades "the big laptop" to precise
[20:59] <broder> slangasek: if you're archive-admining at the moment, can i try harassing you again to run the backport-helper script in ubuntu-archive-tools?
[20:59] <broder> (it's been about 2 weeks since somebody ran it last, based on the outstanding requests)
[20:59] <slangasek> broder: sorry, I briefly took a look at that last night and found the interface entirely bewildering
[20:59] <slangasek> I've never seen this program before and can't say my first interaction with it has been pleasant
[20:59] <micahg> SpamapS: you might want to wait until the perl transition is finished (close to finished)
[20:59] <broder> slangasek: hmm, ok. i wrote it to match the interface of sync-helper
[21:00] <slangasek> what's sync-helper? :P
[21:00] <broder> i see :)
[21:01]  * slangasek has another look
[21:01] <broder> as i understand it, backport-helper writes out a file of instructions which you then pass to...mass-sync.py, maybe?
[21:01] <slangasek> ah
[21:01] <slangasek> I've never used sync-helper, I just run mass-sync manually
[21:01] <slangasek> I vaguely recall someone mentioning they were writing a wrapper and also vaguely recall being put off by the interface ;)
[21:02] <cjwatson> sync-helper is fasntastic
[21:02] <cjwatson> *fantastic
[21:02] <slangasek> fântastic
[21:02] <cjwatson> maybe the UI is a personal thing
[21:02] <broder> slangasek: i'd be happy to implement whatever interface would make it more likely to get run, if you tell me what such an interface would look like :)
[21:02] <cjwatson> SpamapS: yeah, I would wait 'til tomorrow, sorry, this is a slightly rough day
[21:03] <cjwatson> I know it's supposed to work at all times, my powers of archive persuasion slightly failed me today
[21:03] <broder> slangasek: alternatively, if you'd like, i can run backport-helper and tell you what you need to pass to mass-syncs
[21:03] <slangasek> broder: well, I run the command and the first thing it shows me is http://paste.ubuntu.com/739628/
[21:04] <slangasek> which seems to give me 8 options and no guidance
[21:04] <slangasek> broder: you running it and feeding me commands sounds more likely to result in a favorable outcome :)
[21:04] <broder> hmm...ok. yeah, that does seem confusing
[21:05] <broder> the intent is that, because backport requests don't have anything resembling a standardized form, the script has to rely on heuristics to figure out things like package names and such - this is an opportunity to fix when the heuristics go wrong
[21:05] <broder> of course, since i know what the heuristics are, i always make sure to form the requests in such a way that they will pass :)
[21:05] <cjwatson> so you hit 's', read the report, use the options to fix up anything that's wrong, hit 'b' to emit backport instruction
[21:06] <cjwatson> it writes out a file that you pass to mass-sync.py
[21:06] <broder> it does look like you have a slightly out of date copy of the script - i know cjwatson added rmadison output that's not in your paste
[21:06] <cjwatson> it automates the "oh my god I have to open 73 firefox tabs and then close all the bugs manually" bit
[21:06]  * slangasek bzrpulls
[21:06] <cjwatson> also broder fixed the bad handling of hyphens in package names
[21:06] <broder> and full stops
[21:06] <broder> both of which are relevant for the current queue
[21:07] <broder> the bit in parens is the information that will actually be used in the instructions; i guess that's also not very clear
[21:08] <slangasek> ah, so 'activity' shows that I'm using the buggy version :)
[21:08] <broder> yeah
[21:08] <cjwatson> yep
[21:09] <slangasek> and does the helper automatically only look at bugs in the correct state indicating the backports team has approved the backport?
[21:09] <broder> yes. it actually goes one step further and requires that a member of the backports team be responsible for it being in the correct state
[21:10] <slangasek> nice
[21:11] <slangasek> ok, backport-helper success
[21:11] <slangasek> and mass-sync fail
[21:11] <slangasek> debugging
[21:11] <broder> oh, crud. i bet you're hitting the issue with multiple backports of the same source package
[21:12] <slangasek> doesn't look like it
[21:12] <slangasek> http://paste.ubuntu.com/739641/
[21:12] <slangasek> running into the error on a package with only one backport
[21:13]  * broder blinks
[21:16] <broder> ah. that happens if the url is None
[21:16] <slangasek> yes
[21:16] <slangasek> trying to work out why it's none :)
[21:16] <broder> ...which means that sp.changesFileUrl() didn't return anything
[21:18] <slangasek> could it be an adverse interaction between the new syncing stuff and the backporting?
[21:20] <slangasek> the API resource in question is https://api.launchpad.net/1.0/ubuntu/+archive/primary/+sourcepub/2026865
[21:20] <broder> that seems likely
[21:21] <slangasek> https://launchpad.net/ubuntu/precise/+source/activity-log-manager/0.8.0-1 states "No changes file available"
[21:21] <broder> and that looks like a syncpackage'd sync
[21:21] <slangasek> yes
[21:21] <slangasek> so I'll skip that one for now
[21:21] <broder> let me see if i can adjust the backport script to not rely on the changes file, because i don't think we need to anymore
[21:21] <slangasek> broder: yes please :)
[21:21] <broder> especially since it's just looking for the .dsc - that should be in .sourceFileUrls()
[21:22] <slangasek> apw: lucid,maverick,natty kernels all overridden back to main; hardy sounds like it needs more tweaking?
[21:22] <slangasek> broder: libgdata also affected, skipping
[21:25] <slangasek> *now* I'm hitting the bug with backporting to multiple suites ;)
[21:27] <broder> i don't really understand that bug, only that it exists, but if you can describe it and it's something i can help with, i'm always interested in making the backports process smoother
[21:28] <slangasek> I think it's that the scripts get upset when the .orig.tar.gz it's trying to write to the staging directory on cocoplum already exists
[21:29] <slangasek> so it could be smarter about checking if it's the same file instead of aborting
[21:30] <slangasek> not sure if/where the backend code is published however
[21:30] <broder> it looks like the stuff in u-archive-tools just ssh's to cocoplum and runs /home/lp_archive/bin/sync-backend, so it sounds like that might not be something i can really help with
[21:30] <slangasek> yeah, it's /home/lp_archive/bin/backport-source-backend for the relevant bits here
[21:35] <broder> i think bzr:~broder/ubuntu-archive-tools/backpoirt-without-changes-file should fix the syncpackage issue
[21:36] <bdrung> broder: backpoirt?
[21:36] <broder> uh, typo on my part - the branch itself os spelled correctly :)
[21:37] <slangasek> narf poirt
[21:38] <broder> i'm not IRC'ing from my ubuntu dev box at the moment, so i have to re-type everything :-P
[21:39] <slangasek> broder: I assume you also meant lp:~ rather than bzr:~ ?
[21:39] <broder> indeed
[21:43] <SpamapS> cjwatson: heh, no worries, pre-alpha1 I'll be happy if nothing catches on fire. :)
[21:43] <SpamapS> and also, I'm dist-upgrading from a local mirror about 24 hours behind
[21:43] <SpamapS> might have just missed the start of the perl transition
[21:45] <SpamapS> anyway, time for the dentist
[22:00] <bdmurray> If I found 2 debian bug reports that are duplicates what is the process for merging them?
[22:01] <wgrant> mterry: lp:lp-ftbfs-report
[22:04] <slangasek> bdmurray: if you have devscripts installed and the bts command configured, you can do 'bts forcemerge $bug1 $bug2 # these are the same bug because $reason'; or you can manually send the same command, 'forcemerge $bug1 $bug2' to<EMAIL_ADDRESS>[22:04] <slangasek> broder: backports finished, branch merged
[22:09] <bdmurray> slangasek: thanks what kind of confirmation will I get?
[22:11] <slangasek> bdmurray: email acknowledgement
[22:32] <apw> slangasek, thanks for that, i'll get with pitti et al tommorrow to make sure things are ok
[22:39] <broder> slangasek: thanks. i'll also make a note to try and make the initial UI a bit more friendly and informative
[22:40] <slangasek> broder: well, I'm over it now so maybe that's no longer an issue ;)
[22:41] <broder> yes, but you and colin aren't the only archive admins
[22:43] <slangasek> maybe the others already know how to use it too, dunno
[22:44] <broder> i think this is the first time since i wrote the script that i caught anybody but cjwatson running it
[23:10] <doko> slangasek, well, maybe. I don't have this hardware
[23:11] <doko> mterry, not at all
[23:35] <slangasek> cjwatson: that libdbd-sybase-perl upload will surely ftbfs
[23:36] <slangasek> I have 1.14 staged in bzr, dunno if you want to pull it: bzr+ssh://bzr.debian.org/bzr/users/vorlon/libdbd-sybase-perl/trunk/
[23:43] <cjwatson> slangasek: bulk uploads :)
[23:44] <cjwatson> slangasek: it's not critical path for anything particular, so it can wait until you have it in Debian
[23:55] <slangasek> cjwatson: right-o
[23:59] <SpamapS> slangasek: odd .. doing the lvm2 merge.. tons of conflicts on things that don't appear to be documented changes in the changelog.


[00:23] <Unit193> bluesabre: Debian Bug #786582 :P
[00:23] <Unit193> Maybe 786620.
[02:11] <micahg> Unit193: it's already fixed in svn
[02:11] <Unit193> micahg: Right, yeppers.  I think I saw that, but good to know for sure.
[02:12] <micahg> I meant to upload as 1svn1, but got tired of fighting with svn-buildpackage
[02:12] <micahg> I guess Loga-n went and fixed it
[02:12] <micahg> "fixed"
[02:12] <micahg> :)
[02:12] <Unit193> Oi, yeah...  I need to figure that out, used to gbp myself.
[02:13] <micahg> I test built fine, but couldn't get it to spit out a package without needing to commit
[02:14] <Unit193> I'll have to bug you about a good page for the workflow sometime. :P
[02:28] <GridCube> knome, http://xubuntu-showcase.deviantart.com/blog/535637153/
[02:28] <Unit193> \o
[06:43] <ochosi> morning all
[06:44] <elfy> morning ochosi
[06:52] <ochosi> wtf, now i can reproduce that problem with the black icon and xfpm1.5
[06:52] <ochosi> time to investigate...
[06:52] <Unit193> :D
[06:53] <elfy> lol - I've got the icon currently ...
[06:53] <ochosi> awesome, it seems eric broke it with his last commit :'(
[06:54] <ochosi> guess i should've reviewed that more closely before releasing 1.5
[06:54] <ochosi> however, we still have some old icons there in xubuntu-artwork
[06:57] <ochosi> so yeah, it really doesn't use symbolic icons now
[10:30] <bluesabre> elfy: now we can say ochosi is the crazy one :)
[10:40]  * lderan wonders how much extra crazy one needs to have to be the crazy one here
[10:41]  * bluesabre remembers knome holding that title for a while
[10:41] <bluesabre> it might come with XPL
[10:41] <knome> i was too crazy so i dropped the glass trophy and thus lost the title
[10:44]  * ochosi rolls his eyes frantically and hops on his desk
[10:45] <knome> now you have two desks
[10:45] <knome> two TWO-LEGGED desks
[10:48] <bluesabre> New Ikea line of minimalistic desks?
[10:48] <knome> i think elfy has one of those two-legged desks... no kidding
[10:49] <bluesabre> sounds about right, I think Unit193 mentioned something about those too
[10:49] <bluesabre> we should check with pleia2 if she has any recollection about that
[10:50] <ochosi> bluesabre: anyhoo, what i noticed is that i need to refresh xubuntu-artwork, it still has some of the fake symbolic icons
[10:50] <knome> ultimately, i think it's better to ask slickymasterWork to verify
[10:50] <bluesabre> 21:D
[10:50] <bluesabre> where'd that 21 come from, meh :D
[10:50] <ochosi> very short password?
[10:51] <knome> did you try to fake your age on an alcohol-related site?
[10:51] <bluesabre> probably both
[10:51] <lderan> woo
[10:51] <bluesabre> ochosi: cool, will that fix xfpm, or does it also need an update?
[10:52] <ochosi> btw, since you guys are around, shall we finally set up some blueprints for w?
[10:52] <bluesabre> we need to
[10:52] <ochosi> bluesabre: nah, the last commit by eric broke xfpm's icons :/
[10:52] <knome> i was going to ask when you'd like to do that the other day
[10:52] <bluesabre> I think feature definition freeze is tomorrow...
[10:52] <knome> hahah
[10:52] <knome> well,
[10:52] <knome> there isn't much plans for website
[10:52] <knome> at least anything that is cycle deadline related
[10:53] <knome> but FDF is just... blah anyway
[10:53] <bluesabre> dev plans: update catfish/menulibre/parole, wiggle around libreoffice packages... maybe the overlay that I've been lazy on for a few years
[10:54] <knome> i think it's a historical artefact from time when community actually was involved with the main OS spec planning..
[10:54] <ochosi> still empty, but here goes the umbrella bp: https://blueprints.launchpad.net/ubuntu/+spec/topic-w-flavor-xubuntu
[10:54] <bluesabre> knome: re website, we wanted to revamp the FAQs and such, right?
[10:54] <knome> somebody create a pad so i can dump my workitems there while playing FIFA
[10:54] <knome> bluesabre, yes
[10:54] <knome> bluesabre, i'll also look more into adding artwork there
[10:55] <knome> bluesabre, and also update the "get involved" section
[10:55] <knome> (that's WIP already)
[10:55] <bluesabre> yeah
[10:55] <ochosi> i'll start setting up the other blueprints now
[10:55] <lderan> cool
[10:55] <ochosi> bluesabre: what about panel-switch`?
[10:55] <bluesabre> can also bump the dev documentation, since our little xubuntu-dev family keeps getting bigger
[10:56] <bluesabre> ochosi: yeah: panel switch can be finished early this cycle
[10:57] <bluesabre> I guess another dev thing is getting xubuntu-core on cdimage... maybe?
[10:57] <knome> bluesabre, sgt-puzzles launcher
[10:57] <bluesabre> knome: that too
[10:57] <bluesabre> man, I really do have a todo list
[10:57] <bluesabre> :D
[10:57] <ochosi> bluesabre: please just jot down everything here: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-features
[10:58] <ochosi> wait, i might've screwed up the dependency tree there
[10:58] <ochosi> :)
[10:58] <bluesabre> I think "Development" might be a better title than New Features at this point
[10:59] <bluesabre> we're pretty stable these days
[10:59] <ochosi> ok, i'm fine with that too
[10:59] <ochosi> i can remove the bp again (or rename)
[11:00] <bluesabre> your call, boss :)
[11:00] <ochosi> i'm wondering, i guess the right assignee would be xubuntu-dev, not xubuntu-team
[11:00] <ochosi> anyway, done
[11:00] <ochosi> so go ahead, work your magic bluesabre ;)
[11:00] <bluesabre> woot
[11:02] <ochosi> elfy: please check out https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-qa
[11:03] <knome> ochosi, i suggest just creating -community for community+web+marketing
[11:03] <ochosi> ok, fine by me
[11:03] <knome> we can split later if needed
[11:04] <ochosi> https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-community
[11:04] <ochosi> would be good if you could note that straight away in the bp
[11:04] <knome> actually i think i'll create another one for -web
[11:04] <knome> because then the LP teams make sense
[11:04] <ochosi> k
[11:04]  * knome does magics
[11:05] <slickymasterWork> ask me what ochosi, knome?
[11:06] <ochosi> slickymasterWork: i didn't wanna ask you anything, however, your blueprint link is coming up in a minute..
[11:07] <knome> slickymasterWork, i was just messing around with everybody later
[11:07] <slickymasterWork> heh, I was wondering when will we start seting up those
[11:07] <knome> eh, earlier
[11:07] <knome> :P
[11:07] <slickymasterWork> ok
[11:08] <ochosi> slickymasterWork: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-docs
[11:08] <slickymasterWork> great, thanks ochosi
[11:08] <ochosi> sorry for being a bit late with that
[11:08] <bluesabre> using the whiteboard here https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-development
[11:09] <ochosi> knome: so no -marketing?
[11:09] <bluesabre> !team | please add any items you'd like to be considered for development this cycle https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-development
[11:09] <bluesabre> never ever ever works for me
[11:09] <knome> ochosi, there is no marketing LP team, let's group it under .community
[11:09] <knome> - too
[11:10] <bluesabre> !team
[11:10] <bluesabre> see above
[11:10] <bluesabre> :)
[11:10] <knome> ochosi, if pleia2 gets sad, then i'll split it for her
[11:10] <knome> hmm, i'm not sure if that came out all right
[11:10] <ochosi> hehe, "nice"
[11:10] <bluesabre> ok, gotta run, bbl
[11:10] <bluesabre> thanks for getting things rolling, guys
[11:10] <bluesabre> :)
[11:11] <ochosi> anyway, all blueprints set up
[11:11] <ochosi> k, now the pinging begins...
[11:11] <knome> https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-community
[11:12] <knome> pleia2, elfy: you have inherited work items in that BP (carried on from last cycle)
[11:12] <ochosi> Unit193, Noskcaj: we've set up the development blueprint here. if you have ideas/suggestions, note them on the whiteboard for now. if you wanna take up one of the existing ideas as a task for 15.10, please add it as a workitem assigned to yourself: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-development
[11:13] <bluesabre> lderan: you can pull something from that list as well, if you're interested
[11:13] <bluesabre> (panel switch is an interesting one)
[11:13] <ochosi> indeed
[11:13] <ochosi> +1
[11:21] <ochosi> lderan: actually it would be nice to track the meetingology stuff in the development blueprint
[11:21] <knome> ochosi, i would vote for -communit
[11:21] <knome> +y
[11:21] <ochosi> yeah, that's fine too
[11:22] <ochosi> just in some blueprint would be nice
[11:22] <ochosi> otherwise it's not really on the radar
[11:22] <knome> yep
[11:22] <knome> ...bleep...bleep...bleep...
[11:22]  * knome does his infamous radar imitation
[11:22] <lderan> ochosi: oo
[11:26] <elfy> knome: nope - I don't have a 2 legged desk - it has just the one
[11:27] <knome> even better :P
[11:28] <elfy> totally :D
[11:28] <elfy> ochosi: thanks ... I especially like the workitems
[11:29] <ochosi> yup, well obviously you gotta fill in the blanks yourself ;)
[11:29] <elfy> collect £200 go straight to 100% on topic progress
[11:29] <elfy> oh bah
[11:32] <elfy> knome: yep - expected that to turn up on the wibbly blueprint
[11:33] <elfy> the inheritance that is
[11:34] <elfy> bluesabre: was the -bugs blueprint at all useful?
[11:34] <elfy> oh nvm - I see ochosi built it :)
[11:34] <slickymasterWork> knome at some point we'll have to gather to discuss the best approach to deal with the third item in https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-w-docs
[11:34] <knome> yeah, +1 for -bugs
[11:35] <ochosi> elfy: i pulled in the open bugs from 15.04 that made sense
[11:35] <knome> slickymasterWork, propose dylan that he comes to IRC some time and schedule a meeting with us, him and somebody technical
[11:35] <ochosi> elfy: feel free to add new ones as you notice them
[11:36] <elfy> ochosi: ack
[11:52] <ochosi> bluesabre: would you mind setting the "in development"-wallpaper for 15.10 when you're around again?
[13:37] <slickymasterWork> ok, knome, I'll mail him and to schedule it and then I'll warn you and bluesabre of when it's going to be
[16:19] <ochosi> elfy: ok, we have a fix for xfpm in git. if you wanna rebuild cleanly from git without any patches and test that...
[16:24] <pleia2> so many pings
[16:24] <pleia2> I thought I missed a meeting :)
[16:24] <ochosi> well, sort of ;)
[16:25] <pleia2> knome: thanks for updating the blueprints
[16:25] <ochosi> pleia2: so i didn't set up a marketing blueprint cause knome said it should go in community
[16:25] <pleia2> yeah, that's fine
[16:25] <ochosi> k
[16:25] <ochosi> if you feel you need one during the cycle, we can always set one up
[16:26]  * pleia2 nods
[16:27] <elfy> ochosi: ack - did that - have icon
[16:27] <ochosi> \o/
[16:28] <ochosi> eric_the_idiot_: ^
[16:28] <eric_the_idiot_> awesome!
[16:28] <eric_the_idiot_> let us know if it goes missing later :)
[16:28] <ochosi> elfy: i guess if you added the shimmer daily ppa for an up-to-date elementary-xfce, all the icons should be fixed now
[16:28] <ochosi> incl the symbolic icons for the plugin
[16:28] <elfy> ochosi: had that since whenever
[16:29] <elfy> and symbolic icons is one of those it's an ellipse no it's not things ...
[16:29] <elfy> wouldn't know a symbolic icon from not
[16:30] <elfy> though it doesn't appear any different than before to me
[16:31] <elfy> changes when panel size increases
[16:34] <elfy> eric_the_idiot_: ack
[16:35] <elfy> mmm
[16:36] <elfy> synaptic showing xfpm from staging
[16:37] <elfy> I guess it'd not show the one I built from git
[16:55] <Unit193> bluesabre: Libreoffice also includes x-d-s update.
[16:55] <micahg> I'm working on the packagesets now FWIW
[17:13] <ochosi> elfy: yeah, you'd have to uninstall first
[17:16] <elfy> ochosi: that's what I thought
[17:17] <elfy> so I did - which removes the other 2 xfce4-power-*packages - then there's no plugin available to add to panel
[17:28] <ochosi> did you compile with "./autogen.sh --prefix=/usr"?
[17:29] <elfy> http://pastebin.com/wMFXmxVx
[17:29] <elfy> ochosi: ./autogen.sh --prefix=/usr --enable-debug=yes
[17:29] <ochosi> k, sorry, i gotta run, i can look again tomorrow if that's ok
[17:30] <elfy> of course it is :)
[17:31] <ochosi> k, ttyl then :)
[19:18] <micahg> is there a reason we're seeding apt-offline?
[19:18] <Unit193> skellat had a reason.
[19:18]  * micahg digs through bzr
[19:19] <Unit193> It's in the docs too.
[19:19] <Unit193> Think a meeting had it.  The docs has a very good write up though, linked to it elsewhere.  Think something along the lines of it being small and very useful for those in spotchy internet places.
[19:20] <micahg> sigh, and he quotes me
[19:20] <Unit193> Oh?
[19:20] <micahg> ah, I see the comment now
[19:20] <micahg> http://paste.ubuntu.com/11396952/
[19:22] <micahg> sigh, ok, well, the packagesets aren't getting updated today :(
[19:23] <Unit193> :(
[22:16] <ochosi> micahg: any concerns wrt aptoffline or,are you trying to get us below 1gb? :)
[22:17] <ochosi> sry, meh, typing sucks on the ipad
[22:25] <micahg> ochosi: neither actually, trying to update the packageset first


[09:14] <Guest_SADe> Hi everyone
[09:15] <Guest_SADe> Did someone know about future suport of Tascam us-4x4HR sound card ?
[09:16] <Guest_SADe> I saw that old models are compatible, but found nothing about the new one
[09:57] <MauroGaspari[m]> <Guest_SADe "Did someone know about future su"> Sorry, no idea. Please hang on in here, most of the Audio Gurus join the channel a bit later.
[10:02] <snexus> Hi guys. I am trying Ubuntu Studio PPA on Ubuntu 20.10 and I saw that LMMS does not have Carla nor Vestige for VST plugins.  Thanks in advance.
[10:31] <Guest_SADe> thanks for answer MauroGaspari[m] i'll give a try later
[21:39] <twojukeboksi> I think I'm in the next few days going to make the final move to this Ubuntu Studio 20.10.. I mean this seems highly stable straight from pointzero
[21:50] <twojukeboksi> My touchpad Device is locked in as "Elan Touchpad" and the checkbox to enable "Tap-to-click" is grayed out
[21:51] <twojukeboksi> I think I've seen this same situation before somewhere. Someone suggested installing some synaptics package, but iirc that did not lead to a working system (old advice prlly)


[00:00] <wrst> well that worked
[01:02] <vychune> o/
[13:09] <wrst> morning everyone
[14:07] <vychune> morning
[15:07] <Xpistos> ditto
[16:09] <wrst> hello
[16:47] <chibihogoshino> lol  Obama's Goal: 98% of US Covered By 4G
[16:48] <Xpistos> that would be nice
[16:49] <Xpistos> but why only 98 percent
[16:49] <chibihogoshino> he hates the rest
[17:06] <Xpistos> what percent am I in?
[17:06] <Xpistos> ... say 98 ... say 98
[17:11] <chibihogoshino> hmm
[17:11] <chibihogoshino> im the 2%
[17:18] <wrst> i'm always the 2%
[17:18] <Xpistos> ah, you guyes are always in my 98%
[17:19]  * wrst feels somewhat uncomfortable with Xpistos' last statement
[17:20] <Xpistos> lol
[17:32] <orias> all up inside my 98%
[17:32] <orias> just warm and snuggled in nice and close
[17:33] <orias> you smell pretty
[17:33] <orias>  /creepy
[17:39] <Svpernova09> I've got a ubuntu issue if you guys are up for a question
[17:39] <Svpernova09> "E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem."
 Only a restart fixes it. yet still leaves dpkg broken.
[17:40] <Svpernova09> The package it's hung up on is openssh-server.
[17:40] <Svpernova09> I can't remove, purge, install or anything else directly with the package.
[17:40] <orias> what about -f to force ?
[17:41] <Svpernova09> apt-get install -f will eventually hang as well
[17:41] <orias> :/
[17:43] <chibihogoshino> this is why a ignore options would be nice
[17:47] <chibihogoshino> Svpernova09: is the file downloaded ?
[17:51] <Svpernova09> I just don't know what to do without breaking apt.
[17:52] <Svpernova09> I assume so, the original problem was the apt-get update was interrupted
[17:55] <Svpernova09> So I did apt-get autoclean
[17:56] <Svpernova09> and then tried to dpkg-reconfigure openssh-server
[17:56] <Svpernova09> and it said /usr/sbin/dpkg-reconfigure: openssh-server is broken or not fully installed
[17:56] <Svpernova09> So I did apt-get remove -f openssh-server
[17:56] <Svpernova09> and it's hanging at Removing openssh-server ...
[18:10] <chibihogoshino> you have to edit one of the files in /var/lib/dpkg
[18:10] <chibihogoshino> i think its status
[18:23] <Svpernova09> I removed it from there
[18:23] <Svpernova09> and it let me run the --configure
[18:23] <Svpernova09> so I ran apt-get remove openssh-server and it hung up again
[18:25] <chibihogoshino> hmm
[18:26] <chibihogoshino> have you added repos ?
[18:27] <Svpernova09> No, this is a minimal open-vz container
[18:27] <Svpernova09> the only repos are the official 10.04 ones
[18:27] <Svpernova09> I think I'm just going to move data and nuke the VM
[18:28] <chibihogoshino> there could be another file you need to edit i can remember
[18:28] <Svpernova09> I could move data + reconfigure apache faster than I could fix it.
[18:28] <chibihogoshino> i think there was two files
[19:50] <cyberanger> how's everybodys day going?
[20:09] <wrst> good cyberanger how about you?
[20:11] <cyberanger> mixed, had to pull out some backup systems
[20:12] <cyberanger> so this is being typed at 20kbps
[20:12] <cyberanger> annoyingly
[20:20] <cyberanger> temporary resolution to a temporary problem though
[20:24] <Xpistos> stupid wordpress dropdown menus
[20:24] <cyberanger> Xpistos: sounds like your day isn't going smoothly either
[20:33] <Xpistos> nope
[20:54] <Xpistos> does it have to be so hard to add a dropdown menu to a site?
[20:57] <wrst> Xpistos: what are you using wordpress? if so i have asked my question a million times!
[20:57] <Xpistos> yep
[20:58] <wrst> some themes make it really easy best i remember
[21:53] <Svpernova09> Changing a mount point for a drive (that isn't / ) is just a matter of unmounting it, changing /etc/fstab and then remounting it yeah?
[21:56] <cyberanger> Svpernova09: usually that simple
[21:56] <Svpernova09> ok, seemed a bit too simple.
[21:56] <cyberanger> thus the usually
[21:57] <xTEMPLARx> z0mg!  pplz!
[21:58] <xTEMPLARx> awww i haz killt the peoplez?
[22:07] <cyberanger> xTEMPLARx: 20 kbps here, you didn't kill me
[22:07] <cyberanger> however something else is trying to slowly
[22:15] <pace_t_zulu> wrst: did you see unity now has that windows 7 feature of maximizing windows dragged to the top of the screen?
[22:22]  * cyberanger gags at the idea of comparing linux features to windows features
[22:24] <pace_t_zulu> cyberanger: alot of folks have been wanting that specific feature
[22:25] <cyberanger> oh, I understand the feature request fine, just the source of inspiration is odd
[22:25] <pace_t_zulu> cyberanger: windows deserves credit when it actually does innovate... it doesn't happen too often
[22:26] <cyberanger> thing is, that was in some other window managers already
[22:28] <cyberanger> but I'm not sure who was first


[02:13] <Cheri703> boring monday
[02:13] <Cheri703> well, boring monday evening, earlier was busy-ish
[13:27] <thafreak> Morning Ohio
[13:27] <thafreak> everyone psyched for OLF?
[13:43] <_bbb> gonna try and make it but baby on the way might complicate things =)
[13:43] <_bbb> kinda at his mercy
[13:47] <thafreak> bah, bring the baby
[13:47] <thafreak> maybe your wife could give birth at olf...
[13:48] <thafreak> slap a tux sticker on the kid
[13:48] <thafreak> ;)
[13:49] <thafreak> The first year I went, I dragged my pregnant wife along...
[13:49] <thafreak> she only went to the pre party though...
[13:49] <thafreak> that was when the pre-party was a few pizzas and about 20-30 people and a keg
[13:50] <thafreak> in a tiny room
[13:50] <thafreak> then my wife went to a horse show the next day
[13:50] <thafreak> oh, and that was the year i won the psp from novell...only year i won anything
[13:54] <_bbb> we won a eee pc one year
[14:41] <thafreak> nice...I think I remember that year...is that the year that shaun powers one one too?
[14:41] <_bbb> sounds right
[15:56] <paultag> thafreak: haha, oh lordy - senior powers
[15:56] <paultag> that was a good year


[03:13] <handsome_feng> Hi, could someone here handle my request? Thanks! https://answers.launchpad.net/launchpad/+question/670540
[03:48] <wgrant> handsome_feng: Done.
[03:49] <handsome_feng> wgrant: Thank you very much!
[14:44] <Laney> what's the right invocation to change the owner of a git_repository from the API?
[14:45] <Laney> I tried setting 'owner' and calling lp_save() on all the things but it didn't get updated
[14:47] <cjwatson> That ought to work.  Do you have a transcript?
[14:48] <Laney> I'll run it again.
[14:48] <cjwatson> You should just need to call lp_save on the repository
[14:49] <Laney> https://paste.ubuntu.com/p/m4ZGPBFjNC/
[14:51] <cjwatson> gits[0].lp_refresh()
[14:52] <cjwatson> Wait, what is gits in this case?
[14:52] <cjwatson> Can I have a more complete transcript? :P
[14:52] <cjwatson> I bet gits is a collection
[14:52] <Laney> It is, it's from getBranches() or something
[14:53] <cjwatson> Listify it first, or assign gits[0] to a variable
[14:53] <cjwatson> Otherwise the __getitem__ inside gits[0] does a separate fetch from the webservice each time and so forgets your changes
[14:53] <cjwatson> Bit of a gotcha with collections
[14:53] <Laney> Ahh, this is a peculiarity with LP programming that I'm not aware of
[14:53] <Laney> That works, thanks!
[14:54] <cjwatson> np, it's not at all obvious when you haven't encountered it before
[14:54] <Laney> Oh, but I've got to fix the subscribers too
[14:55] <cjwatson> You can call methods without this trick - it's only property assignments that are problematic
[14:55] <cjwatson> Though it may be a good idea anyway to avoid excessive webservice calls
[14:56] <cjwatson> https://help.launchpad.net/API/launchpadlib#Three_things_to_make_your_client_faster has a little trick to see what webservice calls are happening
[15:00] <Laney> That'll be useful, cheers
[15:01] <Laney> Good semantic use of HTTP error codes (409 in this case)
[15:02] <cjwatson> Yeah, the LP webservice is sort of what you get if you go all-out on REST design and kinda forget the performance bit


[00:41] <slangasek> cyphermox: this hard-codes fbx64.efi, is that correct?
[00:41] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
[00:49] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.10]
[00:49] <slangasek> cyphermox: seems grub2 also needs a reupload for yakkety, same reason?
[00:51] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.3]
[00:53] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.9 => 2.02~beta2-36ubuntu3.10] (core)
[01:12] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
[01:13] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.10 => 2.02~beta2-36ubuntu3.10] (core)
[01:27] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.10]
[09:52]  * apw hopes that is a double burp by queuebot rather than a race
[19:58] <slangasek> cyphermox: LP: #1692181; fixing up shortly
[20:02] <Bashing-om> slangasek: :) seen it twice in #ubuntu channel .
[20:04] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.10 => 2.02~beta2-36ubuntu3.11] (core)
[20:06] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
[20:06] -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.10 => 1.66.11] (core)
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.11]
[20:17] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.11 => 2.02~beta2-36ubuntu3.11] (core)
[20:32] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.11 => 2.02~beta2-36ubuntu3.11] (core)
[20:51] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
[20:52] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.11]
[21:28] <xnox> snapd regressed, but i can't even tell what the failure is from the log. Can anybody help?
[21:28] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
[21:28] <xnox> and scroll down to snapd
[21:33] <infinity> xnox: "Error executing autopkgtest:ubuntu-17.10-amd64:tests/main/listing"
[21:33] <infinity> xnox: Then it dumps a bunch of state.
[21:34] <infinity> Which, to be fair, isn't super informative to me.
[23:10] -queuebot:#ubuntu-release- New binary: libgit2 [s390x] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:11] -queuebot:#ubuntu-release- New binary: libgit2 [i386] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:11] -queuebot:#ubuntu-release- New binary: libgit2 [ppc64el] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:12] -queuebot:#ubuntu-release- New binary: libgit2 [amd64] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:14] -queuebot:#ubuntu-release- New binary: libgit2 [arm64] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:14] -queuebot:#ubuntu-release- New binary: libgit2 [armhf] (artful-proposed/universe) [0.25.1-2] (kubuntu)
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [amd64] (artful-proposed) [0.25.1-2]
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [armhf] (artful-proposed) [0.25.1-2]
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [ppc64el] (artful-proposed) [0.25.1-2]
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [arm64] (artful-proposed) [0.25.1-2]
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [s390x] (artful-proposed) [0.25.1-2]
[23:37] -queuebot:#ubuntu-release- New: accepted libgit2 [i386] (artful-proposed) [0.25.1-2]


[09:41] <JohnTeddy> http://pastie.org/1707503
[09:42] <JohnTeddy> I don't know how to program, I'm trying to setup a script so my ssh tunnel is working on local host, so I can proxy out on my web browser and avoid the great Chinese firewall.. so I can get to facebook and youtube, etc.
[09:42] <JohnTeddy> Can someone look at that url and tell me what is wrong with the script. Doing service china.firewall status keeps showing a new pid. How can I debug upstart scripts, is there a log somewhere?
[16:28] <SpamapS> JohnTeddy: start on startup is too soon
[16:28] <SpamapS> JohnTeddy: you need to have a network first
[16:29] <SpamapS> JohnTeddy: try 'start on net-device-up IFACE!=lo'
[17:36] <jMCg> ion/Keybuk - is it intendet for intendant to leave a mess in /tmp? http://pastebin.com/944LsUKr
[21:25] <ion> jmcg: It’s just a test program. That doesn’t matter.
[23:00] <Keybuk> ion: there was kudos for your ionice stuff in mountall earlier
[23:00] <ion> Yeah, i noticed :-)


[03:09] <krababbel> Hi, why is there a relative path in openssl.cnf for CA_default? Where should I keep my files like certs if I want to be my own CA for a LAN? Some say in /root/ca but others suggest /etc/ssl
[03:14] <krababbel> Also I want to create a certificates for my webserver and mailserver. Without my own CA signing both certs, I'd need to install multiple certificates on clients, correct? With my CA, a client could verify both mail and web certs using only the CA cert, correct?
[03:16] <patdk-lap> depends on what you do
[03:17] <patdk-lap> you could have some other ca sign them
[03:17] <krababbel> patdk-lap: I need to sign them myself, it is just a test LAB.
[03:19] <krababbel> patdk-lap: So if I sign them myself, my clients in the lab could verify all server certificates, which were signed by my CA, and the clients would only need to install my CA certificate, correct? I am a bit unsure now.
[03:20] <krababbel> patdk-lap: Otherwise I could just self sign the certs on the mailserver and webserver for example each.
[03:20] <patdk-lap> yes
[03:20] <patdk-lap> but the server would need it's certificates and any intermediate certs (that doesn't sound like your making)
[03:23] <krababbel> patdk-lap: OK, thank you a lot.
[03:48] <rsd> any good suggestions for a MON replacement (if any)?
[03:49] <patdk-lap> what is a mon
[03:49] <rsd> system monitoring, alert, etc
[05:31] <krababbel> I am unsure about LDAP authentication and /home on an NFS server. If the LDAP and NFS servers are different machines on the network, could pam_mkhomedir create the homedirs on the NFS server on first login?
[05:39] <krababbel> Why is it a problem with having both local and LDAP homedirs in /home? I read that usually you should separate them, but I don't see why. Aren't UID and GID enough?
[05:45] <krababbel> Maybe that's only for users which already exist locally.
[05:49] <krababbel> Or is the problem that a local user trying to login and mounting their /home/... could be rejected by the NFS server because NFS may not find that user in LDAP and locally, I guess.
[05:51] <krababbel> So if the same local user already exists on all machines, and the only additional users in /home would be LDAP users, then separating /home wouldn't be necessary?
[09:25] <Rar9> morning. need some help with an Error 503 for installing Solr4 with Tomcat7  .. Anyone?
[09:43] <ikonia> Rar9: 503 is service unavailable suggesting that it's not listening on the port you have defined, or it is listening but the application is not configured (which is common with solr)
[13:08] <krababbel> Why is it a problem with having both local and LDAP homedirs in /home? I read that usually you should separate them, but I don't see why. Aren't UID and GID enough? But if there is only the same local user on all machines, and the only additional users in /home would be LDAP users, then separating /home wouldn't be necessary?
[15:52] <zul> rbasak/hallyn: im adding that arm64 patch before uploading a new libvirt (1.2)
[15:54] <ahnkle> i am thinking of getting a Proliant DL140 G3 for personal use. there is an Ubuntu 10.04 release. is this retired now?
[15:54] <rbasak> zul: I'm not sure we should right now.
[15:54] <rbasak> zul: I don't want to cause a future conflict with a Linaro patch.
[15:55] <rbasak> I emailed Clark (Linaro) to get his view.
[15:55] <zul> rbasak:  arrgh after i rediffed it
[15:55] <rbasak> Since he's doing the libvirt armhf/arm64 enablement work which involves pushing it upstream.
[15:55] <rbasak> zul: well, I did say in the bug·
[15:55] <zul> rbasak:  yes but im not awake yet :)
[16:25] <hallyn> zul: bug 1264955 - any objections to nfs-common being in libvirt build-dep?
[16:28] <zul> hallyn:  nah
[16:28] <zul> hallyn:  1.2.0 has been uploaded like a half hour agao
[16:34] <hallyn> yeah - and on the one hand i don't want a new uplaod just for that, but otoh if we don't do it now we'll never remember :)
[16:35] <hallyn> well i've added it to my long list of libvirt bugs to work on when i have time
[16:35] <zul> hallyn:  sweet...just batch them up :)
[16:50] <krababbel> Hi, is there a problem sharing one public folder over samba and nfsv4 at the same time?
[16:51] <jrwren_> no, no problem.
[16:51] <krababbel> jrwren_: OK thanks, I'll try that.
[16:51] <jrwren_> why would there be a problem :)
[16:52] <krababbel> jrwren_: I asked because NFSv4 uses usually this special folder /exports
[16:53] <krababbel> So I was unsure if they'd work nicely together. (samba and nfs)
[16:55] <jrwren_> oh no.
[16:55] <jrwren_> that /exports is just a default config. you can export anything
[16:55] <krababbel> jrwren_: Thank you a lot. :)
[17:23] <hallyn> zul: is ppa:ubuntu-cloud-archive/havana-staging "the havana cloud archive" ?
[17:24] <zul> hallyn:  its the staging area http://www.ubuntu.com/download/cloud/cloud-archive-instructions
[17:24] <hallyn> where is the real havana cloud archive then?
[17:25] <hallyn> oh i see, thx
[17:25] <hallyn> how do i add the apt-key?
[17:26] <hallyn> eh, nm.  no matter for the test
[17:44] <hallyn> zul: are you doing anything right now on libvirt apparmor bugs?
[17:45] <hallyn> jdstrand: can I (later today/tomorrow) point you to some debdiffs relating to libvirt-apparmor?
[17:46] <zul> hallyn:  nope just getting libvirt-python ready for mir
[17:46] <hallyn> oh i thought with merge from debian you didnt' have to
[17:46] <hallyn> ok.  just one more lxc thingie and then i'm hitting libvirt-apparmor hard.
[17:46] <zul> hallyn:  nah i wish it was like that
[18:43] <adam_g> zul, if you get some minutes today could you plz take a look at the 2013.2.1 branch updates at https://code.launchpad.net/~ubuntu-server-dev/+activereviews ?
[18:44] <zul> adam_g: 2013.2.1?
[18:44] <adam_g> zul, the first havana stable release
[18:45] <zul> adam_g:  cool gimme a sec
[18:45] <adam_g> zul, no rush
[18:48] <zul> adam_g:  +1
[18:49] <adam_g> zul, nice thanks
[20:02] <krababbel> I want to export /home directories over NFS. Why do people say it is a problem if I do not separate the remote home folder from the local home?
[20:02] <krababbel> For example like described here in the second paragraph: http://nickportertech.blogspot.co.at/2010/02/ubuntu-machine-with-nfs-home-and-ldap.html
[20:04] <jrwren_> krababbel: its only a problem if you want to login to an nfs client system when the nfs server is down
[20:05] <krababbel> jrwren_: OK thanks a lot, of course, I am tired. :)
[20:05] <jrwren_> if that is not a requirement, then it is no problem.
[20:06] <krababbel> jrwren_: I see, yes.
[21:45] <hallyn> jdstrand: in qrt test-libvirt.py, there are two lines restoring "/etc/apparmor.d/abstracations/libvirt-qemu" <sic>.  Is that some intended genius, or a typo?
[21:49] <tclarke> I'm setting 12.04 MAAS and I'm having trouble following the install docs...I get to the point where I need to d/l initial boot images and run "maas-cli mynam node-groups import-boot-images" where mynam is the name of my login profile
[21:49] <tclarke> node-groups: error: argument COMMAND: invalid choice: u'import-boot-images' (choose from 'register', 'list', 'refresh-workers', 'accept', 'reject')
[22:01] <stdaro> https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/257857 is pretty unpleasant, still applies today
[22:20] <bravvve22> hello am newbe,in a vps ubuntu 10.04 is installed and if config gave me venet0:0,no eth0 what meen?
[23:06] <bigjools> tclarke|AFK: you need to run the version of maas in the cloud archive
[23:41] <adam_g> zul, ping
[23:44] <krababbe1> Hi, if I enable no_root_squash on an export, could it be dangerous for the NFS server, or would that "just" allow a remote root to do anything within that export folder?
[23:45] <bekks> krababbe1: yes, it could dangerous, dependingon what you are sharing.
[23:47] <krababbe1> The problem is, that I want to have an NFS server export /home to clients.  But I get 'permission denied', and I guess it has to do with the fact that remote machines are restricted by root_squash. With no_root_squash it seems to work.
[23:48] <krababbe1> bekks: The NFS server, LDAP server and client are three different machines on the LAN.
[23:49] <bekks> krababbe1: Which doesnt matter, and doesnt clarify which shares you are going to share with no_root_squash
[23:49] <krababbe1> bekks: The /home folder would be shared with no_root_squash.
[23:50] <krababbe1> bekks: On the NFS server it would be /mnt/home, since I separated local home from LDAP user's homes
[23:50] <bekks> krababbe1: Unless root isnt going to use stuff from /home, it's nasty, but somehow safe.
[23:51] <krababbe1> bekks: I guessed so. :) Is there an similar alternative?
[23:52] <krababbe1> using pam_mkhomedir I mean
[23:52] <krababbe1> I am doing this for the first time.
[23:52] <hitsujiTMO> krababbe1: i'd also ensure subtree_check is used
[23:53] <krababbe1> hitsujiTMO: Thanks, I'll try that.
[23:54] <adam_g> zul, anyway, /me needs sponsorship for http://people.canonical.com/~agandelman/heat-2013.2.1/ . can you help? guess heat is not seeded properly?