[03:38] <Bonez> do any of you folks manage the actual ubuntu repositories?
[03:40] <sarnold> some people here are archive admins..
[03:42] <Bonez> i'm assuming ubuntu uses dak to manage its repositories?
[03:42] <StevenK> We do not.
[03:44] <pitti> Good morning
[03:44] <Bonez> well that sucks. thanks anyways then.
[03:44] <StevenK> ...
[03:49] <ion> … indeed
[07:10] <dholbach> good morning
[07:10] <didrocks> good morning Mr Holbach :)
[07:11] <dholbach> salut didrocks
[09:20] <doko> cjwatson, is there light at the end of the haskell tunnel?
[09:29] <ev> slangasek: due to a bug (https://bugs.launchpad.net/errors/+bug/1154189) I cannot see the graph for that bucket.
[09:30] <leagris> Hello
[09:30] <ev> I have a branch to fix the URL issue. Please feel free to file a bug for anything amiss you find in the data (http://launchpad.net/errors/+filebug)
[09:42] <cjwatson> doko: it's some way off yet, but I think so.  Definitely making progress
[09:45] <doko> jodh, should upstart-monitor be kept in main?
[09:46] <doko> Daviey, zul: should cinder-backup, python-pybabel, quantum-lbaas-agent quantum-plugin-midonet  be kept in main?
[09:47] <Daviey> doko: I believe so
[09:47] <doko> seb128, didrocks: should gwibber, gcalctool be kept in main?
[09:47] <doko> Daviey, could you seed these?
[09:47] <seb128> doko, no to both
[09:47] <jodh> doko: it's not essential, so maybe not. But would it be odd to have a single source package with binary packages in different repos?
[09:47] <seb128> doko, gcalctool is a dummy transitional package (got renamed gnome-calculator)
[09:48] <doko> jodh, it's your call
[09:48] <soren> jodh: No, that's not odd at all. It's quite common.
[09:49] <soren> jodh: So don't let that affect your decision.
[09:49] <Daviey> doko: ack
[09:49] <doko> cjwatson, should libdrm2-udeb be kept in main?
[09:50] <doko> seb128, can you help with account-plugin-icons?
[09:50] <seb128> doko, what about it?
[09:50] <doko> should it be kept in main?
[09:50] <jodh> doko/soren: I'm easy where it lives then :) It just ended up in main by default.
[09:51] <seb128> doko, probably not, it's a dummy transitional package
[09:51] <doko> seb128, ok, demoting
[09:51] <seb128> thanks
[09:51] <doko> jodh, could you seed it?
[09:51] <cjwatson> doko: No.  Moved to universe
[09:53] <cjwatson> seed upstart-monitor> I would suggest lp:~ubuntu-core-dev/ubuntu-seeds/platform.raring supported-sysadmin-common
[09:53] <cjwatson> Or perhaps supported-sysadmin-desktop since it includes GUI support
[09:54] <cjwatson> (Doesn't matter that much, it's support lifetime pedantry)
[09:55] <jodh> cjwatson: thanks
[09:55] <doko> seb128, should ubuntu-system-service be demoted?
[09:56] <doko> or maybe removed?
[10:01] <pitti> seb128: ^ is that actually completely replaced by other things? didn't that set the apt proxy in the past?
[10:03] <seb128> doko, pitti: no, it's still useful and should still be installed by default
[10:03] <seb128> let me find the right place to add back a depends/recommends
[10:03] <seb128> what pitti said
[10:03] <pitti> seb128: did we switch over to system-services now?
[10:04] <pitti> ah, so we did
[10:04] <seb128> pitti, we did, and I dropped the u-s-s systemd compat parts
[10:04] <seb128> but as you said it still does stuff useful for us
[10:04] <seb128> we didn't get to move those bits somewhere else yet
[10:05] <pitti> seb128: what's left except the apt proxy stuff?
[10:06] <seb128> pitti, some keyboard stuff
[10:06] <seb128> pitti, but I'm not sure where/if we still use that
[10:06] <pitti> isn't that being done by accountsservice now?
[10:07] <pitti> another instance where I'd love to have codesearch.ubuntu.com :)
[10:07] <seb128> pitti, is has "is_reboot_required" as well
[10:09] <seb128> pitti, yeah, would be useful to have a codesearch, I'm wondering if we have anything left using those inferfaces
[10:09] <pitti> seb128: I guess apt proxy is g-c-c ?
[10:09] <seb128> pitti, it was, but we didn't port that feature to the new network panel afaik
[10:09] <seb128> so I'm not even sure it's used atm
[10:09] <pitti> uh
[10:10] <pitti> gnome-control-center-3.6.3/debian/patches/50_ubuntu_systemwide_proxy.patch:+                                       "com.ubuntu.SystemService",
[10:11] <pitti> we still have that
[10:11] <pitti> apparently upstream doesn't have a system-wide proxy config
[10:11] <seb128> pitti, series: "#50_ubuntu_systemwide_proxy.patch needs-rewrite"
[10:12] <pitti> it's not used at all in software-properties
[10:12] <seb128> pitti, right, one of the blueprint mention that it's planned to add to n-m
[10:12] <pitti> so I suppose the keyboard stuff can go as well
[10:12] <seb128> pitti, what's the right thing to grep for? com.ubuntu.SystemService I guess?
[10:12] <pitti> update-notifier and software-properties also don't use u-s-s
[10:12] <seb128> pitti, I will ask jdstrand if he can archive grep for it
[10:12] <pitti> seb128: *nod*
[10:13] <seb128> jdstrand, hey, is there any chance you could archive grep for com.ubuntu.SystemService in raring?
[10:14] <seb128> pitti, the only match in my local packaging dir is g-c-c and the patch is commented of the serie
[10:14] <pitti> so I suppose there's no need to add a dependency right now
[10:14] <pitti> i. e. raring just can't set system-wide proxy with a GUI
[10:15] <seb128> right, we might want to try to fix that before release though
[10:15] <seb128> not sure how important the feature is
[10:25]  * xnox had multiple reports from people not managing to get proxy settings right globally. E.g. apt-get works, yet downloading flash in the flashplugin-installer times-out and doesn't have the right proxy settings =(
[10:25] <xnox> is_reboot_required - shouldn't that now be handled by the upstart file bridge? or do we need to enable user sessions as well (not enabled by default for raring) ?
[10:26] <seb128> xnox, well, that code gives a dbus interface to query to know if a reboot is required
[10:27] <seb128> not sure what uses it, seems like that should be an info available in aptd though
[10:27] <seb128> that's useful for e.g update-manager or the indicator-session to turn the icon red
[10:28] <xnox> seb128: /me thought that we emit a dbus broadcast event upon flaggin up "reboot required" for the indicators and the like. They don't poll the status.
[10:28] <xnox> oh, they might on startup/first login.
[10:28] <seb128> right
[10:29] <seb128> stuff like update-manager are not running all the time
[10:29] <xnox> seb128: we can totally add that dbus interface to upstart, which has everything on dbus already.
[10:29] <xnox> seb128: e.g. a file-bridge dbus interface to check reboot_required file, wherever that file is.
[10:30] <seb128> wouldn't it make sense to have that interface provided by aptd rather?
[10:30] <seb128> that seems like the appropriate service for package management related apis
[10:31] <pitti> seb128: preferably we don't want to trigger aptd on every boot each time, though
[10:31] <pitti> it's really heavy
[10:31] <seb128> that's a good point
[10:31] <pitti> programs could just look for the stamp file
[10:32] <pitti> this is all heavily ubuntu specific anyway, so if we hardcode the ubuntu specific path or the ubuntu specific dbus name doesn't make much of a difference from a maintenance POV
[10:32] <pitti> but a huge one for performance
[10:33] <pitti> the same is true for u-s-s, of course (being written in python)
[10:48] <vrodic> hey guys, i've just upgraded to 13.04 from 12.04, and now my single ext4 root filesystem doesn't unmount cleanly on reboot. a known bug?
[10:50] <xnox> pitti: looking at the code for bug 1103024 the __gsignal__ only specifies 3 parameters. Unless action-done is name clashing with some other "action-done" with 5 parameters?
[11:22] <OdyX> tkamppeter: build in the pipes
[11:50] <jdstrand> seb128: re archive grep> started
[11:51] <xnox> doko: some of the underlinking is reported during gtk-doc builds, which frankly we don't care about underlinking as it does build a scanner only to find relevant/wanted symbols.
[11:51] <xnox> can it be somehow disabled in gtk-doc?
[11:51] <seb128> jdstrand, hey, thanks!
[12:03] <tkamppeter> OdyX, OK. I am assuming that you are based on today's BZR commit (including the cups-browsed.postinst to overtake cupsd.conf entries).
[12:08] <jibel> jtaylor, I proposed a patch for bug 1164362, if it is accepted you can keep the versions in ipython's test control file.
[12:08] <jibel> jtaylor, just fix the deps for the test 'incomplete-install', there is a comma missing, and add python-lxml and python3-lxml to tools2 and tools3 dependencies respectively
[12:11] <OdyX> tkamppeter: saw them later on; yes.
[12:11] <OdyX> tkamppeter: uploaded to experimental right now.
[12:12] <tkamppeter> OdyX, thanks.
[12:13] <OdyX> tkamppeter: I have pushed my changes to the repository.
[12:16] <OdyX> tkamppeter: can you tag the repository for me. I'm done with fighting with bzr…
[12:35] <doko> xnox, sorry, failing to parse that ...
[12:36] <Mirv> didrocks: hi. upstream has approved my patch to Qt Creator fixing bug #1135336 , at  lp:~kubuntu-packagers/kubuntu-packaging/qtcreator
[12:36] <Mirv> if you're willing to sponsor
[12:37] <xnox> doko: https://launchpadlibrarian.net/136066048/buildlog_ubuntu-raring-i386.glade-3_3.8.0-0ubuntu5_FAILEDTOBUILD.txt.gz fails during scanning docs. Can that "undefined reference to symbol" be optional at gtk-doc stage?
[12:37] <didrocks> Mirv: oh, excellent news! do you mind summing that up for me on how this is fixed?
[12:37] <didrocks> Mirv: like, I never lauchad qtcreator and installed qt4-qmake
[12:37] <didrocks> what happens? :)
[12:38] <Mirv> didrocks: it configures the Qt for you that is the default (Qt 5 in case of qt5-default)
[12:38] <didrocks> Mirv: the fact to prefer qmake will should both qt5 and qt4 projects?
[12:39] <didrocks> s/should/show/
[12:39] <didrocks> in the new project window?
[12:40] <Mirv> didrocks: it will show both qt quick 1 and quick 2, if that's the question, yes
[12:40] <Mirv> (Qt 5 supports qt quick 1 as well)
[12:40] <didrocks> Mirv: exactly, thanks! :)
[12:40] <didrocks> ah, that was what I meant, didn't realize the qt quick1 was coming from qt5
[12:40] <didrocks> but yeah, makes sense
[12:40] <didrocks> Mirv: building and sponsoring :)
[12:40] <doko> xnox, I don't think so. so is this gtk-doc which needs the fix? apparently something is linked during the doc build
[12:40] <doko> seb128, ^^^
[12:41] <seb128> no idea about gtk-doc
[12:41] <Mirv> didrocks: Qt Quick of Qt 4 was renamed to Qt Quick 1 when Qt 5 / Qt Quick 2 came out
[12:41] <didrocks> Mirv: right right, I just didn't think about it when looking at the dialog that even qt quick 1 was indeed still coming from qt5 ;)
[12:41] <didrocks> Mirv: nice work, the patch makes sense :)
[12:42] <Mirv> thanks. nice that upstream agreed, I was wondering if they had some other logic on mind.
[12:42] <didrocks> Mirv: yeah, it seems too obvious and tricky. Great that you get them reviewed first, I was afraid of side-effects :)
[12:43] <xnox> doko: so to generate gobject like API docs, a scanner is compiled and linked against a library one have just built. And like a lot of ugly things, it only links that .so and nothing else. As well frankly it doesn't care about linking in the dependencies.
[12:44] <xnox> doko: anyway I uploaded a fix in glade-3, but I wonder how many more of "failed to build gtk api docs" we have in that test rebuild.
[12:45] <doko> xnox, seb128: well, you could patch gtk-doc to explicitly pass --copy-dt-needed-entries
[12:45] <doko> -Wl,--copy-dt-needed-entries
[12:46] <xnox> doko: nice. well just patch the gtk-doc included makefile snippet to do that in the correct target.
[12:46] <xnox> (that snippet is used by all gtk-doc packages, as that's the way to build gtk-docs)
[12:46] <xnox> via include.
[12:50] <doko> lamont, do you have a complete log for bug 1157687?
[12:59] <doko> jibel, did you see this upgrade issue? ^^^ (or aren't you involved anymore with upgrade testing?)
[13:02] <jibel> doko, psivaa and plars are doing upgrade testing now. psivaa plars did you see this issue^
[13:03] <lamont> doko: looking
[13:05] <psivaa> jibel: no i did not see this issue, i normally update quantal before upgrading to raring and not sure if thats the reason why we do not see that.
[13:07] <doko> xnox, are you working on the gtk-doc patch?
[13:08] <ev> @pilot in
[13:11] <xnox> doko: well back from lunch. Will quickly check how many other things failed at gtk-doc, and whether it's worthwhile to do in gtk-doc.,
[13:32] <tkamppeter> OdyX, why have you added your own init script for cups-browsed? there is an upstream one in utils/cups-browsed.in.
[13:36] <plars> jibel, psivaa: no doesn't look like anything I saw either
[13:36] <xnox> doko: couldn't find another instance so far.
[13:36] <nigelb> pitti: Do you know if/when there will be an update for postgres in the ubuntu repos for today's sec release?
[13:36] <xnox> nigelb: > #ubuntu-hardened maybe?
[13:37] <xnox> for security team.
[13:37] <nigelb> xnox: Aha, thanks!
[13:37] <plars> jibel, psivaa: only thing I had problems with was compiz (shocker!) :)
[13:37] <pitti> nigelb: way ahead of you :)
[13:37] <nigelb> pitti: already building?
[13:37] <pitti> nigelb: it was built two days ago, mdeslaur is pushing out the announcements and packages right now
[13:37] <nigelb> or already *built*
[13:37] <nigelb> hah!
[13:37] <nigelb> Good job you guys! :)
[13:38] <pitti> nigelb: upstream, debian security, ubuntu security and me are currently doing live coordination
[13:38]  * pitti currently feeding his backport PPA
[13:38] <nigelb> \o/
[13:41] <pmcgowan> jdstrand: re the app launcher how is the app actually invoked such that this launcher is used
[13:41] <tvoss> pmcgowan, the shell needs to make sure that the launcher is invoked as I understand it
[13:42] <barry> doko: are you going to give back pycurl?
[13:42] <jdstrand> pmcgowan: that is TBD. we are going to write a prototype that is just an executable that can do 'applaunch /opt/../bin/foo' (or something)
[13:42] <jdstrand> pmcgowan: but we figured this would be more closely integrated with Unity
[13:43] <pmcgowan> ok makes sense
[13:43] <jdstrand> pmcgowan: hence the 'handoff' portion
[13:43] <pitti> oh dear, the PPA autobuilders are totally blocked at a bad time
[13:43] <cjwatson> pitti: asking for score bumps would be justified
[13:43] <ricmm_> jdstrand: is the invocation just a middle-exec ?
[13:43] <pitti> cjwatson: I did bump them (psql security updates)
[13:43] <tvoss> jdstrand, is there a work item for the apparmor definition step (leaving aside how to do it)?
[13:44] <ricmm_> or is it a service that exposes an API
[13:45] <jdstrand> tvoss: in that same blueprint, there is work for the apparmor definition. next month (iirc) we start looking at making it integrate with the SDK
[13:45] <tvoss> jdstrand, cool
[13:46] <OdyX> tkamppeter: which is too generic as far as I'm concerned. Also $cups and $alioth don't work.
[13:46] <tvoss> jdstrand, we were initially thinking about an executor approach that allows for more fine-grained entry points to an application than just int main(...)
[13:46] <jdstrand> ricmm: my team is concerned really on with making sure the sandbox is setup properly. I think the Unity team is in the best position to define (with our review) how to execute a sandboxed app
[13:46] <ricmm> I mean in terms of the launcher, just wondering what your planned implementation for it is in terms of consumers
[13:46] <mitya57> pitti: hi, did you see debian bug 700838? do you want me to write a patch for it? :)
[13:46] <ricmm> not just the definition of the sandbox itself
[13:46] <pitti> mitya57: oh, please
[13:47] <mitya57> ok
[13:47] <ricmm> or maybe I'm reading this wrong and the launcher is actually a work item on someone elses plate, to match your sandbox definition
[13:47] <jdstrand> tvoss: sure. do you have existing code for this?
[13:47] <OdyX> tkamppeter: also, it would be ideal if cups-browsed could 1) fork itself; 2) write its pidfile somewhere on his own.
[13:48] <tvoss> jdstrand, nope, it was more an initial idea that would allow us to offer test executors and the like
[13:48] <jdstrand> ricmm: well that's just it. we don't have a planned implementation for consumers. we have a plan for the sandbox setup. we want to plugin to your (I'm assuming you are on the Unity team) plan for executing things
[13:49] <tvoss> jdstrand, however, people vetoed the idea for multiple reasons, among them the lack of protection of the executor, and the argument that not every app will be an executable/shared library
[13:49] <jdstrand> which is why we are just doing a super simple prototype at first
[13:50] <jdstrand> tvoss: I'm not sure I understand that comment. can you rephrase? for an app to be confined properly, it needs to have its own pid for attachment such that we can attach a profile to it for that application
[13:51] <jdstrand> ie, multiple tabs for different HTML5 apps won't do
[13:51] <jdstrand> s/ie/eg/
[13:51] <tvoss> jdstrand, okay, the idea was that the executor is an executable that loads an app from a shared-object by resolving some pre-defined entry points, obviously, we could run the executor in your sandboxed env
[13:51] <jdstrand> (well, unless each tab is a separate process-- it gets slightly more complicated there, but it is technically doiable)
[13:53] <jdstrand> tvoss: this executor you refer to-- is that for the entire supported set of apps? (HTML5, QML, etc)
[13:53] <tvoss> jdstrand, yup, that was the idea, although we didn't explore it any deeper tbh
[13:53] <mitya57> pitti: unrar in dfsg tarball?
[13:54] <jdstrand> tvoss: ok, so your executor could be our app launcher (ie, we plugin to it to setup the sandboxed env)
[13:55] <jdstrand> tvoss: we have the aa_change_profile() library call that we can use in the executor to change into the apparmor profile at an appropriate time (eg, just before fork())
[13:55] <tvoss> jdstrand, interesting .. perhaps we stick to your first cut of main as an entry point and see how we can evolve things over time?
[13:57] <jdstrand> tvoss: I'm fine with proceeding how it makes sense. the prototype we want to have is really about showing how to setup the sandbox. that code can be pulled in to Unity in your executor or in some other fashion however it works best for Unity
[13:57] <ScottK> pitti: If you have postgresql-9.1 ready for raring, go ahead and upload (or when you do).  I'm happy to go ahead and accept it, freeze or no.
[13:57] <tvoss> jdstrand, cool :) that sounds like a really good idea
[13:58] <pitti> ScottK: ah, can do; I was going to sync it in about two hours or so, as dinstall is just running
[13:58] <tvoss> jdstrand, can you point ricmm and me to the branch (under the assumption there is one already?)
[13:58] <lool> tvoss: It seems practical to me to combine default handlers and apparmor setup in the same wrapper
[13:58] <ScottK> pitti: OK.  That should be fine.
[13:58] <pitti> ScottK: but I can upload a fakesync now of course
[13:58] <lool> tvoss: e.g. empty event handlers if the shared object doesn't provide this or that callback
[13:58] <pmcgowan> tvoss: does this have any impact on making a qmlscene replacement for qml apps?
[13:59] <jdstrand> tvoss: cool :) so, we'd like to watch the executor work (coordinate, review, get involved), so if that is turning up on BPs, can you ping me and sbeattie (sbeattie will be working on the launcher)
[13:59] <pitti> ScottK: I'm going to do just that; let's cover all our bases
[13:59] <ScottK> pitti: I'll trust you assessment of the urgency.  I mostly wanted to make sure you weren't waiting on beta 2 to release.
[13:59] <lool> pmcgowan: We need one to set some env vars in any case
[13:59] <ScottK> OK
[13:59] <lool> albeit I'm not we have a list
[13:59] <lool> *sure
[13:59] <jdstrand> tvoss: there is not one already
[13:59] <tvoss> pmcgowan, totally not
[13:59] <pmcgowan> vg
[13:59] <tvoss> pmcgowan, think about it like a helper that just bootstraps a sandboxed env
[13:59] <jdstrand> sbeattie: ^ when you have something, can you point to tvoss and ricmm
[13:59] <ricmm> jdstrand: tvoss lets entwine our names in single blueprint that contains the launcher/apparmor and executor story
[13:59] <ricmm> from the point of view of the extended app lifecycle
[14:00] <ricmm> not just shell->desktop
[14:00] <tvoss> ricmm, +1
[14:00] <pitti> ScottK: oh, it's a merge anyway, darn; I didn't notice that we got ubuntu changes; uploading
[14:00] <ScottK> Great.  Thanks.
[14:00] <jdstrand> ricmm: sure, we can move our prototype work items over to you-- we just did it where we did since we don't have anything yet :)
[14:00] <ricmm> jdstrand: can we maybe have a call to explain how our lifecycle works right now? theres one thing that I deem important for this apparmor story and that is the resuming of previously-running applications after a power cycle and so on
[14:01] <ricmm> we need to retore certain things, so all in all restore the sandbox... etc
[14:01] <ricmm> anyways, would be cool to have a voice call about it as sometimes chat can be slow
[14:01] <ricmm> jdstrand: no I'm fine with confinement being handled by your team, I find it awesome
[14:01] <tvoss> ricmm, do you think the app lifecycle bp makes sense?
[14:01] <ricmm> great work indeed
[14:01] <ricmm> tvoss: yes
[14:02] <jdstrand> ricmm: there shouldn't really be any concerns there-- apparmor policy is loaded into the kernel. any env variables are in memory and other stuff is filesystem, so a suspend/resume shouldn't need any particular attention
[14:02] <jdstrand> ricmm: but maybe I misunderstand your question
[14:02] <ricmm> jdstrand: this is a power cycle scenario, apps exit memory
[14:02] <ricmm> and we restore from saved states
[14:02] <ricmm> I'd like to discuss the security concerns about it
[14:02] <ricmm> and update our lifecycle drafts
[14:03] <jdstrand> ricmm: ok, please ask mdeslaur and jjohansen to attend the meeting
[14:03] <jdstrand> (I can also be there)
[14:03] <jdstrand> (mdeslaur is my techlead and jjohansen the apparmor lead)
[14:03] <ricmm> awesome, thanks
[14:03] <pitti> ScottK: uploaded
[14:03] <ricmm> tvoss: jdstrand any date preference?
[14:04] <tvoss> ricmm, not on a weekend :)
[14:05] <ricmm> jdstrand: is there a blueprint for your work somewhere?
[14:05] <ricmm> so we can kind of bridge between our relevant ones and add them to the call
[14:06] <jdstrand> ricmm: this particular work item is in https://blueprints.launchpad.net/ubuntu/+spec/security-1304-appisolation-example
[14:06] <ricmm> thanks
[14:06] <ScottK> pitti: Thanks.  Accepted.
[14:07] <pitti> infinity, Daviey: ^ if you need to rebuild the server ISOs for beta 2 for some reason, including postgresql-9.1 9.1.9 would be a very good idea; I'll warn about this in my blog post
[14:13] <jdstrand> ricmm: re date preference> none on my end other than what tvoss said :)
[14:40] <dholbach> didrocks, ready? :)
[14:40] <didrocks> dholbach: seems that rickspencer3 abandonned my hangout, so yeah ;)
[14:40] <rickspencer3> hi didrocks
[14:40] <rickspencer3> sorry
[14:40] <rickspencer3> otp
[14:40] <rickspencer3> :/
[14:41] <didrocks> no worry rickspencer3 :)
[14:41] <dholbach> didrocks, we still have 20m - it's all good :)
[15:24] <BigWhale> Greetings.
[15:28] <BigWhale> ev: I was tolk I could bug you for an upload... :)
[15:30] <ev> BigWhale: sure
[15:30] <ev> well, depends on what you want to upload :)
[15:32] <BigWhale> ev: a new release of Kazam. This one, to be more preceise: https://launchpad.net/kazam/stable/1.4.2
[15:32] <BigWhale> 1.4.1 is already in raring, this is just a minor bugfix release.
[15:33]  * ev looks
[15:36] <pitti> xnox: I'll look at that tomorrow; too much psql troubles this afternoon
[15:39] <tkamppeter> OdyX, I had to release cups-filters 1.0.33, there was a NULL check needed. I have updated also the BZR for Debian.
[15:40] <ev> BigWhale: is there a bug for this?
[15:41] <xnox> pitti: ack.
[15:42] <BigWhale> ev: yes, there were two...
[15:43] <BigWhale> They were targeted
[15:43] <ev> BigWhale: numbers please :)
[15:44] <BigWhale> #1100626 #1085438
[15:45] <ev> BigWhale: ah, I meant targeted against the Ubuntu source package
[15:45] <ev> for the upload
[15:45] <ev> since it will require freeze exceptions
[15:45] <ev> BigWhale: see: https://wiki.ubuntu.com/FreezeExceptionProcess
[15:46] <BigWhale> Oh, none of them are.
[15:48] <ev> BigWhale: would you mind creating one http://launchpad.net/ubuntu/+source/kazam/+filebug that requests the new version?
[15:49] <ev> I'll then attach the debdiff to that
[15:51] <BigWhale> ev: https://bugs.launchpad.net/ubuntu/+source/kazam/+bug/1164584
[15:52] <ev> thanks!
[15:52]  * ev moves quick in his remaining 10% of battery
[15:52] <BigWhale> Oh, thank you. :)
[15:52] <ev> on*
[15:59] <ev> BigWhale: I've updated the bug with the debdiff and some follow-up instructions
[16:00] <BigWhale> ev: great, thanks!
[16:00] <ev> once you have approval from the release team, let whomever is patch piloting know and they can shepherd the upload through
[16:00] <ev> good luck! :)
[16:03] <ev> @pilot out
[16:05] <BigWhale> I just subscribed to a bunch of mailing lists... :>
[16:15] <mdeslaur> ricmm: whoops, just got your invite...
[16:15] <mdeslaur> ricmm: are you rescheduling it?
[16:32] <OdyX> tkamppeter: ah, great, thanks.
[16:40] <ricmm> mdeslaur: yes, rescheduling
[17:05] <roadmr> Hey folks! I'm backporting a couple of python packages, A depends on B. I successfully backported B, but since it's only available in a PPA, I'm wondering how to indicate that the build for A should use that PPA to install B as a build-depends
[17:15] <xnox> roadmr: > better ask similar questions on #ubuntu-packaginging. But simply uploading into the same ppa will use depends from that ppa during build.
[17:15] <xnox> roadmr: well "biggest version wins", so packageB in ppa should be >> version number than in ubuntu archive proper.
[17:16] <roadmr> xnox: oh perfect! thanks! and OK, I'll ask there next time, didn't know that channel existed :)
[17:25] <zyga> hey
[17:25] <zyga> xnox: so let's talk about command-not-found here
[17:25] <xnox> zyga: \o/
[17:25] <zyga> xnox: so there are a few pieces
[17:25] <zyga> xnox: how to rebuild the data
[17:25] <zyga> xnox: when to rebuild it
[17:25] <zyga> xnox: when it should be documented
[17:25] <zyga> xnox: er, where
 Hey folks! I'm backporting a couple of python packages, A depends on B. I successfully backported B, but si
[17:25] <zyga> xnox: and where it should be running
[17:26] <xnox> https://wiki.ubuntu.com/CommandNotFoundMagic
[17:26] <zyga> xnox: that's the original spec IIRC
[17:26] <xnox> with some *.pl URLs =))) ;-)
[17:26] <xnox> both are 404 though.
[17:35] <zyga> re
[17:35] <zyga> sorry
[17:35] <zyga> xnox: haah, I guess that's suxx.pl
[17:36] <zyga> xnox: sorry, need to move networks, brb
[17:36] <zyga_> re
[17:37] <zyga_> xnox: so let me see that page again
[17:37] <zyga_> xnox: so the code is on launchpad which mirros github (or should, I'll update that)
[17:37] <zyga_> xnox: the code is on github.com/zyga/command-not-found
[17:37] <zyga_> xnox: inside the code there are a bunch of readme files
[17:37] <zyga_> xnox: I should probably update the layout a bit to look less sucky
[17:40] <zyga_> xnox: what do you expect in terms of automation
[17:41] <xnox> zyga_: at the moment, all I want is to run and update command-not-found-data.
[17:41] <xnox> zyga_: later i want instructions on a wiki page how to do that.
[17:42] <zyga_> xnox: ok
[17:42] <zyga_> xnox: so assuming you have the archive
[17:42] <zyga_> xnox: you need to look at https://github.com/zyga/command-not-found/tree/master/UnifiedDataExtractor
[17:42] <zyga_> xnox: and run ...
[17:43] <zyga_> xnox: probably create-binary-database
[17:43] <zyga_> xnox: let me check that in practice
[17:48] <zyga> xnox: heh, it's been a while, let me do some basic cleanups to use it
[17:49] <mitya57> pitti: I have a huge patch for you @ lp:~mitya57/debian/sid/calibre/remove-embedded-libraries
[17:49] <mitya57> it removes bundled copies of mathjax, python-markdown and unrar
[17:49] <mitya57> and also fixes some minor issues such as not working clean target
[17:50] <mitya57> known issues: (1) it still has embedded jQuery
[17:50] <mitya57> (2) it tries to write to /usr/share/applications/defaults.list during build
[17:51] <mitya57> (3) the mime file is not installed
[17:51] <mitya57> none of these seems to be caused by my changes though :)
[17:52]  * zyga cannot believe how crappy was his code just 8 years ago
[17:52] <xnox> zyga: to be honest python2.4 was a different kind of animal.
[17:52] <mitya57> note that embedded unrar is a "Severity: serious" bug, but it doesn't affect wheezy
[17:56] <zyga> xnox: yeah but so were my python skills back then I guess :)
[17:57] <zyga> xnox: I think this was my first python program as well
[17:57] <zyga> xnox: and preinstalled on ubuntu, how cool is that :)
[17:57] <zyga> xnox: I didn't stress that much back then
[17:58] <zyga> xnox: the first commit is from 2006 though, I guess it's an import from something other than bzr, probably darcs
[18:00] <zyga> xnox: ok, so to run it
[18:00] <zyga> xnox: you need to run the scan script on the archive
[18:00] <zyga> xnox: basically on any debs you may have around
[18:01] <zyga> xnox: I've pushed a cleanup branch to git://github.com/zyga/command-not-found
[18:01] <zyga> xnox: I'll make usability nice
[18:01] <zyga> (enough)
[18:01] <zyga> xnox: do you think this should be a native package?
[18:02] <zyga> omg
[18:02] <zyga> whoever ran this
[18:02] <zyga> scan is still using /usr/bin/env python2.4
[18:02] <zyga> :DDD
[18:03] <roadmr> haha :)
[18:05] <zyga> well, it probably runs on some arcane 10.04 systen
[18:05] <zyga> system
[18:05] <zyga> does 10.04 have python2.4?
[18:05] <zyga> xnox: perhaps there is a branch that is used by cannonical that is not in trunk somewhere?
[18:06] <maxb> Even 8.04 had python 2.5
[18:07] <zyga> wooow
[18:07] <zyga> I wonder when I really wrote that
[18:07] <zyga> did 4.04 had python2.4?
[18:07] <zyga> (times when python2.4 was new, OMG :)
[18:08] <zyga> plars: hey
[18:08] <zyga> roadmr: I kept making logging.debug("..." % (...)) mistakes back then :)
[18:08] <roadmr> zyga: haha well the old you didn't have the present you to help with that ;)
[18:09] <zyga> haha
[18:10] <zyga> roadmr: anyway, even today, the code that implements get_alternatives in both crazy and amazing https://github.com/zyga/command-not-found/blob/master/UnifiedDataExtractor/scan#L41
[18:10] <zyga> roadmr: it actually tries to interpolate for loops and keep track of shell variable values
[18:10] <roadmr> wow! reading
[18:10] <zyga> roadmr: it's not even close to correct but it improves results from 0% to something rather large
[18:11] <zyga> roadmr: I don't have the raw data to compare but when I wrote that, cnf is only usable with that hack
[18:11] <zyga> without it most of the things that people mistype/don't have around is not found as it is actually installed via alternatives system
[18:13] <zyga> well
[18:13] <zyga> back then mirroring the archive was hard
[18:13] <zyga> I remember it filled my _spare_ disk
[18:13] <zyga> and I took a week to download all the packages
[18:14] <zyga> I guess I can start the mirror now, put my kids to bed and have the full archive after that
[18:14] <dobey> it was a different time, before fiber was available everywhere
[18:22] <zyga> dobey: yeah
[18:22] <zyga> dobey: note: I'm still on ADSL, no fiber around where I live
[18:22] <zyga> dobey: but it's 25MBit, not 0.1
[18:23] <roadmr> wow heh
[18:25] <zyga> I guess I can make it a bit better now
[18:26] <zyga> like scanning partner repo
[18:26] <zyga> and getting skype :)
[18:26] <zyga> and scanning arm
[18:26] <zyga> wow
[18:26] <zyga> that's really old stuff there
[18:26] <zyga> xnox: I'll get you the data for raring in a few hours
[18:26] <zyga> xnox: what's the total deadline for this?
[18:28] <xnox> zyga: between now and 18th of April.
[18:28] <xnox> the updated command-not-found should be uploaded.
[18:29] <jdstrand> ricmm: hey, I'd like to attend the meeting you scheduled for tomorrow, but I have a conflict. it is possible to move it a half an hour earlier?
[18:29] <jdstrand> s/it is/is it/
[18:30] <zyga> xnox: ok
[18:31] <zyga> xnox: while I'll clean the code a bit we can just upload the data file
[18:32] <zyga> xnox: do you know where are the armhf files in the archive?
[18:32] <zyga> xnox: http://archive.ubuntu.com/ubuntu/dists/raring/ looking there I can only see i386 and amd64
[18:33] <sarnold> zyga: ports
[18:34] <sarnold> zyga: http://ports.ubuntu.com/dists/<release>/main/
[18:34] <zyga> ah
[18:34] <zyga> ok
[18:34] <sarnold> zyga: https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
[18:34] <zyga> thanks
[18:34] <mitya57> pitti: filed a MP (https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195), have to go now
[18:36]  * zyga starts mirroring the archive, I'll be back later when that is finished
[19:37] <t1mp> rickspencer3_: ping
[20:50] <zyga> xnox: ping
[20:51] <zyga> xnox: quick question, let's say I'm going to build a manually-verified database that annotates _all_ ubuntu packages with the update-alternative targets that each particular package might or does use; I could then automatically annotate the control files of all of those source packages with the appropriate meta-data, could we then merge this (big) delta back into debian so that we don't have to maintain it and so that command-not-found gets reliable, perfect 
[20:52] <zyga> slangasek: ^^ (maybe you can also say how crazy I am :)
[20:53] <zyga> xnox: I'll start with a standalone database (text, editable) that keeps each package-version -> mapping of update-alternatives used in version control
[20:53] <zyga> xnox: then try to get the latest version of all those packages in source form, patch the control file, generate a diff from that
[20:53] <zyga> xnox: do you think that's the right approch to getting that information back to debian?
[20:55] <xnox> zyga: I'm slightly confused by above. In general we already have debtags on debian side for "annotating" packages. As all of this data gets volatile very quickly.
[20:56] <zyga> xnox: could you quickly describe those debtags?
[20:56] <zyga> xnox: are they in the source package or somewhere on the side?
[20:56] <zyga> xnox: (I remember this discussion years ago, I remember someone said 'ah yes, debtags can solve that', but debtags were still under discussion back then)
[20:57] <zyga> xnox: my goal is to have _reliable_ meta-data as to what update-alternatives targets each package uses
[20:57] <zyga> xnox: that data is required for command-not-found
[20:57] <xnox> zyga: the general ideas about such things tends to end up in "AppStream" proposals (multiple incompatible with same name but different implementations) such that package self annotate a bit, but archive publishing software (dak in debian, launchpad in ubuntu) further scans source/binary packages and publishes one co-herent all-purpose index.
[20:57] <zyga> xnox: instead of mainitaining this data separately I'd like to get it back to debian
[20:57] <xnox> neither of which are at a usable state at the moment.
[20:57] <xnox> zyga: http://debtags.debian.net/search/?q=game
[20:58] <zyga> xnox: this cannot be automated
[20:58] <zyga> xnox: it's the same kind of data as Depends or Build-Depends
[20:58] <xnox> zyga: sure. with AppStream proposal parts that cannot be automated live inside the package (source or binary as appropriate) other parts which can be automated live in archive software which merges the two together.
[20:59] <zyga> xnox: I see that, quickly and ugily as X-Update-Alternatives-Targets: /usr/bin/vim.real=/usr/bin/vim
[20:59] <zyga> xnox: so I don't care about the automated part simply because it's not automated in any way at all
[20:59] <zyga> xnox: how does one express the non-automated variant of that in the control file?
[21:00] <xnox> zyga: the beauty of update-alternatives is that we have packages from 3rd parties hooking into that, e.g. like google-chrome web-browser and packages comming from outside of the archive (e.g. things like extra/new versions of emacs, postgresql etc)
[21:00] <zyga> xnox: great
[21:00] <zyga> xnox: so what?
[21:01] <zyga> xnox: for high-profile packages we can keep side-data in command-not-found itself
[21:01] <zyga> xnox: for the archive, I'd like to keep this _in_ the archive, otherwise it's something that's forever broken
[21:02] <zyga> xnox: it's something that packages would have to maintain
[21:02] <zyga> xnox: the benefit is accurate hit database from commmand-not-found
[21:02] <zyga> xnox: hint
[21:03] <zyga> xnox: I'm willing to do the initial scan myself, manually
[21:03] <xnox> zyga: i think packages will ok self declaring "i update-alternative emacs with vim.real binary I provide", and then one can quickly scan and collate all those that declare "i update-alternative emacs"
[21:03] <zyga> xnox: I'm just looking for a way to contribute this back
[21:04] <zyga> xnox: packages or packages?
[21:05] <xnox> zyga: it's best to raise that on debian-devel with a sample scan results & carefully explaining what you are trying to achieve. Prepare for a flamewar of being shot down with "apt-archive Package index is too big already" and "we don't need this" and "one day when dak supports this we may consider it"
[21:05] <xnox> zyga: but hey maybe there are other people who where looking to achieve this as well.
[21:05] <zyga> xnox: the last item is exactly what I want to avoid
[21:06] <xnox> zyga: plan your email well =)
[21:06] <zyga> xnox: I want to get this done done for ubuntu
[21:06] <zyga> xnox: getting this to debian is a bonus
[21:06] <zyga> xnox: sure
[21:06] <xnox> zyga: ubuntu-devel then =)
[21:06] <zyga> xnox: I'll get the initial database today/tomorrow
[21:06] <zyga> xnox: do you think I should discuss this in ubuntu over debian first?
[21:07] <zyga> xnox: given my history of collaboration with debian, I'd rather not start wrong again
[21:08] <xnox> zyga: the amount of overlap between the two mailing list is ever increasing =) no harm imho to start it on either lists & bounce to the other mailing list after initial rough corners are considered.
[21:09] <zyga> ok
[21:11] <zyga> xnox: I'll start with ubuntu-devel to get the c-n-f goal done
[21:29] <ausxxh_> ubuntu/debian defaults to IET while Redhat defaults TGT, openstack/cinder now defaults to TGT due to ubuntu's efforts, confused
[21:32] <rickspencer3> t1mp, hi
[21:41] <t1mp> rickspencer3: hi, I saw your bug report https://bugs.launchpad.net/ubuntu-qtcreator-plugins/+bug/1161910 and created an MR that should fix it.
[21:41] <t1mp> rickspencer3: it is eod for me, but feel free to try out my changes and comment on the MR
[21:41] <rickspencer3> thanks t1mp, let me know if you want me to test it in some way
[21:42] <rickspencer3> t1mp, will do
[21:43] <t1mp> rickspencer3: thanks. You didn't include code with the bug, but if there is still some weird positioning happening, make sure that you do not set the anchors of the Page (that should be automatic)
[21:43] <rickspencer3> t1mp, well, it was a defualt app
[21:44] <rickspencer3> so, it should be easy for me to test it out
[21:44] <doko> ogasawara, the gcc-4.7.3 release candidate is currently building in raring. the version is now set to 4.7.3, just in case that you still depend on that
[21:49] <doko> jtaylor, why the syncs of the new java lib packages?
[21:49] <jtaylor> doko: bugfix releases
[21:50] <doko> 1.1.0?
[21:50] <jtaylor> yes I was confused to
[21:50] <jtaylor> but the changes lists only bugfixes, diff is also small
[21:51] <jtaylor> I was asked by the debian maintainer to sync them