[06:31] <nigelb> tumbleweed: still stuck, yes. Let me get the debdiff. I got past one problem and hit another.
[08:05] <dholbach> good morning
[11:24] <X3lectric> is there anyone who is a expert with debian packaging? I require some help with some packaging that should work on ppa and fails to build yet teh only differnce is the version of the packges being built
[11:24] <X3lectric> https://launchpad.net/~x3lectric/+archive/nvidia-vdpau
[11:25] <X3lectric> the nvidia drivers fail to build yet the packaging is identical to https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:26] <X3lectric> tried variatons of the packging and erros make 0 sense + im not that savvy
[11:26]  * X3lectric n00b
[11:30] <tumbleweed> X3lectric: what are you trying to do? backport drivers?
[11:32] <X3lectric> er no
[11:32] <X3lectric> not backport
[11:33] <X3lectric> its actual debian packages for those distros
[11:33] <X3lectric> https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:33] <X3lectric> see the drivers there were built ok on this ppa https://launchpad.net/~x3lectric/+archive/nvidia-vdpau
[11:33] <tumbleweed> X3lectric: backport means build for an older release
[11:34] <X3lectric> I know
[11:34] <X3lectric> backpost mean using the current debian packaging which is not the case
[11:34] <X3lectric> backport
[11:34] <tumbleweed> the version that's failing to build on lucid and karmic (which is out of support, btw) is the version currently shipping in oneriric
[11:35] <X3lectric> yea but look at the 270 version bilt ok back then
[11:35] <tumbleweed> I'm not suprised it's not building on lucid or karmic, they look like complicated packages and could easily depend on things only available in newer relaeses
[11:35] <X3lectric> now it wont even build those
[11:35] <X3lectric> not a dependency issue
[11:36] <tumbleweed> well, not a stated dependency
[11:36] <X3lectric> ok lemme explain
[11:36] <X3lectric> https://launchpad.net/~team-iquik/+archive/nvidia-vpau/+packages
[11:36] <X3lectric> the packages there for drivers
[11:37] <X3lectric> they built ok
[11:37] <X3lectric> now if I upload ppa7 to superceed the same packages and rebuild with no changes except that it fails
[11:37] <tumbleweed> err no, I see a different version in that PPA
[11:38] <X3lectric> Show details nvidia-graphics-drivers - 270.41.19-0ubuntu1~lucid1~ppa4 	(changes file) 	x3lectric 	2011-05-23 	Published 	Lucid 	Misc 	All builds were built successfully.
[11:38] <tumbleweed> yes. 270.41.19. Your failing build is 275.09.07. Not identical
[11:39] <X3lectric> I tried to uplaod same packages because the 275 were failing and now the 270 also fail
[11:39] <tumbleweed> you can't upload an older version. Version numbers can only go up
[11:39] <X3lectric> yes
[11:40] <X3lectric> i tried it on a differnt ppa
[11:40] <micahg> tumbleweed: well, if the binaries were never published you can (even if they were you still can)
[11:41] <X3lectric> problem is the 270 can no longer be built evn if they suceeded a few weeks ago
[11:41] <X3lectric> they fail with same error as the 275
[11:42] <tumbleweed> micahg: sure
[11:42] <tumbleweed> X3lectric: the exact same source package that built before? Is it not because of something else in the ppa that was updated?
[11:42] <tumbleweed> anyway, let's look at one issue at a time
[11:43] <X3lectric> I didnt do the packaging for lucid or karmic Im reusing previous packaging by other people only modifying the drivers versions on the stated files
[11:43] <X3lectric> ok
[11:43] <X3lectric> pls
[11:44] <X3lectric> if you can help and guide me
[11:51] <X3lectric> tumbleweed: I used dget -xu https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+files/nvidia-graphics-drivers_270.29-0ubuntu1%7Elucid%7Exup2.dsc
[11:52] <X3lectric> that I modifies for the 270.41.19
[11:53] <X3lectric> so every file that mentioned the 270.29 I updated it to match the newer version
[11:54] <X3lectric> took 6 tries to build on ppa
[11:54]  * tumbleweed is having a quick look, but these packages are big and gnarly. I'd suggest getting more familiar with debian packaging, with simpler packages.
[11:54] <X3lectric> right
[11:55] <X3lectric> since no one guided me at all untill now
[11:55] <tumbleweed> basically, as you can see from the build log, the error is in debian/nvidia_supported
[11:55] <X3lectric> and i dont have problems with smaller packages
[11:56] <X3lectric> ok
[11:56] <X3lectric> so something in nvidia supported wasnt correctly updated?
[11:56] <X3lectric> i dont understand the error
[11:57] <tumbleweed> read the source, and you can see where it came from
[11:59] <tumbleweed> however, in this case I'm guessing the problem is that rules.lucid isn't included any more (and thus presumably the logic that would make it use rules.lucid, so maybe you need to see what that was doing differently
[11:59] <tumbleweed> or you could talk to the guy who maintains it, but I doubt he's that interested in backports to karmic :P
[11:59] <X3lectric> correct me if im worng
[12:00] <X3lectric> but the debian packages as long as their origin is the distro they inteded for they should build any version of drivers or packages as long as the changes point to new versions where applicable
[12:01] <tumbleweed> theoretically yes, assuming the maintainer cares enough to specify all the correct versioned dependancies and all the necessary quirks for older releases
[12:02] <tumbleweed> practically, *well* maintained packages tend to be backportable to supported releases, but may require other backports too, and complicated packages are very likely to require modifications
[12:02] <X3lectric> even if the origin of the packages are based on official releases
[12:02] <tumbleweed> yes
[12:02] <X3lectric> those since are official should already be sorted that way
[12:03] <tumbleweed> no
[12:03] <X3lectric> what you mean no
[12:03] <tumbleweed> just because a package is in an officaial release doesn't mean it can be backported with no changes. There is no such requirement.
[12:03] <X3lectric> but im not backporting
[12:05] <X3lectric> what tells the ppa to build the official version should work and already account for all dependencies
[12:05] <X3lectric> heck the fact that what use to build ok now doesnt tells me the error is somewhere else
[12:06] <X3lectric> but since im not any sort of expert its illogical and i dont have skills to correct what not only doesnt make sense why it fails but its beyond my skills
[12:09] <X3lectric> for e,g thers a erro it says Failed to find the list.... what list?
[12:09] <tumbleweed> read the script that outputs the error. I don't know what list either, it looks like a symbol list, but I'm not about to invest an hour or two in understanding this package
[12:09] <Laney> the source will tell you
[12:10] <X3lectric> if [ "$ret" -eq 0 ]; then
[12:10] <X3lectric>     printf '%s\n' '# List generated by nvidia_supported. Do not edit manually.'
[12:10] <X3lectric>     while read id; do
[12:10] <X3lectric>       printf 'alias pci:v%08Xd%08Xsv*sd*bc03sc*i* %s %s\n' \
[12:10] <X3lectric>         0x10de "0x$id" "$modname" "$pkgname"
[12:12] <X3lectric> ive extracted the driver packages and the output except for the driver verdion is same
[12:12] <X3lectric> heck all files are same
[12:12] <X3lectric> except for in this case driver version numbers
[12:14] <tumbleweed> but what's inside them is different, and this script looks inside them to generate the modaliases
[12:15] <X3lectric> I actually dont need the modaliases since im not using gdm
[12:16] <X3lectric> thers a note on the drivers
[12:16] <X3lectric> # This is a nasty kluge, but it seems to work. Better check the output when
[12:16] <X3lectric> # upgrading to a new release of the nvidia driver, though.
[12:17] <X3lectric> thast on the nvidia_current
[12:17] <tumbleweed> yes, I read that file
[12:18] <X3lectric> i mean nvidia_supported
[12:18] <tumbleweed> if you don't need it, don't call it from debian/rules
[13:33] <X3lectric> ill try and see
[14:07] <c_korn> how can I prevent that quilt edit opens a new instance of gedit? in 10.10 just a new tab was opened
[15:00] <c_korn> how can I prevent that quilt edit opens a new instance of gedit? in 10.10 just a new tab was opened
[15:03] <tumbleweed> c_korn: export a sensible value for $EDITOR ?
[15:04] <c_korn> actually I have an alias for quilt: alias quilt="EDITOR=gedit quilt"
[15:05] <Ampelbein> c_korn: add --new-document to $EDITOR
[15:12] <c_korn> Ampelbein: this has strange effects. if I open a new gedit instance and type something without saving, quilt edit now opens the to be edited file in the same instance as a tab but also creates a new empty tab. if I open a text file in gedit and then quilt edit then the to be edited file is opened in a complete new instance and also a new empty tab is created.
[15:14] <Ampelbein> c_korn: that sounds indeed strange. can you test what happens if you manually open some files with gedit fromt he command line?
[15:16] <c_korn> gedit <file 1> creates the first instance of gedit and opens the file (the gedit process runs in the terminal so I cannot run another command there). I open another terminal and run gedit <file 2>. the file is opened in the same gedit instance as a tab and the gedit process ends there in the terminal so I can type another command
[15:19] <c_korn> Ampelbein: ^
[15:21] <Ampelbein> c_korn: that sounds about right (you can prepend '&' to the command line to continue work in one terminal)
[15:22] <tumbleweed> although quilt will need to have a way of knowing that you've finished editing (normally when the command returns, it's done. I'm a vim user, so I don't know how you are supposed to do that)
[15:23] <c_korn> why does quilt have to know about finished editing? It should just pick the state when I do quilt refresh. If I was still editing there, then it is my fault.
[15:23] <tumbleweed> oh, fair enough
[15:24] <c_korn> quilt edit for me is just a shortcut for me for quilt add and manually opening the file
[15:24] <tumbleweed> yes
[15:24]  * tumbleweed is sufferincg from lack of sleep, which is probably why I'm lurking on IRC
[15:25] <c_korn> heh ;)
[15:25] <Ampelbein> c_korn: after some testing it seems to be a gedit problem. If I do 'gedit doc1 &' and (in the same terminal) do 'gedit --new-document doc2' I get a new empty tab
[15:30] <ScottK> tumbleweed: Sounds like the perfect time for a complex merge.
[15:30] <tumbleweed> heh
[15:43] <c_korn> Ampelbein: what is --new-document supposed to do now? is the new empty tab intentional when opening a file with --new-document?
[15:45] <Ampelbein> c_korn: hmm, maybe I read the man page wrong and it just means to open a new document in a new tab.
[15:45] <Ampelbein> c_korn: I thought it was an option to open the file in a new tab instead of new window.
[15:46] <Ampelbein> c_korn: but testing it further it seems that 'gedit doc1 & gedit doc2' does the right thing and only opens one instance of gedit.
[15:48] <c_korn> Ampelbein: which would mean the problem is in quilt?
[15:50] <Ampelbein> c_korn: fwiw, I can't reproduce the issue in oneiric.
[15:51] <c_korn> hm, ok. which means it is already fixed.
[15:51] <c_korn> now we need to backport the patch
[15:52] <Ampelbein> c_korn: quilt hasn't changed in over a year
[15:53] <c_korn> hm, so it has to be gedit which changed
[18:19] <c_korn> does someone know about a policy for packaging gem applications?
[18:20] <paultag> c_korn: they just changed policy, I got a mail about it
[18:21] <paultag> c_korn: let me see if I can dig it up, I got it a bit ago
[18:21] <paultag> c_korn: http://pastebin.com/2d1Wa1KS
[18:22] <paultag> c_korn: http://wiki.debian.org/Teams/Ruby/RubyInWheezy#Changes_to_rubygems_packaging ← that might be what you're looking for
[18:26] <c_korn> paultag: awesome, thank you very much!
[18:26] <paultag> c_korn: rock on, man
[18:54] <pcpratts> hi.  is there a way to dynamically build a menu for a debconf template?
[18:54] <pcpratts> I tried to modify the appropriate templates file in /var/lib/dpkg/info
[18:55] <pcpratts> is there a tool I need to run to re-sync the modified template?
[19:04] <pcpratts> okay I got it
[19:04] <pcpratts> sorry for bothering


[18:30] <kees> jdstrand, mdeslaur: ok, starting...
[18:30] <mdeslaur> go
[18:30] <kees> I'm at LinuxCon/ Plumber's Conf this week.  will publish the now tested neon
[18:32] <kees> looking at valgrind, finished gdb and will be watching for regressions
[18:32] <jdstrand> kees: is that the valgrind bug I never got back to?
[18:32] <kees> will likely take the glibc issue once upstream has fixed it
[18:33] <kees> jdstrand: yeah, but it looks like an FFe will fix it
[18:33] <kees> i.e. 3.5.0-1 fixes it
[18:33] <jdstrand> that will be much easier
[18:34] <kees> I've started doing karmic installs and running qa tests
[18:34] <kees> we should probably get a bit more organized about our release testing :P
[18:34] <kees> that's it for me
[18:35] <jdstrand> shall I go?
[18:35] <kees> sure
[18:35] <jdstrand> the two main things I am working on is libvirt/apparmor and the openoffice.org update
[18:35] <kees> (oh, i'm also working on apparmor with keybuk this week)
[18:36] <jdstrand> the former is for upstreaming and syncing that work with karmic, which will fix a couple of important bugs
[18:36] <kees> jdstrand: be sure not to forget the nogst build option for OOo
[18:36] <jdstrand> the latter is just time consuming
[18:36] <kees> yeah
[18:36] <sbeattie> kees: we should synchronize testing; I did a smidgen of qa-r-t testing for alpha 6
[18:37] <jdstrand> we should
[18:37] <jdstrand> (that's it from me)
[18:37] <kees> sbeattie: oh good, yeah, some kind of sign-up process
[18:37] <mdeslaur> my trn
[18:38] <mdeslaur> I was looking at the webkit issues this morning. I plan to only fix the medium severity issues (ie: code execution).
[18:38] <mdeslaur> I've got them all except one
[18:38] <jdstrand> awesome :)
[18:38] <mdeslaur> CVE-2009-1701 patch is non-obvious and code has substantially changed
[18:39] <mdeslaur> I won't be able to fix that one
[18:39] <kees> hat's fine
[18:41] <mdeslaur> And this week I'm on triage
[18:41] <jdstrand> oh, I'm on community
[18:42] <kees> cool. meeting over?
[18:43] <mdeslaur> that's it for me
[18:43] <jdstrand> sure


[01:17] <qman__> so, my server's still broken, and it looks pretty unsalvageable, so I was going to reinstall
[01:18] <qman__> my current plan is to back up the drive and get a dpkg-get-selections, and use it to restore /etc and the installed packages
[01:18] <qman__> anyone with experience have other suggestions?
[01:19] <qman__> obviously I wouldn't just blanket restore /etc, I'd go app by app
[05:29] <Fuginator> Would anyone have a moment to help me with a new MAAS installation and Openstack config?  I've been using the guide here: https://help.ubuntu.com/community/UbuntuCloudInfrastructure but have run into an issue.
[07:19] <jamespage> Daviey, all thrift-y bits a pieces for floodlight now in the NEW queue
[07:19] <jamespage> Fuginator, what issue are you hitting?
[07:30]  * jamespage goes to fix openvswitch
[08:17] <confusius> hi, is there anyway I can see with do-release-upgrade why it wants to install new packages like openal, webkit, gtk2-engines, etc. I seriously don't need that cruft on my server
[08:29] <Daviey> jamespage: ok, will review shortly.. thanks :)
[13:47]  * n3rdo hi all
[15:03] <utlemming> FYI -- the Ubuntu Cloud Images are now being served by S3 for archive mirrors.
[16:20] <smoser> xnox, s3 mirrors giving snapshot.debian.org like behavior is a great idea.
[16:20] <smoser> utlemming, ^ it'd be great if you could at least sniff that. xnox if you had specific implementation thoughts, that'd be nice.
[16:22] <xnox> smoser: no implimentation details. But I have one more feature request: can you please do $ juju deploy S3mirrors on all three regions in the HPCloud
[16:22] <xnox> I have contacted them, they are 'escallating it'
[16:23] <smoser> xnox, i bleieve there is some work being done on that, but i'll poke a bit
[16:23] <xnox> but you can also contact jorge
[16:23] <xnox> smoser: well currently we have setup "unofficial" apt-mirror based mirrors in the first region
[16:24] <xnox> smoser: and those will probably go away after the free 3month period is over.
[16:24] <xnox> smoser: cause it's setup by one of the devs who got sponsored to use HPCloud for free for three monts
[16:25] <smoser> xnox, yeah, i saw that.
[16:25] <smoser> xnox, when it was free i was running a public squid proxy for the same thing
[16:27] <xnox> smoser: ideally we should partner with HPCloud people to have ~ official mirrors there same as in EC2
[16:27] <xnox> is your S3 stuff using juju-deploy? =)
[16:27] <xnox> cause I am sure there are plenty of clouds that need local mirrors ;-)
[16:28] <utlemming> xnox: nope, its not using JuJu
[16:28] <utlemming> xnox: its using Auto Scaling
[16:28] <xnox> utlemming: is it OpenStack friendly?
[16:29] <utlemming> xnox: the code is done with boto. I've seen some requests for me to use a more generic cloud api so that it would be OpenStack, et al, friendly, but no, its not
[16:29] <utlemming> xnox: programming around S3 is, er, finicky
[16:30] <utlemming> you have to assume that its A) going to fail, B) it going to fail even when it says it succeeded and C) its going to succeed even when it says it failed
[16:30] <xnox> =))))
[16:31] <utlemming> I have done some initial looking in switching the code over to libcloud, but I haven't had the time per se.
[16:31] <xnox> https://www.hpcloud.com/products seems to have CDN, object, block storage, et al
[16:32] <smoser> xnox, thinking about snapshots, i dont think we coould easily do this without magic (i believe) new feature from amazon
[16:32] <smoser> if we had a magical feature from amazon that allowed you to do something like:
[16:33] <smoser>  TIMESTAMP.bucketname.s3.amazonaws.com/ubuntu/
[16:33] <smoser> and give you the content as of that TIMESTAMP for the versioned bucket
[16:33] <smoser> (or put TIMESTAMP somewhere else in the url, but the dns portion is the only part that is clearly not part of the path to an object)
[16:33] <utlemming> xnox, smoser: the feature is there, just that APT wouldn't understand it. The request looks like http://.../ubunut/precise-main/Packages.gz?Version=4 or something like that
[16:34] <smoser> utlemming, right. but you'd have to collect the Version= for each given path
[16:34] <utlemming> (don't take that as the gospel truth, I have to look at it to be sure)
[16:34] <smoser> and that would have to be in Release
[16:34] <smoser> and Release would then have to be re-signed.
[16:35] <utlemming> which is why apt wouldn't understand it. But having a timestamp feature would be nice
[16:35] <smoser> so, not really possible. you need a way to magically move all of /ubuntu to /TIMESTAMP/ubuntu
[16:35] <smoser> or potentially, to specify TIMESTAMP in a header.
[16:35] <xnox> well - on snapshot.debian.net they generate static versioned release files, but access generic buckets with debs
[16:35] <wrapids> My server is suddenly not letting me log in via ssh. Just getting a permission denied error each time I attempt the pass, which is correct. Using my hosts ajax console I can login just fine with the credentials I'm providing.
[16:36] <xnox> but utlemming: can't we just teach apt to support magic URLs and cloud version mirrors?
[16:36] <xnox> =)
[16:36] <utlemming> sounds like xnox has volunteered :)
[16:36] <smoser> 2 ways to do this, i think
[16:37] <xnox> utlemming: sounds like utlemming volunteered to write the spec of what/how apt should do requests.... since /me has no clue about clouds
[16:37] <smoser> a.) ask amazon for some header that you can set, and have the version returned give the content as of that timestamp
[16:37] <xnox> and APIs to clouds
[16:37] <smoser>  then we'd have to make apt able to specify arbitrary headers (and you'd just specify 'Timestamp: ' in your apt config to get as of one timestamp... that seems a bit less than ideal)
[16:38] <smoser> b.) have a re-director service that tracks versions of metadata and allows /TIMESTAMP/ and does the translation.
[16:39] <smoser> utlemming, can you get the revision history of a bucket including timestamps of changes?
[16:40] <smoser> if you could, then we wouldn't need to require additional code form the populating code, but could just read what was there
[16:40] <utlemming> smoser: yes, if versioning is on. You can request the versioning information
[16:40] <utlemming> smoser: but that's not public
[16:40] <smoser> right.
[16:40] <smoser> but thats ok.
[16:41] <smoser> that service could have acl, but woudl mean your populating code didn't have to export that data.
[16:41] <utlemming> for you redirector service then, it would also have to feed the files to the client too
[16:41] <utlemming> unless it 302's all requests for anything not meta-data
[16:42] <smoser> 302 would be right.
[16:42] <smoser> as we'd never delete the data
[16:42] <smoser> rbasak,
[16:43] <smoser> the above is actually one benefit of the prposed "change the format of the release file to contain a hash in the path"
[16:44] <smoser> (versus the /by-hash scheme we're proposing at https://wiki.ubuntu.com/AptByHash)
[16:45] <smoser> the redirector service would'nt be that hard to do i dont think.
[16:46] <smoser> xnox, thanks for making us think about this.
[16:46] <rbasak> smoser, xnox: why not just use by-hash and keep multiple InRelease files around?
[16:46] <utlemming> smoser: so reading between the lines...you could have a by-hash and a by-date?
[16:46] <rbasak> Start off with a historical InRelease file and then hit the mirror exactly as usual with the by-hash scheme
[16:46] <smoser> rbasak, because keepign multiple in-release files around doesn't work.
[16:47] <smoser> because the path is in them
[16:47] <rbasak> Path to what?
[16:47] <smoser> ok. so http://us.archive.ubuntu.com/ubuntu/dists/precise/Release
[16:47] <smoser> says "get main/binary-amd64/Packages" based on the path to Release.
[16:47] <smoser> right?
[16:48] <rbasak> Yes, but with the by hash scheme "main/binary-amd64/Packages" is just a key, not a path. The path is taken from the hash.
[16:49] <smoser> wait. yeah, you're right.
[16:50] <smoser> then if you add '?version=4' to "main/binary-amd64/Packages" and traverse that for all the relevant hashes,t hey're still present
[16:50] <smoser> and you eseentially pin the date.
[16:50] <smoser> yeah.
[16:50] <smoser> that works too
[16:50] <rbasak> You never need to add ?version=4 to anything except InRelease
[16:50] <smoser> right.
[16:51] <smoser> so the redirector service would then only have to redirect that one file
[16:51] <rbasak> It'd be hard to do in client code, but I could write a http frontend that translated the entire S3 mirror dynamically to any date fairly easily
[16:51] <rbasak> Yes exactly
[16:51] <storrgie> is there a good article for how to connect an ubuntu server to an AP via wireless?
[16:51] <rbasak> Then we just need to keep old index files and old pool debs around
[16:52] <storrgie> I've got wired working fine but I wouldn't mind dropping the cable
[16:52] <rbasak> I want to do a PoC on this now
[16:52] <smoser>  storrgie /usr/share/doc/wireless-tools/README.Debian
[16:52] <rbasak> It's a relatively trivial addition to our existing scheme, and would have some immediately useful benefits to developers
[16:52] <utlemming> (and sys admins/engineers)
[16:53] <rbasak> The only real extra cost is a redirector service so one EC2 instance basically
[16:53] <genii-around> storrgie: Basically make a wpa-supplicant.conf   file and then wpa_supplicant -i eth# -c /wherever/conf-file-is &      and then maybe dhclient eth#
[16:53] <smoser> rbasak, right.
[16:54] <smoser> and it doesn't even need storage
[16:54] <rbasak> Yep
[16:54] <genii-around> ( substitute wlan0 or whatever accordingly )
[16:54] <rbasak> I wonder if apt supports following a 301 http redirect?
[16:54] <smoser> rbasak, i'm pretty sure it does.
[16:54] <utlemming> rbasak: I was wondering that myself
[16:54] <rbasak> smoser: for every index file and pool deb?
[16:55] <storrgie> genii-around, I'm not sure how to specify a wpa key then
[16:55] <storrgie> the document doesn't describe it
[16:55] <rbasak> Anyway we can implement a redirector without that, by actually serving every file from S3 through the instance. And support for that could always be added to apt
[16:55] <ivoks> stgraber: around?
[16:56] <smoser> rbasak, right. but that doesn't really scale
[16:56] <storrgie> https://gist.github.com/3061307
[16:56] <smoser> well, at least not as well as rediret
[16:56] <rbasak> Yes, but it could scale later by adding 301 support to apt if it isn't already there
[16:57] <rbasak> How much scale would a historical archive service need?
[16:57] <rbasak> I mean that we can implement now and scale later without having to change the architecture later
[16:58] <storrgie> https://gist.github.com/3061307#comments
[16:58] <utlemming> rbasak: one way to do this might be have "apt-historical" package
[16:58] <storrgie> not sure how to get the interface to work properly
[16:58] <storrgie> it doesn't appear to be connecting
[16:58] <genii-around> storrgie: The key is in the wpa_supplicant.conf ... man wpa_supplicant.conf   has the syntax for that file
[16:58] <utlemming> rbasak: have it local to the box in question which hits "http://localhost:1337" or something like that
[16:59] <utlemming> smoser: then we don't have to have a service per se
[16:59] <rbasak> utlemming: that's a good idea
[16:59] <rbasak> Then we wouldn't need an ec2 instance for it either
[16:59] <genii-around> storrgie: Apologies on lag, work required me for bit
[16:59] <utlemming> rbasak: then you don't have to use a 302, because it could just be passed through
[16:59] <storrgie> genii-around, not sure if I have wpa supplicant installed
[16:59] <rbasak> Actually that's not a good idea at all. It's a great idea ;)
[17:00] <utlemming> rbasak: the other advantage is that it means that someone could make it a service if they wanted to
[17:01] <rbasak> Yes
[17:01] <storrgie> genii-around, is it required to have wpa supplicant
[17:01] <rbasak> So do we have a plan then? :)
[17:01] <genii-around> storrgie: Yes
[17:01] <rbasak> Also, did anyone have any feedback for me on https://wiki.ubuntu.com/AptByHash?
[17:01] <genii-around> storrgie: The packagename is just wpasupplicant  if you do not already have it installed
[17:03] <storrgie> turns out it is installed
[17:03] <storrgie> genii-around, so wait, the doc you pointed me to didn't show me anything about wpasupplicant.... it just said to edit the /etc/networking/interfaces file
[17:03] <genii-around> storrgie: I did not point you to any documents.
[17:04] <stgraber> ivoks: yep
[17:04] <utlemming> rbasak: another thing you can do is to use the "Last-Modified" HTTP header (http://paste.ubuntu.com/1078335/) to determine the dates
[17:04] <utlemming> rbasak: which makes it really, really fast
[17:04] <storrgie> smoser, did, sorry
[17:04] <storrgie> genii-around, where do you suggest I place this wpa_supplicant.conf file? What is good nature?
[17:04] <ivoks> stgraber: you remember, bacin in 2011, you've added a workaround for open-iscsi in its init script
[17:05] <genii-around> storrgie: I said more-or less: make a wpa-supplicant.conf file and then wpa_supplicant -i eth# -c /wherever/conf-file-is & and then maybe dhclient eth#   and then: substitute wlan0 or so accordingly
[17:05] <ivoks> stgraber: idea was not to start open-iscsi if iscsi was started in initramfs
[17:05] <utlemming> rbasak: you hit the by-hashes and look at the last modified so that if someone as YYYYMMDD-HHmmsSS you can choose the by-hash that is applicable.
[17:05] <rbasak> utlemming: so I do an HTTP HEAD on each InRelease?version=x and note the Last-Modified dates, right? And I'll eventually get a 404 or something which means I have all the versions. Then cache those.
[17:05] <ivoks> stgraber: bug https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/850960
[17:05] <genii-around> storrgie: Someplace like /etc/my-wpa-supplicant.conf    maybe. Doesn't really matter so long as the command-line has the path to it
[17:05] <smoser> storrgie, i'm sorry, i shared all knowledge i have of this.
[17:05] <utlemming> rbasak: yup
[17:05] <smoser> :)
[17:06] <utlemming> rbasak, smoser: the other thing is that now that these mirrors are public and production, I need to wrok with IS to get versioning turned on
[17:06] <stgraber> ivoks: right, I believe this bug was fixed upstream/Debian so in theory the hack is no longer required, but someone should test before dropping it
[17:06] <stgraber> (haven't looked at the bug again but that's what I remember from the last time I read it)
[17:06] <ivoks> stgraber: right, but we don't have the fix in our open-iscsi
[17:06] <smoser> utlemming, well, even before IS was involved, you should have thought about it
[17:07] <rbasak> storrgie, genii-around: whoa. No need to create wpa_supplicant.conf. You can put all needed keys directly in /etc/network/interfaces.
[17:07] <ivoks> stgraber: i've tested the patch from upstream and it works
[17:07] <smoser> as not deleting, means massive increase in storage
[17:07] <stgraber> ivoks: yeah, it needs merging from Debian I believe...
[17:07] <ivoks> stgraber: or that...
[17:07] <genii-around> rbasak: Ah, nice. I've never used it in this way before.
[17:07] <utlemming> smoser: I delete now
[17:07] <smoser> and bill
[17:07] <smoser> even if everything else in s3 versioning was magic and perfect
[17:07] <utlemming> smoser: to save storage
[17:07] <rbasak> storrgie, genii-around: see /usr/share/doc/wpasupplicant/README.Debian.gz for examples
[17:07] <utlemming> smoser: the change here is that we need to _not_ delete and we need to enable vesioning.
[17:08] <stgraber> ivoks: I think we definitely want to merge from Debian, not sure how many other changes we have on that one though so don't know how painful it'll be
[17:08]  * genii-around bookmarks
[17:08] <smoser> utlemming, right
[17:08] <utlemming> smoser: which is a big, big change
[17:08] <smoser> which increases costs significantly
[17:08] <smoser> well, even if the versioning was magic
[17:08] <stgraber> at least it's good to know that the fix works and we can get rid of my ugly hack :)
[17:08] <ivoks> stgraber: i could take a look, in precise we are at 0ubuntu9
[17:08] <storrgie> rbasak, genii-around how do i reference this wpa_supplicant.conf file from my /etc/networking/interfaces ?
[17:08] <utlemming> smoser, rbasak: looks like the makings of blueprint for UDS-R
[17:09] <ivoks> stgraber: yeah, just wanted to let you know if it's still making problems for you somwhere :)
[17:09] <rbasak> utlemming: I'm very tempted to JFDI. Assuming by-hash is accepted, this feels relatively simple
[17:09] <stgraber> ivoks: right, we'd probably want to merge from Debian in quantal and if there are enough people asking for it and we know it's 100% safe, then drop my hack from oneiric and precise and replace it by a cherry-pick of the fix
[17:09] <genii-around> storrgie: For that you would probably need to read the documentation rbasak referred to. I have myself not used it in this way and so of limited help there.
[17:09] <ivoks> stgraber: yeah, fix is an onliner
[17:09] <utlemming> rbasak: except that I can't implement this on the S3 side that easily
[17:10] <stgraber> ivoks: I'm not actually using iscsi, I just happened to be the lucky one to get that bug escalated to intially :)
[17:10] <stgraber> ivoks: good, should be easy to cherry-pick then :)
[17:10] <rbasak> storrgie: you don't need a wpa_supplicant.conf. See the example in the docs. Just a few lines in /etc/network/interfaces is all you need.
[17:10] <utlemming> rbasak: the _best_ case is that I can throw up a parallel mirror that has versioning, but we're talking a cost of $600/month
[17:10] <rbasak> utlemming: oh yeah, there's the money :)
[17:10] <stgraber> ivoks: I'll try and have a look at it this afternoon once I'm done fighting with my automated ipv6 testing
[17:10] <utlemming> rbasak: ubuntu-server does not own the S3 mirrors as of ~20 hours ago
[17:10] <ivoks> stgraber: https://github.com/mikechristie/open-iscsi/commit/f0b670c016c85c882bb0583eaef8ea2f7147d4af :)
[17:11] <ivoks> pretty silly :)
[17:12] <rbasak> utlemming: I have a test quantal mirror right now :)
[17:12] <rbasak> (btw, any idea how much that's costing us? I can't see the size of the bucket)
[17:12] <utlemming> rbasak: ~$30-40USD/month
[17:13] <rbasak> utlemming: OK. And I have an instance running too.
[17:13] <rbasak> utlemming: it'll need to be syncing the mirror every 30 minutes, so not worth turning off
[17:13] <utlemming> rbasak: ~$250/month + 0.10/GB inbound
[17:14] <rbasak> I should kill the instance actually. It's only sitting idle right now, pending feedback.
[17:14]  * rbasak does so
[17:16] <utlemming> the reason I used AutoScaling is because it is cheaper...we don't have to pay bandwidth in to update the mirrors because the first 1GB is free.
[17:17] <rbasak> That's different for a long lived instance?
 I wonder if utlemming can see stats on the total of S3 PUTs in the S3 mirror?
 That should give us an approximate monthly storage growth figure, right?
[19:05] <Insyte> I'm getting kernel crashes in Lucid when running NFS + iscsi inside KVM.  Unfortunately, it crashes hard and fast enough that nothing is logged, even remotely.
[19:05] <Insyte> Lucid.
[19:05] <Insyte> They seem to happen every five days or so.
[19:05] <Insyte> Anyone seen anything similar?
[19:14] <roaksoax> Daviey: /win 13
[19:14] <roaksoax> err
[19:16] <stgraber> hallyn: just spent half an hour trying to figure out why my ipv6 testing scripts are failing quite badly: http://paste.ubuntu.com/1078528/
[19:20] <hallyn> stgraber: hm, yeah, hooks and api came through separate  branches
[19:21] <stgraber> hallyn: yeah but I rebased the API branch on quantal, so we now have the hooks in there but they somehow get stripped every time I save the config
[19:22] <hallyn> stgraber: yes, because i had to implement save_config - there was none.  so the lxc.hooks need to be implemented in save_config
[19:23] <stgraber> hallyn: ah, right, I guess I'll just skip using the hooks for now then
[19:24] <hallyn> stgraber: which bzr branch are you using atm?
[19:24] <hallyn> i'll whip up a merge proposal
[19:25] <stgraber> hallyn: lp:~ubuntu-lxc/ubuntu/quantal/lxc/lxc-api-and-python
[19:57] <hallyn> stgraber: feh, of all the files in that $(*&% patch, conf.h wasn't one.  gotta rebuild my patch :)
[20:11] <hallyn> stgraber: why did you remove the README in your last commit?
[20:11] <hallyn> it makes it fail to build
[20:12] <stgraber> hallyn: oops, I'll fix the FTBFS. The reason is that the directory is no longer empty as we have lxc-init in there
[20:13] <hallyn> stgraber: ok, lemme first check in my change for hooks.  it compiles, hopefully it runs right too :)
[20:14] <stgraber> hallyn: oops, saw your comment right after I pushed the fix for README, so you may need to uncommit/pull/commit, sorry
[20:34] <hallyn> stgraber: done - but your fix isn't enough.  the *makefile* wants there to be a README
[20:35] <stgraber> hallyn: ... ok, will fix the Makefile too then :)
[20:41] <mu3en> is it possible to ensure grubpc is installed instead of grubefi during server install?
[20:53] <hallyn> stgraber: thanks :)  at any rate save_config() is working
[20:53] <hallyn> for hooks that is
[20:54] <stgraber> hallyn: cool, and I just updated the branch to make it buildable again. I'll push to the PPA soonish
[21:01] <hallyn> refetching.  let's see if i can think up a good plan for get_config()
[21:02] <hallyn> probably makes the most sense then to re-implement save_config in terms of get_config
[21:02] <hallyn> stgraber: for c->get_config_item(c, "lxc.mount"), would you want just the value part, or the whole 'lxc.mount = value' string?
[21:03] <stgraber> just the value
[21:03] <hallyn> ok.  i think unfortunately in the c cal li'l lhave to make it
[21:03] <hallyn> int get_config_item(struct container, char *key, char *return)
[21:04] <stgraber> I can live with that
[21:04] <hallyn> returning the length, so you can do 'len = get_config_item(c, key, NULL); v = malloc(len+1); len = get_config_item(c, key, v)'
[21:07] <hallyn> still seriously ugly because of multiple-line things like lxc.mount.entry
[21:15] <hallyn> stgraber: do you need to be able to do 'get_config_item(c, "lxc.cgroup")' to get all cgroup items, or can we just support only specific cgroup items?
[21:15] <hallyn> like lxc.cgroup.devices.allow
[21:16] <stgraber> would be best to enforce an exact match of the key
[21:17] <stgraber> so lxc.cgroup.devices.allow would work but lxc.cgroup would return an error (no match)
[21:17] <stgraber> not sure what to return for these that can exist multiple times (network, devices.allow, ...)
[21:20] <hallyn> i can just return a string with newlines,
[21:20] <hallyn> or if you prefer I can return one line at a time with indication of wether there are more lines
[21:23] <stgraber> hallyn: newlines is best I think. Easier to handle for me at least
[21:24] <stgraber> hallyn: btw, how does that work in set_config_item? how would I got about defining multiple network interfaces using it?
[21:27] <hallyn> stgraber: IIRC just do same way (order) as in a config file
[21:27] <hallyn> does that not work?
[21:28] <hallyn> so, you can't change a setting for an already-defined nic, i uess
[21:28] <hallyn> i guess
[21:28] <stgraber> I can see that being a bit annoying for a few of my setups ;)
[21:29] <hallyn> would it suffice to have a clear_config(c, "network") and clear_config(c, "cap.drop") ?
[21:29] <stgraber> clear_config_item(key) wiping all occurences of a key would be good yeah
[21:29] <hallyn> anything more structured doesn't really fit with the set_config
[21:30] <stgraber> for scripting, I don't really care so much about the current values, I just want to see them gone and replaced ;)
[21:30] <hallyn> if you can think of a better way to do something like container->nic[1].name = "eth3" with the api, i'm all ears
[21:31] <hallyn> clear all network entries, or only #0 or #1 ?
[21:31] <hallyn> all nics i should say
[21:31] <stgraber> ideally I'd like to see the config format change to not allow duplicate keys unless they are just multiple values for a key
[21:31] <stgraber> and see network be moved to lxc.network.ethX.type/flags/link/hwaddr
[21:32] <stgraber> I'd expect clear_config_item(key) to be a generic function removing any occurence of "key" from the config, so in the case of .network, all nics
[21:32] <hallyn> ok.  will see what i can come up with
[21:42] <hallyn> stgraber: network multiple entries are of course a bit of a pain since subkeys might exist for only some of the nics
[21:48] <hallyn> stgraber: maybe the right answer will hit me over the weekend.  have a good weekend
[21:49] <stgraber> hallyn: well, with multiple calls to set_config_item (one per key and per interface) + get_config_item returning multiple lines and clean_config_item to wipe the entries, I should be able to make a wrapper in python that lets you change the network config in a scripter friendly way
[21:50] <stgraber> hallyn: have a good weekend!
[21:57] <hallyn> stgraber: ok, sounds good.


[04:45] <walltender> Dear upstart expert, will some one tell me what this means?
[04:52] <walltender> http://i.stack.imgur.com/rCLl1.jpg
[04:53] <walltender> People says I shall ask upstart devs.


[10:16] <Mikaela> Hi, would this be a place to ask someone to look into behaviour of Ubuntu member https://launchpad.net/~aaronfarias ? They have been more or less hostile on #limnoria for a couple of days, going enough to ban evade on both networks, and also opened https://github.com/ProgVal/Limnoria/pull/1466 (check edit history) and https://github.com/ProgVal/Limnoria/issues/1465 while they have
[10:16] <Mikaela> since removed that GitHub account (as it appears as ghost). There are also some emails I find strange from them as Farias Martinez on https://lists.ubuntu.com/archives/ubuntu-irc/2021-May/author.html
[18:01] <jose> Mikaela: Thanks for letting us know.
[18:02] <Mikaela> you're welcome, I understand Unit193 has also forarded it and possibly logs somewhere


[01:08] -ubottu:#ubuntu-news- ::omg!ubuntu:: 8BitDo’s Commodore 64 Mechanical Keyboard Even Has a Joystick @ https://www.omgubuntu.co.uk/2024/03/8bitdo-commodore-64-keyboard-is-geektastic
[01:49] -ubottu:#ubuntu-news- ::planet:: Simos Xenitellis: How to install and setup the Incus Web UI @ https://blog.simos.info/how-to-install-and-setup-the-incus-web-ui/
[01:49] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Deploying Open Language Models on Ubuntu @ https://ubuntu.com//blog/deploying-open-language-models-on-ubuntu
[01:56] <Bashing-om> UWN: Opening 833 shortly for the day's update.
[02:42] <Bashing-om> UWN: Update completed - saved and out - getting largish this issue.
[18:28] -ubottu:#ubuntu-news- ::ubuntuonair:: Documentation Office Hours 29th March 2024 @ https://www.youtube.com/watch?v=Xc-_Uu6asgA
[20:41] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: AI and automotive: navigating the roads of tomorrow @ https://ubuntu.com//blog/ai-and-automotive-navigating-the-roads-of-tomorrow
[21:17] <guiverc> bashing-om, https://lists.ubuntu.com/archives/ubuntu-devel/2024-March/042954.html may be worth including
[23:06] <Bashing-om> UWN: Opening 833 shortly for the day's update.
[23:16] <guiverc> Bashing-om, I wonder if https://lists.ubuntu.com/archives/ubuntu-devel/2024-March/042954.html is worth including...   i've seen a few end-users (using the alpha) impacted by it..
[23:33] <Bashing-om> guiverc: Yeah - worthy in my opinion - was inclided in yestday's update.
[23:33] <Bashing-om> UWN: update compleyed - saved and out.
[23:33] <guiverc> :)


[05:32] <tvoss> mgraesslin, ping
[05:33] <mgraesslin> tvoss: pong
[05:33] <tvoss> mgraesslin, good morning (under the assumption you are in Germany) :)
[05:33] <mgraesslin> yes :-) good morning
[05:33]  * tvoss loves the brain melting temperatures early in the morning right now
[05:34] <tvoss> mgraesslin, so I was looking through the kwin source code and wonder if you could help me in getting a few questions answered
[05:34] <mgraesslin> I can try
[05:35] <tvoss> mgraesslin, great :) here we go: So for integrating with an EGL/GL platform, OpenGLBackend is the class to implement? Do I understand that correctly?
[05:35] <mgraesslin> yes
[05:35] <mgraesslin> but that's just for the OpenGL compositor obviously
[05:36] <mgraesslin> the XRender one is currently getting adjusted
[05:37] <tvoss> mgraesslin, yup :) so one question (out of curiosity): is there a reason you do not use the q platform abstraction layer to "hide" those GL bits?
[05:37] <mgraesslin> when we started the OpenGL part, Qt's OpenGL was not up to where it is now
[05:38] <mgraesslin> maybe that changed with Qt 5 - I haven't looked into it enough
[05:38] <mgraesslin> but Qt 4 doesn't provide what we need
[05:39] <tvoss> mgraesslin, ah okay, that makes perfect sense then
[05:39] <tvoss> mgraesslin, so for interfacing with GL it's OpenGLBackend. I was wondering where you bridge over to the input subsystem. Or do you read directly off evdev?
[05:40] <mgraesslin> quite simple: that code is not there yet
[05:40] <mgraesslin> the egl_wayland_backend does some nasty hacks
[05:40] <mgraesslin> but in general the code still needs to be written
[05:41] <tvoss> mgraesslin, ah okay :) I would think the same holds true for app mgmt/focus/window placement strategies?
[05:42] <mgraesslin> no that all exists, just only for the X11 backend
[05:42] <tvoss> mgraesslin, ah, that is cool :) can you point me to the code?
[05:42] <tvoss> mgraesslin, that is, for the existing x11 backend
[05:42] <mgraesslin> well that's everything :-)
[05:43] <mgraesslin> tvoss: best explained in http://community.kde.org/KWin/Hacking
[05:43] <tvoss> mgraesslin, got it, thx
[05:44] <mgraesslin> tvoss: at the moment I highly recommend to not try to integrate KWin with Mir - it's a bad point in time
[05:44] <mgraesslin> we are about to switch to Qt 5 and KF 5
[05:44] <mgraesslin> so the code will break badly
[05:44] <mgraesslin> and the code will change
[05:44] <mgraesslin> we don't mind moving large code parts around
[05:45] <tvoss> mgraesslin, hmm, that would be great as we have a working qpa implementation for Mir. Do you have some ballpark estimate for the qt5 switch?
[05:46] <mgraesslin> when master opens up again - in a few weeks
[05:46] <mgraesslin> we plan to have a development preview release this year
[05:47] <mgraesslin> for Kubuntu the earliest release on Qt 5 can be 14.10, maybe 15.04
[05:47] <mgraesslin> 14.04 will come 4.11 just like 13.10
[05:48] <tvoss> mgraesslin, okay, thanks, that helps me. I might start playing around with the kwin code as is, though, totally being aware that I'm standing on shaky ground :)
[05:49] <tvoss> mgraesslin, would you be the right guy to talk to for XMir, too?
[05:49] <mgraesslin> tvoss: I have no interest in anything with Mir, it's a downstream problem from my point of view
[05:49] <mgraesslin> and it's a downstream I'm not running, so I cannot help anything there
[05:50] <tvoss> mgraesslin, okay, fair enough
[05:50] <mgraesslin> tvoss: in fact I don't think you will find any upstream developer who is able to help there - no KDE workspace core developer is to my knowledge using Kubuntu
[05:52] <tvoss> mgraesslin, okay, however, my questions were answered :) thanks for that
[05:52] <mgraesslin> you're welcome
[06:12] <soee> good morning
[07:56] <smartboyhw> Damn it, okular still is crapped.
[07:56] <smartboyhw> I REALLY HATE SYMBOLS...
[08:05] <smartboyhw> Re-uploaded...
[08:05] <shadeslayer> smartboyhw: make sure you supply pkgkde-symbolshelper with both the build logs
[08:05] <smartboyhw> shadeslayer, ?
[08:06] <shadeslayer> both = both i386 and amd64
[08:06] <shadeslayer> wait
[08:06] <shadeslayer> smartboyhw: how are you fixing the symbols file?
[08:06] <shadeslayer> by hand?
[08:06] <smartboyhw> shadeslayer, hand yeah.
[08:07] <shadeslayer> ...
[08:07] <smartboyhw> shadeslayer, that's why I'm stupid:P
[08:07] <smartboyhw> shadeslayer, btw how do you do it?
[08:07] <shadeslayer> pkgkde-symbolshelper
[08:07]  * smartboyhw didn't know that existed:P
[08:07] <shadeslayer> smartboyhw: please go through http://pkg-kde.alioth.debian.org/symbolfiles.html
[08:08] <smartboyhw> shadeslayer, hmm interesting.
[08:10] <smartboyhw> After okular, it would be kwallet.
[08:10] <smartboyhw> The damning .install file error;P
[08:14] <smartboyhw> On this pace, we can get 4.10.80 out when 4.10.81 releases:P
[08:14] <smartboyhw> (Kidding)
[08:15] <yofel> not really kidding. I think we've been doing that for the last 2 releases ^^
[08:17] <smartboyhw> yofel, yeah!:)
[08:20]  * shadeslayer is trying to do everything as fast as possible
[08:21] <smartboyhw> Currently existing problems are for korundum (code error), kwallet (I will fix it), rocs (cmake grantlee error), kajongg (weird build-dep error on python-twisted), kdegraphics-mobipocket (due to okular)
[08:21] <smartboyhw> kdegraphics-stringi-analyzers failed (code again)
[08:21] <smartboyhw> s/kdegraphics/kdenetwork/
[08:21] <kubotu> smartboyhw meant: "kdenetwork-stringi-analyzers failed (code again)"
[08:21] <yofel> well cmake rather
[08:21] <yofel> it's missing a check for boost
[08:22] <yofel> (and the package is missing the dep)
[08:22] <smartboyhw> kdewebdev (.install files problem)
[08:22] <shadeslayer> I think we can be done by this weekend
[08:22] <shadeslayer> hopefully
[08:22] <smartboyhw> klickety (again .install files problem)
[08:23] <smartboyhw> Fortunately I can join in this mess at the right time:)
[08:25] <Quintasan> yofel: kajongg is still fcksd on i386
[08:25] <Quintasan> Seems like kiten is ok now
[08:26] <yofel> someone else look into kajongg, that's some python issue in the archive
[08:26] <shadeslayer> ^^
[08:27]  * shadeslayer won't be available on the weekend
[08:27] <shadeslayer> erm
[08:27] <shadeslayer> s/on the weekend/in the evening/
[08:27] <kubotu> shadeslayer: You did something wrong... Try s/you/me/ or tell me "help sed"
[08:27] <smartboyhw> help, I now have the exact error as the ORIGINAL okular i386 plasma-active-dev issue (what? the build in ninja is ok while here not)
[08:27] <shadeslayer> pastebin them build logs
[08:28] <smartboyhw> shadeslayer, erm it is just this...
[08:28] <yofel> your chroot does have saucy-proposed enabled?
[08:28] <smartboyhw> yofel, erm no.
[08:28] <yofel> you'll need that ;)
[08:28] <smartboyhw> 1. that's my actual computer:p
[08:28] <smartboyhw> yofel, meh.
[08:29] <yofel> that's why we have chroots...
[08:29] <yofel> if you don't want to use pbuilder a simple debootstrap chroot works too
[08:29] <yofel> or a VM, but that's overkill
[08:29] <shadeslayer> ^^
[08:29] <shadeslayer> lxc
[08:29] <shadeslayer> ftw
[08:29] <yofel> true ^^
[08:30] <smartboyhw> Heh
[08:35] <shadeslayer> huh odd
[08:35] <shadeslayer> there is a applets/kdeobservatory/src/
[08:35] <shadeslayer> however
[08:35] <shadeslayer> there is no kdeobservatory widget that's built
[08:51] <shadeslayer> oh
[08:51] <shadeslayer> hmm
[08:51] <shadeslayer> Qwt5-Qt4_FOUND
[09:02] <smartboyhw> shadeslayer, I'm supposed to include http://paste.kde.org/777638/ in symbols too?
[09:04] <shadeslayer> that kind of looks odd but yes
[09:04] <shadeslayer> just use pkgkde-symbolshelper
[09:09] <smartboyhw> Hmm, it really takes a long time to set up pbuilder i386...
[09:12] <smartboyhw> Maybe I should upload this thing first into Ninjas and see how symbols fail in i386....
[09:13] <smartboyhw> Uploaded ~ppa5.
[09:13] <smartboyhw> Hopefully I don't need a ~ppa10.
[09:18] <yofel> that's what I usually do ^^
[09:19] <smartboyhw> yofel, yeah. I hope not this time.....
[09:19] <yofel> and ppa10 is fine, with the build priority ninjas has you'll still be done today
[09:19] <smartboyhw> yofel, yeah, that's the important point:P
[09:19] <smartboyhw> Thank you private PPAs:P
[09:24] <apachelogger> "To get the mighty Kubuntu pbuilder-hooks (written by mighty Harald Sitter aka apachelogger), run:"
[09:24] <apachelogger> lol
[09:25] <smartboyhw> apachelogger, :O
[09:25]  * smartboyhw feels terror terror terror terror terror
[09:28] <smartboyhw> yofel, shadeslayer dh_sameversiondep: cannot continue because the reference package libokularcore2abi1 could not be found in debian/control or dpkg status
[09:28] <smartboyhw> The strange error
[09:28] <smartboyhw> Since the symbols have been solved now it seems.
[09:28] <yofel> look through the control file
[09:29] <yofel> there's some sameversiondep definition in a Depends: field somewhere
[09:29] <smartboyhw> yofel, ok.
[09:29] <smartboyhw> yofel, yeah got it.
[09:29]  * smartboyhw builds ~ppa6.
[09:33] <smartboyhw> Uploaded.
[09:33] <smartboyhw> Hope that this build finally works.
[09:38] <apachelogger> ErrorMessage: não pode copiar dados extráidos para './usr/lib/kde4/libexec/ksendbugmail' para '/usr/lib/kde4/libexec/ksendbugmail.dpkg-new': fim de ficheiro ou stream inesperado
[09:38] <apachelogger> if only I knew what it means
[09:39] <apachelogger> yofel: good to see you SRUd finally :P
[09:39] <yofel> I would guess it failed to write a file
[09:39] <apachelogger> yofel: /opt/project-neon5/share/pkg-project-neon5/0/default-settings.mk:3: *** missing target pattern.  Stop.
[09:39] <apachelogger> yofel: file stream got interrupted unexpected I suppose
[09:39] <smartboyhw> yofel, \o/
[09:39] <smartboyhw> We can get 4.10.4!
[09:40] <apachelogger> locale on terminal is le fufufufufufufufufu
[09:40] <yofel> apachelogger: why are you using default-settings directly? Either use project-neon5.mk, or write your own %: target
[09:40] <apachelogger> yofel: include /opt/project-neon5/share/pkg-project-neon5/0/project-neon5.mk
[09:40] <apachelogger> see lp:~neon/project-neon5/qtbase
[09:41] <yofel> brrrrr
[09:41] <yofel> looking
[09:41] <apachelogger> yofel: don't seem to find default-settings
[09:42] <apachelogger> ah, I  am just bad at copynpaste
[09:42] <Riddell> yay kde-workspace compiled
[09:42] <smartboyhw> Riddell, yep:
[09:42] <smartboyhw> :)
[09:43] <apachelogger> yofel: NEON_PROJECT_NAME: := project-neon5
[09:43] <yofel> apachelogger: hm?
[09:43] <apachelogger> excess :
[09:43] <yofel> eeeek
[09:44] <yofel> fixed
[09:44] <apachelogger> works without the colon it seems \o/
[09:45] <smartboyhw> :=)
[09:45] <smartboyhw> :P
[09:46] <Riddell> hi Oli
[09:46] <yofel> apachelogger: I triggered a build and need to be off for lunch, bbiab
[09:47] <apachelogger> xcb.cpp:46:27: fatal error: xcb/xcb_icccm.h: No such file or directory
[09:47] <apachelogger> :(
[09:48] <smartboyhw> !?
[09:48] <smartboyhw> :O
[09:49] <smartboyhw> Yes Okular BUILDS!!!!!!!!!!!!
[09:49]  * smartboyhw goes off cheering:P
[09:49] <smartboyhw> still publishing but at least it builds without issues.
[09:53] <apachelogger> !find randr.h
[10:02] <smartboyhw> Okular successfully uploaded.
[10:23] <smartboyhw> kwallet done, now kdepim-runtime.
[10:23] <Riddell> you're on a roll
[10:24] <shadeslayer> Riddell: maybe even send a email about analitza ABI breakage
[10:24] <shadeslayer> Riddell: commit 3c1f0b4ea784eeed754a68e611a1f6f3aa4f9cac fixes it
[10:25] <smartboyhw> Riddell, heh.
[10:26] <Riddell> shadeslayer: groovy
[10:32] <smartboyhw> Riddell, shadeslayer I saw kgoldrunner in the kubuntu-ninjas notes, but I can't see that package in our PPA. Did it disappear or just it wasn't built?
[10:33] <yofel> it wasn't uploaded
[10:33] <smartboyhw> yofel, for what reasons?
[10:33] <yofel> as that was the first batch, bzr-buildpackage-ppa failed
[10:33] <yofel> for whatever reason
[10:34] <yofel> (usually it's patches)
[10:34] <smartboyhw> Grrrrrrr :P
[10:49] <apachelogger> JontheEchidna: https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/1183615 you totally should close this bug because I forgot again when a file stream error occurs :P
[11:03] <smartboyhw> kdepim-runtime uploaded!
[11:16] <BluesKaj> Hey all
[11:16] <Riddell> smartboyhw: awooga!
[11:17] <smartboyhw> Riddell, :P
[11:21] <smartboyhw> Riddell, any thoughts on http://paste.kde.org/777746/ ?
[11:27] <apachelogger> yofel: I can build source package \o/
[11:27] <yofel> \o/
[11:28] <smartboyhw> \o/
[11:28] <smartboyhw> yofel, apachelogger thoughts on http://paste.kde.org/777746/ ?
[11:29] <yofel> not sure, but smokegen is broken too, fix that first
[11:29] <yofel> considering there's _SMOKE stuff missing that might be the reason
[11:30] <apachelogger> yeah, fixing smoke before fixing stuff that uses smoke is a good idea generally :P
[11:30] <yofel> ah hm, smokegen is only that stupid lib symlink
[11:31] <apachelogger> gawd
[11:31] <apachelogger> kmix is so broken it's just not funny anymore
[11:32] <yofel> oh fun, kdenetwork-strigi-analyzers has 0 copyright files
[11:32] <apachelogger> of course
[11:32] <yofel> why am I not surprised...
[11:32] <apachelogger> they moved to git
[11:32] <BluesKaj> the whole audio setup is a mess ...a nice comprehensive audio suite would be nice
[11:33] <smartboyhw> Eh:P
[11:33] <apachelogger> and after some 7 modules having moved to git still no one remembers to copy the flipping copying files
[11:33] <apachelogger> BluesKaj: eh?
[11:33] <yofel> anyway, need to fix cmake first
[11:33] <smartboyhw> yofel, wait a minute: Didn't smokegen compiled successfully?
[11:34] <BluesKaj> apachelogger, kmix is just a small part of the problem
[11:34] <yofel> smartboyhw: yeah, it's just list-missing
[11:34]  * apachelogger gets a headache
[11:34] <apachelogger> BluesKaj: it is?
[11:34] <smartboyhw> yofel, ah.
[11:34] <yofel> try to retry what failed
[11:34] <yofel> or maybe you need to sequentially retry smoke too, if something was chained in the chain
[11:34] <apachelogger> yofel: someone should revise them qtbase build deps, I have a feeling half of those are not needed :O
[11:34] <yofel> *changed
[11:34] <BluesKaj> aw c'mon apachelogger , you know what I mean
[11:35] <apachelogger> BluesKaj: I really don't
[11:35] <yofel> apachelogger: does this look sensible? http://paste.kde.org/777758
[11:35] <smartboyhw> OK yofel I will fix smokegen.
[11:35] <yofel> smartboyhw: just add the dropped not-installed file back
[11:35] <smartboyhw> yofel, OK.
[11:35] <smartboyhw> Then?
[11:35] <apachelogger> yofel: no, see strigi above? :P
[11:35] <smartboyhw> Just that?
[11:36] <yofel> apachelogger: I copied that from kdepim...
[11:36] <BluesKaj> apachelogger, I'm oin no mood to rant about alsa's negelect , pulseaudio , pavucontrol , gstreamer etc tetc
[11:36] <apachelogger> then kdepim is silly too
[11:36] <smartboyhw> yofel, ?
[11:36] <apachelogger> yofel: that command will fail immediately if it is not found
[11:36] <apachelogger> yofel: macro_optional_find_package OTOH will only fail at the very end
[11:37] <yofel> ok, so macro_optional_find_package(Boost REQUIRED) ?
[11:37] <yofel> or how does that work?
[11:37] <apachelogger>  macro_log_feature(STRIGI_FOUND "Strigi" "Metadata extraction" "" FALSE "" "Needed to get metadata for .torrent files") <- you'll simply want a TRUE in the middle there, marking it as required
[11:37] <yofel> aaaah
[11:37] <yofel> ok, next try
[11:37] <apachelogger> BluesKaj: then don't? :P
[11:37] <BluesKaj> \I won't
[11:38] <apachelogger> from where I am standing there is a comprehensive audio suite which is phonon which is based on pulseaudio :P
[11:39] <BluesKaj> prefer to run without pulse , but if i want web audio then I need it , alsa used to do the job nicely until pulse got shoved down our throats
[11:40] <apachelogger> -rw-r--r--  1 root root  43M Jun 19 13:38 project-neon5-qtbase_0.0+git20130619-9~saucy0.tar.xz
[11:40] <apachelogger> ooomph
[11:40] <apachelogger> that could take a while
[11:40] <apachelogger> BluesKaj: it didn't
[11:40] <yofel> apachelogger: paste.kde.org/777764
[11:41] <apachelogger> the amarok forum actually has like 30000 cases of proof how alsa did not work
[11:41] <apachelogger> and the phonon bugzilla has about 10 ongoing reasons of why alsa still does not get the job done nicely
[11:41] <apachelogger> yofel: looking good
[11:41] <smartboyhw> yofel, can't understand: What not-installed file?
[11:41] <yofel> thanks
[11:42] <BluesKaj> odd, I didn't have any problems with alsa ,and of course I don't use amarok
[11:42] <smartboyhw> Ah found it now.
[11:43] <apachelogger> BluesKaj: yeah, that's neither objective nor solid evidence of anything, so I'd very much prefer if you didn't pull the multimedia stack down
[11:43] <apachelogger> as a matter of fact it looks the same on every platform that has been around for more than 5 years
[11:44] <apachelogger> on windows 7 you have some six supported means to play audio
[11:45] <BluesKaj> apachelogger, like I said earlier it would be nice iif there was an audio suite that just worked out of the box , a comprehensive integrated one
[11:45] <apachelogger> yofel: I am uploading to ppa:neon/kf5, we'll see what comes of it
[11:45] <apachelogger> though I doubt it will build
[11:45] <yofel> yay
[11:45] <apachelogger> or at least master did not build with gcc 4.8
[11:45] <yofel> it's there, that's progress :P
[11:45] <smartboyhw> yofel, so I just add back the not-installed and upload it again? .....
[11:45] <apachelogger> though I got told dev should
[11:45] <apachelogger> so
[11:45]  * smartboyhw does not understand what he should do now....
[11:45] <apachelogger> maybe we are lucky ^^
[11:46] <yofel> smartboyhw: yeah, that'll be enough
[11:46] <smartboyhw> yofel, don't tell me that can erase the red light on the page:O
[11:46] <yofel> smartboyhw: it's just red because list-missing isn't empty
[11:46] <apachelogger> BluesKaj: yeah, we have that.
[11:46] <smartboyhw> yofel, ah alright.
[11:46] <yofel> and not-installed will hide that file
[11:46] <apachelogger> if you choose to not use the solutions we provide then that's not the solutions' problem TBH
[11:48] <smartboyhw> Uploaded.
[11:48] <BluesKaj> apachelogger, it's difficult for new users to understand the audio setup , it's rather complicated to them and discouraging at times ..as it is for us trying to help
[11:55] <apachelogger> how so? you order devices by priority, there is nothing more one needs to do (or should need to anyway)
[11:57] <BluesKaj> what ?
[11:59] <BluesKaj> anyway , bbl
[12:00] <apachelogger> BluesKaj: http://wstaw.org/m/2013/06/19/plasma-desktopdI2287.png
[12:01] <apachelogger> https://launchpad.net/~neon/+archive/kf5/+build/4727447
[12:01] <yofel> meh, one time I try to fix something in git and the server craps out
[12:01] <apachelogger> oh, yeah git servers are migrating right now
[12:01] <yofel> yeah, I just read the horror story in -sysadmin ^^
[12:02] <yofel> oh wow, qtbase compiles \o/
[12:02] <apachelogger> but for how long ^^
[12:03] <yofel> that's already more than the first editions of project-neon-qt did :P
[12:03] <apachelogger> lol
[12:03] <apachelogger> shadeslayer: I may needs a server soonishy
[12:21] <apachelogger> yofel: https://launchpadlibrarian.net/142832008/buildlog_ubuntu-saucy-i386.project-neon5-qtbase_0.0%2Bgit20130619-9~saucy0_FAILEDTOBUILD.txt.gz
[12:21] <apachelogger> that's the gcc problem
[12:22] <apachelogger> no clue what to do :(
[12:26] <apachelogger> or maybe I am still on master
[12:26] <apachelogger> git shallow clones are weird
[12:26]  * apachelogger reclones
[12:29] <Riddell> smartboyhw: sorry missed it, how did you get on with your link error?
[12:30] <Riddell> smartboyhw: looks like it's missing a -lsmoke_akonadi somewhere
[12:31] <Riddell> shadeslayer: I still need kubuntu_krfb_link_to_pthread.diff in krfb
[12:47] <smartboyhw> Riddell, OK.
[12:47] <Riddell> smartboyhw: complain upstream is probably the best thing, rdale would be the chap
[12:48] <smartboyhw> Riddell, heh:P
[12:48] <Riddell> he seems to be on irc
[12:49] <smartboyhw> Riddell, pinged him.
[12:50] <smartboyhw> Wow, now only 4 packages build-fail!:O
[12:51] <smartboyhw> Am I wrong or analitza has some --list-missing problems?
[12:51] <smartboyhw> Uh, it's the symbols:(
[12:51]  * smartboyhw does not want to touch symbols today ...
[12:52] <smartboyhw> But someone has to be the guinea pig, let me be it:P
[12:52] <smartboyhw> Laters though, I need to take dinner.
[13:16] <Riddell> hmm, I can't run kppp cos I'm not in dialout
[13:18] <soee> i see only 3 packages failed to build for saucy?
[13:20] <smartboyhw> soee, yep. But Riddell you haven't yet split all packages right?
[13:21] <Riddell> just finishing kdenetwork
[13:22] <smartboyhw> Riddell, great:)
[13:22] <smartboyhw> Riddell, what's the response of korundum?
[13:23] <Riddell> smartboyhw: did you see those two patches?
[13:23] <smartboyhw> Riddell, no didn't. Now working on analitza.
[13:25] <yofel> libkwinglutils.so.1abi2 libkwinglutils1abi1 #MINVER#
[13:25]  * yofel thought he already fixed that o.O
[13:27] <apachelogger> yofel: uploading new qtbase
[13:27] <apachelogger> this time apparently really from dev branch ^^
[13:30] <smartboyhw> Riddell, you going to fix korundum or me?
[13:30] <Riddell> smartboyhw: I'm still on splits
[13:30] <smartboyhw> Riddell, OK I shall do it then.
[13:43] <smartboyhw> Guys, we have prob with krfb https://i142838148.restricted.launchpadlibrarian.net/142838148/buildlog_ubuntu-saucy-i386.krfb_4%3A4.10.80-0ubuntu1~ubuntu13.10~ppa2_FAILEDTOBUILD.txt.gz?token=87b02fb2551e0decb4c4509968692674 (cmake error?)
[13:44] <smartboyhw> analitza uploaded BTW.
[13:44] <Riddell> smartboyhw: thanks, build deps need fixing, will look
[13:45] <smartboyhw> And can someone tell me how adding not-installed to smokegen works, I added it and it still is in red light...
[13:47] <smartboyhw> Hmm sounds like an old problem came back on analitza.....
[13:47] <smartboyhw> libsmokekate..........
[13:48] <smartboyhw> !?
[13:50] <yofel> what does analitza have to do with smoke?
[13:51] <smartboyhw> yofel, sorry korundum:P
[13:51] <smartboyhw> And actually I just found that korundum failed to build in armhf for 4.10.4 .....
[13:52] <yofel> smartboyhw: and it seems you didn't add the patch to analitza
[13:52] <smartboyhw> yofel, you mean in bzr or?
[13:53] <yofel> smartboyhw: well, I don't see it in bzr
[13:53] <smartboyhw> yofel, wait what patch?
[13:53] <smartboyhw> I only changed symbols.
[13:53] <smartboyhw> Patch was for korundum...
[13:53] <yofel> smartboyhw: you didn't read the pad...
[13:53] <yofel> and your symbol changes are something which isn't allowed
[13:54] <smartboyhw> yofel, ah? (for second sentence)
[13:54] <yofel> - _ZNK8Analitza12PlotsFactory11requestPlotERKNS_10ExpressionENS_9DimensionE@Base 4:4.9.80
[13:54] <yofel> - _ZNK8Analitza11PlotBuilder6createERK6QColorRK7QStringPNS_9VariablesE@Base 4:4.9.80
[13:54] <yofel> those are missing PUBLIC symbols
[13:54] <yofel> that must never happen without an SOVERSION change
[13:55]  * smartboyhw is too confused with symbols....
[13:55] <Riddell> the soversion change did happen didn't it?
[13:55] <smartboyhw> Let me add patch first ....
[13:55] <yofel> that's why you need to cherry-pick 3c1f0b4ea784eeed754a68e611a1f6f3aa4f9cac
[13:55] <yofel> Riddell: right ^
[13:56] <smartboyhw> Sorry guys...
[13:56] <yofel> smartboyhw: well, we helped you this time around because this is a complicated matter. But you really need to investigate every single MISSING symbol
[13:58] <yofel> smartboyhw: reason: if an application uses the library and uses those methods, it will crash with a symbol lookup error unless it's at least rebuilt (or fixed if the API changed too)
[13:59] <smartboyhw> yofel, OK.
[14:00] <smartboyhw> Re-uploaded.
[14:00] <yofel> smartboyhw: btw, this is a good read on the topic: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[14:00] <yofel> you should've at least read the library packaging part of the debian policy though
[14:00] <smartboyhw> Whoas....
[14:02] <smartboyhw> Anyways, analitza done, now can someone tell me why that smokekate returned to haunt korundum!?:O
[14:04] <Riddell> Tm_T: you admin kopete-devel mailing list? could you let through my posts?
[14:04]  * smartboyhw cries....
[14:06] <yofel> smartboyhw: btw. if you add header-less patches, please at least mention the patch filename and commit hash that was used if you add upstream patches.
[14:06] <yofel> We don't require DEP-3 or anything like that, but at least this is good practice
[14:06] <smartboyhw> yofel, ok......
[14:07] <smartboyhw> So I have to re-upload again?
[14:07] <smartboyhw> ...
[14:07]  * smartboyhw is already getting smoked of that smokekate thing...
[14:07] <yofel> where's that anyway? I only see akonadi stuff in kroundum
[14:07] <GGGGEEO> l
[14:08] <smartboyhw> yofel, it just shows up.
[14:08] <smartboyhw> http://paste.kde.org/777926/
[14:09] <yofel> what o.O?
[14:09] <smartboyhw> yofel, and there IS a kate folder in modules...
[14:09] <yofel> yeah, but we don't build the kate bindings...
[14:09] <yofel> too unstable I think
[14:10] <smartboyhw> Grrrrr.........
[14:10] <smartboyhw> It haunted us after 3 cycles:O
[14:10] <yofel> -- Skip SmokeKDE bindings: Kate
[14:10] <smartboyhw> I agree....
[14:11] <yofel> as for analitza: yes, you'll have to upload again
[14:11] <yofel> but wait, the package build will fail anyway
[14:11] <smartboyhw> We aren't going to ship smokeKDE right?
[14:12] <yofel> huh? ofc. we ship it
[14:12] <smartboyhw> Ah yep.
[14:12] <smartboyhw> yofel, I mean kate.
[14:12] <smartboyhw> smokekate.
[14:12]  * smartboyhw goes to fix analitza again:)
[14:12] <yofel> no, that not, we ship:
[14:12] <yofel> -- Build SmokeKDE bindings: Akonadi;Attica;KDECore;KDEUi;KFile;KHTML;KIO;KNewStuff2;KNewStuff3;KParts;KTextEditor;KUtils;Nepomuk;Okular;Plasma;Solid;Soprano
[14:13] <smartboyhw> yofel, so I have to patch korundum to not make kate?
[14:13] <smartboyhw> !?
[14:14] <yofel> meh, let me try to build it myself. Otherwise I'm just guessing
[14:20]  * Riddell cheers as he gets kopete working with no missing symbols
[14:22] <yofel> smartboyhw: I don't get your kate error here
[14:22] <smartboyhw> yofel, :O
[14:22] <yofel> maybe you have some kate headers lying around?
[14:22] <yofel> (the cmake part for kate is weird...)
[14:22] <smartboyhw> yofel, check your modules folder...
[14:22] <yofel> but the akonadi issue is ${SMOKE_AKONADI_LIBRARY} being empt...
[14:22] <smartboyhw> :O
[14:23] <yofel> smartboyhw: modules folder?
[14:23] <yofel> I know that kate is there, but
[14:23] <yofel> -- Skip KorundumModules bindings: Kate
[14:23] <yofel> so I'm fine
[14:23] <smartboyhw> yofel, hmm it doesn't skip for me weird.
[14:23] <yofel> well, as I understand the check, it looks whether you have kate, but not whether you have smokekate
[14:24] <yofel> if you have the kate headers lying around without smokekate it fails
[14:26]  * Riddell cheers as the ical transition goes through
[14:26] <smartboyhw> I tried to remove packages with kate and it will remove 67 packages:O
[14:26] <BluesKaj> yeah I had the kate problem as well , so I re-enabled the proposed deb and yofel's n inja deb , and the right dependencies installed , after which I promptly commented them again
[14:26] <smartboyhw> only 2 of them have kate in it.
[14:27] <yofel> well, I don't get why it even finds it for you...
[14:27] <smartboyhw> The removed packages include all the dependencies to build this....
[14:27]  * smartboyhw has a weird system...
[14:27] <shadeslayer> apachelogger: server?
[14:28]  * smartboyhw does reverse-steps.
[14:28] <yofel> smartboyhw: do you have a  kate/plugin.h somewhere?
[14:28] <smartboyhw> Removing then build-dep.
[14:28] <yofel> that's what it looks for
[14:28] <Riddell> you can build-conflict if it's a problem
[14:28] <yofel> nah, it's only an issue on his system
[14:31] <soee> on g+ is it possible to see hangout history ?
[14:31] <yofel> smartboyhw: hm, looking closer the cmake output is already weird
[14:31]  * Riddell moves onto the all important kdetoys
[14:32] <yofel> there is no found message for okular and akonadi
[14:32] <smartboyhw> yofel, I have...
[14:32] <smartboyhw> akonadi.
[14:32] <smartboyhw> Then it fails at kate.
[14:33] <apachelogger> shadeslayer: for builder
[14:33] <shadeslayer> apachelogger: what are your requirements?
[14:33] <apachelogger> root access
[14:33] <apachelogger> well
[14:33] <apachelogger> actually that are pbuilder's requirements ^^
[14:34] <apachelogger> also at least 10gb of space
[14:34] <shadeslayer> uhm .. uhm
[14:34] <shadeslayer> space is not an issue
[14:34] <apachelogger> Can't open perl script "bin/syncqt": No such file or directory
[14:34] <apachelogger> eh
[14:34] <apachelogger> uh
[14:34] <shadeslayer> you could have complete git clones on disk
[14:34] <apachelogger> Oo
[14:35] <shadeslayer> *git clones of qt5
[14:35] <yofel> smartboyhw: what does 'locate kate/plugin.h' yield on your system?
[14:35] <smartboyhw> yofel, speaking of that: Looking at the patch, it should be libanalitza5, X-Debian-Abi =0?
[14:35] <yofel> right
[14:35] <smartboyhw> yofel, I've removed all kate things, so locate says nothing
[14:36] <yofel> very weird
[14:36] <smartboyhw> yofel, but DebianABIManager still fails!
[14:36] <smartboyhw> :O
[14:36] <yofel> with what error?
[14:36] <smartboyhw> -- DebianABIManager: CMake target 'analitza' SOVERSION does not match package name 'libanalitza5'
[14:36] <smartboyhw> !?
[14:37] <apachelogger> rm -rf include && QTDIR="."  (After installing all the build-deps)
[15:07] <smartboyhw> yofel, ^
[15:08] <Riddell> smartboyhw: committed any changes to bzr?
[15:08] <smartboyhw> Riddell, not yet.
[15:08] <smartboyhw> For korundum I mean.
[15:08] <Riddell> smartboyhw: mind and do that before you go to sleep
[15:09] <smartboyhw> Riddell, I don't really have much changes here, I can't even build...
[15:10] <Riddell> ok
[15:10] <Riddell> just leave a note in etherpad then
[15:12] <smartboyhw> Riddell, DONE.
[15:23] <smartboyhw> Riddell, amor failed (#include file missing error)
[15:24] <Riddell> smartboyhw: yeah fixing it now, missing cmake check on xlib
[15:24] <Riddell> or missing build-dep depending on your point of view
[15:27] <Riddell> hmm, 1 hour to repackage kdetoys
[15:27] <Riddell> so sdk will probably take at least 2
[15:45] <smartboyhw> Will do analitza tmr (or if anyone can pleaes takeover), I'm sleeping and the patch has been committed but not arrived:O
[17:32] <ryanakca> There, #kubuntu-bugs now forwards to here.
[17:44] <lordievader> Good evening.
[19:30] <ahoneybun> hello all
[19:31] <lordievader> Good evening, ahoneybun
[19:31] <ahoneybun> hey lordievader :)
[19:35] <ahoneybun> lordievader: good afternoon
[19:50] <lordievader> ahoneybun: ;)
[19:50] <ahoneybun> lordievader: have you gotten around to reading the getting involved page?
[19:53] <lordievader> Yes, I think it is quite good. Gets the finished stamp if you ask me. (The include might need a bit of a trim)
[19:54] <ahoneybun> lordievader: can you trim it and then mark it as finished?
[19:54] <lordievader> ahoneybun: On the trello page?
[19:54] <ahoneybun> yes
[20:16] <yofel_> great, broken libkwinglutils ABI -.-
[20:25] <yofel> o.O
[20:25] <yofel> + (arch=amd64)_ZN4KWin14XRenderPictureC2Eji@ABI_1_4 4:4.10.80
[20:25] <yofel>   (subst|arch=i386)_ZN4KWin14XRenderPictureC2E{size_t}i@ABI_1_4 4:4.10.80
[20:26] <yofel> how can that happen...
[21:12] <yofel> RuntimeError: the sip module implements API v10.0 but the PyKDE4.kdeui module requires API v9.2
[21:12] <yofel> it's this time of the year again...
[21:15] <ScottK> yofel: Bug xnox for not updating python-qt4 like he said.
[21:15] <ScottK> That and I kind of screwed up in Debian, but xnox is slowing the cleanup in Ubuntu.
[21:16] <ScottK> Or if you want to be proactive about it, just merge python-qt4 from Debian.
[21:16] <ScottK> Then do a no change upload of pykde4 after it's built.
[21:16] <ScottK> Personally, I'm waiting for xnox, since he TIL python-=qt4.
[21:17] <yofel> hm, he did upload python-qt4 yesterday
[21:17] <ScottK> yes.  too soon
[21:17] <yofel> let me check again if I'm missing something
[21:17] <ScottK> No, you aren't.
[21:17] <yofel> aah
[21:17] <ScottK> He needs to do it again.
[21:17] <yofel> ok ^^
[22:36]  * ScottK pokes at xnox.
[23:11] <Riddell> yofel: no libkwinactiveglutils1abi2.symbols?
[23:11] <yofel> there was none of abi1
[23:11] <yofel> *for
[23:12] <Riddell> yofel: oh? how did you know to bump the abi?
[23:12] <yofel> that's synchronized with !abi, as debian abi manager can't handle double building with differen cmake targets
[23:12] <yofel> with !active I mean
[23:13] <yofel> so libkwinglutils and libkwinactiveglutils always have the same ABI version
[23:13] <yofel> it doesn't work otherwise
[23:14] <Riddell> mm, I learn something new, thanks
[23:15] <Riddell> but I didn't review martin's post to kde-packager on kde-workspace so there  might be more to do there
[23:16] <yofel> as I understood it that's all about depending on wayland and EGL
[23:18] <yofel> wayland we have now, egl maybe not and we don't recommend weston yet
[23:18] <yofel> I uploaded a new meta-kde with meta packages for kdesdk, kdeadmin, kdetoys and kdenetwork
[23:19] <Riddell> oh cool thanks
[23:19] <yofel> kdesdk might need fixing depending on the final list of binary packages we have
[23:22] <ScottK> Definitely not Weston.  It's only for people to play with who know what they are doing.
[23:26] <Riddell> but that's a soft dependency so it can be a Suggests
[23:27] <yofel> pkgkde-symbolshelper... are you kidding me??
[23:27] <yofel> I have (subst)_ZN4KWin14XRenderPictureC1E{size_t}i@ABI_1_4 4:4.10.80
[23:28] <yofel> now it wants to change that to (subst|arch=i386)_ZN4KWin14XRenderPictureC1E{size_t}i@ABI_1_4 4:4.10.80
[23:28] <yofel> but on an earlier build it wanted to add + (arch=amd64)_ZN4KWin14XRenderPictureC2Eji@ABI_1_4 4:4.10.80
[23:28]  * yofel is confused


[09:23] <mdke> where is the blasted queue?
[09:24] <mdke> I can't find corey's magazine story
[09:24] <mdke> ah, found it in the logs
[09:30] <popey> mdke: FYI: http://fridge.ubuntu.com/admin/content/node then choose "not published" and press filter, it will show all unpublished articles
[09:31] <mdke> ah, that's helpful, thanks
[09:31] <popey> Administer --> Content management --> Content   to get to there
[09:31] <popey> np
[09:32] <mdke> well done with that thread on -uk by the way
[09:32] <popey> :S
[09:32] <popey> could have gone either way tbh
[09:33] <mdke> you handled it perfectly
[09:33] <popey> that original subject line may well have been somewhat contentious in retrospect
[09:33] <popey> I'll keep my humour locked up next time
[09:33] <mdke> heh
[09:34] <mdke> still, reasonable to assume that british geeks will be doctor who fans
[09:34] <mdke> the two go hand in hand
[09:34] <mdke> alright, spose I ought to go to work
[09:34] <mdke> cya
[09:36] <popey> ttfn
[07:18] <bluekuja> hi all :)
[07:18] <Rinchen> howdy :-)
[07:18] <bluekuja> Rinchen: thanks for inviting me in
[07:19] <Rinchen> You're always welcome
[07:19] <bluekuja> :) , leaving for a while, then back for the mail
[07:19] <bluekuja> brb
[08:09] <bluekuja> Rinchen: is the ML open to members only right?
[08:10] <Rinchen> it should be open to everyone
[08:10] <bluekuja> Rinchen: seems that archives are closed to non-members
[08:10] <bluekuja> that's why I asked
[08:11] <bluekuja> usually closed-archive means members-only ML
[08:11] <bluekuja> but I might be wrong
[08:13] <bluekuja> Rinchen: I'm register on the ML
[08:13] <bluekuja> *registering
[08:13] <Rinchen> great thanks
[08:13] <bluekuja> ;)
[08:15] <bluekuja> Rinchen: done, should receive a mail soon for moderator approval
[08:16] <Rinchen> I'll look for it now
[08:16] <bluekuja> thanks
[08:24] <bluekuja> Rinchen: received anything?
[08:26] <Rinchen> not yet
[08:27] <bluekuja> Rinchen: strange, it was quite fast here
[08:28] <Rinchen> gah sorry
[08:28] <Rinchen> I auto file those
[08:29] <bluekuja> ah ok! thats why :)
[08:30] <Rinchen> done
[08:30] <bluekuja> Rinchen: thanks! writing the mail atm
[08:53] <bluekuja> Rinchen: mail sent, thanks again for your hints
[08:54] <Rinchen> bluekuja, glad to help
[08:54] <bluekuja> :)
[12:15] <newz2000> wow, quick acting on that countdown banner...
[12:15] <popey> http://fridge.ubuntu.com/node/1149
[12:15] <popey> can someone approve that story please
[12:15] <newz2000> I just uploaded some CSS to fix konq/opera and hit refresh and about had a panic attack
[12:16] <popey> :)
[12:16] <mdke> ok
[12:16] <newz2000> speaking of which, anyone here have safari at hand and willing to do a site check on the fridge?
[12:17] <mdke> very nice that countdown, good work newz2000
[12:17] <newz2000> thanks. Graphics were done by an agency, I just did the javascript
[12:17] <newz2000> So I'll assume you were complementing me on the js
[12:17] <newz2000> :-)
[12:18] <popey> hey matthew, _great_ job on the js there..
[12:18] <newz2000> thanks!
[12:18] <popey> :)
[12:18] <newz2000> :-D


[06:13] <dholbach> good morning
[12:03] <dholbach> relocating, brb
[14:56] <dholbach> dpm, shall we have the quick catch-up now?
[14:56] <dholbach> dpm, I'll probably be here for another 60-90m though - I can just ping you shortly before I leave as well, if that works better
[14:57] <dpm> dholbach, just wrapping up another call, but I need to prepare something else before I go. Yeah, pinging would be good if it works for you
[14:57] <dholbach> ok cool
[14:57] <dholbach> will do
[14:57] <dholbach> dpm, I don't think we'll need a lot of time anyway
[14:58] <dpm> ok, great
[16:03] <dpm> dholbach, up for a hangout in a few minutes, let's say at 10 past?
[16:03] <dholbach> dpm, sure sure
[16:03] <dpm> cool
[16:29] <dholbach> all rightie - with that I call it a day - have a great weekend everyone! :-)
[16:29] <dholbach> dpm, enjoy the trip!
[16:29] <dpm> thanks, and you have a good weekend!
[16:29] <dholbach> will do :)
[16:29] <elfy> cya dholbach
[16:29] <dholbach> bye elfy
[16:56] <mhall119> dpm: ready whenever you are
[19:07] <popey> BEER O'CLOCK!
[20:09] <toddy> popey: BEER O'CLOCK, too! :)