[00:43] <stokachu> is there a way to just manually change the version string in a debian/changelog file with dch? basically i can do "dch -v 0.1+git-aaabbb-0ubuntu1" but without loading up the editor and appending a extra * at the end of the entry
[02:01] <ScottK> mitya57: For the new sip API version it's a transition.  You'll need to rebuild all the packages that depend on the API.  It definitely needs an FFe and please test rebuild everything before you ask because that'll be my first question.
[02:51] <mitya57> ScottK: Ok, will do
[03:15] <RAOF> Man I wish our python pretty-printers for STL containers weren't all busted to hell.
[05:35] <pitti> Good morning
[05:45] <RAOF> Aloha, pitti!
[05:45] <pitti> hey RAOF
[05:55] <RAOF> How does that umockdev sync interact with the STOP THE WORLD!! from phone CI?
[05:55] <pitti> RAOF: umockdev isn't (I hope) on any image
[05:55] <infinity> libumockdev0 (from umockdev) is seeded in:
[05:55] <infinity>   ubuntu-touch: daily-preinstalled
[05:55] <pitti> RAOF: also, I only read that afterwards
[05:55] <RAOF> But is in all the CI stuff.
[05:56] <infinity> That said, you can see my opinion of the stop the line thing in my followup post...
[05:56] <pitti> RAOF: yes, sure; as I said, the three syncs (postgresql and umockdev) were the first things I did this morning before attacking my mailboxes
[05:56] <pitti> as yesterday evening they still weren't imported into LP
[05:56] <pitti> but I fully agree with infinity here
[05:56] <RAOF> Yeah, I've certainly done similar things in the past.
[05:57] <pitti> I think we dialed the "no regressions" slider way too far into the other direction now, it's incredibly hard to land anything these days
[05:58] <infinity> pitti: Yes, ScottK brought that point up nicely.
[06:01] <RAOF> Oh, *that's* what he meant!
[06:41] <Mirv> I'd need a packaging ack from a core-dev, ubuntu-download-manager adding a QML plugin http://<IP_ADDRESS>/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140321-0ubuntu1.diff
[06:44] <RAOF> Mirv: = ${binary:Version}?
[06:45] <RAOF> Ah, we've already decided that ABI is for chumps? :)
[06:46] <Mirv> good point, that may be too strict
[06:47] <Mirv> I don't think we've that in others
[06:47] <RAOF> No, you do have that in others.
[06:48] <Mirv> thank you, I'll note that on the branch. darn.
[06:49] <RAOF> The package description isn't consistent with the other ones, either.
[06:49] <RAOF> But I wouldn't block on that.
[06:51] <Mirv> it might be of course that the '0' in lib means they aren't really committing themselves to an ABI yet
[07:16] <pitti> RAOF: umockdev 0.8 just made it into trusty, so happy evemu events recording/replaying :)
[07:19] <dholbach> good morning
[07:29] <zyga> doko_: good morning
[07:29] <zyga> doko_: regarding your question yesterday, how can I reproduce that build failure of bzr?
[07:59] <pitti> zyga: I get the same failure with
[08:00] <pitti> $ bzr selftest -v bzrlib.tests.test_email_message.TestEmailMessage.test_multipart_message
[08:00] <pitti> zyga: in current trusty
[08:00] <pitti> (with apt-get install bzr python-bzrlib.tests)
[08:05] <zyga> pitti: thanks
[08:05] <zyga> pitti: I recall that bzrlib was failing on tests in trunk a while ago (when I looked at bzr3)
[08:05] <zyga> pitti: but I don't assume that it was packaged without running tests
[08:06] <pitti> zyga: the package skips a few tests
[08:06] <zyga> pitti: ok, I reproduce the failure the same way
[08:06] <zyga> pitti: python 2.7 gets very few changes
[08:07] <zyga> pitti: so if this worked before (and bzr was updated and ran the test suite) then it must be something python related
[08:07]  * zyga looks
[08:27] <diwic> Hmm, after today's updates "unity-control-center sound" crashes with "Settings schema 'com.canonical.indicator.sound' is not installed" and then a SIGTRAP.
[08:28] <zbenjamin> cjwatson: ping
[08:28] <pitti> diwic: works here; do you have "indicator-sound" installed?
[08:28] <pitti> indicator-sound: /usr/share/glib-2.0/schemas/com.canonical.indicator.sound.gschema.xml
[08:29] <diwic> pitti, thanks. It's not installed here, how can indicator-sound be not installed if ubuntu-desktop is installed?
[08:30]  * diwic installs indicator-sound manually unless you want to troubleshoot further first
[08:30] <pitti> it's just a recommends
[08:30] <pitti> diwic: so I suppose u-c-c now needs a hard depends on it
[08:30] <diwic> pitti, ah, ok. thanks for the troubleshooting
[08:30] <pitti> diwic: or the schema needs to go someplace else; I'm not sure which is right (I'm not involved in this), so I think reporting a bug about that and prodding seb128 is a good approach
[08:31] <diwic> pitti, will do
[08:40] <tjaalton> is cmocka something that could be more useful and moved to main, or should I drop it from sssd build-depends?
[08:40] <tjaalton> used for some tests
[08:41] <pitti> oh, surprising that samba isn't using that too
[08:41] <tjaalton> probably because of that
[08:41] <tjaalton> it's in universe
[08:41] <pitti> should be fairly harmless in main IMHO
[08:41] <tjaalton> yeah
[08:41] <tjaalton> I'll add a MIR bug
[08:42] <tjaalton> sssd isn't there yet either, should fix that before release
[08:50] <tjaalton> is anyone else having issues with ecryptfs taking ~5min to stop on shutdown?
[08:52] <pitti> not 5 min here, but can easily take 20 s; not sure if I'm seeing the same
[08:58] <tjaalton> yeah that sounds normal
[09:14] <cjwatson> Mirv,RAOF: ABI or not, I tend to think that it's reasonable and appropriate for dependencies within a source package to be (= ${binary:Version}) ...
[09:14] <cjwatson> zbenjamin: hi
[09:14] <cjwatson> zbenjamin: (please include content with your pings, it's quicker)
[09:21] <zbenjamin> cjwatson: ok , just a quick question , can a click package have more than one desktop file?
[09:24] <cjwatson> zbenjamin: yes, you can have multiple apps in a single click package and each would have its own .desktop file
[09:25] <Mirv> cjwatson: RAOF: not having it would allow upgrading the library from the source package without upgrading the QML plugin, but I'm not sure if that's useful of course
[09:25] <cjwatson> zbenjamin: (now, whether stuff in the stack above click all handles multi-app packages gracefully, I can't be certain as I'm not sure I know of any real examples - but we made sure support for this was in the design)
[09:25] <cjwatson> Mirv: yeah, in general I don't think this is a useful thing to support for different binaries from the same source, though of course there are exceptions
[09:26] <zbenjamin> cjwatson: ok thank you
[09:26] <Sweetshark> doko: So about libreoffice-voikko: Cant reproduce that with the libreoffice 4.2.3 prelease I current have from a PPA. It guess it was already fixed by https://gerrit.libreoffice.org/#/c/8368/ for 4.2.2.
[09:26] <Sweetshark> doko: so should be fine with the next LibreOffice upload.
[09:26] <Mirv> cjwatson: ok, thanks for your input. not blockin on that then.
[09:27] <cjwatson> cf.
[09:27] <cjwatson> $ apt-cache show gir1.2-click-0.4 | grep -m1 Depends
[09:27] <cjwatson> Depends: gir1.2-gee-0.8, gir1.2-glib-2.0, gir1.2-json-1.0, libclick-0.4-0 (= 0.4.19)
[09:27] <cjwatson> which I think is spiritually similar
[09:28] <doko> Sweetshark, ok, let me know when I can retry
[09:30] <Sweetshark> doko: will do.
[09:35] <maxiaojun> anyone to look at usb-creator?
[09:35] <seb128> xnox did some work on it this cycle, why?
[09:36] <maxiaojun> Erase Disk still broken
[09:40] <zbenjamin> cjwatson: any idea when we will be able to build in the chroots again?
[09:45] <xnox> seb128: yeah. I am planning to look into usb-creator today.
[10:02] <dakira> hi. can you please change the status of LP:729979. It says "Fix Released" but that fix never worked for anyone.
[10:02] <dakira> This bug affects all users of nvidia binary drivers. It should either be fixed or worked around for 14.04.
[10:04] <darkxst> dakira, it would be more useful, if you put a comment on the bug, rather than here!
[11:45] <ScottK> cjwatson: Thanks for taking care of mplayer/arm64.  I just noticed the lack of it was blocking a -proposed -> -release migration and there it was, fixed (I hope) already.
[11:46] <cjwatson> yeah, turned out to be easier than I'd thought.  I hadn't done it before because gigantic dependency chain and a lot of that wasn't ported until recently.
[11:49] <rbasak> slangasek, stgraber, xnox: so for mysql-5.5, AIUI it automatically broke when debhelper behaviour changed. No upload was required for that.
[11:50] <rbasak> When it was brought to my attention I asked about it (at our sprint in London) and understood that it would be fixed by changing the lsb function, so I left it.
[11:50] <rbasak> So that's one example.
[11:57] <dakira> darkxst: this bug is being ignored. it was marked "fix released" in february 2013. Since then there have been 40 comments stating that the bug is not fixed.
[11:57] <cjwatson> doko,xnox: looks like gcc-arm-linux-androideabi needs to be switched from libppl0.12 to libppl-dev; will one of you take care of that?
[11:59] <dakira> darkxst: I came here as a last resort. My first comment on the bug was in early 2011. This bug makes Unity look broken on all machines that use nvidia binary drivers.
[11:59] <xnox> cjwatson: i'll do it.
[12:00] <doko> cjwatson, yes, and remove the isl b-d
[12:00] <doko> compilers up to 4.7 use ppl, newer ones isl
[12:01] <xnox> cjwatson: so looking at the command-not-found data which mvo's account is still generating..... It not generating things for trusty, and it's only generating against main-archive, as the account got disabled on the ports machine (or the machine is gone)
[12:02] <xnox> cjwatson: can we move command-not-found generator to someplace owned by ~ubuntu-archive which happens to have access to the unsplit mirror?
[12:02] <cjwatson> xnox: it would be simplest to wait for mvo to restart and do it then
[12:02] <cjwatson> we have time :)
[12:02] <xnox> cjwatson: true. Ok then. I'll upload a small bugfix, and that's it.
[12:02] <xnox> (without data update)
[12:29] <cjwatson> cool, porting mplayer to arm64 cleared 15 uninstallables
[12:29] <cjwatson> ten more of those ...
[12:34] <seb128> bdmurray, pitti: can we do anything to get https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276 moving forward? it's the most report trusty issue on e.u.c
[13:15] <pitti> seb128: I'm afraid I don't understand enough what that patch is doing
[13:16] <pitti> it looks like a bandaid, but doesn't explain the reason *why* the model isn't available
[13:16] <seb128> pitti, we need mvo back ;-)
[13:16] <pitti> +1
[13:16] <pitti> and it's not clear that the program/UI would then behave sensibly after just returning
[13:20] <ogra_> seb128, one more week, isnt it ?
[13:20] <ogra_> :)
[13:24] <seb128> ogra_, yeah, can't wait!
[13:24] <ogra_> same here :)
[13:37] <xnox> ogra_: seb128: do we need a blueprint with work-items we'd want mvo to finish by 14.04 release ;-)))))
[13:37] <xnox> ?
[13:37] <seb128> ;-)
[13:38] <pitti> xnox: I'm not sure whether a single BP can hold that many WIs
[13:39] <xnox> pitti: he can fix launchpad and work-items tracker in one go as well to resolve that bug =)
[13:39] <pitti> oh, of course!
[13:39] <pitti> xnox: I keep thinking too small :)
[13:41] <ogra_> there are only two WIs , arent there ?
[13:41] <ogra_> fix all click issues
[13:41] <ogra_> fix all apt issues
[14:42] <tseliot> pitti: hi, any ideas as to why we haven't updated util-linux? LP: #1012081
[14:43] <pitti> tseliot: I poked lamont about it several times
[14:43] <pitti> tseliot: I think the biggest problem is that the package is incredibly hard to update as there aren't broken-out patches, but there is just a single huge patch in debian.diff.gz
[14:43] <tseliot> oh...
[14:43] <pitti> tseliot: I think lamont has some git magic to tell them apart, but I wouldn't know it
[14:45] <tseliot> pitti: I see
[14:50] <mdeslaur> cjwatson: are you planning an openssh update to 6.6, or shall I upload the fix for CVE-2014-2532?
[14:50] <cjwatson> mdeslaur: I have it staged in git already
[14:50] <mdeslaur> cjwatson: great, thanks
[14:51] <cjwatson> though thanks for the CVE ref :)
[14:51] <cjwatson> I'll insert that into my changelog
[14:51] <mdeslaur> great
[14:52] <cjwatson> mdeslaur: I'm waiting for translations of the debconf template in https://lists.debian.org/debian-ssh/2014/03/msg00024.html before uploading, at this point
[14:53] <cjwatson> utlemming,smoser: Do you have any thoughts on the matter raised in https://lists.debian.org/debian-ssh/2014/03/msg00029.html ?
[14:54] <cjwatson> mdeslaur: (http://anonscm.debian.org/gitweb/?p=pkg-ssh/openssh.git, for future reference)
[14:55] <mdeslaur> cjwatson: thanks
[14:55] <utlemming> cjwatson: interesting....from a cloud-image perspecitve, cloud-init would disable that by default for our cloud images, unless the user wants it. Generally, the cloud market is split between allowing and disallowing root logins.
[14:56] <smoser> cjwatson, will have no affect on us. either way.
[14:57] <cjwatson> utlemming: Would you do just just by sedding sshd_config, or equivalent?
[14:57] <smoser> on cloud-iamge boots, cloud-init stuffs the provided ssh key into root's authorized keys, but disables login to it by a ssh key options (gives a message that says 'login as ubuntu')
[14:57] <cjwatson> utlemming: Or do you mean you're already disallowing root logins anyway?
[14:57] <cjwatson> Or disallowing password auth to root anyway
[14:57] <smoser> already disallowing root login. as that.
[14:58] <smoser> we don't change the root password login
[14:58] <smoser> so this would then allow the user to get in as root, but there is no root password in the images unless the user has set one.
[14:59] <cjwatson> OK, so no effect in default configuration.  Thanks
[15:01] <cjwatson> mdeslaur: If you think this is urgent, I guess I could do 6.6 first and then the root login change in a separate upload
[15:01] <mdeslaur> cjwatson: not urgent at all, not a big issue
[15:01] <cjwatson> Right, I didn't think it was too terrible.  Thanks
[15:03] <cjwatson> (Can't think of any especially horrible env vars that contain "LC_")
[15:04] <mdeslaur> yeah, me neither
[15:09] <doko> jamespage, should we sync tomcat8 from unstable?
[15:11] <doko> cking, could I have some feedback about lp: #1294669 ?
[15:12] <cking> nope, it does not exist :-(
[15:12] <cjwatson> it does, it's just private so the bot can't see it
[15:12] <cjwatson> but you filed it so you should be able to :)
[15:12] <cking> ah, sorry, it does, heh doko, will do, sorry
[15:13] <doko> cking, ohh, and 4.3-4ubuntu1 is currently building
[15:15] <cking> doko, unfortunately my history is probably way out of date, I'll try and reproduce it
[15:22] <Laney> doko: http://people.canonical.com/~laney/weird-things/webkit-preprocessed.xz
[15:22] <Laney> I just built wk on harris.debian.org & got that for you re: the ftbfs I pointed out yesterday
[15:23] <doko> ahh, nice
[15:23] <Laney> you should be able to grab it from my homedir there too if you want
[15:23] <Laney> to save building it again
[15:23] <cking> doko, I'm finding it hard to reproduce this issue, where as the day I filed it i could trigger it randomly quite frequently
[15:58] <jamespage> doko, hmmm
[15:58] <jamespage> doko, I'd be hesitant; its just going to sit in universe
[16:02] <doko> ok
[16:13] <doko> Laney, looks you can avoid that by not passing -fno-tree-dce
[16:14] <Laney> doko: turning off dead code elimination? what kind of an impact will that have?
[16:14] <Laney> do you think it's a gcc bug?
[16:15] <doko> no, turning on
[16:15] <doko> every ICE is a gcc bug
[16:15] <Laney> oh, I missed the double negation
[16:16] <doko> but I miss the background why you turned it off
[16:16] <Laney> I thought it could have been webkit generating some invalid asm
[16:16] <doko> just to confirm. you did see this in unstable too?
[16:17] <Laney> It was built in experimental but I don't think it actually installed any build-deps from there, only unstable
[16:18] <Laney> and I don't know why it's disabled, let me see if upstream knows
[16:21] <doko> can't see this with 4.7 and trunk
[16:24] <Laney> mmm, https://github.com/WebKit/webkit/commit/7678ecfd0590c406e43f1b7b8ab8c923d9bd26ab
[16:24] <Laney> so compiler bugs, let me see if they filed them upstream
[16:25] <Laney> bugs without, bugs with, what fun
[16:26] <doko> -fno-omit-frame-pointer doesn't help for the register pressure
[16:27] <slangasek> rbasak: no, it broke when 1) debhelper behavior changed, and then 2) somebody reuploaded mysql-5.5 without making the necessary source changes as described in that mail to ubuntu-devel.  In retrospect it seems we were not proactive enough in making sure that job-containing packages did get the necessary init script source changes, and given where we are now the way forward is to fix it centrally as an lsb functions hook
[16:27] <Laney> the comment there says 'incorrectly compiled operationCallEval'
[16:30] <doko> Laney, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1295738
[16:32] <Laney> doko: thank you, will look out for a fix
[16:56] <cornfeedhobo> hello. I am trying to nail down an issue I am having so I can decide if I should patch this and manually compile, or what.  I am trying to find out if the NetworkManager openvpn plugin has any ipv6 support, and i just dont know how to enable it, or if that is slated for patching soon?
[16:56] <maxiaojun> xnox: any news for usb-creator?
[16:57] <cornfeedhobo> there are some chats about a patch available on the mailing list
[17:06] <jamespage> rbasak
[17:06] <jamespage> oh - nm
[17:12] <hallyn> cking: forkstat looks awesome.  relatedly, comment system on your blog site sucks :)  i cannot get the capchas right.
[17:12] <hallyn> (or, my eyes suck <shrug>)
[17:13] <cking> oh, yeah, sorry about the capchas, but it gets load of spam otherwise
[17:14] <cking> the proc connector interface is poorly documented, hopefully the source of forkstat is some help :-)
[17:15] <hallyn> yes, i think it'll make a big difference in # people looking into it, a good thing
[17:17] <hallyn> cking: anyway to get it to tell who the fork parent was?
[17:17] <hallyn> oh heh there it is
[17:17] <cking> it's all there :-)
[17:18] <hallyn> just used it to look at that virtmanager bogosity.  I say, WTF!
[17:18] <ogra_> xnox, i think i asked you already, but forgot the answer, are you working on getting python-apt from the image (we have python3-apt)
[17:19] <cking> hallyn, that will keep you busy
[17:19] <xnox> ogra_: yes, but e.g. blocked by blockages. See my latest email in response to asac.
[17:20] <ogra_> xnox, yes, that remineded me that i wanted to ask you again :)
[17:20] <xnox> ogra_: yeah, _all_ of it is going, as soon as things land.....
[17:21] <ogra_> xnox, yeah, as soon as davmor2 is done testing i'll promote an image
[17:21] <xnox> ogra_: 250?
[17:21] <ogra_> he is just doing an additional verification test run
[17:21] <ogra_> yeah
[17:21] <xnox> ogra_: i don't see new gallery-app on image 250. So no good for me.
[17:21] <ogra_> i guess 251 will then have it
[17:23] <cjwatson> ogra_: click uses it to parse framework dependencies, that probably won't go away soon
[17:23] <cjwatson> ogra_: oh, sorry, that's only python3-apt
[17:23] <ogra_> :)
[17:26] <davmor2> ogra_, popey, sil2100: can you have a quick scan over the list other than the scopes that I'm about to start can you see anything else missing?  https://docs.google.com/a/canonical.com/document/d/1VkoSTUStDDPN84rwLztHIgSEK2HlbvXghZDBkBYVxTU/edit#
[17:27] <davmor2> sorry wrong channel
[17:28] <ogra_> davmor2, looks good
[17:40] <cyphermox> cornfeedhobo: it's already in the archive, in trusty
[17:43] <cornfeedhobo> cyphermox: orly?
[17:44] <cornfeedhobo> I was just starting to look into how to make a debian style package... i have a patch ready
[17:46] <cornfeedhobo> cyphermox: huzzah!
[17:47] <cornfeedhobo> thanks!
[17:47] <cornfeedhobo> now how should i install just that one package from trusty? can i just dpkg the deb?
[17:52] <seb128> bdmurray, ev: hey, do you know how e.g https://errors.ubuntu.com/problem/dae59d0805bf3202f10977ead46c964a07bb53be can have 0 report in its trusty column but trusty report in the examples list?
[17:53] <bdmurray> seb128: looking
[17:53] <seb128> bdmurray, thanks
[17:54] <bdmurray> seb128: well at least the first couple are missing Package: info in the report
[17:54] <seb128> bdmurray, do you know how that can happen?
[17:56] <bdmurray> seb128: not immediately
[17:56] <seb128> k
[17:56] <seb128> thanks anyway ;-)
[17:56] <seb128> that's probably not on the e.u.c side
[17:57] <bdmurray> it could be apport, I'd try manually causing a crash in hplip-data
[17:58] <bdmurray> actually a lot of 13.10 ones are missing them also
[18:08] <bdmurray> seb128: I setup a crash in hplip-data and my .crash files have the information so I don't really now
[18:08] <seb128> bdmurray, ok, thanks for looking
[18:08] <seb128> it's weird, but it seems only that package so no a big deal either
[18:09] <bdmurray> I know aptdaemon and the release upgrader have their own crash handlers but I don't see anything like that in hplip
[18:15] <arges> bdmurray: hey. i can start taking a look at the sru queue
[18:17] <bdmurray> arges: sounds good, no pending stuff today since its friday
[18:17] <cornfeedhobo> cyphermox: so, that patch seems to deal with not messing up ipv6 routes, which is good, but does not add a tab to the gui to control it
[18:18] <cornfeedhobo> and it does seem to expose ipv6 capability to all plugins, which is also good
[18:21] <cornfeedhobo> the gui layout file /usr/share/gnome-vpn-properties/openvpn/nm-openvpn-dialog.ui doesnt even mention ipv6
[18:23] <cyphermox> no, it doesn't have to
[18:23] <cornfeedhobo> okay
[18:23] <cyphermox> it's detected by NM from the capabilities of the VPN plugin
[18:23] <cornfeedhobo> hmm... let me update the core NM
[18:24] <cornfeedhobo> is trusy going to be systemd based?
[18:24] <ScottK> No
[18:30] <cornfeedhobo> any words on when that transition may start?
[18:31] <ScottK> Later
[18:39] <cornfeedhobo> cyphermox: my apologies. the problem appears to be with plasma-nm
[18:39] <cornfeedhobo> thanks
[18:39] <cornfeedhobo> i have been trying to narrow this down
[19:00] <juliank> bdmurray: Did you already find out why the tests with the pkg.is_upgradable are failing?
[19:01] <bdmurray> juliank: no, not yet
[19:40] <paulb> Is this the correct channel to get help with creating a ppa?
[19:42] <stgraber> paulb: nope
[19:42] <stgraber> paulb: #launchpad maybe
[19:42] <paulb> K, thanks stgraber
[19:51] <bdmurray> jamespage: this upload of juju-core looks a bit like a micro release and I don't see a MRE for juju.
[19:51] <bdmurray> jamespage: this being the one in the saucy proposed queue
[20:00] <jamespage> bdmurray, I agree that it is bordering on needing a MRE (which I have on my list to apply for)
[20:06] <jamespage> bdmurray, park it for the moment; I'll work through the linked bugs and do test-cases
[20:17] <YokoZar> Are archive admins the one to talk to if I want to add a package to the debian import blacklist?
[20:22] <infinity> YokoZar: Yep.
[20:22] <infinity> YokoZar: Also helps if you specify what it is, though.
[20:22] <infinity> YokoZar: (guessing something wine-related?)
[20:22] <YokoZar> infinity: Please add winetricks there, yeah
[20:23] <infinity> YokoZar: Seems we've had that all the way back to precise.  Why is it suddenly a problem?
[20:23] <infinity> (Or was it always, and we just didn't notice...?)
[20:23] <YokoZar> infinity: I'm readapting the debian package but it needs to fork at this point
[20:24] <YokoZar> infinity: basically it's going to keep recommending the debian wine package names (eg wine-unstable)
[20:24] <infinity> YokoZar: Okay, but if you fork it, there's no need to blacklist it.
[20:24] <infinity> blacklisting only makes sense if we're removing it.
[20:24] <YokoZar> infinity: err you're right
[20:24] <YokoZar> infinity: mom won't auto import it
[20:24] <YokoZar> infinity: which will be good enough
[20:25] <infinity> Right, go forth and fork.
[20:25] <YokoZar> actually
[20:25] <YokoZar> I'm wondering how the debian one got synced on top of ours to begin with
[20:25] <YokoZar> in precise
[20:26] <YokoZar> maybe someone did it manually (maybe even me) and I forgot
[20:27] <infinity> I don't see any ubuntu revisions in precise history.
[20:27] <infinity> There was one in quantal.
[20:28] <infinity> And it was indeed you who synced over the quantal delta.
[20:28] <infinity> https://lists.ubuntu.com/archives/quantal-changes/2012-August/007325.html
[20:29] <YokoZar> Well it did work at some level.  But now it needs to be in merge mode dropping the debian patches and making changes to the control file (and we may be upstream ahead of debian too)
[20:29] <YokoZar> Thanks infinity
[20:29] <infinity> YokoZar: If I were you, I'd just make the package clever enough to DTRT on both distros.
[20:30] <YokoZar> DTRT?
[20:30] <YokoZar> do the right thin
[20:30] <infinity> Do The Right Thing.
[20:30] <infinity> YokoZar: Since the build-dep is just debhelper, it's obviously only binary and runtime things you care about, and that can all be handled sanely by substituting things in debian/rules based on dpkg-vendor
[20:30] <YokoZar> I have plans to bring my wine packages to debian/steamos as well (via external apt repo) so it's not a bad idea
[20:31] <YokoZar> infinity: that's actually a clever idea, I forgot about variable substitutions like that
[20:41] <debfx> cyphermox: some patches in network-manager rely on TARGET_DEBIAN being defined, however that has been removed upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=012c5f4b271b935852267ed865933ea3bb6983ba
[21:07] <marrusl> anyone happen to know if there's a PPA with a pre-release version of the HWE trusty x-stack for 12.04?
[21:13] <tarpman> marrusl: looks like canonical-x/x-staging has something like it
[21:13] <marrusl> thanks tarpman, I will take a look
[21:14] <marrusl> tarpman, why I do believe that is exactly it.  sweet!
[22:03] <ekarlso> can someone tell me why my interfaces in 14.04 are named "rename<some number>" vs em3 and em4 as they should be ?!
[22:04] <jpds> ekarlso: New scheme.
[22:05] <ekarlso> jpds: but why the crap does it make it "renameX" instead of em?
[22:05] <ekarlso> i have a em3 which is the 3rd port on the port which _should_ be em3
[22:05] <ekarlso> ibstead it's em2 as a kernel name...
[22:06] <ekarlso> it even ignores my persistent udev rules
[22:12] <infinity> ekarlso: dmesg should have a bit of enlightenment as to which renames were attempted and why.
[22:12] <infinity> ekarlso: A persistent scheme that results in loops can sometimes lead to renames getting "stuck".
[22:14] <ekarlso> nope infinity
[22:14] <ekarlso> http://paste.openstack.org/show/74048/
[22:14] <ekarlso> it's freakin' frustrating
[22:15] <infinity> And what's in /etc/udev/rules.d/70-persistent-net.rules ?
[22:15] <ekarlso> nothing on the mentioned host
[22:15] <ekarlso> it doesn't write rules even
[22:16] <infinity> ekarlso: Is biosdevname in play here?
[22:16] <ekarlso> I have biosdevname installed ye
[22:16] <ekarlso> comes with 14.04 as stock it seems
[22:18] <infinity> Right, so that's where the bug lies, at least.  I'd file one, if I were you.
[22:18] <infinity> It does look like a logical fail with the rename hitting a loop, but that shouldn't happen in your case, I'd think.
[22:19] <infinity> Sadly, I don't know much about biosdevname, so a bug would be better to make sure the right person/people see it.
[22:19] <ekarlso> which udev rule calls it ?
[22:20] <infinity> ekarlso: It'll be something in /lib/udev/rules.d
[22:20] <infinity> I don't have it installed here, so don't recall for sure.
[22:20] <infinity> 71-biosdevname or something.
[22:20] <ekarlso> well I can't see it there..
[22:20] <ekarlso> oh, nvm there it is .
[22:24] <ekarlso> where to report that infinity ?
[22:25] <infinity> ekarlso: ubuntu-bug biosdevname
[22:27] <infinity> jtaylor: Man, that python-cffi testsuite takes an impressively long time to run when it doesn't fail. :P
[22:27] <jtaylor> yes but you only need to run two of them to see the failure
[22:28] <jtaylor> of the files
[22:28] <infinity> jtaylor: Well, I just did a full package build to make sure it worked with my local glibc build.
[22:29] <infinity> jtaylor: The two things you were waiting on were the backport of Siddesh's sin() fixes, and this no-regmove hack, right?  I have both of those staged, just pondering one or two unrelated fixes, but will upload in the next ~24h, so you'll be unblocked before beta freeze.
[22:29] <jtaylor> I wanted to try and bisect gcc-4.7..4.8 but for some reason every checkout failed to build so I gave up
[22:29] <jtaylor> yes I only have those two issues on my want-fixed list :)
[22:30] <infinity> Kay, then I have you covered.
[22:30] <ekarlso> stupid ass bisodevname
[22:30] <ekarlso> sucks balls
[22:30] <jtaylor> thx
[22:31] <jtaylor> does glibc do bugfix releases?
[22:32] <infinity> jtaylor: They do point releases, yeah, though we've been amazingly bad about maintaining the stable branches upstream.
[22:32] <infinity> jtaylor: There's been ongoing discussion over the last month or two about us doing better on that score.
[22:32] <jtaylor> I think this one would be a good reason to do one
[22:32] <jtaylor> the sin issue
[22:32] <jtaylor> wrong math is very bad
[22:32] <infinity> jtaylor: It's in the stable branch already, it'll make it in .1, if/when Allan decides to cut a release.
[22:33] <jtaylor> now that I know how to test glibc dev releases I'm going to run the stuff I care about against git head :)
[22:33] <jtaylor> the ./testrun.sh is quite convinient
[22:34] <infinity> jtaylor: Yeah, now that we're pretty much caught up with upstream, my plan next cycle is to be doing snapshot builds in a PPA.
[22:34] <infinity> jtaylor: And if I can get 2.19 to unstable soon, snapshot builds in experimental too.
[22:35] <infinity> (Should make rebasing patches a bit less painful if we're doing it incrementally instead of in a panic with each new release)
[22:50] <Noskcaj> Is anyone able to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU


[00:00] <apachelogger> omg, qtparted builds again
[00:00]  * apachelogger uploads before he finds something else to fix
[00:13] <apachelogger> [report] qtparted merged
[00:16] <apachelogger> [report] kdmtheme uploaded
[00:16] <apachelogger> Serega: https://edge.launchpad.net/ubuntu/+source/kdmtheme thank you :)
[00:16] <Serega> apachelogger: np =)
[00:20] <Serega> bah! qtstalker has changes in .orig
[00:24] <apachelogger> Serega: yeah, lovely, isn't it :S
[00:24] <Serega> apachelogger: sweet... I'm going to move it to cdbs, ok?
[00:25] <apachelogger> Serega: you can do everything, but you should keep in mind that everything you change increases the time one has to spend on the next merge
[00:25] <Serega> and, actually, want to clean the patch as it is not locale-aware :-\
[00:25] <Serega> woohoo!
[00:26] <apachelogger> lets make that almost everything ;-)
[00:40] <yuriy> Riddell: that timing doesn't work for me. as I said, I don't think any time during the next 3 weekends work for me, so I may not be able to do it at all
[00:42] <jofko> hello
[00:43] <jofko>  anybody knows where i can found default profile for settings  kde4 apps?
[00:46] <nixternal> seele: haven't heard anything about resizing issues
[00:46] <nixternal> I am experiencing a lot of the same issues that I have in the kde4daily
[00:48] <nixternal> Riddell: hahaha, you from Chicago? :P
[00:50] <seele> nixternal: do you have compiz installed?
[00:51] <nixternal> seele: no I do not
[00:56] <seele> ah hah
[00:56] <seele> nixternal: looks like compiz breaks kwin or something
[00:57] <seele> at least with what justin just installed
[00:57] <seele> he disabled all effects and he can resize windows now
[01:03] <nixternal> someone has compiz running with it smewhere because they were talking about it
[01:03] <yuriy> seele: bug 237567?
[01:07] <yuriy> hmm should I be concerned about kdegraphics failing to build on lpia?
[01:07] <yuriy> what is lpia anyways?
[01:14] <nosrednaekim> yuriy: yeah... I have to fix up the effects levels for Intrepid... they suck right now
[01:14] <nosrednaekim> yuriy: Low Power Intel Arch.
[01:32] <Serega> knite, folks
[01:38] <yuriy> nosrednaekim: maybe some of these should be fixed for Hardy?
[01:38] <yuriy> (you did desktop-effects-kde? i keep forgetting if it was you or mhb)
[01:38] <nosrednaekim> yuriy: I wanted to, but by the time I recognized there was a problem I couldn't
[01:38] <nosrednaekim> we kinda did it together
[01:38] <yuriy> ah. that explains it :P
[01:38] <nosrednaekim> but if there is a bug ^_^
[01:38] <yuriy> maybe some of them could be SRU?
[01:39] <nosrednaekim> I'll work on getting a better set of configs
[01:39] <nixternal> kdebindings suck!
[01:39] <nosrednaekim> gotta get compiz running first :P
[01:39] <yuriy> nixternal: are the 4.0 ones bad as well? have been avoiding those
[01:39] <nosrednaekim> nixternal: haha,.... apachelogg was complaing about them a couple weeks ago
[01:40] <yuriy> not that there's a lack of packages to choose from
[01:40] <nixternal> I am having an issue with the DOM:: classes with smoke
[01:43] <nosrednaekim> yuriy: whats a SRU?
[01:44] <nixternal> stable release update
[01:46] <nosrednaekim> ah
[01:46] <nosrednaekim> ok...  I can see any crashers there
[01:55] <yuriy> hmm maybe I can subscribe you or something. I don't know what the policy on that is, it hasn't been an issue for me since I'm in bugcontrl
[01:56] <nosrednaekim> I'd better get in bug ctrl
[01:57] <Jucato> seele, yuriy, Nightrose. congrats
[01:58] <yuriy> thx Jucato
[01:59] <nosrednaekim> yuriy: I suppose you as a council member just can't make me be in bug ctl :P
[02:00] <yuriy> nosrednaekim: hehe. wrong council ^_^
[02:00] <yuriy> it should be OK to just subscribe you or assign to you, but I want to make sure what the policy is
[02:06] <Jucato> the Jedi Council
[02:08] <nosrednaekim> yuriy: I'm the upstream maintaner pretty much so I don't see the harm
[02:08] <yuriy> nosrednaekim: I think these are OK to make public anyway
[02:09] <yuriy> nosrednaekim: what's your LP id?
[02:09] <nosrednaekim> nosrednaekim
[02:09] <nosrednaekim> :P
[02:14] <seele> yuriy: ah, yep. that's it
[02:14] <seele> Jucato: thanks
[02:16] <nosrednaekim> yuriy: ok... that first bug is probably kwin crashing...
[02:21] <yuriy> lol, i take it apport replaces usernames with "username" and this guy's username was "t"
[02:22] <yuriy> have fun reading that backtrace :P
[02:25] <yuriy> nosrednaekim: sorry if a couple of these are duplicates that apport didn't catch, i'm not paying too close attention to the traces
[02:28] <yuriy> nosrednaekim: you should probably just subscribe to bugs for the package
[02:29] <yuriy> (that doesn't help the private thing though)
[02:31] <yuriy> nosrednaekim: ok, you should be able to them all now
[02:31] <nosrednaekim> ok
[02:31] <nosrednaekim> couple of these aren't even bugs
[02:32] <yuriy> nosrednaekim: like? if it crashes it's a bug..
[02:32] <yuriy> titles might be off though, but traces tell all
[02:32] <nosrednaekim> like complaining about compiz not working.... and then saying he has no composite extention.... its a driver problem
[02:33] <yuriy> nosrednaekim: i think the trace is about something else though, same as half of them or so, about not finding Default.ini
[02:34] <nosrednaekim> ah... I see... I think I know what the problem is there too
[02:34] <nosrednaekim> lol.... I see the "t" one.. thats pretty funny
[02:36] <nosrednaekim> thanks yuriy, I'll take a look at those soon
[02:36] <yuriy> :)
[02:37] <yuriy> nosrednaekim: http://wiki.ubuntu.com/StableReleaseUpdates for further reading
[02:47] <yuriy> wow kdeedu is the 2nd biggest module
[03:22] <yuriy> hmm kalzium failed to build
[03:27]  * dAsKrEeCh finds that he doesn't understand stirgi very much
[04:05] <Hobbsee> mhb: i didn't give up.  i switched areas.  that being said, i'm reasonably inactive nwo
[04:06]  * dAsKrEeCh stickes daises in Hobbsee's hair
[04:06] <Hobbsee> ooh, daisies!
[04:07]  * dAsKrEeCh sticks spelling checks in dAsKrEeCh's keyboard
[04:07] <dAsKrEeCh> :-)
[04:11] <dAsKrEeCh> how are you Hobbsee?
[04:12] <Hobbsee> dAsKrEeCh: doing OK.  exams soon :(
[04:12] <dAsKrEeCh> which exams?
[04:14] <Hobbsee> uni
[04:14] <dAsKrEeCh> Duh
[04:14] <dAsKrEeCh> which subejects
[04:14] <dAsKrEeCh> subjects
[04:17] <Hobbsee> a java subject, a computer networking subject, and a maths subject on finite state acceptors, encryption, and otehr fun.
[04:22] <dAsKrEeCh> Hobbsee: sounds wonderful
[04:23] <crimsun> good luck
[04:26] <Hobbsee> thanks..
[06:05] <Jucato> nixternal: pokey pokey. if you could update your yakuake-kde4 package to at least 2.9.2. that version has a fix for keyboard shortcuts :)
[06:06] <Jucato> kthxbye :)
[06:06] <dAsKrEeCh> what kinda keyboard shortcuts?
[06:06] <Jucato> Fixed shortcuts with versions of KDE 4 trunk (4.1) from April 22nd 2008 and newer. The Konsole KPart now defaults to overriding shortcuts, and Yakuake must do additional work to continue to receive them. <---- those kind
[06:06] <Jucato> specially shortcuts to switch tabs
[06:07] <dAsKrEeCh> erk
[06:07] <Jucato> KDE 4.0 users won't probably notice the bug
[06:08] <dAsKrEeCh> That would be me
[06:08] <Jucato> s/notice/have/
[06:24] <dAsKrEeCh> Jucato: http://bomahy.nl/hylke/blog/yes-its-coming/
[06:25] <Jucato> poo kopete
[06:25] <Jucato> er.. poor*
[06:25] <Jucato> :D
[06:26] <dAsKrEeCh> Well far as I know that's why Google has been paying Sean for like a yaer now
[06:26] <dAsKrEeCh> Though.. I guess that might have been rumours
[06:29] <dAsKrEeCh> bah
[06:29] <dAsKrEeCh> reboot time
[06:29] <nixternal> Jucato: yakuake is 2.9.3 :)
[06:29] <nixternal> and yakuake has been 2.9.2 since yesterday
[06:30] <Jucato> your PPA?
[06:30] <nixternal> yup
[06:30] <nixternal> ~kubuntu-members-kde4
[06:30] <Jucato> ok. I'll inform flaccid to update
[06:30] <Jucato> thaaaaaaanks nixternal :)
[06:31] <Jucato> now can I have free money? :D
[06:36] <nixternal> always :)
[07:23] <Serega> good morning, friends
[07:23] <Serega> apachelogger: ping
[07:23] <blizzzek> morning
[07:24] <Hobbsee> evening!
[07:25] <Serega> good evening, Hobbsee! :)
[07:29] <nixternal> mornin'
[07:30] <santiago-ve> http://xkcd.com/433/
[07:34] <dasKreeCh> Oh please let Konqueror be fixed with Qt 4.4 come 4.0.5 :-)
[07:35] <\sh> dasKreeCh, use trunk ;)
[07:35] <dasKreeCh> \sh: after 4.1 ships :)
[07:36] <\sh> what I really like in trunk is the oxygene window color...it has some nice blue stripes in the titlebar...I wonder how I do get that back in 4.1beta packages
[07:37] <dasKreeCh> \sh: wait for Beta 2? :-)
[07:37] <\sh> dasKreeCh, na it's in trunk :) 4.0.81 ;)
[07:38] <\sh> dasKreeCh, so it has something to do with the color scheme
[07:38] <Serega> btw, my kde4-desktop became unusable after night update: strong artifacts on GUI
[07:39] <Serega> maybe proprietary nvidia driver though...
[07:40] <\sh> funny...on intel I don't have any problems with or without compositing...but on ati ... with compositing it's unsuable slow...and without it somehow works
[07:43] <Serega> gurus, who can review and upload my merge? it's not very big
[07:56] <Arby> morning all
[07:56] <Serega> Arby: hey
[07:56] <Serega> Arby: I have beaten kdmtheme :)
[07:56] <Arby> I noticed, good work :)
[07:57] <Serega> thank you
[08:01] <santiago-ve> gah >.< i want to s33lp!!
[08:07]  * Serega misses apachelogger
[08:30] <Nightrose> morning :)
[08:30] <Nightrose> Jucato: thx :)
[08:46] <Serega> morning Nightrose
[09:29] <Serega> interesting,,, can I upload my merge by myself?
[09:33] <Riddell> Serega: not unless you're a motu
[09:33] <Serega> hm... I want to became a motu
[09:34] <Serega> Riddell: Jon, have you a minute to review and upload?
[09:36] <Riddell> Serega: can do, what do you have?
[09:36] <Serega> Riddell: here http://paste.ubuntu.com/17428/
[09:37] <Serega> it is qtstalker
[09:39] <Riddell> https://wiki.ubuntu.com/UbuntuDevelopers#MOTU  for how to join MOTU
[09:43] <Riddell> hmm, paste.u.c not working here
[09:44] <Riddell> Serega: can you use another pastebin
[09:44] <Serega> Riddell: I have use kubuntu.pastebin.ca, but apachelogger has banned it :)
[09:45] <Serega> Riddell: what do you prefer?
[09:45] <Riddell> that's fine
[09:45] <Serega> I can repast this in a second
[09:45] <Serega> wait a sec...
[09:47] <Serega> Riddell: http://kubuntu.pastebin.ca/1040226
[09:47] <Tonio_> Riddell: I have a python/qt developper here that would be interested in coding a kcm module for xrandr for both kde3 ans kde4
[09:47] <Tonio_> Riddell: what is the email of the guy doing the gnome thing we saw at the uds ?
[09:47] <flaccid> Tonio_: does the retricted drivers support randr for multiple displays?
[09:48] <Tonio_> flaccid: I don't use them, but I think there is an effort for this
[09:48] <Riddell> Tonio_: bryce
[09:48] <Tonio_> flaccid: I personnaly use radeonhd atm
[09:48] <Tonio_> Riddell: Harrington ?
[09:48] <Tonio_> Riddell: great, I'll ping him on that point then
[09:48] <Riddell> Tonio_: yes, but it's probably easier to fix the tool in KDE 4
[09:49] <Tonio_> Riddell: the krandrtray ?
[09:49] <flaccid> Tonio_: yep its a big gap in the support :(
[09:49] <flaccid> especially for nvidia users
[09:50] <Tonio_> Riddell: I was thinking about that for kde3 too in fact (I still have to consider kde3 for our clients unfortunatelly...)
[09:50] <Riddell> "Make debian/rules fail on clean errors"  Serega why that?
[09:50] <Serega> Riddell: just to calm down lintian. Maybe phrase isn't so good
[09:51] <Serega> Riddell: you can see: I just have turned on care of clean-errors
[09:51] <Riddell> Serega: you edited Toolbar.h ?
[09:52] <Serega> Riddell: nope, debian had that change in .orig
[09:52] <Riddell> tsk
[09:53] <Riddell> hmm, the same change is in 02_fix_gcc4.3_ftbfs.diff
[09:53] <Serega> if the same == in .orig
[09:53] <Serega> then yes
[09:54] <Serega> It's to send this dpatch stuff to debian maintainer asap
[09:54] <Serega> *it's better
[09:54] <Serega> before they do more changes in original source
[09:57] <Riddell> patch unexpectedly ends in middle of line
[09:57] <Riddell> patch: **** malformed patch at line 238:
[09:57] <Riddell> wibble
[09:57] <Riddell> Serega: can you pastebin just the 02_fix_gcc4.3_ftbfs.diff file, patch doesn't like it for some reason
[09:58] <Serega> Riddell: sec...
[10:02] <Serega> Riddell: here http://kubuntu.pastebin.ca/1040236
[10:02] <Serega> kubuntu.pastebin.ca lagged
[10:03] <santiago-ve> shehs! Riddell you dont sleep?!
[10:04] <Riddell> I just had a good 9 hours of sleep
[10:04] <Nightrose> Riddell: don't tell anyone - you'll loose this superhero aura ;-)
[10:05] <Serega> :)
[10:05] <Riddell> but I was hacking on code in that sleep!
[10:05] <Nightrose> hah
[10:05] <Nightrose> very good
[10:05] <Nightrose> ;-)
[10:05] <Serega> true developer never leaves coding
[10:05] <santiago-ve> ^  true
[10:06] <santiago-ve> im still "merging" 3 sources of the same project... made by different developers... >.<
[10:07]  * santiago-ve started 2 days ago :S
[10:10] <Riddell> santiago-ve: what project is that?
[10:10] <santiago-ve> Riddell, the ROMBO project...
[10:11] <santiago-ve> you can read some here: www.rombo.org.ve if you cna understand spanish... or i can give you a small overview
[10:13] <Riddell> it uses gambas?
[10:14] <santiago-ve> the client, yes
[10:15] <santiago-ve> that project is a exotic mix of languages~
[10:16] <Riddell> Serega: stalker uploaded, many thanks
[10:16] <Serega> Riddell: thanks Jon
[10:18]  * santiago-ve getting hungry >.<
[10:18] <santiago-ve> and no pizzas left...
[10:18] <santiago-ve> well back to work anyways...
[10:19] <Serega> it is ok if I pick qemu?
[10:19] <Riddell> Serega: that's a complex app, and nothing to do with qt
[10:20] <Riddell> you'd need to ask the server team if you wanted to do it
[10:20] <Serega> ah,,, not qt, right
[10:20] <Serega> not really
[10:20] <Serega> so... qsynth?
[10:21] <Riddell> go for it
[10:21] <santiago-ve> Serega, Riddell have you seen some app called Qtdevelop¡
[10:21] <santiago-ve> ?
[10:21] <Serega> santiago-ve: yes
[10:21] <Serega> but only seen
[10:21] <Riddell> santiago-ve: no but I've heard of it
[10:22] <santiago-ve> for a sec i thought it was on the repos... anyways... its somewhat "quick" to develop c++ stuff with qt bindings~ very interesting tho
[10:23] <Riddell>  [dpkg-source output:] dpkg-source: error: file filelight_1.0.orig.tar.gz has size 1386174 instead of expected 718760
[10:23] <Riddell> E: 'dpkg-source -x' failed for /home/lp_archive/syncs/filelight_1.0-2.dsc [return code: 6400].
[10:23] <Riddell> looks like that'll need to be merged then
[10:25] <Serega> how can such happen? misupload of original tar?
[10:32] <Serega> Riddell: looks like qsynth can be synced. I just can't what does "
[10:32] <Serega> mv $(CURDIR)/debian/qsynth/usr/share/applications/desktop $(CURDIR)/debian/qsynth/usr/share/applications/qsynth.deskt
[10:32] <Serega> op
[10:32] <Serega> " do
[10:32] <Serega> sorry
[10:33]  * Serega will never ignore konversation warnings
[10:35] <santiago-ve> hahahah
[10:35] <santiago-ve> :p Serega happens sometimes :D
[10:40] <santiago-ve> woooooo almost done here >.<
[10:45] <Riddell> Serega: it moves it tohave a valid name
[10:46] <Riddell>   * debian/rules: rename desktop to qsynth.desktop (LP: #93218)
[10:46] <Serega> Riddell: ah... first is not a directory... somehow straightforwards solution. May I fix it in the right way?
[10:46] <Riddell> Serega: what's the right way?
[10:47] <Serega> Riddell: if the desktop file is generated by build tools then I will force them to produce 'qsynth.desktop' instead of 'desktop'
[10:48] <Serega> however good patch for upstream
[10:49] <Riddell> doesn't look like it is
[10:49] <apachelogger> Riddell: why would you use another pastebin than paste.u.c?
[10:50] <Serega> Riddell: aha, I see. then create a dpatch which deletes desktop and creates qsynth.desktop. How do you think?
[10:50]  * Serega waves to apachelogger
[10:50]  * apachelogger gives Serega a cookie
[10:51]  * apachelogger has a photo shooting thing in 40 minutes :S
[10:51]  * Serega crunches and smiles widely
[10:52] <Riddell> Serega: shrug, can do
[10:53] <Riddell> apachelogger: because p.u.c wasn't working for me
[10:53] <Serega> woohoo!
[10:54] <apachelogger> Riddell: strange, it's like the only one that is working in a usable way for me all others are loading for ages
[10:57] <Riddell> I just wish they wouldn't change everything to dos lineendings
[11:01] <apachelogger> Riddell: that sounds like a wishlist bug ;-)
[11:01]  * apachelogger has to leave
[11:01] <apachelogger> laters
[11:01] <\sh> apachelogger, it sounds like a developer bug
[11:11] <Serega> server reboot?)
[11:14] <flaccid> trying to install coremoid from the 4.1 beta 1 ppa which requires libplasma1, but thats not in the ppa repos yet?
[11:16] <\sh> flaccid, libplasma2
[11:17] <\sh> flaccid, looks like it's not updated for it
[11:19] <Serega> I see "debian-rules-ignores-make-clean-error" again, is it normal? shouldn't we fix that?
[11:20] <flaccid> \sh: yep gotya
[11:20] <\sh> Serega, it's a packaging faux pas
[11:21] <flaccid> thanks
[11:21] <\sh> Serega, file a bug + send fix in dbts and/or fix it in ubuntu
[11:22] <Riddell> the correct fix is usually not just to remove he dash though
[11:22] <Serega> \sh: I'm merging this package right now, so I guess no need to file a bug
[11:22] <\sh> Serega, it's really a faux pas which should be fixed in debian + ubuntu to be lintian clean :)
[11:22] <Serega> autotools artifacts?
[11:23] <\sh> Serega, debian/rules: clean: \n -$(MAKE) clean is wrong ;)
[11:23] <\sh> Serega, take a look here: http://lintian.debian.org/reports/tags/debian-rules-ignores-make-clean-error.html
[11:24] <Serega> \sh: I understand but it is a consequence, not a source of problem
[11:24] <Serega> \sh: what forces maintainers to put that dash?
[11:25] <\sh> Serega, there are some cornercases where you want that the build / debuild just runs through and not throwing errors
[11:26] <\sh> the "dash" will actually do that...ignoring errors in debian/rules aka makefile
[11:26]  * Serega likes that
[11:26] <Serega> clean builds I mean
[11:27] <\sh> it's a misunderstanding of the clean target imho...the same as "not understanding build-dependencies which needs to be installed before someone does debuild -S [-sa -k...]
[11:29] <santiago-ve> w00t! almost done... and i'm gonna make it to get early to work...
[11:29] <\sh> Serega, well...clean target, as said, will be executed two times: 1. debuild -S , but most of the time (especially for autotools packages) the Makefile is not created...2. during build phase..Makefile exists, so it shouldn't fail at all, but some Makefiles (even produced by configure) do have bugs, and with the "-" in front of that, the maintainer doesn't see them => totally wrong...
[11:30] <Serega> hehe...
[11:30] <\sh> Serega, checking if Makefile exists ==true then executing "make clean" is sane...and if Makefile exists == false , don't call "make clean" :)
[11:31] <Riddell> yes,  [ ! -f Makefile ] || $(MAKE) distclean
[11:31] <Riddell> is the way to go
[11:31] <Serega> cool, I will arm this
[11:31] <\sh> Riddell, as written on linitian report page ;)
[11:31] <Riddell> that's where I copied it from :)
[11:31] <Serega> qsynth behaves strange...
[11:32] <Serega> several patch-system-but-direct-changes-in-diff, but I have copis all source from orig just before debuild
[11:33] <Serega> I guess some targets modify sources :-\
[11:33]  * Serega wants to fix and looks carefully at Riddell and \sh
[11:33] <\sh> depends what was done before ... what does changelog says? :)
[11:35] <Serega> \sh: "patch-system-but-direct-changes-in-diff config.guess" I doubt this is reflected in the changelog :)
[11:35] <Riddell> Serega: if it's just config.guess/config.sub I don't care
[11:36] <Riddell> autotools will do that and I've never found it worth the hassle to tidy it up
[11:36] <Riddell> Makefile.in likewise
[11:36] <Serega> Riddell: not only, that's the problem
[11:36] <Riddell> what else?
[11:36] <Serega> aaa, f..ck
[11:37] <Serega> \sh: changelog rulez
[11:37] <Serega> :)
[11:37] <Serega> Riddell: 'desktop' is just added by the Maintainer)))
[11:37] <Serega> how did you say this? tsk?)
[11:37] <Riddell> tsk indeed
[11:37] <Serega> whew
[11:38] <Riddell> it should be added inside the debian/ dir
[11:38] <Riddell> and given the correct name
[11:38] <Riddell> feel free to fix then send the diff to debian bug tracker
[11:39] <\sh> hopefully he didn't just change the .desktop file, and patching other stuff with quilt/dpatch/simplepatchsys or whatever...he should use only one patch system...
[11:39] <Serega> aha, thanks guys
[11:39] <Serega> \sh: no patchsystem was used at all
[11:40] <\sh> Serega, why is lintian complaing then, a patch system is added to debian/control then but not used?!
[11:40] <\sh> complaining even
[11:40] <Serega> \sh: I have added it :)
[11:40]  * \sh shoots Serega  ;)
[11:40] <Serega> ...but that was only a top of the iceberg
[11:41]  * Serega dies
[11:41]  * Serega pursuits \sh as a terrific ghost
[11:41]  * \sh remebered a ubuntu-motu-school session about patching system...did they ever told the audience, that the debian diff.gz is already a patch system? ,-)
[11:42] <Riddell> a patch system that should never be used!
[11:43] <\sh> -EDEPENDS -EMAINTAINERDECISION -EBUTDONTINTRODUCEANEWONERULE1
[11:44] <\sh> but we can agree...diff.gz is nice, but for small/medium/heavy source patches totally stupid....the same goes for cdbs/simplepatchsys
[11:44] <Serega> that guy have converted one icon fron png to xpm. I think it's better to convert at the build time by imagemagick, how do you think, gurus?
[11:45] <\sh> Serega, and introducing a complete imagemagick build-dep?
[11:45] <Riddell> sounds like hassle
[11:45] <Riddell> also the .xpm is for debian menu system, which we don't care about in ubuntu land
[11:45] <\sh> Serega, shiped in debian/ or directly in $(CURDIR)?
[11:45] <Serega> \sh: .dep of course
[11:46] <Serega> in .org :)
[11:46] <\sh> but the old .png is still there?
[11:46] <Serega> Riddell: oh, okay I will move it to ./debian only for debian
[11:46]  * Serega is poetic today
[11:47]  * \sh is confused now
[11:47] <Serega> \sh: what?
[11:47] <\sh> if debian maintainer is doing that in diff.gz, leave it as it is...don't introduce another barrier....
[11:48] <\sh> if the .png from .orig.tar.gz is not installed to the proper location, address this only in debian/rules and install the .png
[11:49] <\sh> if you need to patch things, please use the same patch system (here: diff.gz) and annotate that in debian/changelog or a sane location
[11:49] <Serega> \sh: png is installed
[11:49] <Serega> \sh: I would like to perform this for build sanity
[11:50] <Serega> \sh: I will do as you advice, thank you
[11:50] <\sh> Serega, just remove quilt/dpatch from debian/control and patch the sources directly as the maintainer did...that helps ... and file a bug to debian maintainer, to switch patch system to a sane default
[11:51] <\sh> hopefully he listens ;)
[11:51] <Serega> \sh: heh, that's easy. ok.
[11:51] <Serega> \sh: erm... please point me to debian bugtracker
[11:51] <\sh> bugs.debian.org ?
[11:52] <Serega> dunno, really
[11:52] <\sh> you need to file the bug via email still :)
[11:52] <Serega> :)
[11:52] <Serega> oh...
[11:52] <\sh> it's not as simple as lp but there is a doc who to do it
[11:52] <\sh> s/who/how/
[11:57] <Serega> \sh: is "Please convert your changes to high level patchsystem patches" sound good?
[11:57] <Serega> as a title
[11:58] <NForce24> hi all, i have a bad crash on kde4.0.80. here it is:
[11:58]  * santiago-ve writes: bzr commit -m "<some loooooooooong comment"
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <santiago-ve> NForce24, use pastebin please
[11:58] <Serega> aw...
[11:58] <NForce24> kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[11:58] <NForce24> shit, sorry
[11:58] <flaccid> ban NForce24
[11:59] <flaccid> NForce24: you might want to read freenode guidelines
[11:59] <NForce24> ok i cant use this client :/
[11:59] <flaccid> why not use something useable like konversation
[12:00] <santiago-ve> hell im hugry as hell
[12:04] <Jucato> flaccid: what was he using?
[12:05] <Jucato> santiago-ve: did you just eat NForce24? O.o
[12:05] <santiago-ve> Jucato, well... i think... i just ate an arepa with meat :D
[12:06] <flaccid> Jucato: actually not too bad.. KVIrc 2.1.3 'Renaissance': build 5022 Thu Nov 23 13:23:48 UTC 2006
[12:06] <nforce__> ok, now i hope it will paste normally
[12:06] <nforce__> i have upgraded my kde4.0.5 to kde4.0.80 via apt-get dist-upgrade, and now system settings->appearance does not work..when i click on it, system settings exits. the same problem with kopete->configure->chat window
[12:07] <flaccid> [20:58] <flaccid> NForce24: i can't replicate your bug. are you sure the upgrade worked correctly? does sudo apt-get update && sudo apt-get upgrade && sudo apt-get install kubuntu-kde4-desktop return anything besides nothing to upgrade?
[12:09] <nforce__> my upgrade didn't work correctly. i got many errors, and i had to do apt-get -f install many times. errors were on kdebase packets (but after few tries, they were updated) and there were errors on updating kdeutils too
[12:10] <nforce__> and only kdf packae is still not installed because of error
[12:11] <flaccid> nforce__: so what is the output of the command above?
[12:11] <Serega> Riddell \sh: damn... looks like qsynth-0.2.5 package is an orphan: upstream is 0.3.2 from 2007-12-19 !
[12:12] <Riddell> hum, time for an upgrade?
[12:12] <\sh> Serega, check wnpp meta bug list on dbts :)
[12:12] <nforce__> updated 0m installed 0 new, 0 for remove, and 0 not updated
[12:12] <Serega> Riddell: may I, may I repackage it? it helps me to understand packaging
[12:12] <Serega> :)
[12:12] <\sh> Serega, http://bugs.debian.org/wnpp
[12:14] <\sh> Serega, the last upload of the orig maintainer was 2006-11-27
[12:14] <\sh> http://packages.qa.debian.org/q/qsynth.html
[12:15] <Riddell> Serega: go for it
[12:15] <Serega> Riddell: repackage from scratch for sid?
[12:15] <Serega> intelligently, of course
[12:16] <Riddell> well I'd start with intrepid
[12:16] <Riddell> then submit to debian if you want
[12:25] <Serega> why are build-stamp file tricks needed?
[12:35]  * Serega goes to the job :(
[12:47] <Riddell> file tricks?
[12:49] <seele> Riddell: so i was thinking about kickoff menu items and intrepid upgrades
[12:49] <Riddell> seele: mm hmm?
[12:49] <seele> Riddell: and pretty much anyone upgrading from 3.5.9 to 4.1.3 will have a lot of double kde3/kde4 applications, huh?
[12:49] <seele> Riddell: should we think about an upgrade/remove utility for in the upgrade process? to clean out old kde3 applications (editable of course)
[12:50] <Riddell> seele: in intrepid most kde 3 apps are just replaced with the kde 4 one
[12:50] <seele> right, so how does that effect currently installed applications?
[12:50] <seele> right now i have hardy and a ton of kde3 applications
[12:50] <Riddell> they get upgraded to the kde 4 version
[12:50] <seele> ok, so kde3 app entry gets removed?
[12:51] <Riddell> it's not like hardy where we have kde 3 and 4 co-installable
[12:51] <seele> unlike what happens now?
[12:51] <Riddell> yep
[12:51] <seele> ok ok, that's what i wanted to make sure of
[12:51] <seele> cool, thanks for indulging me :)
[12:56] <nosrednaekim> Riddell: what if I wanted the kde3 version.... is kde3 now going to be installed to /usr/lib/kde3 :P ?
[12:56] <nosrednaekim> or will you just chnage the executable name....
[12:57] <txwikinger> Will KDE4 really be ready for commercial use?
[12:57] <flaccid> i would hope so
[12:58] <Riddell> nosrednaekim: kde 3 libs is still around, if there's no kde 4 version then we'll only have the kde 3 package still
[12:59] <Riddell> txwikinger: it'll be ready for an intrepid release
[12:59] <nosrednaekim> ok.... I can't think of any kde3 apps I'd like to have when I can have the kde4 one, so thats probably going to be fine.
[13:01] <Riddell> nosrednaekim: how does this time and day suit you? https://wiki.kubuntu.org/KubuntuTutorialsDay/Prep
[13:03] <nosrednaekim> fine as far as I know right now
[13:03] <nosrednaekim> Hopefully there won't be any graduation parties i'll have to go to...
[13:03] <Riddell> so everyone is fine apart from yuriy
[13:04] <nosrednaekim> and I have a day or so to get really familiar with making plasmoids :P
[13:09] <Riddell> a week
[13:10] <nosrednaekim> Riddell: I'll be gone half the week for orientation at the university
[13:11] <apachelogger>   libqt4-debug: Depends: libqt4-gui (= 4.3.4-0ubuntu3) but 4.4.0-1ubuntu5 is to be installed
[13:12] <apachelogger> Riddell: please kill the libqt4-debug deb
[13:16] <JontheEchidna> nixternal: It seems that your recompile-gtk-qt-engine-kde4-with-KDE-4.1 trick didn't work. It also seems that the latest svn update of gtk-qt-engine fixes the segfaultiness.
[13:17] <nosrednaekim> nixternal is still asleep no doubt :P
[13:17] <ScottK> Best time to kick him.  He won't move.
[13:19] <JontheEchidna> I tried to package the latest svn but the patches won't apply
[13:27] <Riddell> JontheEchidna: uploaded your patch to bug 235121 thanks
[13:28] <apachelogger> ah, no need to package google gadgets for linux, plasma is getting native support :D
[13:36] <JontheEchidna> Riddell: Glad I could help
[13:40] <etretyak> Hey guys, do we have some real development plan for Intrepid with people responsibility and so?
[13:40] <etretyak> Riddell: ^^
[13:42] <etretyak> According to USD Specs we need to do a lot of things.. and with out following some plan we may fail..
[13:43] <ScottK> etretyak: In general, yes.  It's not all worked out and we'd always love to have more help.
[13:44] <Riddell> step 1 would be updating the ToDo page I guess
[13:44] <Riddell> then find people for the tasks
[14:07] <etretyak> Riddell: I think it is not enough just to find people.. We need to formilize development process.. It is opensource.. and people starts and quits projects. I think we should create some  simple plans for each project to follow development process..
[14:07] <etretyak> imho :)
[14:14] <Nightrose> ewwww is it just me or is this signature inappropriate? https://lists.ubuntu.com/archives/kubuntu-users/2008-June/028616.html
[14:15] <Riddell> Nightrose: highly
[14:15]  * Riddell e-mails him
[14:15] <Nightrose> thx
[14:16] <\sh> my company sig has more lines ;)
[14:16] <\sh> people don't care about netiquette anymore nowadays
[14:17] <Nightrose> \sh: it is not about the length...
[14:17] <Nightrose> read the first line
[14:17] <Hobbsee> ...wow
[14:17] <Nightrose> indeed
[14:18] <Hobbsee> Nightrose: i'd suggest a signature about castration in return, or something, but i don't think the other men would be so happy...
[14:18] <Nightrose> Hobbsee: ;-)
[14:18] <Nightrose> anyway... it is being dealt with - let's move on
[14:18] <\sh> oh ...
[14:19] <\sh> idiot...I should send him an igasm ;)
[14:19] <Nightrose> heh
[14:21] <\sh> Nightrose, a nice feature of my email client is to cut out signatures...
[14:23] <coreymon77> i dont use email clients
[14:23] <coreymon77> i just use gmail
[14:23] <\sh> gmail doesn't work properly with my imap server...
[14:23] <Nightrose> dito - though I am just giving the new kontact a try
[14:23] <Nightrose> let's see how that goes
[14:24] <\sh> but that's not important...kwin just crashed with twitter plasmoid
[14:24] <coreymon77> what do you mean it doest work
[14:24] <coreymon77> its webmail
[14:24] <coreymon77> you open up a browser and go to it
[14:25] <\sh> coreymon77, 1) webmail is a problem 2) I have my own mailspool on my imap server...never use a global player, if you want to avoid lawful interception especially in the US
[14:25] <coreymon77> oh, im canadian
[14:25] <coreymon77> so i dont have to worry as much about that stuff
[14:25] <coreymon77> besides, ive got nothing to hide anyways
[14:26] <\sh> coreymon77, you have...gmail sits in the us...and the us state can intercept all emails they don't care what nationality the user has
[14:26] <coreymon77> what do i care what the us does
[14:26] <coreymon77> i have nothing to hide
[14:26] <\sh> most people who are intercepted have nothing to hide...
[14:26] <coreymon77> go ahead, read my email
[14:27] <coreymon77> the most you are goig to get is a few links to funny flash sites
[14:27] <\sh> can someone reproduce it? add twitter to the desktop, and resize it...
[14:27] <Nightrose> \sh: worksforme
[14:28] <\sh> hmmm....
[14:28] <\sh> oh it's not kwin...
[14:28] <\sh> it's da plasma itself
[14:28] <\sh> now panel is gone
[14:30] <Nightrose> \o/
[14:31] <\sh> I wonder how I can get it back now
[14:32] <Nightrose> \sh: right klick on desktop -> add panel
[14:32] <ScottK> coreymon77: If you don't care about your privacy now, someday when you do care, you won't have any.
[14:33] <coreymon77> ScottK: that would be when i change email
[14:33] <\sh> Nightrose, there is no clicking anymore...the only thing which works are the key shortcuts to switch desktops
[14:33] <Nightrose> \sh: ohhh nice ;-)
[14:33] <ScottK> For the guy with the bad sig, if it were my list, I'd just unsubscribe him and tell him to come back once he's out of the 1950's.
[14:33] <JontheEchidna> Riddell: kubuntu-meta 1.76 has failed to build across most platforms
[14:35] <Riddell> JontheEchidna: blame python-apt, not worth worrying about currently
[14:35] <JontheEchidna> ok
[14:35] <Nightrose> hmmm keyboard shortcuts in konsole are interferring with my irrsi shortcuts :(
[14:36] <ScottK> Riddell: Any more thoughts about python-kde3 and libkonsolepart.so?
[14:36] <ScottK> Riddell: You were right on about the kde4libs build failures.  Once zul fixed mysql, amd64 built just fine, so I just kicked of retrying the rest.
[14:38] <Riddell> ScottK: not had a chance to look at it but it can't be that hard to stop it using konsole, it was only added recently
[14:40] <ScottK> Remove the konsole dependency and then rip stuff out until it builds?
[14:42] <santiago-ve> err
[14:42] <santiago-ve> guys
[14:42] <santiago-ve> looks like i just found a bug... or idk... konsole doesnt starts when user has fish as default shell :S
[14:42] <santiago-ve> nvm
[14:42] <santiago-ve> my mistake
[14:42] <jpds> fish is a shell?
[14:43] <Nightrose> santiago-ve: i have it as default and it works just fine :)
[14:43] <Nightrose> jpds: it is - and a nice one
[14:44] <santiago-ve> Nightrose, ye... it just saw the "not found msg wrote it wrong lol"
[14:44] <Nightrose> santiago-ve: ah ok ;-)
[14:44] <jpds> Nightrose: ah right.
[14:44]  * jpds hugs his zsh
[14:44] <santiago-ve> now trying to get a tty with root to fix it
[14:44] <santiago-ve> xD
[14:48] <jpds> Nightrose: nice shell indeed.
[14:48] <Nightrose> ;-)
[14:48] <santiago-ve> done... fixed
[14:48] <Nightrose> yay
[14:50] <santiago-ve> ah there :d
[14:51] <santiago-ve> :D
[14:51] <santiago-ve> got my shell again :D
[14:53] <\sh> grmpf
[14:54] <\sh> now i had to delete all my .kde* dirs
[14:55] <emonkey> hf
[14:55] <\sh> moins danimo
[14:55] <danimo> heya
[14:56] <danimo> does anyone know why psi segfaults in hardy?
[14:56] <danimo> seems to crash in qca
[14:56] <nosrednaekim> danimo: not getting any segfaults here
[14:56] <danimo> nosrednaekim: do you have backports enabled?
[14:56] <nosrednaekim> no...
[14:56] <danimo> that might be it
[14:58] <\sh> qt4 crash?
[14:59] <danimo> \sh: I think it's related to  the fact that I have the kde4 repo installed
[15:00] <nosrednaekim> danimo: I have that too...
[15:00] <\sh> danimo, when does it crash?
[15:01] <\sh> directly or only after you logged in?
[15:02] <\sh> doesn't crash here...and I have the ppa packages installed
[15:02] <danimo> \sh: right at startup
[15:04] <\sh> not here...
[15:04] <danimo> \sh: removed the backup packages, problem remains
[15:04] <nosrednaekim> danimo: do you have kde4 packages from backports?
[15:04] <nosrednaekim> *qt4
[15:05] <danimo> I removed the backports and deinstalled all kde4 packages
[15:06] <\sh> danimo, try to reinstall qt4 libs again...
[15:08]  * danimo removes
[15:09] <\sh> apt-get install --reinstall ? ;)
[15:10] <danimo> oh that exists?
[15:10] <danimo> *blushes*
[15:11] <\sh> well, depends what you have installed...hardy libqt4 you need to remove/purge the newer ones and then install from hardy official archives (!= backports, != ppa)
[15:14] <danimo> no worky
[15:15] <danimo> brb
[15:25] <jjesse> with today's updates from the ppa will that be all of kde 4.1 beta 1?
[15:26] <JontheEchidna> I don't think kdebindings have been updated yet
[15:26] <jjesse> JontheEchidna: thanks for the info
[15:29] <danimo> \sh: didn't work
[15:30] <\sh> what does strace say?
[15:33] <\sh> now...time to rush home
[15:33] <danimo> \sh: nothing useful
[15:34] <danimo> \sh: crahses after a few futex calls
[15:34] <\sh> grmpf
[15:34] <danimo> crashes in QCA::providers
[15:34] <danimo> no debug syms unfortunaly
[15:34] <\sh> you can get them
[15:34] <\sh> ddeb.ubuntu.com
[15:35] <\sh> ddebs.ubuntu.com?
[15:36] <\sh> so...now...cu later...
[15:37] <danimo> ok
[16:18] <etretyak> cu
[17:42] <yuriy> kdeaccessibility-kde4 debian/ looks scarily simple
[17:52] <Riddell> yuriy: it needs someone to split it up
[17:52] <Riddell> yuriy: how is 4.0.5 coming along?
[17:54] <yuriy> Riddell: slowly
[17:55] <Riddell> yuriy: I see you've uploaded a good number to updates-testing
[17:55] <Riddell> yuriy: do you know of anyone who has tested them yet?
[17:55] <yuriy> yeah, but a bunch left to go. and I don't think anybody's tested them other than myself
[17:56] <Riddell> hardy testers needed for 4.0.5!
[17:56] <yuriy> hmm for kdeaccessibility I didn't get a debian/tmp after running debuild
[17:57] <Riddell> yuriy: there's only one .deb made so it gets installed to debian/<packagename> instead
[17:57] <Riddell> no need for --list-missing
[17:57] <yuriy> ah, ok
[17:58] <jjesse> if i have 4.1 installed on hardy then i can't test 4.0.5 correct?
[17:59] <Riddell> no, you'd need to uninstall it
[17:59] <Riddell> well, you could use a chroot
[17:59] <jjesse> hrmm
[18:01] <jjesse> don't think i have time right now to figure that out
[18:07]  * Riddell gives it a shot
[18:08] <jjesse> sorry i'm trying to learn a new product and then write a training course about it
[18:17] <Riddell> ah, stdin :)
[18:18] <stdin> \o
[18:19]  * nixternal is hungry
[18:19] <Riddell> stdin: able to test yuriy's 4.0.5 packages?
[18:20] <stdin> should be able to on my desktop, yeah
[18:20] <Riddell> deb http://ppa.launchpad.net/kubuntu-updates-testing/ubuntu hardy main
[18:37] <Riddell> yuriy: working good here
[18:37] <yuriy> cool
[18:38] <nixternal> hrmm, how come dpkg --compare-versions doesn't want to work for me dangit
[18:38] <Riddell> nixternal: echo $?
[18:38] <Riddell> what are you doing?
[18:39] <Riddell> yuriy: what modules still to do?
[18:39] <nixternal> 0
[18:39] <nixternal> just messing around
[18:40] <Riddell> 0 means true
[18:40] <yuriy> Riddell: everything there that's not updated in the last 2 days. -kdeartwork is incoming
[18:40] <nixternal> 0 means true? what? :)
[18:41] <Riddell> nixternal: well it depends on what you asked it
[18:41] <Riddell> dpkg --compare-versions 1 gt 2; echo $?
[18:41] <nixternal> ahhh
[18:41] <nixternal> that's what I was doing wrong
[18:42] <txwikinger> nixternal: yes
[18:42] <txwikinger> 0 means no error
[18:43] <nixternal> ooh, I get a new laptop on monday :)
[18:46] <nixternal> oh my, I can't believe I just did what I did
[18:46] <Riddell> did you burn the new laptop?
[18:46] <nixternal> hehe, not yet :)
[18:47] <nixternal> I had created a plasmoid for adept notifier
[18:47] <nixternal> and....well I did rm -rf on the directory I thought was the old one
[18:47] <nixternal> it wasn't
[18:47] <Riddell> erk
[18:47] <yuriy> er..wow, ouch
[18:47] <Riddell> is why bzr push is recommended
[18:47] <nixternal> shouldn't be to hard to get back working though
[18:47] <nixternal> Riddell: ya, I need to start doing that more often
[18:48] <nixternal> since you said that, let me fire off one now on my personal directory
[18:53] <Riddell> yuriy: grabbing kdesdk and kdetoys
[18:53] <yuriy> k, grabbing kdenetwork
[18:54] <jjesse> nixternal: do you start your job on monday?
[18:59] <nixternal> jjesse: yes
[18:59] <Riddell> nixternal: what's the job?
[19:01] <nixternal> Linux Packaging and Development Engineer as well as the future Open Source Community Manager
[19:02] <yuriy> ooh sounds good
[19:02]  * yuriy needs to find a company interested in that kind of stuff
[19:03] <nixternal> there are a few in Chicago, but most want you to work with Red Hat or CentOS
[19:03] <nixternal> right now, the applications will be built on an appliance based off of CentOS
[19:03]  * yuriy is working with Red Hat at school
[19:04] <nixternal> but I would like to go with a deb repo or a conary setup there
[19:04] <nixternal> I haven't worked with Red Hat in a while, but it can't be that difficult
[19:04] <yuriy> except the answer to "what should I be working on?" is "I don't know, it's friday" so i'm working on kubuntu packages instead
[19:04] <nixternal> hehe
[19:10] <Riddell> nixternal: sounds like just your sort of thing
[19:10] <nixternal> ya, getting paid for what I do here, can't beat that :)
[19:10] <Riddell> nixternal: do you get to tell us what you're packaging and community managing?
[19:11] <nixternal> yup
[19:11] <nixternal> it is all GPL
[19:11] <jjesse> no he signed a non-disclosure
[19:11] <nixternal> Riddell: cleversafe.com - they make a distributed storage solution
[19:11] <jjesse> you can be a part of a community, but you have to sign this no disclosure
[19:11] <nixternal> jjesse: haven't signed it yet, but there is one of course
[19:11] <nixternal> they do have some code that isn't GPL
[19:11] <jjesse> i've signed so many vof those for my work
[19:12] <Riddell> uh oh, he used the word "solution"
[19:12] <Riddell> he'll be wearing a tie next
[19:13] <Riddell> "PPA exceeded its size limit (1695.00 of 1024.00 MiB)" uh oh
[19:13] <nixternal> nevah, shorts, t-shirt, and flip flops :)
[19:13] <nixternal> Riddell: ya, I was gonna ask about cleaning out the ~kubuntu-members-kde4 ppa to be safe
[19:13] <Riddell> might be an idea
[19:13] <nixternal> I removed some outdated stuff, but there are some gutsy kde4 stuff in there
[19:14] <Riddell> well, ~kubuntu-members-kde4 I think I asked for lots of extra space on hat
[19:14] <nixternal> didn't know if they were safe to remove yet or not
[19:14] <nixternal> oh, groovy
[19:14] <stdin> afaik, the limits aren't enforced atm
[19:14] <nixternal> we can leave them in there for the time being and if we hit the size limit we can blow them away
[19:15] <yuriy> bug 234415 invalid?
[19:16] <jjesse> yuriy: you are invalid :)
[19:16] <stdin> I was going to mark that as invalid, but I'm not sure so left it
[19:17] <yuriy> Riddell: ^
[19:17] <yuriy> Riddell: also should I add the recommends in bug 146198 to kdenetwork?
[19:17] <stdin> seems like a bit too much work for a minor change imho
[19:18] <stdin> (234415)
[19:19] <Riddell> yuriy: close bug 234415, it's just what happens when we have 4.4 in backports
[19:19] <Riddell> yuriy: I wouldn't worry about that recommends
[19:22] <Riddell> yuriy: chap in #kubuntu-testers confirmed that they work, so moving to -backports
[19:23]  * yuriy flinches
[19:39] <jjesse> nixternal: under a tornado watch till 10pm eastern
[20:12] <nixternal> jjesse: same here, just until 6pm our time
[20:22] <Serega> lintian gives me no-architecture-field, but I have it :-\
[20:24] <apachelogger> Serega: plz paste the control file
[20:26] <Serega> apachelogger: http://paste.ubuntu.com/17663/
[20:29] <Serega> apachelogger: I guess you compare letter-by-letter the word "Architecture"
[20:29] <Serega> apachelogger: dude, I did it 10 times :)
[20:32] <apachelogger> nah
[20:32] <apachelogger> just lost connection ;-)
[20:32] <Serega> maybe lintian just hates me?)
[20:32] <apachelogger> maybe you broke  your lintian :P
[20:32] <Serega> :)
[20:32] <apachelogger> please paste the whole error
[20:33] <apachelogger> I've never heared that one
[20:34] <Serega> apachelogger: http://paste.ubuntu.com/17666/
[20:34] <apachelogger> well, scru it
[20:34] <apachelogger> the arch field is there
[20:35]  * Serega googles about "scru"
[20:36] <Serega> apachelogger: I guess it means "ignore"m right?
[20:36] <apachelogger> yes ;-)
[20:36] <Serega> apachelogger: thank you :)
[20:42] <yuriy> I am getting some files with dh_install --list-missing on kdewebdev
[20:42] <yuriy> but those files are already listed in kxsldbg-kde4.install, some twice
[20:48]  * a|wen notices some coincidence of build-tools going crazy today
[20:48] <yuriy> Riddell: ^
[20:56] <Serega> apachelogger: muhaha, dh_installman have fixed that quirk :))
[21:27] <Serega> Riddell: qsynth_0.3.2-0ubuntu1 is done
[21:29] <Serega> ah... I brb
[21:33] <stdin> it's good to know I still have the power to crash X
[21:46] <apachelogger> stdin: lol
[21:51] <Serega> apachelogger: Harald, maybe you want to look at my shinig-new qsynth_0.3.2-0ubuntu1?
[21:51]  * Serega tries to do not brag
[21:51]  * Serega fail
[21:52]  * apachelogger is too demotivated to revu :S
[21:52] <apachelogger> stdin could do that
[21:53] <Serega> stdin: pleease
[21:53] <stdin> got a link?
[21:53] <Serega> apachelogger: I'll give you a cookie!
[21:54] <apachelogger> stdin gets a cookie from you for checking and I get a cookie from stdin for uploading ;-)
[21:54] <Serega> stdin: I should give you 3 files, right?
[21:54] <Serega> dsc tar.gz and diff.gz
[21:54] <stdin> yep
[21:55]  * stdin wonders if he can crash the internet next
[21:55] <Serega> I have no outer ftp unfortunately, what is the common method of file transfer in such cases?
[21:56]  * Serega wants to present stdin a DVD with Windows Vista
[21:56] <stdin> I guess you could use one of those file upload sites, or email (I don't know if dcc will work)
[21:57] <stdin> or any other imaginative way you can think of
[21:57] <Serega> stdin: email sounds good. where to send?
[21:57] <Serega> I can't find your
[21:58] <apachelogger> revu is also an option
[21:58] <stdin> revu is always a good option, if you can
[21:58] <stdin> or<EMAIL_ADDRESS>if not and I'll slap it on my server
[22:09] <Serega> stdin: sent
[22:14] <stdin> you're missing the XSBC-Original-Maintainer field
[22:15] <stdin> do you have the copyright on the project?
[22:16] <Serega> stdin: I thought it is the copyright of the package
[22:17] <stdin> no, that goes at the bottom
[22:17] <Serega> stdin: I have removed that field, as this package was created from scratch for ubuntu by me
[22:18] <Serega> stdin: I have added that copyright to calm down lintian thoug
[22:18] <Serega> *though
[22:18] <stdin> Serega: why does the debian/changelog have other entries if you created it from scratch?
[22:19] <Serega> stdin: is it better to delete it?
[22:19] <Serega> I am confused here
[22:19] <Serega> it is a... some history of a package in ubuntu
[22:20] <Serega> stdin: please, advice me how to do
[22:20] <stdin> well, if you took the debian package and remade it for ubuntu you should have the XSBC-Original-Maintainer field, if it's your package then the changelog should only have one entry
[22:20] <Serega> stdin: it's completely mine
[22:20]  * Serega is deleting the rest of changelog
[22:20] <stdin> then I'd say a new changelog to stop confusion is best
[22:21] <Serega> stdin: where is the difference?
[22:22] <stdin> a changelog documents changes from an original, it's a completely new package so it is the original
[22:24] <Serega> stdin: okay. so I have 1 entry and "s/New upstream release/Initial release". good?
[22:24] <stdin> Serega: change debian/watch to "http://heanet.dl.sourceforge.net/sourceforge/qsynth/qsynth-(.*)\.tar\.gz debian  uupdate", uscan doesn't like it otherwise
[22:24] <stdin> yeah
[22:25] <stdin> do you have a "Needs Packaging" bug?
[22:26] <Serega> not yet, I have only 256kbs inet yet :)
[22:26] <stdin> I mean on launchpad
[22:26] <Serega> bah! Timeout on server...
[22:26] <stdin> oh, timeouts, fun
[22:26] <Serega> stdin: no I don't
[22:27] <Serega> actually I was merging this package]
[22:27] <Serega> But I have found it is seriously outdated and malformed
[22:28] <Serega> so, with a bless of Riddell I have created the new one :)
[22:29] <stdin> doesn't the Makefile understand DESTDIR?
[22:29] <stdin> and I'm guessing you wanted usr/share/man for the mandir, not usr/share/mani
[22:30] <Serega> oooh... the second is infodir
[22:30] <ryanakca> Serega: if you're updating the packaging and the app, I'd poke the Debian Maintainer...
[22:30] <Serega> but there is neither man nor info thoug
[22:30] <Serega> *though
[22:30] <Serega> so I delete both
[22:31] <Serega> ryanakca: it is an orphan
[22:31] <Serega> ww... damn, forgot the abbreviation
[22:31] <ryanakca> Serega: adopt it then :)
[22:32]  * Serega smiles and lovely says "Come on, baby, go to your daddy"
[22:32] <Serega> here I am
[22:32] <Serega> ryanakca: I like this idea :)
[22:33] <Serega> stdin: what to do with that Copyright? Just remove or copy from any sourcefile?
[22:35] <stdin> Serega: the copyright is ok, you just need to change the line "Copyright (C) 2008 by..." to whoever owns the copyright
[22:36] <yuriy> stdin: think you could help me with kdewebdev?
[22:36] <yuriy> I am getting some files with dh_install --list-missing on kdewebdev
[22:36] <yuriy> but those files are already listed in kxsldbg-kde4.install, some twice
[22:36] <stdin> Serega: ie: "Copyright (C) 2003-2007, rncbc aka Rui Nuno Capela" I guess
[22:37] <stdin> yuriy: do you know if the files are in the .deb though?
[22:37] <Serega> stdin: aha, found it
[22:37] <Serega> thanks
[22:38] <Serega> done
[22:38] <stdin> and have you changed the debian/watch file?
[22:38] <Serega> nope
[22:39] <Serega> even don't know what is it
[22:39] <stdin> should be "http://heanet.dl.sourceforge.net/sourceforge/qsynth/qsynth-(.*)\.tar\.gz debian uupdate"
[22:40] <stdin> it lets you scan the server to see if a new .tar.gz is available
[22:40] <Serega> ah, cool
[22:41] <Serega> stdin: you specified only 3 fields, is it ok? Or split Site/Directory?
[22:41] <stdin> as it as :)
[22:41] <stdin> I tested with uscan and it doesn't like it when split
[22:42] <Serega> heh :)
[22:42] <Serega> I have not tested that url for validity...
[22:43] <Serega> downloads.sourceforge.net !
[22:43] <santiago-ve> ryanakca, ping
[22:45] <Serega> nah... heanet.dl.sourceforge.net is right
[22:54] <yuriy> stdin: hmm none of the xsldpg files are in any of the generated debs
[22:55] <stdin> is the package in the control file?
[22:55] <yuriy> and there is no kxsldbg-kde4 deb
[22:55] <yuriy> no
[22:56] <stdin> that'd be the problem, you need to put kxsldbg-kde4 in the control file for it to be made I guess
[22:56] <yuriy> I don't see anything documenting why it's not being built
[22:57] <stdin> me either
[22:59] <a|wen> yuriy: do you have the package accessible anywhere?
[22:59] <yuriy> a|wen: i'm working off the debian/ that's currently in backports
[22:59] <yuriy> kdewebdev-kde4
[23:00] <yuriy> wondering if kxsldbg-kde4 not being built was intentional
[23:01] <a|wen> yuriy: looks like someone forgot it
[23:02] <yuriy> I could add it, but I don't know anything about it so don't know what to put for dependencies and such
[23:02] <a|wen> yuriy: if not i suppose you would clean up the build-dir for that package ... which it isn't
[23:03] <yuriy> although, can't just add new binaries like that can I
[23:04] <a|wen> yuriy: not in a backport i suppose
[23:04] <Serega> stdin: I have sent you a corrected diff.gz
[23:05] <yuriy> OK, i'll leave it as is for now, and will do another version if Riddell has a better suggestion
[23:07]  * a|wen hoped debian had kxsldbg in experimental ... but they didn't
[23:08] <a|wen> yuriy: sounds like a good idea asking Riddell
[23:08] <yuriy> heh there aren't actually any changes in this module anyway
[23:09]  * a|wen suspects that kxsldbg might have been introduced sometime between 4.0.0 and 4.0.4 and it just wasn't discovered
[23:10] <yuriy> a|wen: but there is a .install file for it..
[23:10] <stdin> Serega: you should change " $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr \ install" to just "$(MAKE) DESTDIR=$(CURDIR)/debian/$(package) install"
[23:10] <stdin> and add your copyright to the bottom of debian/copyright
[23:10] <a|wen> yuriy: you've got a point ... strange no matter what
[23:12] <stdin> Serega: like "This Debian package is (C) 2008 Sergey Rudchenko<EMAIL_ADDRESS>and is licensed under the GPL, see `/usr/share/common-licenses/GPL'."
[23:12] <stdin> (stolen from the kde4 packages)
[23:12] <yuriy> ok that leaves just kdesdk which Riddell said he's working on :)
[23:13] <yuriy> oh and kdebindings
[23:14] <Serega> stdin: done
[23:15] <Serega> stdin: something else? should I send you an update now?
[23:15] <stdin> Serega: I think that's it now, send me the new diff and I'll put it on a server for apachelogger
[23:16] <a|wen> yuriy: cool :) ... sounds like we're getting close ... we'll soon be able to actually run kubuntu intrpid as the very large transitions in kde packages start to slow down
[23:16] <Serega> stdin: thank you
[23:16] <stdin> no problem :)
[23:16] <yuriy> a|wen: this is 4.0.5 for backports, nothing to do with intrepid
[23:17] <Serega> stdin: sent
[23:18] <a|wen> yuriy: ahh ... thought you were also part of the big kde-move-to-/usr/bin
[23:18] <yuriy> nah, i'm doing easy stuff
[23:19] <yuriy> other than the 3 debdiffs in the last couple months, I haven't done any packaging before
[23:19] <a|wen> heh :) ... sounds like you're starting to get hooked
[23:20]  * a|wen notes that even his intrepid pbuilder root seems fragile to all the transitions ... good sign that an upgrade would be too early
[23:21] <stdin> Serega: you sure that's the new .diff?
[23:21] <stdin> md5sum is the same as the last, so I'd guess not ;)
[23:21] <Serega> stdin: arrr.... forgot to debuild :)
[23:23] <apachelogger> http://aplg.kollide.net/screencasts/kde-nightly.ogg
[23:24] <Serega> apachelogger: kool!
[23:25] <Serega> stdin: check again. sorry.
[23:26] <yuriy> hmm kde4's open with dialog needs a search feature
[23:26] <a|wen> apachelogger: nice!
[23:26] <yuriy> I keep expecting it since it's everywhere else in kde4
[23:26]  * yuriy clicks a couple extra things and watches the screencast
[23:27] <yuriy> is this really 514 hours long? :P
[23:27] <Serega> yuriy: not really :)
[23:27] <yuriy> dragon bug!
[23:28] <yuriy> (hmm I wonder if there is such a species)
[23:28] <apachelogger> probably
[23:28] <stdin> Serega: the line is a bit long, and you should remove the old reference to /usr/share/common-licenses/GPL-2, otherwise you're there
[23:28] <stdin> yuriy: dragonfly :)
[23:29] <yuriy> apachelogger: sweet!
[23:29]  * Serega doubts KDE4 on BSD already
[23:30] <DAskreeCH> Serega: based on?
[23:30] <Serega> :)
[23:30] <nixternal> Serega: bsd + kde4 == good to go!
[23:30] <Serega> hm... that's cool
[23:30]  * nixternal uses pcbsd + kde 4.trunk
[23:31] <Nightrose> woahhh apachelogger++
[23:32] <apachelogger> ah that is totally worth a ++
[23:32]  * apachelogger hacked startkde to more dynamic behaviour
[23:33] <Serega> stdin: sent again :)
[23:34] <Serega> ++apachelogger then!
[23:34] <apachelogger> if only we had a karma bot ;-)
[23:34] <Serega> many people dislike postfix :)
[23:42] <stdin> my server's down for upgrade right now, hope jussi doesn't mind :)
[23:42] <stdin> apachelogger: http://jussi01.com/stdin/upl/
[23:44] <apachelogger> hm
[23:44] <apachelogger> stdin, Serega: you killed a bunch of debian changelog entries
[23:44]  * Serega says "it's not me"
[23:45] <stdin> apachelogger: that was my idea because it;s no longer a merge
[23:45]  * Serega points to stdin :)
[23:45] <apachelogger> stdin: what happened to the debian package?
[23:45]  * stdin points to Serega for that one
[23:46] <Serega> apachelogger: very outdated orphan and very malformed (changes in .orig, etc)
[23:46] <apachelogger> hm
[23:47] <apachelogger> Serega: please at least mention the reasons for completely repackaging in the changelog
[23:47]  * stdin awaits judgement from the great apachelogger and offers lambs for the sacrifice
[23:47] <Serega> :)
[23:47] <apachelogger> and technically it should go through the revu package
[23:47] <apachelogger> as it is a new package
[23:48] <Serega> np, I just made it :)
[23:48] <Serega> my first, btw
[23:48] <stdin> apachelogger: well, we've "broken" those rules before on occasion ;)
[23:48] <apachelogger> I know, but it's not really urgent or important or anything ;-)
[23:49] <apachelogger> so I see no reason for breaking the rules right now :P
[23:49] <Serega> apachelogger: one thing: could you please edit changelog by yourself? I will commit suicide I if debuild and send diff.gz one more time
[23:49] <apachelogger> well
[23:49] <apachelogger> stdin: do you think we should break rules?
[23:49] <apachelogger> what if the revu coordinator finds out?
[23:50]  * apachelogger is all of a sudden scared
[23:50] <Serega> revu isn't so far, right?
[23:50] <stdin> apachelogger: if you can get a motu/core-dev to ack the package, it should be ok I suppose
[23:50] <apachelogger> ah wth
[23:50] <Serega> my package isn't a great exception :)
[23:50] <apachelogger> we are teaching here
[23:50] <apachelogger> Serega: https://wiki.ubuntu.com/MOTU/Packages/REVU
[23:50] <apachelogger> get it up on revu
[23:51] <stdin> making sure you have your gpg key set in launchpad
[23:51] <stdin> (then await the sync)
[23:53] <Serega> okay
[23:53] <Serega> stdin: yes, I have
[23:54] <apachelogger> Serega: watch file needs some love
[23:54] <apachelogger> man uscan
[23:54] <apachelogger> describes how to properly use it with sourceforge
[23:54] <apachelogger> and please remove the comments
[23:54] <Serega> apachelogger: ok, thanks
[23:55] <apachelogger> section="Apps/Sound"\ <--- in menu file is IIRC the old format, nowadays it's "Applications/Sound"
[23:55] <Serega> please suggest me a good text for changelog (explanation of rebuilt)
[23:56] <apachelogger> Repackaged because current package in Debian is ....
[23:56] <stdin> ... pants
[23:56] <Serega> em... so maybe remove "* Initial release" ?
[23:56] <apachelogger> yep
[23:56] <apachelogger>  QSynth is a fluidsynth GUI front-end application written in C++ around the Qt4
[23:56] <apachelogger>  toolkit using Qt Designer
[23:57] <apachelogger> the information that Qt Designer was used is quite .... unnecessary
[23:57] <yuriy> what and where is libsmokeqt2 and why does kdebindings depend on it?
[23:57] <Serega> apachelogger: directly from the homepage
[23:57] <apachelogger> that's in debian/control
[23:57] <apachelogger> yuriy: it is from kdebindings
[23:57] <apachelogger> it's some kind of scripting library thingy
[23:58] <yuriy> apachelogger: there is a libsmokeqt4-2 package from kdebindings
[23:58] <apachelogger> well
[23:58] <apachelogger> smokeqt2 is from kde3
[23:58] <yuriy> then the depends is a mistake?
[23:59] <apachelogger> Serega: yeah, I am just saying that a user probably wouldn't mind if the devs have created the GUI on paper with a pencile, then scanned it and ran it through an OCR application ;-)
[23:59] <Serega> =)
[23:59] <yuriy> apachelogger: ah, right, bug 215012
[23:59] <Serega> apachelogger: you told about sections, where is it?
[23:59] <apachelogger> Serega: debian/menu
[23:59] <yuriy> apachelogger: ok to change that to libsmokeqt4-2 you think?


[05:53] <nathwill> if i make a merge proposal to update an existing charm, does the merge proposal stand alone, or should i open a bug as well?
[06:03] <marcoceppi> nathwill: it will stand alone and should show up in the review-queue
[06:04] <nathwill> ok, cool. thanks marcoceppi
[06:04] <nathwill> of course right after doing so, i realize that i overlooked something o_O
[06:04] <marcoceppi> :D
[06:05] <nathwill> i got the db portion (users, etc) for owncloud setup so that units can share a backend, but... owncloud also needs to share files in this config, so now i need to add an nfs backend :P
[06:12] <marcoceppi> nathwill: can the charm just re-create those config files for each unit?
[06:13] <nathwill> marcoceppi, it's the user data like uploaded files, calendars etc that's problematic. i've already got the config-file re-creation taken care of
[06:13] <marcoceppi> nathwill: ah, yeah you'll want to implement the "shared-fs: mount" relation: interface
[06:14] <nathwill> k. i put it down as "storage: \n interface: mount", is shared-fs an established name?
[06:15] <marcoceppi> shared-fs is an established name
[06:15] <nathwill> k. i'll switch it up then :)
[06:15] <marcoceppi> all the shared filesystem charms should be using it
[06:15] <marcoceppi> sooner or later ;)
[06:17] <nathwill> makes sense.
[06:17] <nathwill> thanks for the heads-up
[07:53] <stayarrr> Hi all, I get an error while trying juju on ubuntu 12.04 lts
[07:53] <stayarrr> I installed everything for local dev
[07:53] <marcoceppi> stayarrr: what's the error?
[07:54] <stayarrr> and if I try to execute juju bootstrap
[07:54] <stayarrr> i get
[07:54] <stayarrr> internal error Network is already in use by interface virbr0
[07:55] <stayarrr> Do you know how I can reset virbr0 interface?
[07:56] <marcoceppi> stayarrr: could you run `groups` and paste the output?
[07:58] <stayarrr> marcoceppi: oliver adm cdrom sudo dip plugdev lpadmin sambashare
[07:59] <marcoceppi> stayarrr:  the problem is you're not in the libvirtd group, http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage covers the details how how to fix this (See "error: Failed to start network default"); however, you just need to run the following:
[07:59] <marcoceppi> sudo usermod -aG libvirtd oliver
[07:59] <marcoceppi> newgrp libvirtd
[07:59] <marcoceppi> then try to juju bootstrap
[08:00] <marcoceppi> newgrp will make it so you don't have to log out then back in again for the group modification to take place. Though it'll only affect the terminal window you run it in. Each new terminal window will need to execute that command until you restart or log out/back in again
[08:02] <stayarrr> ok, thx
[08:03] <stayarrr> as i know, the bootstrap exec should be finished or is it a daemon?
[08:04] <stayarrr> I ran juju bootstrap
[08:04] <marcoceppi> stayarrr: bootstrap command will finish almost instantly, however it does several things in the background that can take up 20 minutes to complete depending on your internet connection
[08:04] <stayarrr> output: 2012-05-27 10:04:02,477 INFO Bootstrapping environment 'local' (origin: distro type: local)...
[08:04] <stayarrr> 2012-05-27 10:04:02,478 INFO Checking for required packages...
[08:04] <stayarrr> 2012-05-27 10:04:03,525 INFO Starting networking...
[08:05] <stayarrr> okay...
[08:05] <stayarrr> thx so far
[08:05] <marcoceppi> It should say bootstrap finished
[08:05] <marcoceppi> if it doesn't then the bootstrap is hanging somewhere'
[08:06] <marcoceppi> stayarrr: http://paste.ubuntu.com/1009298/
[08:09] <stayarrr> hm... okay aborts without feedback after STARTINg Networking
[08:11] <marcoceppi> stayarrr: try running juju -v bootstrap
[08:11] <marcoceppi> for more verbose output
[08:16] <stayarrr> marcoceppi: no output so far, hanging on INFO Starting networking...
[08:16] <marcoceppi> interesting.
[08:17] <marcoceppi> Do you have any KVMs or Virtual Machines setup on your computer?
[08:18] <stayarrr> marcoceppi, this OS runs in a VM
[08:18] <stayarrr> if it helps
[08:18] <marcoceppi> Ah, that might be the issue. What type of virtualization?
[08:21] <stayarrr> a standard hardware virt.?
[08:22] <stayarrr> I run ubuntu in vmware installed via an iso its completely virtualized os with  virt. hardware config
[08:23] <stayarrr> network is NAT
[09:21] <stayarrr> marcoceppi: Okay, I tried several (maybe all) vm ware configs, seems not working. I found this bug-report: https://bugs.launchpad.net/juju/+bug/920454
[09:21] <_mup_> Bug #920454: juju bootstrap hangs for local environment under precise on vmware <local> <juju:New> < https://launchpad.net/bugs/920454 >
[10:58] <anos> i have a question about load average?
[15:04] <SpamapS> stayarrr: I went ahead and marked that bug Confirmed/High. the local provider uses libvirt's networking, and I would suspect this is not working well with the vmware guest additions.
[16:30] <hazmat> stayarrr, could you pastebin ifconfig on the virt machine?