[02:59] <kubotu> ::qt-bugs:: [1080861] package qt4-doc-html (not installed) failed to install/upgrade: cannot copy extracted data... @ https://bugs.launchpad.net/bugs/1080861 (by heathhensh)
[03:10] <ScottK> xnox: Is the cmake patch upstreamed?
[06:50] <soee> good morning
[10:40] <yofel> could someone please look at armhf build https://launchpad.net/ubuntu/+source/avogadro/1.0.3-5ubuntu4/+build/4076596 and tell me what I did wrong o.O?
[10:51] <apachelogger> yofel: it includes GLES and GL
[10:51] <persia> Looks like fallout from rebuilding lots of stuff for GLES rather than GL, but I would have expected that to be abstracted at a Qt level
[10:52] <yofel> ah, I did notice that it included both - but I have no clue why it does..
[10:52]  * yofel -> lunch
[10:52] <apachelogger> persia: it's more painful to do drawing using Qt4's regular drawing API than by writing a shader
[10:53] <apachelogger> though you could indeed abstract GL in parctise it rarely makes sense 
[10:53]  * persia dreams of the QtGL abstraction layer
[10:53] <apachelogger> in fact that goes away somewhat entirely in Qt5
[10:53] <persia> Anyway, probably have to make a GL vs. GLEZs decision for now (unfortunate, as there are devices for both APIs for that architecture)
[10:53] <apachelogger> as with QML you are encouraged to write GL shaders directly
[10:54] <apachelogger> yofel: btw, I had a dream about release packaging automation last night
[11:00] <apachelogger> ah, I was running proposed, that's why my initramfs broke over i915
[11:28] <jussi> o/
[11:28] <jussi> gles is the way forward imho...
[11:31]  * persia mumbles something about having GL-supporting devices for every architecture supported by Ubuntu in pluggable form-factors that work on other folks hardware too
[11:54] <yofel> apachelogger: as in making our process better or a completely different one?
[11:54] <apachelogger> better
[11:55] <apachelogger> someone runs a cron that ignites mad automation
[11:55] <yofel> what for?
[11:56] <apachelogger> updates tars from ftpmaster (triggering version bumps and rebuilds accordingly), updates branches from bzr (triggering rebuilds accordingly), rebuilds whatever needs rebuilds and uploads wahtever needs uploading
[11:57] <apachelogger> so it becomes continous integration and the intended workflow is: throw random change at bzr->see if it works (for 99% of the problems)
[11:58] <yofel> would need an untrusted pgp key, but I guess doable if someone finds the time to implement it
[11:58] <yofel> and don't look at me - my vacation todo list is pretty full as it is
[11:58] <apachelogger> define untrusted
[11:58] <yofel> passwordless
[11:58] <yofel> or how would you upload packages from cron?
[11:58] <apachelogger> one can script the way out of that
[11:58] <persia> apachelogger: Don't run a cron: rather take the notication from upstream VCS when the release is tagged, and drive from that.
[11:59] <apachelogger> plus since only one person in theory has access it matters little
[11:59] <apachelogger> persia: what notification?
[11:59] <persia> apachelogger: Which VCS are you using?
[11:59] <apachelogger> le git
[11:59]  * persia tries to track down that bit of code
[12:00] <apachelogger> well, the point is that tarballs get rerolled ever so often between official tagging and actual release
[12:00] <yofel> which reminds me that we need something that shows us post-release commits to the bugfix branches in kde
[12:00] <apachelogger> so IMO the most reliable way is to simply check checksums of the tars and if they changed, update them bumping the version
[12:00] <persia> Add a post-receive hook, which can be an arbitrary shell script.  Have it wget something as a trigger.
[12:01] <yofel> to find 4.9.5+ commits etc.
[12:01] <persia> Better yet, have it send an IRC message or do something else everyone can use.
[12:01] <apachelogger> persia: KDE has that
[12:01] <apachelogger> IRC messages require someone to do something though
[12:01] <persia> Yeah, it's the tarball re-rolling bit that gets in the way.
[12:01] <persia> Why?  Bots can subscribe to IRC messages...
[12:02] <persia> What's the notice procedure when the re-rolling is complete?  Posting on a web page?  Mail?
[12:02] <apachelogger> mail on private list
[12:02] <yofel> well, usually kde-release is CC'd
[12:02] <persia> Does anyone on that private list use a mail filter?
[12:03] <persia> Have one of those folk trigger something when the magic message is received (maybe provide automation to the release team to ensure it is a machine-readable message), and then trigger from that.
[12:04] <apachelogger> single point of failure
[12:04] <persia> And a cronjob isn't?
[12:04] <apachelogger> I want this to have as few requirements and as few failure points as possible
[12:04] <apachelogger> persia: not if the system it invokes is so simple that you can just as well invoke it by hand or setup another builder on another machine
[12:05] <yofel> hm... do we have a team-internal dev TODO list? The blueprints are more about release work
[12:05] <persia> OK.  I just don't like polling.  I think it damages the planet.
[12:05] <apachelogger> yofel: no, how would a team-internal list be different?
[12:06] <yofel> apachelogger: I mean for stuff like our support scripts - where to keep that todo list?
[12:06] <yofel> I'll put some notes on the pad for now
[12:06] <apachelogger> persia: I'd usually agree, but in this case simplicity takes lead ^^
[12:06] <apachelogger> persia: on a related note ... we'd also have to somehow watch bzr changes
[12:07] <persia> I know lots less about bzr hooks, but I hear they exist.
[12:07] <apachelogger> yeah they do
[12:07] <apachelogger> but I doubt we get one on launchpad
[12:08] <apachelogger> so those needed to be client side (ewww) or mail filtering again
[12:08] <persia> I think LP supports them: at least there are several LP-hosted branches with notifications, etc.
[12:08] <yofel> I wouldn't mind to have a mailing list for our commits actually...
[12:08] <apachelogger> persia: yeah there are email notifications
[12:09] <apachelogger> yofel: set a mailing list for ~kubuntu-packagers
[12:09] <yofel> yeah
[12:09] <yofel> that and change the subscription settings IIRC
[12:09] <apachelogger> ohm
[12:09] <apachelogger> hf with the 300 branches
[12:09] <yofel> shouldn't be hard to script
[12:09] <apachelogger> if one can script that :P
[12:09] <apachelogger> which reminds me
[12:10] <apachelogger> yofel: newpackage still broken :P
[12:10] <yofel> the API is junk in some places, but overall it's good
[12:10] <apachelogger> also it's not working :P
[12:10] <yofel> apachelogger: right, on todays todo list, I'll get to it later...
[12:10]  * apachelogger draws diagrams
[12:10] <apachelogger> ah yes, I forgot
[12:10]  * yofel makes a lucid chroot in the meanwhile
[12:11] <apachelogger> so then you have the second piece which continuously builds the build status page
[12:11] <apachelogger> completely independent of the builder, so that can run on another machine etc.
[12:12] <apachelogger> and finally the conflictchecker which builds a list of all binary packages supposed to be built, installs those in a clean chroot from a stable version, then tries to upgrade
[12:12] <yofel> define continuously. The lp admins don't like cron scripts that pull all the time too much. Ideally the page would be cached and have a refresh button on it
[12:13] <apachelogger> i.e. QA for file conflicts and broken maintscripts etc.
[12:13]  * yofel needs an IRC to pad parser btw.
[12:13] <apachelogger> dunno what that is
[12:14] <apachelogger> yofel: and by continously I mean every 15 minutes
[12:14] <yofel> a simple version of the brain to pad interface :P
[12:15] <apachelogger> if builder and buildstatus on the same machine one could think about smarter behavior here
[12:16] <apachelogger> e.g. track all versions uploaded by builder, status then removes them as it gets the data for that version
[12:16] <apachelogger> if no packages pending -> no autorefresh
[12:20]  * yofel wonders if one can deduce whether there was an update from the Packages.gz in the binary archive
[12:20] <yofel> timestamp I mean
[12:21] <yofel> not sure which of those files are updated when something is published
[12:26] <yofel> hm, if I find out how to do the https authentication that's doable actually...
[12:28] <yofel> fun, wget can handle the password url's for apt, so it's in fact trivial
[13:07] <yofel> apachelogger: newpackage should work on lucid now
[13:22] <persia> "continuous" as in "continuous integration" shouldn't be time-based, but rather event-based.  Packages.gz always gets updated when stuff gets published (the version strings in the file need to change)
[14:20] <shadeslayer> btw does this look good : http://paste.kde.org/628682/ : for kde-workspace?
[14:21] <shadeslayer> or should I install Minimalistic/None/Simple ?
[14:21] <shadeslayer> hmm ... I guess I should
[14:22] <yofel> shadeslayer: that's fine
[14:22] <shadeslayer> ?
[14:22] <yofel> current kde-workspace git has no themes folder anymore
[14:22] <shadeslayer> oh
[14:22] <shadeslayer> awesome
[14:23] <yofel> see d4b00fa89292e4dc84ba344cedbaa645ef3ebe9a
[14:24] <shadeslayer> btw regarding active dual building kde-workspace
[14:24] <yofel> shadeslayer: ah, not quite, only the default one is gone
[14:24] <shadeslayer> should we rebuild all binaries with active in the binary name?
[14:24] <shadeslayer> because we're building with a different profile ....
[14:25] <yofel> dunno
[14:25] <shadeslayer> s/we're/we will be/
[14:25] <kubotu> shadeslayer meant: "because we will be building with a different profile ...."
[14:25] <shadeslayer> possibly kickstart a discussion on the ML?
[14:36] <yofel> shadeslayer: feel free to, but looking at my todo list don't count on my much in the near future wrt active
[14:36] <yofel> *me
[14:36] <shadeslayer> heh ok
[14:46] <shadeslayer> ~seen SteveRiley
[14:46] <kubotu> SteveRiley was last seen 1 month, 2 hours, 35 minutes and 18 seconds ago, quitting IRC (Read error: Operation timed out)
[14:46] <shadeslayer> 0.o
[14:46] <shadeslayer> he seems to have disappeared after UDS :P
[14:47] <shadeslayer> Hopefully we didn't scare him off
[15:08] <persia> shadeslayer: You can just say something, rather than pointing me somewhere I am :p
[15:08] <shadeslayer> heh :P
[15:08] <shadeslayer> persia: anywho
[15:09] <shadeslayer> so you're saying that the config in /etc/kde4 should override the kubuntu-settings-desktop?
[15:09] <shadeslayer> then the entire point of custom configs is lost 
[15:09] <persia> I'm saying that there should be the potential for local-system-config that overrides packaging config, unless that packaging config is a conffile or local-system-managed configuration file.
[15:10] <shadeslayer> tbh any custom configs should be debated upstream and resolved as either useless on our side, or committed upstream
[15:10] <persia> I won't agree with that: I think there's value in distribution defaults.
[15:11] <persia> I just think that sysadmins should be able to set local default that override distro defaults in a way that is preserved accross upgrades.
[15:11] <shadeslayer> yeah that's easily doable
[15:11] <persia> Doesn't have to be in /etc/kde4rc
[15:11] <shadeslayer> just add your path before kubuntu-desktop-settings ?
[15:11] <shadeslayer> so it'll do cascaded configs
[15:11] <shadeslayer> sysadmin settings > distro settings > kde upstream settings
[15:12] <persia> Rather, package should already have an (empty) local system config listed before the disto config, and the documentation should tell system administrators to change things there.
[15:12] <persia> Right.
[15:12] <persia> Well, user settings > admin settings > distro settings > upstream settings
[15:12] <shadeslayer> right
[15:12] <shadeslayer> that's already done by KConfig
[15:13] <persia> Thought so: you should tell people do use the admin settings rather than hunting under /usr/share :p
[15:13] <shadeslayer> I see, I probably explained it a bit poorly in #kubuntu then :)
[15:14] <persia> At least enough to get the response "that gets lost on upgrade", but really it belongs in good docs, not your head and channel logs.
[15:14] <shadeslayer> heh
[15:14] <shadeslayer> or API docs
[15:14] <persia> No: admins don't read API docs, only devs do.
[15:14] <shadeslayer> right
[15:14] <shadeslayer> that's what I meant
[15:14]  * persia ignores the existence of the devops crowd for the sake of argument
[15:15] <shadeslayer> haha
[15:15] <persia> Oh, right.  Yeah, I suppose it is in the API docs already :)
[15:15] <shadeslayer> I've actually been working a derivative for the last 4-5 months so I've experienced all of these issues :P
[15:16] <shadeslayer> and I've seen people ( i.e the mint team ) implement this horribly
[15:17] <shadeslayer> even more fun is software that doesn't respect XDG settings, like QtCurve
[15:18] <persia> There's KDE software that respects XDG?
[15:19]  * persia still has ~/.kde/ and .kderc
[15:19] <yofel> akonadi would be one
[15:19] <shadeslayer> :D
[15:20] <shadeslayer> there's the gtk3 kcm
[15:20] <shadeslayer> <3 apol_ for respecting XDG
[15:20] <apol_> <3
[15:20] <yofel> well, the kcm is good, the gtk3 settings not. Not that you have a better chice
[15:20] <yofel> *choice
[15:21] <persia> No, I'm making fun.  More and more bits seem to be in the right places, and things that aren't (like KDECACHE KDEVARTMP KDETMP) do interesting things that would be hard to do within the .xdg framework
[15:22] <persia> s/./△/
[15:22] <kubotu> persia meant: "△o, I'm making fun.  More and more bits seem to be in the right places, and things that aren't (like KDECACHE KDEVARTMP KDETMP) do interesting things that would be hard to do within the .xdg framework"
[15:22] <persia> kubotu: Err, not quite, but good try
[15:41] <yofel> shadeslayer: how's kde-workspace?
[15:41] <Peace-> rc is out ?
[15:41] <Peace-> :D annoying question i know
[15:42] <Peace-> i mean packaged :P
[15:42] <yofel> still WIP
[15:42] <Peace-> uu
[15:42] <shadeslayer> yofel: still building
[15:42] <shadeslayer> will upload as soon as it's done
[15:42] <Peace-> goog
[15:43] <Peace-> good
[15:43] <yofel> shadeslayer: what did you do about the themes now?
[15:43] <shadeslayer> I removed the default one, kept everything else
[15:43] <yofel> good
[15:53] <shadeslayer> yofel: btw with the active profile it's just ifdef'd code right?
[15:54] <shadeslayer> 0.o
[15:54] <shadeslayer> o.0
[15:55] <shadeslayer> not a single mention of the tablet profile in kde-workspace
[15:55] <shadeslayer> wtf?
[15:55] <yofel> don't ask me
[15:55] <shadeslayer> http://paste.kde.org/628730/
[15:56] <yofel> it seems not choosing desktop simply disables lots of stuff
[15:56] <shadeslayer> yeah
[15:56] <yofel> so maybe just stick to desktop if it doesn't hurt
[15:56] <shadeslayer> I guess
[15:56] <shadeslayer> so we don't need to dual build?
[15:56] <shadeslayer> yay
[15:57] <yofel> don't you still need an alternate kwin? or is that now merged?
[15:57] <shadeslayer> there was no mention of it from sebas
[15:58] <yofel> well, then yay
[15:58] <shadeslayer> http://paste.kde.org/628736/
[15:58] <shadeslayer> wat
[15:58] <shadeslayer> shouldn't that be "Tablet" or sth?
[15:59] <yofel> well, that works too...
[15:59] <yofel> but seems like you still need to double build
[15:59] <yofel> meh
[15:59] <shadeslayer> yeah
[15:59] <yofel> though just keeping it as it is should work it seems
[15:59] <shadeslayer> yeah
[16:00] <shadeslayer> it looks as if it merely turns off some kwin options
[16:00] <yofel> seems we never backported amarok
[16:00] <shadeslayer> ouch
[16:00] <shadeslayer> oh
[16:01] <shadeslayer> ScottK: should I put ktp in kubuntu-updates or backports?
[16:01] <shadeslayer> since I would like to get that SRU'd, I was thinking updates
[16:04] <shadeslayer> yofel: http://paste.kde.org/628742/
[16:04] <shadeslayer> just to make sure I didn't do something wrong
[16:05] <yofel> looks ok as I understand it
[16:05] <shadeslayer> cool
[16:08] <shadeslayer> uploaded to ninjas
[16:51] <yofel> amarok 2.6.90 uploaded to /beta for quantal
[16:51] <yofel> bbl
[19:27] <doctorpepper> hi guys !!! 
[19:28] <doctorpepper> is there any way to get kde 4.10 rc on  12.04  ?
[19:28] <shadeslayer> erm, nope
[19:28] <doctorpepper> shadeslayer:  why   ? 
[19:29] <shadeslayer> because we usually don't backport for stable-1
[19:29] <shadeslayer> build deps are *usually* too old
[19:31] <doctorpepper> well 12.04  is supported  for 5 years so  according  what you say  i am stuck with 4.9  for the next 4 years
[19:32] <shadeslayer> on a related note, does unity get similar upgrades?
[19:32] <doctorpepper> i dl
[19:33] <doctorpepper> i dont know  since  i dont use anything but  kde  or fluxbox 
[19:33] <shadeslayer> hmm .. maybe someone else knows?
[19:34] <yofel> well, it's probably not impossible, but I don't see how we'll have time to do this currently
[19:35] <shadeslayer> well
[19:35] <yofel> if someone wants to try it we can give pointers on how to do it
[19:35] <shadeslayer> we could just run backportpackage on stuff
[19:37] <doctorpepper> yofel:  is there any plan to  build kde 4.x with  qt5  for future kubuntu releases ?
[19:37] <yofel> well, we'll first need qt5, but IIRC we wanted qt5 in raring?
[19:38] <JontheEchidna> ^not all of it would necessarily build anyway
[19:38] <JontheEchidna> (all of kde)
[19:38] <yofel> wasn't qt5 supposed to be api compatible?
[19:38] <yofel> (except webkit maybe)
[19:38] <JontheEchidna> mostly
[19:38] <JontheEchidna> an easy example, kwin won't
[19:38] <yofel> because it uses gl?
[19:39] <JontheEchidna> anything using Qt3support still won't
[19:39] <yofel> ouch
[19:39] <doctorpepper> and 3D stuff  is expected  for 5.1 or 5.0.1
[19:39] <JontheEchidna> kwin because this: http://blog.martin-graesslin.com/blog/2012/12/the-road-towards-kwin-on-qt-5/
[19:39] <yofel> ah thx
[19:40] <JontheEchidna> I don't suspect that KDE will be built against Qt 5.x until KDE Frameworks 5 is out
[19:41] <JontheEchidna> here's some more stuff that has to be changed, in general: http://www.kdab.com/porting-from-qt-4-to-qt-5/
[19:46] <afiestas> JontheEchidna: Frameworks depend on at leat Qt 5.1
[19:47] <afiestas> I say at least because maybe somebody gets out of Qt 5.1 and we have to wait until 5.2
[21:02] <soee> hiho
[23:30] <Riddell> evening, what did I miss?
[23:37] <shadeslayer> not much I think
[23:39] <rbelem> hi Riddell :-)
[23:40] <rbelem> Riddell, all patches merged on icecc upstream
[23:40] <rbelem> Riddell, media.rbelem.info/icecc_0.9.98~git2012122001-0ubuntu1.debian.tar.gz http://media.rbelem.info/icecc_0.9.98~git2012122001.orig.tar.bz2
[23:40] <Riddell> groovy
[23:40] <rbelem> :-D
[23:45] <yofel> hm, which reminds me that I forgot to report icecc bugs
[23:45] <yofel> start-stop-daemon: unable to open pidfile '/var/run/icecc/iceccd.pid' for writing (No such file or directory)
[23:47] <rbelem> yofel, fixed :-)
[23:47] <yofel> great :)
[23:48] <rbelem> how do i submit these changes to debian?
[23:49] <shadeslayer> reportbug + patches?
[23:49] <rbelem> hum... how about utunubu?
[23:49] <shadeslayer> poke the person who last uploaded icecc?
[23:50] <shadeslayer> which would be you ....
[23:50] <shadeslayer> :P
[23:50] <rbelem> :-D
[23:50] <shadeslayer> imho you should have packaged 0.9.8 with proper patches in debian/patches
[23:51] <shadeslayer> unless the next version comes out before feature freeze
[23:54] <rbelem> shadeslayer, i think it will be ready before. i will poke upstream to make sure
[23:54] <shadeslayer> in which case ignore my comment :)
[23:55] <rbelem> shadeslayer, yesterday 0.9.97 was released two days ago iirc
[23:55] <shadeslayer> cool
[23:55] <rbelem> shadeslayer, soon we will have 1.0 :-)
[23:55] <shadeslayer> :D
[23:56] <rbelem> and with support to multiple compilers