[01:49] <DiegoTc> hi
[01:49] <DiegoTc> Is someone available right now?
[01:57]  * mhall119 is available but not a motu
[02:26] <nigelb> !ask | didrocks
[02:26] <nigelb> ugh!
[02:26] <nigelb> !ask | DiegoTc
[02:29] <wrapster>  in the postinst script i cannot execute how do i execute shell commands?coz one in particular called 'update-ca-certificates' fails if written inside the postinst scrip
[02:30] <wrapster> but anywhere else if i write its working fine.
[02:30] <wrapster> http://pastie.org/900511
[02:33] <sistpoty> wrapster: got the package a depends on ca-certificates?
[02:55] <wrapster> sistpoty: one sec let me see
[02:57] <wrapster> yes there are quite a few pkgs that depened on ca-certificates
[02:58] <wrapster> sistpoty: but why is that important?
[02:59] <sistpoty> wrapster: if the packages uses a command found in ca-certificates (i.e. update-ca-certificates), it needs to have the package providing the command installed prior to it
[02:59] <wrapster> sistpoty: apt-get install ca-certificates is giving me this error http://pastie.org/903294
[03:00] <wrapster> hmm.. ok let me verify that .. one sec pls.
[03:00] <wrapster> sistpoty: yes that pkg is already installed.
[03:02] <sistpoty> wrapster: then, s.th. went wrong? not too sure how to debug that in the first place, I guess running the commands of the postinst by hand could shed further lights
[03:02] <sistpoty> s/lights/light/
[03:04] <wrapster> sistpoty: yes i kinda did that and was able to see that the shell command here ' http://pastie.org/900511 ' that is update-ca-certificates is the probelm.. I was able to deduce so by actually removing that line from the postinst script .. then the pkg was installed cleanly. so its definitely the case with this cmd.
[03:04] <sistpoty> wrapster: did you check what went wrong with that command yet?
[03:05] <wrapster> sistpoty: i cannot find that out.. coz i ran the cmd independently and it works fine.
[03:05] <wrapster> its only within the script.
[03:06] <wrapster> and secondly 'update-ca-certificates' binary comes from 'ca-certificates' pkg .. and this pkg's postinst script itself is calling the update-ca-certificate cmd ... Will this cmd be initialized by the time postinst is run?
[03:06] <wrapster> could that be the reason?
[03:08] <sistpoty> wrapster: there's no state of initialized/uninitialized for a *command*, however the command might need data provided by a package
[03:08] <wrapster> hmm..
[03:08] <wrapster> but i see it working on a lot of debian machines already.
[03:09] <wrapster> my own ubunutu has it working.
[03:09] <wrapster> this pkg working.. its on another machine im trying to install this and its failing.
[03:09] <sistpoty> wrapster: just a wild guess, but maybe update-ca-certificates checks some data and fails if e.g. a certificate is not in the right format?
[03:10] <wrapster> hmm.. let me check that..
[03:10] <wrapster> thanks..
[03:10] <sistpoty> yw
[03:40] <DiegoTc> I got this erro https://wiki.ubuntu.com/PackagingGuide/Complete when I  am doing the debuild command
[03:40] <DiegoTc> I am really lost here :S
[03:40] <ScottK> What error?
[03:42] <DiegoTc> Scottk this one http://pastebin.com/qSuibTZR
[03:43] <DiegoTc> sorry i got confuse of link
[03:43] <ScottK> No problem.  Looking
[03:45] <ScottK> DiegoTc: Does your package build-depend on qmake?
[03:45] <DiegoTc> Scottk yes it does, its a small app I did using QT4c++
[03:45] <ScottK> Is qmake installed?
[03:46] <ScottK> What is "No hay ninguna regla para construir el objetivo" in English?
[03:47] <DiegoTc> "there is no any rule for building the objective"
[03:47] <DiegoTc> Scottk I suppose its build because I am compiling it on my computer right now
[03:48] <ScottK> I'm not sure exactly what the problem is.
[03:49] <DiegoTc> :S
[03:49] <ScottK> What happens if you run make -f debian/rules clean from the source directory of your package?
[03:50] <DiegoTc> ScottK, you mean to do this  make -f debian/rules
[03:50] <ScottK> DiegoTc: Close.
[03:50] <ScottK> make -f debian/rules clean
[03:50] <ScottK> That should just run the clean rule.
[03:51] <ScottK> Which is where the error you showed me was.
[03:53] <DiegoTc> ScottK,  HERE http://pastebin.com/hhbWMJWn
[03:53] <DiegoTc> i put the translation down
[03:54] <ScottK> Right.
[03:54] <ScottK> So I guess there is some qmake problem here.
[03:54] <ScottK> Unfortunately it's not something I know about.
[03:56] <DiegoTc> ScottK, so what you will recommend me ??
[03:57] <ScottK> Figure out why you don't have the Makefile parts that qmake is saying are needed.  I have no idea what those are.
[03:57] <ScottK> Sorry I can't be more help.
[03:58] <DiegoTc> thanks
[04:16] <DiegoTc> ScottK,
[04:17] <DiegoTc> ScottK, I found this link http://pkg-perl.alioth.debian.org/debhelper.html#module__build__compat
[04:17] <DiegoTc> and i add this to the rules debhelper 7.0.17.
[04:19] <DiegoTc> and when i do the  sudo make -f debian/rules clean I got this message http://pastebin.com/VVjqTa6A
[04:32] <thewho> hi all
[04:43] <kobrien> hey guys
[04:43] <kobrien> looks like debian fixed the public_html problem Bug: 554903
[04:44] <kobrien> how exactly do their fixed get into our builds?
[04:44] <ScottK> Bug 554903
[04:45] <kobrien> I can make a patch if that helps?
[04:45] <ScottK> kobrien: Generally once the new package is in Debian, someone would prepare an updated merge.
[04:45] <ScottK> kobrien: It would.
[04:46] <ScottK> The most preferred patch would be a merge debdiff (unless their upload has other invasive changes).
[04:46] <ScottK> But any form of patch attached to a bug would be a help.
[04:46] <kobrien> ScottK: how would I go about "merge debdiff". take their debdiff and apply?
[04:47] <ScottK> !merge
[04:47] <ScottK> Have a look there.
[04:47] <kobrien> ScottK: will do. thanks
[04:57] <kobrien> ScottK: when I run grab-merge it fails
[04:58] <kobrien> with "unexpected operator"
[04:59] <RoAkSoAx> kobrien, as ../grab-merge.sh <package_name> ?
[04:59] <kobrien> yes
[04:59] <kobrien> well
[04:59] <kobrien> ./grab-merge.sh php5
[05:00] <kobrien> in an empthy dir, correct?
[05:00] <kobrien> empty*
[05:01] <RoAkSoAx> kobrien, yep. But check in merges.ubuntu.com/universe.html or merges.ubuntu.com/main.html for which packages are available for ".grab-merging"
[05:03] <kobrien> it's really libapache2-php5 I'm after, but it's not listed
[05:04] <RoAkSoAx> kobrien, libapache2-mod-php5 ?
[05:04] <ScottK> RoAkSoAx: That's only work for things in Testing.
[05:05] <ScottK> He's looking for something just uploaded.
[05:05] <kobrien> ScottK: please advise
[05:06] <kobrien> RoAkSoAx: yes
[05:06] <RoAkSoAx> ScottK, since he was using grab-merge that's why I thought he was looking to merge a package from debian in testing :)
[05:07] <ScottK> kobrien: You mean libapache2-mod-php5?
[05:07] <kobrien> ScottK: yes
[05:07] <ScottK> That's part of the php5 source package.
[05:07] <RoAkSoAx> kobrien, poh o just read backlog. You would have to do: 'apt-get source libapache2-mod-php5', which is actually in php5 source package. So it will download the source package and you can start working from there
[05:08] <kobrien> RoAkSoAx: ok so
[05:08] <kobrien> that's how I'd normally patch, but debian have released a fix, I was gonna merge their fix, but I can easily just implement it in a patch
[05:08] <kobrien> of my own
[05:09] <ScottK> Better to get Debians.
[05:09] <ScottK> (for consistency)
[05:09] <RoAkSoAx> yep
[05:09] <kobrien> right, so can I apply their debdiff directly?...how to proceed?
[05:10] <ScottK> kobrien: I don't see anything new uploaded yet: http://packages.qa.debian.org/p/php5.html
[05:10] <ScottK> "There are 64 open security issues, please fix them."
[05:10] <kobrien> basing off this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571714
[05:11] <ScottK> kobrien: We should have that in Lucid already
[05:11] <ScottK> Are you wanting a fix for Karmic?
[05:12] <kobrien> nope, Lucid
[05:14] <ScottK> We already it then (at least in theory).
[05:14] <ScottK> It could have been a bad merge.
[05:15] <ScottK> So I'd grab the Ubuntu source (apt-get soure php5) and then check too see if it's there already.
[05:15] <kobrien> righteo
[05:15] <kobrien> 2 secs
[05:31] <kobrien> ScottK: It appears that in the current lucid version, the behaviour of not serving php from public_html is known. It gives details of how to enable it, but it's not default. surely it should be
[05:32] <kobrien> do you agree?
[05:32] <ScottK> kobrien: I'd ask zul on #ubuntu-server when he's working tomorrow.
[05:32] <ScottK> Personally I've never failed to avoid dealing with php and prefer to keep it that way.
[05:33] <kobrien> ScottK: ;) no probs. I'll see what I can do. The fix is easy, but I'll consult zul. thanks
[05:56] <nigelb> ok, so in my .pbuilderrc I have this line UBUNTU_MIRROR="http://ubuntuarchive.hnsdc.com/" unfortunately, pbuilder is not using that mirror even after source .pbuilderrc
[05:57] <nigelb> any thoughts on what I'm doing wrong ?
[06:00] <ScottK> I don't see any mention of UBUNTU_MIRROR in man pbuilder
[06:00] <nigelb> I use this https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders
[06:05] <ScottK> OK.
[06:05] <nigelb> and its still not working :D
[06:05]  * kobrien compiles the hell out of php
[06:10] <ScottK> nigelb: If you want to figure out how to get this one to build, that'd be nice too: https://launchpad.net/ubuntu/+source/php-imlib/0.7-1build1
[06:12] <nigelb> ScottK, was that for me or kobrien ?
[06:12] <kobrien> probably me, I'll look into ot
[06:12] <ScottK> nigelb: Actuall kobrien.  Thanks.
[06:12] <ScottK> ../
[06:12] <ScottK> y
[06:12] <kobrien> :)
[06:12]  * ScottK goes to bed.
[06:12] <kobrien> nn
[06:12] <ScottK> Good night.
[06:12] <nigelb> good night :)
[06:12] <kobrien> thanks for the help
[06:14] <kobrien> ooh, that bug looks good.
[06:15] <wrapster> vi and vim are not a part of any pkg?
[06:16] <nigelb> it is
[06:16] <wrapster> dpkg -S didnt show anything.
[06:16] <wrapster> why so then?
[06:16] <nigelb> you dont have it installed?
[06:17] <kobrien> it lists fine when it's installed
[06:18] <kobrien> wrapster: install with "sudo apt-get install vim"
[06:18] <wrapster> kobrien: and how about vi?
[06:18] <kobrien> hmm, can't vim work in vi mode
[06:19] <nigelb> vim-tiny perhaps?
[06:19] <wrapster> no..
[06:19] <wrapster> Im acutally curious to know about 'update-alternatives' for my own reasons.. thats why asking you guys.. as i see that both vi and vim point to the same file eventually.
[06:20] <wrapster> and that is 'vim.basic'
[06:20] <kobrien> :set compatible?
[06:20] <kobrien> I think that'll put vim in vi mode
[06:21] <wrapster> kobrien: no i dont have issues using the editor nor do i want info on using it.. I want to know just how both vi and vim manage to point to the same file.
[06:21] <wrapster> i need to just take a look at it thats all.
[06:22] <kobrien> oh...cause vi isn't packaged. only vim is availible but it acts just like vi
[06:22] <kobrien> if you want it to. that's why both point to it
[06:22] <wrapster> ah.. ok..
[06:22] <wrapster> I got that..
[06:24] <wrapster> kobrien: so by default debian does not ship vi at all.. Is that what your telling me?
[06:24] <nigelb> yup
[06:24] <wrapster> thank you.
[06:24] <wrapster> guys
[06:24] <kobrien> yup
[06:24] <kobrien> cool
[06:24] <kobrien> there's no need as vim provides its functionality
[06:26]  * kobrien still compiling...
[07:07] <kobrien> if I make a patch, is it useful for me to upload more than a debdiff?
[07:09] <persia> kobrien: Not really, no.  Also, does your patch fix an issue generally, or is it just an aggregation of currently available patches?
[07:10] <kobrien> it is a single fix for default configuration of apache2
[07:11] <persia> Ah, for that just the debdiff is fine then.
[07:13] <kobrien> cool, thanks.
[07:20] <nigelb> how do I unapply a patch?
[07:20] <nigelb> is there a way?
[07:20] <maco> nigelb: diff -r, i think
[07:20] <persia> What sort of patch?
[07:20] <nigelb> well, I was going to patch with quilt, but forgot quilt add
[07:20] <nigelb> so, now I have to remove applied patch and do a quilt add and then patch again
[07:21] <persia> How did you apply the patch?
[07:22] <nigelb> patch -p1 < blablabla.pach
[07:22] <maco> brain not working sorry
[07:23] <nigelb> maco, I did wonder
[07:23] <maco> nigelb: have you learned about "quilt import" yet?
[07:23] <nigelb> um, no
[07:23]  * nigelb goes to man pages
[07:23] <nigelb> ah, never knew this one.. this is cool :)
[07:24] <persia> diff -r ought work for that case, but quilt import is better.
[07:24] <nigelb> so no need to do a quilt new when using quilt import?
[07:25] <persia> Right.
[07:25] <persia> Instead, you need to use -f or -d when you want not to have a new patch.
[07:26] <maco> persia: you mean like if you want to combine 2 or 3 external patches into 1 quilt patch?
[07:26] <persia> maco: Or you want to merge/overwrite some quilt patch with some external patch.  man quilt :)
[07:27] <maco> ooh alrighty. i only ever used it for adding 1 patch at a time
[07:27]  * nigelb glares at maco
[07:27] <nigelb> you taught me quilt :D
[07:27] <maco> nigelb: what?
[07:27] <maco> nigelb: i taught you a long way round?
[07:27] <nigelb> yeah
[07:28] <maco> nigelb: was possibly before i learned about import
[07:28] <nigelb> ahhh
[07:29] <maco> ive only done the new, add, edit, <manually edit things without the patch command>, refresh thing once, i think
[07:30] <maco> having a patch to import is much more common
[07:30] <nigelb> generally I did new, add, (then manually patch -p1...), quilt refresh
[07:30] <maco> yeah thats what i did til i learned about import
[07:31] <nigelb> so if the patch is improperly formatted, I guess I have to manually do it
[07:31] <maco> hmmm? well i hope you dont normally add patches that dont apply...
[07:32] <nigelb> I'm doing patch review... well.. a lot of patches dont apply properly
[07:32] <maco> yeah
[07:32] <maco> patch --dry-run
[07:32] <nigelb> I do that first always
[07:33] <nigelb> I guess I have to manually correct the directory structure
[07:34] <persia> Did you use the right -pN argument?  That's my most frequent mistake.
[07:35] <nigelb> naah.  the patch author hasn't referenced the file (s)he wants to patch correctly
[07:35] <nigelb> instead of share/applications/vlc.desktop its just vlc.desktop
[07:36] <nigelb> someday, someone will write a script to properly tag patches
[07:36] <nigelb> until then, I'll just crib about it I guess
[07:39] <nigelb> is normal for series file to have $patch_name -p$ ?
[07:39] <nigelb> i.e. after importing
[07:40] <maco> if the patch has a p number other than 1, sure
[07:40] <maco> (1 is default i believe)
[07:40] <nigelb> I think if I specify something it turns up there
[07:40]  * maco waits for persia to say she's wrong
[07:41] <nigelb> 1 is default :)
[07:41] <persia> maco is wrong
[07:41] <nigelb> persia, which part?
[07:41] <persia> No, the default is not to do nested trees.
[07:42] <nigelb> -p num - Number of directory levels to strip when applying (default=1)
[07:42] <nigelb> ^ from man quilt
[07:42] <persia> The default is for the directory hierarchy in the patches to be ignored, and for it to apply to patches in the local directory.  Under certain circumstances, this is indistinguisable from p1
[07:42] <persia> Oh, sorry.  I'm describing patch behaviour.  quilt is likely saner
[07:42] <nigelb> ah :)
[07:50] <nigelb> why is my pbuilder not accepting a mirror from the .pbuilderrc file :(
[07:59] <nigelb> is this part of a mirror problem? http://paste.ubuntu.com/409379/
[08:03] <persia> nigelb: That does indicate a mirror problem.  I recommend adding *multiple* entries to sources.list for each component.  Put the ones network-closest to you first, followed by those further away, and with archive.ubuntu.com/ports.ubuntu.com at the end of the list.
[08:03] <nigelb> persia, well, its from my pbuilder build log
[08:03] <persia> apt will try them in order, so you get the advantages of mirroring where the mirror works, and fall back to something trusted if the mirror doesn't work.
[08:03] <persia> There too :)
[08:03] <nigelb> I set the mirror as my closest one, but it just refuses to accept that one :x
[08:04] <nigelb> persia, pbuilder seems adamant on using the mirrors.kernel.org one
[08:05] <nigelb> I did a source .pbuilder and still didn't change
[08:06] <persia> That's hacked into pbuilder-dist
[08:06] <nigelb> no no
[08:06] <nigelb> I use this https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders
[08:06] <persia> No idea then.
[08:06] <persia> Have you considered sbuild?
[08:06] <nigelb> no
[08:07] <nigelb> is there a how-to somewhere?
[08:07] <persia> Are you running lucid?
[08:07] <nigelb> nope... ugh.. sbuild needs lvm?
[08:07] <persia> Not in lucid.
[08:07] <nigelb> I'm running karmic
[08:07] <persia> Upgrade!
[08:08]  * kobrien slaves over lucid bugs
[08:08] <nigelb> I'm not a fan of Upgrade.  I always do clean installs
[08:08] <persia> lucid is stable enough that if there's anything that doesn't work, you want to know *now* so you have a chance of fixing it.
[08:08] <persia> Mind you, I run karmic on some of my machines, but most certainly not on my development machines.
[08:10] <persia> upgrade should just work.  If something doesn't work, that's a fixable bug.
[08:10] <kobrien> lucid is quite stable
[08:10] <nigelb> still I'm curious as to why pbuilder doesn't work
[08:12] <persia> I can't help you with that.  My experience with pbuilder is limited to patching pbuilder-dist a couple times.
[08:12] <nigelb> I'll just try override-config and if that doesnt work pbuilder-dist
[08:13] <persia> pbuilder-dist hardcodes the mirror in a way I think non-optimal
[08:13] <persia> And I believe lool was working upstream to try to obsolete pbuilder-dist
[08:14] <nigelb> sigh.  I guess I have to upgrade then
[08:21] <geser> lfaraone: http://paste.ubuntu.com/409383/ I hope this finally fixes it
[08:32]  * kobrien face palm. a static type, qualified by static when declared in a function.
[08:39] <kkszysiu> is package freeze now? Or I can upload new packages?
[08:40] <nigelb> kkszysiu, we are in feature freeze for lucid now.  If you really want your package in, you need a feature freeze exception
[08:40] <kobrien> ScottK: successfully compiled https://launchpad.net/ubuntu/+source/php-imlib/0.7-1build1
[08:41] <nigelb> kobrien, you work magic :)
[08:41] <kkszysiu> nigelb, ah
[08:41] <nigelb> kkszysiu, I would suggesting getting the package into debian, it will be synced into lucid then
[08:41] <nigelb> urm... lucid+1
[08:42] <kkszysiu> yeah, thats my plan :P
[08:42] <kobrien> nigelb: I just code C. :). It compiles anyway.
[08:42] <nigelb> kobrien, :)
[08:43] <kobrien> nigelb: I'm unsure as to how to proceed. It's not like there's a report I can attach a patch to. How do I commit my change?
[08:43] <nigelb> just make a bug report
[08:43] <kobrien> nigelb: cool
[08:43] <nigelb> attach a debdiff and subscribe sponsors
[08:44] <nigelb> if you're unsure how to make a debdiff.. attach a simple patch and ping me I'll make a debdiff for ya :)
[08:44] <kobrien> I can debdiff :), cheers
[08:44] <nigelb> cool :)
[08:44] <kobrien> oh wait
[08:44] <kobrien> no, I can debdiff
[08:45] <kobrien> :D
[09:07] <kkszysiu> hmm anyone have idea how to change libexecdir in package? I mean it should be /usr/telepathy/telepathy-sunshine but is /usr/telepathy-sunshine/telepathy-sunshinee. Its strange because if I compile it uusing make & make  install it  see that llibexecsir is /usr/lib/telepathy/telepathy-sunshine
[09:24] <geser> kobrien: for php-imlib?
[09:25] <geser> there is a patch from me waiting in the Debian BTS
[09:25] <geser> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569118
[09:26] <nigelb> geser, for the vlc bug, I got hit with glibc error
[09:26] <geser> have you an error message?
[09:27] <nigelb> ouch...lost it... 2 mins
[09:30] <kobrien> geser: didn't see that. my patch does the same thing...
[09:31] <geser> kobrien: just a hint for the next time: look if there is a bug (with patch) in LP or in the Debian PTS just waiting on someone uploading it, it can save you time
[09:33] <kobrien> geser: noted
[09:34] <geser> kobrien: can you test if the package still works? I don't have a setup ready to test it and didn't had time yet to setup one.
[09:36] <kobrien> geser: other than installing it, how can I test?
[09:37] <geser> http://packages.ubuntu.com/lucid/i386/php-imlib/filelist shows that it contains some examples
[09:38] <kobrien> geser: ok, I'll have a look now.
[09:38] <geser> with apache + php + php-imlib you should be able to run them
[09:38] <kobrien> geser: yeah, I'll copy them and see if they work
[09:42] <geser> thanks
[09:47] <nigelbabu> geser, so this error I got had something to do with glib c and I got a trace output, etc
[09:47] <nigelbabu> I'm rebuilding right now to get a log
[09:50] <kobrien> geser: package is broken
[09:50] <geser> kobrien: :(
[09:51] <kobrien> geser: it's "fatal error" in the logs is that it can't "imlib_create_image" which is kinda necessary for it, as an image library, :(
[10:00] <nigelb> geser, something strange just happened... twice.. everytime I build vlc again, my system shuts down :(
[10:02] <geser> oh
[10:03] <nigelb> any clue whats going wrong?
[10:03] <kobrien> nigelb: weird
[10:03] <nigelb> kobrien, definitely
[10:03] <geser> sorry no idea
[10:03] <nigelb> I'll try pushing to a PPA
[10:03] <nigelb> that should give an idea if somethings wrong only locally :)
[10:04] <geser> have you checked your logs for a kernel oops or a out-of-memory case?
[10:04] <nigelb> how do I do that?
[10:06] <geser> check /var/log/messages or /var/log/syslog
[10:06] <geser> and hope your system was still enough alive to log something
[10:07] <geser> anyone interested in merging "xpdf"? It contains some security fixes and would be nice to have in lucid.
[10:07] <nigelb> neither exists
[10:56] <nigelb> oh, success.. vlc builds :)
[14:25]  * hyperair tickles james_w. banshee-community-extensions is NEW again :-)
[14:57] <cnd> I've got a fix for gnome-settings-daemon bug 484186, I've proposed merging my fix branch, and linked the bug to the branch
[14:57] <cnd> should I also be subscribing ubuntu-sponsors?
[15:04] <dyfet> cnd: I gather you have a patch?  I have seen this issue also, and had wondered about it :)
[15:04] <cnd> dyfet: I've actually created a bzr branch in lp with the fix
[15:04] <cnd> it's ready to be merged
[15:19] <persia> cnd: Yes, subscribing ubuntu-sponsors is potentially helpful, although you'd want to check the sponsoring report source to be sure.  You might also see if anyone is around in #ubuntu-desktop who can push it quickly (most of us don't have upload rights to that package).
[15:20] <cnd> persia: check the sponsoring report for what? (and where is the sponsoring report?)
[15:21] <persia> cnd: Check the code to see if subscribing ubuntu-sponsors does anything at all, and https://code.launchpad.net/~dholbach/ubuntu-sponsoring/trunk
[15:22] <cnd> persia: I'm not following you, what should I be checking in this code for?
[15:23] <nigelb> persia, the bug does show up in the sponsoring report
[15:24] <persia> nigelb: So subscribing ubuntu-sponsors when performing a merge request is superfluous?
[15:25] <cnd> if you're referring to here: http://qa.ubuntu.com/reports/sponsoring/, then the merge request is enough to get on there
[15:25] <nigelb> persia, I believe so, yes
[15:25] <cnd> is that all I need to do then? (outside of maybe bringing it up in #ubuntu-desktop)?
[15:26] <persia> If it appears at qa.ubuntu.com/reports/sponsoring then yes.
[15:26] <cnd> persia: ok, thanks!
[15:28] <c_korn> does the source format 3.0 (quilt) need an explicit build dependency for quilt ?
[15:28] <ScottK> c_korn: No.
[15:28] <ScottK> (mostly)
[15:29] <persia> ScottK: mostly?
[15:29] <c_korn> because lintian warned me that a quilt is missing in build-depends. but maybe because I had "include /usr/share/quilt/quilt.make" in the debian/rules file. is this also required or is patching now done automatically ?
[15:30] <james_w> not unless you call quilt while building
[15:30] <james_w> c_korn: you should be able to drop that
[15:30] <ScottK> persia: Depending on the exact version of dpkg(-dev) involved if you ship a quilt .pc file (I think that's it), the build-dep on quilt is still required.
[15:31] <ScottK> I think, but am not certain, that's not an issue anymore.
[15:31] <persia> ScottK: Ah, yes.  That's not an issue anymore in sid/squeeze/lucid
[15:31] <matttbe> Hello james_w
[15:31] <matttbe> I've a question about this branch https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/cairo-dock/lucid : cairo-dock packages have been updated but not this branch, is there a problem?
[15:31] <c_korn> is README.source required in 3.0 (quilt) ?
[15:32] <ScottK> Not due to having quilt and patches
[15:32] <matttbe> (cairo-dock-plug-ins branch has been updated => https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/cairo-dock-plug-ins/lucid )
[15:32] <persia> c_korn: And please don't reference quilt in the build for format 3.0(quilt) : if you rely on some obscure behaviour related to how patches are applied at build time using quilt, use format 3.0(native).
[15:33] <james_w> hyperair: you never replied to my mail, is the part without any license statements sorted?
[15:33] <james_w> matttbe: probably
[15:34] <hyperair> james_w: ah sorry about that. yes, everything's now documented in debian/copyright.
[15:34] <james_w> matttbe: yeah, there's a bug in the importer that this package is hitting
[15:34] <hyperair> james_w: lirc still is missing copyright statements, but i've mentioned in a comment where the original code came from, plus a debian/copyright that upstream did before  b-c-e was founded.
[15:35] <c_korn> persia: ok, thanks for the warning
[15:35] <matttbe> james_w: ok, I'd seen this problem and somebody tells me to ping you
[15:40] <matttbe> I also have another question: I've added 'apport' support in 'cairo-dock' packages but all needed informations are located in a private bug report. How can I access to this private bug? e.g. bug #553265
[15:41]  * Pici looks at bot error
[15:44] <persia> matttbe: Your best plan for getting access to that class of bugs is to work with the bugsquad long enough to gain Bug Control.  They usually hang out in #ubuntu-bugs and are always happy to help new folks learn the processes.
[15:44] <persia> matttbe: Alternately, I believe you can subscribe to *all* bugs for the package of interest, but I'm not absolutely sure that works.
[15:45] <matttbe> I subscribed to all bugs for these packages but it didn't work
[15:46] <persia> Yeah, then you need to be in bug control.
[15:46] <persia> I can inspect that bug in particular, and maybe make unprivate, but that's not a general solution.
[15:46] <matttbe> yes but can I only access to cairo-dock's bugs ?
[15:47] <persia> No, bug control is for access to *all* apport bugs.
[15:47] <matttbe> :) strange
[15:50] <lfaraone> Hm. Does updating a packages' protocol support count as "new features"? I'm eyeing http://www.wireshark.org/docs/relnotes/wireshark-1.2.7.html right now.
[15:52] <persia> lfaraone: Can it introduce new bugs?
[15:54] <persia> matttbe: bug #539889 is no longer private
[15:57] <soren> I'm trying to use mk-sbuild to build me a debian chroot. It fails because apparantly apt is not build-essential in Debian. I can't get that to make sense to me.
[15:57] <persia> soren: Which part doesn't make sense?
[15:58] <soren> persia: Good question :)
[15:58] <persia> soren: And I believe the solution was in debootstrap, although if I'm wrong, I'm happy to hint apt in mk-sbuild.
[15:58] <soren> persia: Probably that apt is not build-essential in Debian (even though it is in Ubuntu).
[15:59] <persia> It won't be in Ubuntu much longer, I think.  Personally, I don't see any reason for it to be build-essential.
[15:59] <soren> persia: Except that buildd's won't work very well without it.
[15:59] <persia> It's not safe to call apt *during* a build, after all.
[16:00] <persia> That's an artifact of how the buildds are configured.
[16:00] <soren> I suppose.
[16:00] <persia> There's no reason one can't set the right apt arguments, and complete the build-deps in the chroot *before* entering the chroot to run the build.
[16:01] <persia> It just doesn't happen to be implemented that way.
[16:03] <ScottK> lfaraone: I'd call it bug fix.
[16:03] <ScottK> We definitely want the latest wireshark anyway.
[16:10] <lfaraone> ScottK: okay then :)
[16:33] <DktrKranz> I prepared a list of orphaned packages with Ubuntu changes: http://merkel.debian.org/~dktrkranz/ubuntu_QA   It could be interesting uploading such changes to Debian as QA uploads if feasible, thoughts?
[16:34] <ScottK> It's a good idea.  I've been doing that as I run across such packages.
[16:35] <DktrKranz> some packages could be candidate for removal as well, but at least there's a chance to reduce deltas a bit. Any idea how to spread it?
[16:36] <nigelb> DktrKranz, I've been uploading to debian and requesting sync when debian qa is the maintainer
[16:37] <DktrKranz> nigelb: do you have uploads yet to be sponsored?
[16:38] <nigelb> nope.  all done and synced
[16:38] <DktrKranz> good .)
[16:38] <DktrKranz> _=
[16:38] <DktrKranz> :) (\o/)
[16:38] <nigelb> I can try and help with this btw, giving back upstream is nice :)
[16:39] <DktrKranz> definitely :)
[16:46] <nigelb> DktrKranz, anyway to agree to fix a particular package?
[16:46] <nigelb> i.e. mark as I will be fixing it
[16:47] <DktrKranz> nigelb: wiki page? upload on mentors.d.n, so PTS is informed?
[16:48] <nigelb> DktrKranz, ah, I wanted to delay uploading to mentors.  well, I guess I'll have to do it sooner than later
[16:49] <DktrKranz> nigelb: no need to use it, I can sponsor them as well, just give me a pointer to a .dsc or a debdiff :)
[16:49] <nigelb> ok, I'll get to work :)
[16:50] <DktrKranz> thanks!
[17:00] <nigelb> DktrKranz, I'll move that table onto a wiki.  some of the ubuntu changes need not be moved back upstream
[17:35] <nigelb> DktrKranz, https://wiki.ubuntu.com/Debian/QADelta
[17:42] <wrapster> in the postinst script i cannot execute how do i execute shell commands?coz one in particular called 'update-ca-certificates' fails if written inside the postinst script
[17:42] <wrapster> but anywhere else if i write its working fine.
[17:43] <wrapster> http://pastie.org/900511
[17:43] <wrapster> i've been at it with no result.. would really appreciate help
[17:55] <geser> wrapster: then find out why it fails (edit that shell-script to show you what it's doing and where it fails)
[17:55] <geser> even if you post it once more, we can't tell you what's wrong because we don't know why the script fails
[18:02] <stevecrozz> I've just built a new package 'uwsgi' which provides one binary, should I copy the binary to /usr/bin in debian/rules?
[18:03] <stevecrozz> and how would apt no to remove it during apt-get remove?
[18:04] <geser> why would you want to remove the package but not the binary?
[18:05] <stevecrozz> geser: you wouldn't want that of course, but I don't know how to provide that
[18:07] <stevecrozz> if I just "cp uwsgi26 $(CURDIR)/debian/$(package)/usr/bin" in install: build ... will that work?
[18:08] <geser> yes, that will make it part of the deb
[18:09] <DktrKranz> nigelb: nice, thanks
[18:10] <wrapster> geser: i did all those.. i was able to find out that command 'update-ca-certificte' was failing
[18:10] <wrapster> and thats about it.
[18:10] <nigelb> DktrKranz, some changes are not required to be sent to debian, so people can comment :)
[18:10] <wrapster> I tried with 'set -x' to figure it out but nothing was helpful
[18:11] <wrapster> geser: I can also confirm that this cmd is the problem as i removed this from the postinst script and the pkg was installed cleanly.
[18:11] <geser> wrapster: you added "set -x" to update-ca-certificates? that should show you where it failed so you can try to figure out why
[18:11] <stevecrozz> geser: Is there any reading you can point me to on how to do this right? I'm seeing this type of stuff: mkdir: cannot create directory `/home/stevecrozz/src/uwsgi/uwsgi-<IP_ADDRESS>/debian/uwsgi/usr/bin': No such file or directory
[18:12] <wrapster> geser: yes i added it to that command.. as such in the postinst script.. I cannot add it else where.
[18:13] <wrapster> geser: and it didnt work.. http://pastie.org/904051
[18:14] <geser> stevecrozz: either mkdir $(CURDIR)/debian/$(package)/usr/bin or put "usr/bin/" debian/dirs and use dh_installdirs
[18:14] <slytherin> Can anyone think of any reason why liboscache-java is missing from archive even though it is listed on LP - https://edge.launchpad.net/ubuntu/+source/oscache
[18:15] <geser> wrapster: you have to add "set -x" to update-ca-certificates to see where it fails. without this nobody can help you as we don't know where and why it fails
[18:15] <wrapster> but thats a command right and its provided by the same pkg that is failing.. namely 'ca-certificates'
[18:16] <geser> slytherin: see the mail from slytherin on u-d-a (see also https://edge.launchpad.net/ubuntu/lucid/i386/liboscache-java)
[18:17] <geser> wrapster: you have to temporarily modify that script else you don't figure out why it fails (once you know why it fails, you can undo those changes again)
[18:17] <geser> I don't know an other way to debug this
[18:18] <wrapster> ok thanks.. i try to do something and get back to you.
[18:18] <slytherin> geser: Thanks. I missed the mail.
[18:19] <geser> slytherin: once you resolved the FTBFS the package can come back
[18:19] <slytherin> geser: Checking why it FTBFS
[18:20] <wrapster> geser: yes got it.. thanks .. here is the problem..
[18:20] <wrapster> http://pastie.org/904060
[18:23] <geser> wrapster: now you have to figure out what c_rehash does and why it fails
[18:23] <geser> slytherin: http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/oscache_2.4.1+dak1-1_llucid32.buildlog
[18:24] <slytherin> geser: Found that. Looks like problem with target JVM version set during compilation.
[18:24] <slytherin> Or probably problem with GCJ
[18:25] <stevecrozz> geser: it looks like this works: "cp uwsgi26 $(CURDIR)/debian/tmp/usr/bin"
[18:25] <stevecrozz> I was using "cp uwsgi26 $(CURDIR)/debian/$(package)/usr/bin
[18:25] <geser> stevecrozz: depends on which debhelper level you use
[18:26] <stevecrozz> geser: is that why I'm getting these messages? "Compatibility levels before 5 are deprecated."
[18:26] <geser> yes
[18:26] <slytherin> geser: We now have uninstallable circular build-deps. :-( oscache build-deps on libhibernate3-java which in turn depends on liboscache-java.
[18:26] <stevecrozz> geser: how do I change that?
[18:27] <geser> put the debhelper level you want to use in debian/compat. Current is 7
[18:32] <geser> slytherin: crap
[18:33] <slytherin> checking if it build without hibernate
[18:33] <geser> ScottK: on the next round of binaries removals in universe we should be more careful with -java packages as they like to have circular build-dependencies
[18:34] <ScottK> geser: There was all kinds of warning for people to check this stuff.
[18:34] <geser> I know
[18:34] <geser> and yet slipped it though but we should try to not make it worse
[18:36] <ScottK> Agreed.
[18:36] <stevecrozz> geser: that works great thanks.. now if I want to provide a symlink to uwsgi26 named uwsgi should I do "ln -s /usr/bin/uwsgi26 $(CURDIR)/debian/$(package)/usr/bin/uwsgi"
[18:38] <ScottK> stevecrozz: dh_link is preferred.  See man dh_link for details.
[19:11] <slytherin> geser: oscache fixed.
[19:11] <geser> \o/
[19:17] <ScottK> accepted too
[19:18] <slytherin> ScottK: Thanks
[19:22] <slytherin> ScottK: FYI... Package built and is in NEW queue now.
[19:22] <ScottK> OK.
[19:22] <ScottK> Hopefully slangasek will have a chance to work on New today.
[19:23] <slytherin> ok
[19:23]  * slytherin moves on to other packages.
[19:25] <slangasek> oh, ace is back?
[19:35] <ScottK> slangasek: Yep.   (I'm considereing whether to submit https://edge.launchpad.net/ubuntu/+source/rbot/0.9.14-1ubuntu1 upstream)
[20:38] <mhall119> when does the window for FFe close?
[20:38] <mhall119> is it open until Beta2 is released?
[20:43] <arand> mhall119: I think it's open until the very final, just increasingly stricter..: https://wiki.ubuntu.com/FreezeExceptionProcess
[20:45] <mhall119> arand: thanks
[20:45] <mhall119> now I just need someone to review my packages
[20:45] <mhall119> any Motu's willing to help?
[20:46] <mhall119> no compiling required, honest
[20:53] <RoAkSoAx> mhall119, which ones
[20:55] <mhall119> qimo-session, qimo-games and qimo-wallpaper
[20:56] <RoAkSoAx> mhall119, where are they
[20:56] <RoAkSoAx> revu?
[20:57] <mhall119> yes
[20:57] <mhall119> I've also created bugs for each, with needs-packaging, and attached orig.tar.gz and diff.gz
[20:58] <RoAkSoAx> i'll try to take a look on them later today
[21:00] <RoAkSoAx> but I dont usually woprk with new packages
[21:01] <mhall119> there's not a whole lot to them
[21:01] <mhall119> mostly graphics and config files being copied into the filesystem
[21:02] <RoAkSoAx> mhall119, i'll take a look at them, but wouldn't have been easier to create one source apckages with several binary packages?
[21:02] <mhall119> in theory, maybe
[21:02] <mhall119> in practice, I have no idea what that even means
[21:03] <mhall119> this is my first time making packages, so I'm pretty green
[21:04] <RoAkSoAx> mhall119, i.e. qimo-extras source package, which means only 1 .tar.gz and several binary packages that install the necessary from the source
[21:04] <RoAkSoAx> unless ytou maintain those differently
[21:04] <RoAkSoAx> (or in different sources)
[21:14] <geser> lfaraone: pkgstriptranslations is Ubuntu-specific
[21:22] <arand> joaopinto: Hia, currently checking out bloodfrontier from playdeb, is there currently anything blocking that from making it into the debian and ubuntu repos? (For 10.10 in ubutnus case...)
[21:23] <joaopinto> arand, nothing that I know
[21:24] <joaopinto> it's Sauerbraten based, there should be no problem with the license
[21:24] <arand> joaopinto: Would you mind if I took a stab at it at some point?
[21:25] <joaopinto> feel free
[21:28] <arand> joaopinto: By the way, is the current playdeb version based off 0.85-beta2 (dates seem to indicate that), I didn't find any references in the package.
[21:29] <joaopinto> it is
[21:30] <arand> joaopinto: Okay, cheers for info.
[22:09] <mhall119> RoAkSoAx: I'll look into that for the M cycle
[22:43] <tsimpson> anyone want to apply a fix to a 3 year-old bug? (bug #86685)
[23:12] <bencrisford> ive created a patch for bug #555422 and uploaded the debdiff, set status to confirmed, unassigned myself and subscribed the ubuntu-sponsors
[23:12] <bencrisford> is that correct?
[23:12] <bencrisford> because i havent submitted any fixes for a few months
[23:13] <ScottK> Sounds right.
[23:19] <bencrisford> ScottK: :)


[03:47] <jamin> I'm somewhat surprised that this bug is still effectively ignored over a year later: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/825897
[03:53] <micahg> cyphermox: ^^
[05:33] <pitti> Good morning
[05:34] <sarnold> hey pitti :)
[05:54] <tjaalton> infinity: https://bugs.freedesktop.org/show_bug.cgi?id=54226
[05:54] <tjaalton> dunno why I'm not hit by it more often
[06:37] <infinity> tjaalton: I got it like ten times yesterday. :/
[07:32] <tjaalton> infinity: well there's things to try on that bug
[07:38] <infinity> tjaalton: With a nasty performance and power draw hit, apparently.  I'm not sure it's worth the effort.  I can live with the lockups.
[07:38] <infinity> tjaalton: I just don't think we can live with them for release.
[07:44] <tjaalton> infinity: are you running 3.8 already, btw?
[07:45] <infinity> tjaalton: No, I will be after a reboot, but can't reboot just now.
[07:47] <tjaalton> infinity: ok, it should be better.. i'll be in touch with upstream after you've tried
[08:50] <mitya57> Does anybody have problems with logging in to errors.u.c?
[08:50] <mitya57> I "The site has requested some personal information. Please choose what you would like to share:" page,
[08:51] <mitya57> press "yes, log in" there, and after some five seconds the same page loads
[08:51] <mitya57> I'm getting this in Chromium and Firefox (resetting cookies & cache doesn't help)
[08:54] <infinity> mitya57: Works for me.  Are you actually in the group(s) it wants?
[08:55] <mitya57> infinity: I'm in ubuntu-bug-control
[08:55] <mitya57> and I was able to access that site in the past
[08:56] <infinity> mitya57: I think it was further locked down, pending review of data privacy laws and other such madness.
[08:56] <infinity> mitya57: When you log in, is there a more info expander or something that shows you that it's looking for a group you're not in?
[08:56] <mitya57> no, nothing like that
[08:57] <infinity> If I could remember how to log OUT of an SSO service...
[08:57] <infinity> I guess I could just log out of login.launchpad.net entirely.
[08:57] <mitya57> IIRC there was a "log out" link at the page bottom
[08:57] <infinity> Oh, which doesn't do anything. :P
[08:58] <infinity> No log out links on errors once logged in, no.
[08:59] <mitya57> https://login.ubuntu.com/+logout ?
[08:59] <infinity> That didn't actually log me out of errors.
[08:59]  * infinity gives up and uses an incognito browser.
[09:00] <infinity> Team membership: canonical-ubuntu-platform
[09:00] <infinity> ^-- Yeah, it's looking for that right now.
[09:01] <infinity> We're hoping to be able to open it up a bit more in the future, AFAIK, but it's a bit messy.
[09:01] <infinity> mitya57: ev might know more about progress on that front.
[09:02]  * mitya57 hopes it's possible to open it at least for ~ubuntu-dev
[09:03] <infinity> I'd probably be happy even with just core-dev, but anything that isn't "just the company" gives lawyers heart attacks when it comes to users sending us data that could be, well, anything.
[09:03] <infinity> (And rightfully so, I suppose)
[09:04] <mitya57> ok, can you (or anybody else) show me a couple of tracebacks?
[09:04] <mitya57> https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Funity-mail%2Funity-mail%3Aimaplib.abort%3A_command_complete%3A_get_tagged_response%3A_get_response%3A_get_line%3Aon_mm_item_clicked%3Amark_message_as_read%3Aselect%3A_simple_command%3A_command_complete
[09:05] <mitya57> and https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Funity-mail%2Funity-mail%3Aemail.errors.HeaderParseError%3Astart_loop%3Astart_loop%3Adecode_header%3Adecode%3Aupdate%3Aupdate_single%3Aget_header_wrapper%3Adecode_wrapper%3Adecode_header
[09:11] <infinity> mitya57: http://paste.ubuntu.com/1519349/ and http://paste.ubuntu.com/1519350/
[09:11] <mitya57> thanks infinity!
[09:14] <infinity> ev: So, apparently community developers do use errors.u.c (or, try to)
[10:11] <mlankhorst> can some ubuntu sru admin look at the mesa I uploaded this morning?
[10:49] <ogra_> Laney, wow, thanks !!! what i dont get though is why would that be invoked if someone sends an error report
[10:50] <Laney> ogra_: I'm not sure how it's all hooked up (pitti probably would know), but it seems like that's what invokes apport
[10:50] <ogra_> oh
[10:50] <Laney> it's probably something which can be converted to pkexec in any case
[10:50] <pitti> ogra_: update-notifier gets invoked when a non-user crash happens, not when someone sends an error report
[10:50] <pitti> Laney: nope, update-notifier still uses gksu
[10:50] <ogra_> yeah, i thought about it the other way round ... didnt think that IT coudl eb invoking apport :)
[10:50] <pitti> that's one of the two places which still need to be fixed
[10:51] <ogra_> whats the other ? xdiagnose ?
[10:52] <Laney> yeah I know it still does - was confirming that it was the source of ogra_'s bug from yesterday
[10:53] <pitti> ogra_: yes
[10:53] <ogra_> great
[12:56] <ev> infinity: and we want them to be able to access the data. But we're waiting for an NDA to be written up.
[13:26] <xnox> pitti: Program received signal SIGSEGV, Segmentation fault.  _dbus_watch_invalidate (watch=0x0) at ../../dbus/dbus-watch.c:171
[13:28] <xnox> usb-creator-gtk in certain combinations often triggers that. bug #915626. In the past there were also bug #1043887 and bug #852342
[13:28]  * xnox will try to sanitise that function in dbus & see if I can still trigger the bug.
[13:29] <xnox> bdmurray: you are a rock star @ finding the right set of options that trigger above more often than others.
[13:29] <pitti> xnox: I haven't seen this, but it's obviously passing a NULL argument to that function?
[13:30] <xnox> yeap. the function accepts dbuswatch pointer, it's passed NULL and it tries to do two simple assignments NULL->fd=-1 and something else. which causes SIGSEGV
[13:31] <xnox> I don't see how in high level python/dbus it could be causing this deliberately. the clean up looks racy to me.
[13:32]  * xnox also notes that python3-dbg tracebacks are verbose and seem to hide stuff =)
[13:32] <xnox> here is the full gdb log: https://launchpadlibrarian.net/128192354/gdb-dbus.txt
[13:36] <ogra_> pitti, bug 871662 looks like it can be closed in favour of an update-notifier bug
[13:36] <pitti> ogra_: or just reassigned; apport lost its dependency a while ago already
[13:37] <pitti> ah, there is one already, right
[13:37] <ogra_> yes, thats what i wrote in my last comment, but i didnt want to close without asking
[13:38] <pitti> ogra_: done, thanks for pointing out!
[13:38] <ogra_> (the focus grabbing makes it nastier on tablets than it used to be due to onboard )
[14:03] <zul> mterry:  hi..
[14:03] <zul> mterry:  i disabled the failing test for testrepository although it runs fine not in a buildd
[14:04] <mterry> zul, disabled the test?  :(
[14:04] <mterry> zul, I got the failure locally
[14:05] <zul> mterry:  if i just run make check then it runs fine
[14:49] <dbarth> hey, i have an apparmor, pam and lightdm question
[14:50] <xnox> go on =) sounds interesting so far.
[14:50] <dbarth> setuid is failing in a lightdm child process and i'm not sure if that's really not normal, or if it's just an apparmor file that is missing
[14:51] <mdeslaur> dbarth: do you have an apparmor denial in dmesg?
[14:51] <dbarth> mdeslaur: not that i can see though
[14:51] <mdeslaur> dbarth: then it's unlikely to be apparmor the problem
[14:52] <dbarth> does it go in auth.log or syslog by default?
[14:52] <mdeslaur> dbarth: syslog unless you have the "audit" package installed
[14:53] <dbarth> hmm, let me check that maybe first
[14:53] <mdeslaur> s/audit/auditd/
[14:54] <mdeslaur> if you have that package installed, it goes to /var/log/audit* somewhere
[14:54] <mdeslaur> (can't recall off-hand)
[14:54] <dbarth> no audit here
[14:54] <dbarth> and nothing from the lightdm process in syslog
[14:55] <dbarth> i will go through lightdm.log again
[14:59] <mterry> bdmurray, remember you talked to me a bit ago about the two duplicity SRUs in quantal?  you haven't accepted the other duplicity yet.  Would it be wasting your review cycles to upload another duplicity to quantal that combined both uploads?
[15:00] <dbarth> mdeslaur: i can see some old denial messages for the freerdp session though (in kern.log)
[15:00] <dbarth> but that was fixed once the config. file for the wrapper executable was installed
[15:01] <dbarth> (for the 12.10 release)
[15:01] <mdeslaur> dbarth: ok, but if there's nothing newer, then your issue is probably elsewhere
[15:01] <mdeslaur> all denials should be logged
[15:02] <jdstrand> it goes to kern.log
[15:02] <jdstrand> lightdm itself is not confined
[15:02] <jdstrand> the guest session is
[15:03] <ogra_> if lightdm already habnded over to the session manager if your issue happens, the errors would be in ~/.xsession-errors of teh user btw
[15:03] <mdeslaur> oh, whoops, yes, kern.log
[15:03] <dbarth> mdeslaur: ok, i'll dig deeper; thanks for pushing me further at least
[15:03] <jdstrand> we don't have any explicit denials that would block setuid
[15:03] <jdstrand> (even in the guest session)
[15:04] <mdeslaur> dbarth: check kern.log first though
[15:05] <dbarth> ogra_: the session opens fine if i make the pam session layer optional
[15:05] <hallyn> zul: infinity: is the raring qemu upload still waiting for review, or is it hanging on something else I forgot?  (it was waiting on ipxe-qemu for awhile...)
[15:05] <dbarth> the issue is when i re-enable the pam session part, to inject creds in the session
[15:05] <hallyn> i'm just confused bc i still don't see it on the uploads page for qemu
[15:06] <dbarth> jdstrand: ok, noted
[15:08] <hallyn> (oh, i do see it in the NEW queue)
[15:15] <zul> mterry:  can we get alembic looked at today as well please?
[15:16] <mterry> zul, oh that is part of nova too?  I hadn't looked at that MIR yet
[15:16] <mterry> zul, sure
[15:16] <zul> mterry:  its apart of quantum actually :)
[15:28] <cjwatson> bdrung: Are you planning to finish the libibmad/libibumad transition, having sponsored syncs of a soname change from experimental last month?
[15:28] <cjwatson> bdrung: It's been sitting in -proposed unmigrated since then.
[15:39] <cjwatson> bdrung: srptools was an easy rebuild so I did that; ibsim and qlvnictools FTBFS
[15:41] <mterry> zul, all approved I believe
[15:42] <zul> mterry: cool thanks
[15:43] <bdmurray> mterry: come to find out there was a 3rd upload of duplicity - https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=duplicity
[15:44] <bdmurray> that one fixes bug 1080423
[15:44] <mterry> bdmurray, yeah, I had done that one a long time ago, and when I made my second upload, I included that fix, obsoleting that guy
[15:44] <mterry> bdmurray, so 2 of the uploads were mine, one was this 07caching.dpatch fix
[15:45] <bdmurray> mterry: okay, so one with all three seems fine to me
[15:45] <mterry> bdmurray, will do
[15:45] <bdmurray> mterry: thanks, just let me know and I'll review it
[15:45] <mterry> bdmurray, k
[15:54] <dbarth> i found my issue; it's a segfault, but visible on the host system, not in the lxc-container!
[16:16] <jamespage> mterry, thanks for the approval of alembic - I just subscribed ubuntu-server team to bug mail
[16:16] <mterry> jamespage, awesome
[16:31] <xnox> ev: is there a way to run  /usr/share/usb-creator/usb-creator-helper under debugger? everytime i start usb-creator-gtk it seems to spawn it's own helper.
[16:33] <ev> xnox: it wont spawn it if there's one already running on the system bus
[16:33] <ev> so just tack a sudo in front of that
[16:33] <xnox> hmm...
[16:34] <roadmr> Hey folks! So I netbooted a uefi installation with a few kernel parameters to boot to a desktop installer over nfs, but once installed, the grub menu entry "inherits" those parameters and won't boot out-of-the box; requires some editing :/
[16:35] <roadmr> is there a way to tell the installer not to "inherit" those grub parameters? it properly ignored e.g. automatic-ubiquity but kept e.g. url, initrd, nfsroot and log_host
[16:36] <xnox> ev: thanks, seems to work. I may have had a stale one already. =))))
[16:36] <mterry> bdmurray, duplicity 0.6.19-0ubuntu2.1 uploaded to quantal-proposed, when you're ready.  I'm preparing a new precise upload too (that combines the two patches uploaded separately there)
[16:36] <mterry> bdmurray, I'll be more careful about checking the queue next time
[16:37] <ev> xnox: yay
[16:38] <xnox> if only dbus.so would stop segfaulting.....
[16:38] <bdmurray> mterry: okay, thanks
[16:42] <cjwatson> roadmr: There's normally a "--" as a boot parameter (certainly is by default), which acts as a separator.  Parameters after that may be copied into the target system; parameters before that won't be.
[16:44] <roadmr> cjwatson: oh, you're absolutely right, I'm putting them *after* the --, I'll try your suggestion, thanks as usual :)
[16:54] <bdrung> cjwatson: i will contact the sponsoree if he is willing to do it (otherwise i probably have to do it)
[17:05] <mterry> bdmurray, and now duplicity 0.6.18-0ubuntu3.1 uploaded to precise-proposed
[17:15] <iBelieve> I just branched apport to work on a bug fix, and am getting the message "OUT-OF-DATE". What does this mean and how does this affect me?
[17:16] <seb128> iBelieve, usually it means the vcs you checked out doesn't have the current version ... what vcs did you branch?
[17:16] <iBelieve> seb128: I ran "bzr branch ubuntu:apport".
[17:17] <seb128> iBelieve, you should probably make your patch against lp:apport
[17:17] <seb128> but dunno why the ubuntu: one is out-of-date
[17:17] <seb128> maybe pitti knows (if he's still around)
[17:18] <iBelieve> seb128: Don't the developer docs (http://developer.ubuntu.com/packaging/html/udd-getting-the-source.html#branching) say to use "ubuntu:"? What is the difference?
[17:19] <seb128> iBelieve, ubuntu: is the packaging branch
[17:19] <seb128> lp:apport is the upstream project branch
[17:19] <seb128> that's less obvious when upstream is on launchpad
[17:21] <iBelieve> seb128: So I can use "lp:apport" instead, and that will work fine for working on a bug fix (LP #657275)?
[17:22] <seb128> iBelieve, yes
[17:22] <iBelieve> seb128: Great, thanks for your help!
[17:23] <seb128> yw
[18:13]  * Laney cries as he abandons trying to work with a SRU bzr branch
[18:13] <Laney> an
[18:15] <xnox> Laney: branch the sponsoree branch, generate source package, generate debdiff against the base, work with that =)
[18:15] <Laney> I got some inexplicable error about .pc
[18:15] <Laney> download diff of the (thankfully single) commit + apply to source package :-)
[18:16] <Laney> branching sponsoree branch + generating diff from that would have also worked
[18:16] <infinity> Which is much simpler anyway. :P
[22:00] <infinity> pitti: You around?
[22:02] <Aeyoun>  Regarding updating a upstream package. I have successfully followed[1] for version 1.0. Now I want to update to 1.1. But there seems to be a step missing regarding using bzr and launchpad on[2]. Is there another document that explains it all? [1] http://developer.ubuntu.com/packaging/singlehtml/index.html#document-ubuntu-packaging-guide/packaging-new-software [2] https://wiki.ubuntu.com/PackagingGuide/Complete#Creating_and_Using_a_deb
[22:02] <Aeyoun> ian.2BAC8-watch_File
[22:02] <Aeyoun> I end up with one packagename/ that is the bzr repo, and one packagename-1.1/ which is not a repo.
[22:07] <infinity> Aeyoun: http://developer.ubuntu.com/packaging/singlehtml/index.html#merging-a-new-upstream-version
[22:24] <Aeyoun> infinity, that would be exactly it. again: thank you so much. :-)
[22:53] <tjaalton> so on raring I have four separate dnsmasq's running, one of which should enable virbr0 for libvirt, but it can't create the socket for it
[22:53] <tjaalton> this was supposed to be fixed ages ago, I think
[22:54] <slangasek> I haven't had any problems with multiple dnsmasqs running
[22:54] <slangasek> the nm one should be bound to a different interface than the virbr0 one
[22:59] <tjaalton> so there's one for lxc, libvirt, nm, and one system-wide?
[23:00] <tjaalton> seems as if it's running one extra
[23:14] <tjaalton> eh, I had both dnsmasq and dnsmasq-base installed for some reason
[23:19] <tjaalton> now it should work, but virtbr0 still doesn't have an address
[23:50] <tjaalton> stopping libvirt-bin probably should stop it's dnsmasq too


[05:45] <mac_v> beuno: hi... this bug's milestone needs to be changed https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/15495
[05:45] <mac_v> its marked incomplete and is in the first milestone
[05:46] <beuno> mac_v, right, maybe...  milestone 8?
[05:47] <mac_v> beuno: maybe even later,10. since it is suggested, it needs user testing
[05:48] <beuno> 9?  :)
[05:48] <djsiegel> I don't think you need to move the bug
[05:48] <mac_v> sure... :)
[05:49] <djsiegel> leave it in its milestone, it was just missed
[05:49] <djsiegel> the 10 milestones are more of a guideline for the design team's involvement
[05:49] <mac_v> djsiegel: beuno also... the context menu is now changed in Karmic to "Compress"
[05:49] <djsiegel> ideally, all paper cuts could get random-access attention
[05:49] <djsiegel> mac_v: are you serious?
[05:49] <mac_v> yeah
[05:49] <djsiegel> it got changed
[05:49] <djsiegel> wow
[05:49] <djsiegel> awesome
[05:50] <djsiegel> ivanka will be psyched
[05:50] <djsiegel> ok I need to sleep
[05:50] <djsiegel> night buys
[05:50] <djsiegel> guys*
[08:26] <mac_v> hi... any channel ops around?
[08:27] <mac_v> beuno: ^
[11:50] <MacSlow> hyperair, I've just pushed your wnck fix to notify-osd trunk (https://bugs.edge.launchpad.net/notify-osd/+bug/401809/comments/1). Thanks!
[11:50] <MacSlow> hyperair, but in the rush I forgot to add you to the Contributor: section in the file-header
[11:51] <hyperair> MacSlow: ah you did eh, thanks. =)
[11:51] <hyperair> MacSlow: take your time for that
[11:51] <MacSlow> hyperair, just fixing that now
[11:52] <hyperair> ah
[11:52] <hyperair> cool =)
[11:55] <MacSlow> hyperair, what's your email?
[11:55] <MacSlow> address
[11:55] <MacSlow> I mean
[11:55] <hyperair> hyperair, gmail
[11:55] <MacSlow> .com?!
[11:55] <hyperair> yes
[11:56] <hyperair><EMAIL_ADDRESS>[11:59] <hyperair> MacSlow: are you going to be releasing soon, or shall i bring the patch forward to ubuntu's notify-osd package?
[12:00] <MacSlow> hyperair, I just did a tarball-release of notify-osd yesterday and only today pushed your patch
[12:01] <MacSlow> unlucky timing
[12:01] <MacSlow> hyperair, but the next tarball release is due in about two weeks, so your patch will certainly be in karmic
[12:02] <hyperair> oh okay then. good to hear. =)
[12:07] <MacSlow> hyperair, http://bazaar.launchpad.net/~notify-osd-developers/notify-osd/main/revision/350
[12:08] <hyperair> thanks. =)
[13:01]  * MacSlow -> lunch
[14:40] <MacSlow> DBO, ping
[17:03] <DBO> MacSlow, pong
[17:03] <MacSlow> DBO, hey there
[17:03] <MacSlow> DBO, was my first patch any good?
[17:04] <DBO> to be honest I have not had time to review it
[17:05] <DBO> been working on canonical stuff like a mad man
[17:05] <MacSlow> DBO, no worries... just wondering
[17:06] <MacSlow> it's not work-related anyway
[17:06] <MacSlow> just some minor spit-and-polish for Docky
[17:08] <DBO> yeah, there is always spit polishing to do =)
[18:16] <DanRabbit1> DBO: ping-a-ling
[20:01] <veritos> Is it planned to attempt to push the new notification system upstream?
[20:02] <beuno> veritos, where is upstream?
[20:03] <veritos> beuno, libnotify maintainers or whoever dealt with the old balloon-style messages
[20:03] <beuno> veritos, this is a whole new system from scratch
[20:11] <tedg> beuno: Apparently you offended him :)
[20:11] <beuno> of course
[20:11] <beuno> he wanted to fight
[20:12] <tedg> He was totally unwilling once he realized you're from Argentina.  Everyone knows they raise amazing IRC battlers there :)
[20:45] <ryanprior> some folks love to rail on any Ubuntu project about their upstream policies
[20:45] <ryanprior> even when they aren't exactly sure what that means in a given scenario


[03:50] <Makalak> guys is ubuntu touch repo being updated?
[03:51] <Makalak> since i cant seem to be able to get it to build
[03:51] <Makalak> i keep getting error about certain files missing.... and after i replace them, that leads to more errors down the line... certain types dont match etc...
[05:36] <JBar> Can I ask a Ubuntu Touch installation newb question here? I have already searched for an answer
[05:39] <lotuspsychje> !devices | JBar
[05:48] <J_Bar> what chat room do i go to for ubuntu touch install questions?
[05:52] <nhaines> J_Bar: depends on the device.
[05:57] <J_Bar> I just installed ubuntu touch to my nexus 4. It went without a hitch. Now, do I need to lock the bootloader after I am done installing it, or is that not even applicable?
[06:03] <nhaines> Not applicable.  Locking the bootloader just prevents you from flashing the device in the future (or until you unlock it).
[06:04] <nhaines> Unlocking it will cause the phone to erase your user data, though, so unless you have an actual security concern, you may want to just leave it unlocked.
[06:05] <J_Bar> Got it. Thank you very much.
[06:05] <nhaines> You're welcome.  Sorry for the delay.  Have a lot of windows open at the moment.  :)
[12:25] <henri> 1
[12:43] <E524> Hi all, happy new year! i don't understand, if i have my device in Developer mode, how can i update the system and it's programs? is there a good read for that?
[12:44] <E524> btw: i have dualboot on a nexus4 if this is important to my question
[12:48] <jgdx> E524, you can use ubuntu-device-flash
[12:48] <jgdx> however, I can't speak for dual booters.
[12:52] <E524> jgdx: thanks, at least i have the key-word i have to search for. google will take it form here ;)
[12:56] <jgdx> E524, right, I think that's in the phablet-tools package
[12:56] <jgdx> which includes gems like phablet-screenshot, phablet-shell and phablet-config :)
[13:00] <E524> jgdx: i see there is a lot to read :)
[14:07] <srwood> #ubuntu-us-tx
[14:31] <damn> help me seeting ubuntu emulator
[15:45] <bentech4you> i have installed ubuntu touch on my nexux 4 from devel channel. how can i enable ssh access.
[15:46] <bentech4you> ssh is running. but when i try to connect to that IP, i am getting error like no authentication mechanism or something liekt hat
[15:47] <bentech4you> is here anyone ? please help me to fix this
[16:30] <aquarius> Elleo, ping: you around?
[17:43] <CarlosMazieri> bentech4you: you can do: "adb shell" then "sudo setprop persist.service.ssh true"
[17:44] <CarlosMazieri> bentech4you: then restart the phone to sedw if that works
[19:50] <Elleo> aquarius: pong
[19:50] <aquarius> Elleo, ah, is ok now, I think I've solved it :)
[19:50] <aquarius> but cheers
[19:51] <Elleo> okay, cool :)
[19:53] <aquarius> progress being made on the community component store, too.
[19:53] <Elleo> aquarius: awesome
[19:53] <aquarius> since you're good with Qt stuff, do you have a little time over tonight or the weekend when I can pick your brains about how best to set it up?
[19:55] <Elleo> sure :)
[19:55] <aquarius> sweet. when's good for you?
[19:55] <Elleo> pretty much any time in the evenings or mornings over the next couple of days
[19:55] <aquarius> oh! cool
[19:56] <aquarius> well, then, here's the thing I'm trying to decide; what should "ucs install" actually do? Specifically, where should it put the component it downloads, and what do I the app developer then have to do to use that component?
[19:58] <aquarius> I personally think that in a perfect world I'd do "ucs install elleo/somecomponent" from the command line while inside an ubutnu sdk project, and that component would be downloaded and put in the folder ubuntu_component_store/elleo/somecomponent/qml/SomeComponent.qml, and then it would magically end up on the import path so that in any other QML file in my app I can just import SomeComponent 1.0.
[19:58] <aquarius> but I'm not sure if that's a correct thing to want -- I'm open to suggestions there -- nor am I sure if that's doable with qmldir magic
[19:59] <aquarius> (obviously it'd work the same way for binary components)
[19:59] <aquarius> how would *you* want it to work?
[19:59] <Elleo> yeah, doing everything automatically might be tricky
[20:00] <aquarius> Example: I create a simple pure QML app, with one main.qml file and that's it. I then want to add two components: sil/RedRectangle (which provides a Rectangle qml object which defaults to red, and is pure QML) and elleo/CommandShell (which provides a binary compiled CommandShell{} Item component).
[20:01] <aquarius> So I do "ucs install sil/RedRectangle; ucs install elleo/CommandShell", and $SOMETHING happens. What would we then want me to have to put in main.qml to import these things?
[20:02] <aquarius> 'import CommandShell 1.0'? ' import "ubuntu_component_store" '? something else?
[20:03] <Elleo> aquarius: I'd guess ideally you want to set the QML2_IMPORT_PATH or qmlscene's -I option to ubuntu_component_store/elleo/somecomponent/ so you can just import "somecomponent"
[20:03] <Elleo> which is something you'd probably do in the .desktop file
[20:03] <aquarius> so you think it's: import "somecomponent"
[20:03] <aquarius> not: import SomeComponent 1.0
[20:03] <aquarius> ?
[20:03] <aquarius> that is: we import a directory, not an actual component?
[20:03] <Elleo> import SomeComponent 1.0
[20:04] <aquarius> ah, OK
[20:04] <Elleo> aquarius: I wasn't really thinking of that side, just the path imports in that example
[20:05] <Elleo> and using QML2_IMPORT_PATH is probably preferable over qmlscene's options, since it'll be available to c++ apps as well then
[20:06] <Elleo> but you're also going to have to make sure those files get installed in the click build dir, which in your simple example might be the current directory anyway requiring no work, but is more likely to involve modifying the cmake/qmake files generated by the SDK
[20:06] <Elleo> since that's how most people are going to start their projects
[20:06] <aquarius> hrm
[20:06] <Elleo> which gets a bit more complicated
[20:06] <aquarius> click build just bundles up the whole folder, I think?
[20:07] <aquarius> QtCreator might pretend it can't see the files if they don't end up in CMakeLists.txt, perhaps
[20:07] <aquarius> which sounds annoying
[20:07] <Elleo> click build will bundle up everything that's in the dir it's run on
[20:07] <aquarius> although perhaps we can do the equivalent of "include: ubuntu_component_store/* !important"
[20:07] <Elleo> but QtCreator will do out of tree builds iirc, so it'll depend if those files get added to the dir QtCreator runs click build on
[20:09] <aquarius> ah, right
[20:09] <Elleo> you can probably have ubuntu_component_store/ containing it's own CMakeLists.txt and ucs.pro file or something, which we modify to handle all ucs components as they get added
[20:09] <aquarius> yeah, it copies stuff to ../build-some-long-stupud-name-whatever-ProjectName-Desktop-i386-whatever
[20:09] <aquarius> forgot about that
[20:10] <Elleo> then you'd just need to detect if it's a qmake or cmake project and add add_directory(ubuntu_component_store) or include(ubuntu_component_store/ucs.pri) or something to the main project file
[20:10] <aquarius> adding its own CMakeLists.txt which we dynamically update as components are installed sounds like a good idea
[20:10] <aquarius> (this is one of the reasons why I wanted to confine it to a separate folder)
[20:12] <Elleo> yeah, keeping it separate seems safest
[20:12] <aquarius> actually...
[20:13] <aquarius> the current folder is in the import path, right?
[20:13] <Elleo> yeah
[20:13] <aquarius> and stuff has to be on the import path in a folder structure which matches its name
[20:13] <aquarius> so can't we just import ubuntu_component_store.Elleo.SomeComponent 1.0?
[20:14] <Elleo> aquarius: I think we could if the qmldir defined the modulename that way, but I wouldn't swear to it
[20:14] <aquarius> and drop a qmldir file in ./ubuntu_component_store with "module ubuntu_component_store" in it?
[20:14] <Elleo> yeah, possibly
[20:14] <aquarius> http://doc.qt.io/qt-5/qtqml-modules-identifiedmodules.html *suggests* that this is the case
[20:14] <aquarius> (we can even call it 'module UCS' which is nicer ;))
[20:15] <Elleo> yeah
[20:15] <Elleo> doing it that way would avoid namespace issues when people create two components with the same name
[20:15] <aquarius> totally
[20:15] <aquarius> this seems doable
[20:15] <aquarius> I shall experiment to see if I have correctly understood import paths.
[20:15] <aquarius> and the cmake/qmake stuff.
[20:16] <Elleo> cool, let me know if you hit any snags :)
[20:16] <aquarius> will do. Might be tomorrow before I get to it :)
[20:16] <aquarius> this was helpful! cheers
[20:16] <Elleo> glad to be useful :)
[21:06] <wwwt> hi, i am new here
[21:08] <popey> hello wwwt
[21:08] <wwwt> probably question about samsung galaxy s3 has been rised few times but if someone show me the right way to move from android to ubuntu touch i promise to not ask more stupid questions
[21:09] <popey> !devices
[21:09] <popey> that page lists supported devices
[21:11] <wwwt> ok, so the lastes version is from 2013?
[21:11] <wwwt> latest*
[21:31] <aquarius> Elleo, so, imagine you've done "ucs install sil/RedRectangle", and now you want to use that new RedRectangle component in your QML file. Would you prefer: import "ubuntu_component_store"; SilRedRectangle {}       or      import ubuntu_component_store.sil.RedRectangle 1.0; RedRectangle {}      ?
[21:31] <aquarius> Elleo, I'm not sure I'm happy with either of them
[21:32] <aquarius> maybe: import "ubuntu_component_store/sil" as sil; sil.RedRectangle {}   ? (not sure if that can even work)
[21:34] <aquarius> Elleo, it'd be          import "ubuntu_component_store/sil" as Sil; Sil.RedRectangle {}             (namespaces have to begin with a capital letter)
[21:35] <aquarius> nik90_, also interested in your opinion on that
[21:36]  * nik90_ reads backlog
[21:38] <nik90_> aquarius: I would imagine importing "Ubuntu.Component.Store.Sil" as Sil; Sil.RedRectangle{} would work
[21:39] <nik90_> it follows the same format as the ubuntu sdk
[21:39] <aquarius> ooh, you think?
[21:39] <nik90_> import Ubuntu.Components.ListItems
[21:39] <nik90_> as ListItem
[21:39] <nik90_> and then ListItem.SubtitledP
[21:39] <aquarius> that needs versioning, though
[21:40] <aquarius> so it'd be: import ubuntu_component_store.sil 1.0 as Sil
[21:40] <aquarius> which can't work because there isn't one version number for all my components....
[21:40] <nik90_> hmm true
[21:41] <aquarius> So your options are, I think, these three (but please say what you *want* to type if it isn't any of them, and I'll see if it's doable!)
[21:42] <Elleo> aquarius: I have thought long and hard, and decided I don't really have a preference ;)
[21:42] <aquarius> 1. import "ubuntu_component_store"; SilRedRectangle {}
[21:42] <aquarius> 2. import ubuntu_component_store.sil.RedRectangle 1.0; RedRectangle {}
[21:42] <aquarius> 3. import "ubuntu_component_store/sil" as Sil; Sil.RedRectangle {}
[21:42] <aquarius> I do not like number 1; it means munging the component name to not have a dot in it.
[21:43] <aquarius> tbh I like number 2 the most, it's just a bit verbose.
[21:43] <nik90_> I would prefer option 2
[21:43] <nik90_> but we need to plan out how the versioning of components would work
[21:44] <aquarius> number 3 is OK, though, if everyone else prefers it -- my problem with it is that it *requires* capitalising the username, which looks weird.
[21:44] <Elleo> aquarius: as far as verbosity goes 2 is less verbose than 3 where it counts in actual usage, since RedRectangle/Sil.RedRectangle is what you'll be using everywhere whereas the import statement only happens once
[21:44] <aquarius> Elleo, yeah, and it's very clear where the component is coming from, too
[21:45] <Elleo> and 3 gets worse with usernames longer than Sil
[21:45] <nik90_> aquarius, Elleo: Btw it has to be Sil.RedRectangle{} when using that component in the code since multiple components could use the same name "RedRectangle" thereby leading to confusion
[21:45] <aquarius> nik90_, component versioning is fine -- we'll require a version number in the community component's manifest file (and define a storage place for one in the curated components), and then set that correctly in the qmldir file I create.
[21:46] <nik90_> ok
[21:46] <Elleo> nik90_: if you have two competing ones you could still do import ubuntu_component_store.sil.RedRectangle 1.0 as SilRedRectangle to disambiguate
[21:47] <nik90_> ack.
[21:47] <aquarius> nik90_, duplicate names is not a problem -- if you ucs install nik90/RedRectangle and sil/RedRectangle, then you do: import ubuntu_component_store.sil.RedRectangle 1.0 as S; import ubuntu_component_store.nik90.RedRectangle as N; N.RedRectangle{}; S.RedRectangle{}
[21:47] <aquarius> most of the time you won't have to -- only if you import two components with the same name but different authors, which ought to be pretty rare anyway :)
[21:47] <aquarius> OK. We'll go with version 2. :)
[21:48] <aquarius> is "ubuntu_component_store" too long, do we think? UCS would be nicer, but it's a bit more generic, especially since there must be a top-level folder named that.
[21:49] <aquarius> and requiring ubuntu_component_store makes it a bit more obvious.
[21:50] <nik90_> well you only require one import statement per file
[21:50] <nik90_> so I would go with ubuntu_component_store
[21:51] <aquarius> *nod*
[21:51] <nik90_> with a dot if possible
[21:51] <aquarius> OK, now to work out the harder bit, which is binary components and how to put them on the import path ;)
[21:52]  * nik90_ goes to read aquarius blog post for recap
[21:52] <Elleo> aquarius, nik90_: sorry, vm died so I probably missed stuff
[21:52] <aquarius> Elleo, we decided that option 2 was best :)
[21:52] <Elleo> okay, cool
[21:53] <nik90_> Elleo: u dint miss much..option 2 and import with "Ubuntu_Component_Store" and not "UCS" as it is too short
[21:53] <aquarius> I now need to work out where .so files need to live to end up on the import path :)
[21:54] <Elleo> aquarius: for automatic multiarch stuff I think you're limited to putting them in lib/<arch>/ I guess you might want to enforce some naming on the libs to avoid namespace conflicts though
[21:54] <Elleo> like libucssilredrectangle.so
[21:55] <aquarius> Elleo, do you know how that works? is lib/$arch/ on the import path becuase Qt puts it there or because Ubuntu puts it there?
[21:55] <aquarius> I wonder if I can do something with qmldir again as I have with QML things
[21:55] <Elleo> aquarius: I would assume ubuntu puts it there
[21:55] <Elleo> aquarius: but I don't really know anything about that side of things, that's just my suspicioun
[21:56] <Elleo> suspicion*
[21:57] <aquarius> aha, multi/lib/$arch according to balloons' click package thing
[21:58] <aquarius> but that may be where it is in the click package but not on the filesystem
[21:58] <aquarius> hrm
[21:59] <aquarius> I wonder who knows about this stuff? Colin will know something but I'm not asking him because he is not the Man any more. I can never get good answers out of bzoltan_ ;-)
[22:00] <aquarius> beuno, who knows about arch-specific stuff in QtCreator?
[22:01] <aquarius> aha, balloons' multi-arch click package is instructive
[22:01] <aquarius> although there is no multi folder in it, balloons, you big liar!
[22:19] <aquarius> goldarnit, something somewhere does some magic to put lib/$arch on the import path. I do not know if that's even doable with a pure QML project which doesn't have any cmake files or anything
[22:20] <aquarius> and it's hard to find information about this because half the docs, as usual, say that you should already have been using c++ and cmake and if you weren't then you are a loser. :(
[22:31] <aquarius> tedg, ping about how Unity actually launches a QML app: in particular, I think it adds lib/$arch folders to the import path, but I do not know *how* it does this, and you might.
[22:34] <nhaines> I think it also does a few thousand NOOPs before it launches the app.
[22:45] <aquarius> nhaines, ?
[22:49] <dobey> aquarius: i think they're added by qtubuntu plug-in
[22:50] <aquarius> dobey, there is stuff in the cmake files to add bits to the import path, but I do not think that the default setup for such projects builds them as qml plugins; they're qml extensions, which isn't quite the same thing.
[22:50] <dobey> huh?
[22:50] <dobey> pure qml things are not arch specific so lib/$arch is irrelevant
[22:51] <dobey> and i meant the plug-in to qt, not the qtcreator bits to make ubuntu-sdk
[22:51] <aquarius> dobey, ah, that's useful; I didn't know there was a plugin to qt
[22:51] <dobey> if you have pure qml components, then "components/" is added to the import path for those, iirc
[22:52] <aquarius> dobey, more importantly, projects without a cmake file at all (that is: pure qml projects) don't put any folder for compiled binary plugins onto the import path.
[22:52] <dobey> why wouldn't it have a cmake file?
[22:52] <aquarius> nah, components/ isn't added by magic; you import it with ' import "components" '. I understand that bit of it :)
[22:52] <nhaines> aquarius: just a slow launch joke.
[22:52] <aquarius> apps which only use qml don't need a cmake file, and don't have one.
[22:53] <aquarius> nhaines, ah, gotcha :)
[22:54] <dobey> well, the sdk is cheating there and using the qtcreator .qmlproject stuff, sure
[22:54] <aquarius> yeah. Third party components need to be an "Extension Plugin": http://doc.qt.io/qt-5/qtqml-tutorials-extending-qml-example.html#chapter-6-writing-an-extension-plugin -- a subclass of QQmlExtensionPlugin.
[22:55] <dobey> i think all the projects created by the sdk, for "ubuntu" projects, should have cmake files, and be relatively similar. becuase right now if you create a pure qml plug-in then later decide you need to add some c++, it's a huge pain in the arse to do
[22:55] <dobey> as you are apparently discovering
[22:56] <dobey> :)
[22:56] <aquarius> but this doesn't really deal with multi-arch stuff here; it deals with multi *platform* stuff OK, in that you define your plugin with a basename ("silplugin") and then Qt takes care of loading silplugin.so on Linux and silplugin.dll on Windows. But it doesn't deal with multiarch at all, which is annoying.
[22:56] <dobey> "this" ?
[22:56] <aquarius> so the Qt people are happy for me to build an app which can be deployed as-is to both Windows and x86 Linux, but not one which can be deployed as is to both ARM Linux and x86 Linux. Irritated.
[22:57] <dobey> well, that's a bit expected
[22:57] <dobey> you're trying to do something with ubuntu sdk apps
[22:57] <dobey> the upstream qt docs doesn't know anything about ubuntu sdk apps :)
[22:58] <aquarius> this is a Qt/QML thing; I'm not doing anything Ubuntu-specific here.
[23:01] <dobey> what are you trying to do exactly anyway? you are pulling random .so files out of .bzr as "components" (or whatever you're calling them), have a pure qml project, and are trying to import them, but the SDK won't add the import paths you need to add?
[23:02] <aquarius> sort of.
[23:03] <aquarius> If the whole world was x86_64, then what I would do is just drop the libMyComponent.so into ubuntu_component_store/MyComponent along with a qmldir file which said "plugin MyComponent", and then everything's fine: a QML file in that project can just do "import MyComponent 1.0", and everything works.
[23:05] <aquarius> The issue is that, of course, we need multiple versions of the component for different arches. So I *believe* that the Unity launcher executes a QML app with qmlscene and silently adds a "-I lib/$arch" parameter to make sure that the appropriate version of a plugin is imported.
[23:05] <dobey> unity doesn't do anything additional to launch apps
[23:05] <dobey> it simply does standard fd.o .desktop file launching stuff
[23:05] <aquarius> it might be in upstart-app-launch or something
[23:06] <dobey> i don't think it adds an -I to qmlscene
[23:06] <dobey> you can verify that by running such an app on the phone, and just poking at /proc to look at the process arguments for the pid
[23:06] <aquarius> or perhaps you're right and we do nothing at all in the launch process to put lib/$arch on the import path. If that's the case then either our Qt is patched to do it, or I can't see how any apps which import a plugin actually work (because the plugins aren't on the import path)
[23:07] <aquarius> ooh, that's a good thought, looking in /proc
[23:07] <aquarius> I'll do that.
[23:07] <aquarius> well, hm
[23:07] <aquarius> it is possible that we do something special for fat click packages, and I haven't got any
[23:07] <dobey> but i'm pretty certain the "lib/$arch" import path is added by the qtubuntu plug-in to qt
[23:08] <aquarius> that sounds useful
[23:08] <aquarius> is that added on the phone only? or would it also be the case on the desktop?
[23:08] <dobey> the plug-in should be installed if you have the sdk installed at least (not sure if it's installed by default otherwise, but probably is)
[23:09] <aquarius> I should note that I have tried dropping a compiled plugin into lib/$arch with a qmldir file and importing it, and it doesn't work. But I do not know if it's not supposed to work or if it is and I'm doing something wrong :)
[23:09] <aquarius> (specifically, the import statement doesn't find the plugin)
[23:11] <dobey> oh maybe it's not installed; i see qtubuntu-desktop wasn't installed on my machine anyway
[23:11] <dobey> at least i *think* that is what does the magic
[23:12] <dobey> aquarius: if you have latest terminal version installed on your phone, then it should be a fat click i think
[23:13] <dobey> hmm, or not
[23:14] <dobey> or click is doing magic to not install the irrelevant arch directories
[23:14] <dobey> but i suspect that's not the case
[23:15] <aquarius> but *something* weird is going on with imports. Because if I make a pure QML app, and then make pure QML components which are qmldir'ed onto the import path, and then run it *with qt creator*, it works... but "qmlscene main.qml" from bash fails to find the extra components.
[23:15] <dobey> right
[23:15] <aquarius> finding how anything works in qtcreator is a nightmare, though
[23:16] <dobey> look at your .desktop file and the .qmlproject file
[23:18] <aquarius> not quite what I meant. In Projects > Run there's a "Run configuration", and "QML Scene" is selected, which is fine... but I can't find what the "QML Scene" run configuration actually *does*. It doesn't seem to be editable, or listable; I think it might be hardcoded into Qt Creator.
[23:21] <dobey> if you build a click and install it on a device, does it work when you launch it from unity?
[23:25] <aquarius> as in, a multiarch click?
[23:25] <aquarius> I haven't tried that yet
[23:26] <dobey> as in whatever you claim works under qtcreator, but not when running just "qmlscene foo"
[23:26] <aquarius> good question
[23:26] <aquarius> I will try that
[23:27] <aquarius> also, there appears to be no way in qtcreator to list what a "run configuration" actually does, at all :(
[23:27] <dobey> i think a) the .desktop adds an -I for some directory, and b) the qtubuntu-desktop plug-in does soemthing (but i don't know which code might be adding it exactly, or if it's just apparmor doing)
[23:28] <aquarius> aaargh this is so infuriating
[23:29] <dobey> eh, this isn't even a /hard/ problem :)
[23:30] <aquarius> I both agree and disagree with that -- I am confident that what I'll actually need to do to resolve it is just add one line to one file somewhere and it'll all work. But this sort of problem, where you've got no idea where to even look, I always find a lot harder than ones where I know what to do but I need to work out complex stuff to actually do it :)
[23:32] <dobey> you shouldn't have to look anywhere to make it work
[23:32] <dobey> it should just work
[23:32] <aquarius> I agree. Nonetheless it does not :)
[23:33] <dobey> well, that said, i wouldn't expect opening a terminal and typing "qmlscene foo.qml" to necessarily work
[23:38] <aquarius> I wish I didn't always come up with this stuff in the dead air period at new year. )
[23:39] <dobey> well look at it this way. if you were doing the same thing with python, i wouldn't expect "python app.py" to work without adding the extra import paths either
[23:40] <aquarius> yeah. I don't mind that much that extra import paths are being added; I mind that they're being added by invisible magic that I can't find :)
[23:40] <dobey> are you trying to do something where you have a different import path, other than under lib/$arch, when running from a click package?
[23:41] <aquarius> no. I want whatever I do to work everywhere -- I do not want to have to set things up twice, once for running from qtc and once from an installed click.
[23:41] <aquarius> I am starting to believe that that's precisely how ubuntu sdk apps work, though
[23:42] <aquarius> am trying the pure-qml-import-components-with-qmldir thing in the emulator.
[23:42] <aquarius> aha!
[23:43] <aquarius> it works in the emulator
[23:43] <aquarius> but not with just "qmlscene main.qml". So we're doing *something* different somewhere.
[23:43] <aquarius> small piece of knowledge, but useful.
[23:44] <dobey> i still don't really understand what you're trying to do exactly
[23:45] <dobey> meh, i forget how to make the proc environ file readable
[23:47] <aquarius> you're right; no import magic going on with pure qml apps. It's all working correctly with just the qmldir stuff. Which is what I would expect to happen.
[23:47] <dobey> so on the phone, QML2_IMPORT_PATH and LD_LIBRARY_PATH have the click package's lib/$arch directory
[23:48] <aquarius> ooh! do they?
[23:48] <aquarius> how do you know? looking in /proc/X/env or something?
[23:48] <dobey> i'm guessing qtcreator probably adds the project dir to it
[23:48] <dobey> yes
[23:48] <dobey> ML2_IMPORT_PATH=/usr/lib/arm-
[23:48] <dobey> linux-gnueabihf/qt5/imports:/opt/click.ubuntu.com/.click/users/phablet/com.ubunt
[23:48] <dobey> u.terminal/lib/arm-linux-gnueabihf
[23:48] <dobey> gah terminals
[23:49] <aquarius> ugh, it's all one big long string
[23:49] <aquarius> ah, with nulls in.
[23:49] <dobey> it's a PATH-style varaible
[23:50] <aquarius> QML2_IMPORT_PATH=/usr/lib/i386-linux-gnu/qt5/imports:/opt/click.ubuntu.com/.click/users/phablet/com.ubuntu.developer.sil.simple-ui/lib/i386-linux-gnu
[23:50] <aquarius> indeed
[23:50] <aquarius> there's the lib folder
[23:50] <aquarius> so... what sets that, I wonder?
[23:51] <aquarius> there's nothing in the click package itself that sets it. It's being set by *something* in the app startup process
[23:53] <dobey> click-apparmor: /usr/bin/aa-exec-click
[23:53] <dobey> that's what sets it
[23:54] <aquarius> well found!
[23:54] <aquarius> right. So that's how it works on the phone
[23:54] <dobey> and when you install a click, the hook rewrites the Exec line
[23:55] <dobey> debs are not a supported target for ubuntu sdk apps
[23:55] <dobey> so if you want to do the same thing in a deb package, you need to manually add stuff to do that
[23:56] <aquarius> I'm not worried about deb packages. What I want is for that same path to be added to the QML2_IMPORT_PATH when running the app from Qt Creator.
[23:56] <aquarius> and how best to do that from a command-line utility
[23:57] <aquarius> projectname.qmlproject has importPaths in it -- I think it'd be best to tweak that
[23:58] <dobey> you could tweak the qmlproject yes
[23:58] <dobey> (i told you to look at the qmlproject file earlier :P)
[23:58] <aquarius> you did, and I did, and that's how I know it has importPaths in it :)
[23:59] <aquarius> I was hoping there was a way to do this which worked in both places (in qtc and in the deployed app), but there clearly isn't. :)


[03:51] -queuebot:#ubuntu-release- Unapproved: intel-microcode (impish-security/main) [3.20220510.0ubuntu<IP_ADDRESS> => 3.20220510.0ubuntu<IP_ADDRESS>] (core) (sync)
[03:54] -queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [sync] (impish-security) [3.20220510.0ubuntu<IP_ADDRESS>]
[04:20] -queuebot:#ubuntu-release- Unapproved: intel-microcode (bionic-security/main) [3.20220510.0ubuntu<IP_ADDRESS> => 3.20220510.0ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server) (sync)
[04:20] -queuebot:#ubuntu-release- Unapproved: intel-microcode (focal-security/main) [3.20220510.0ubuntu<IP_ADDRESS> => 3.20220510.0ubuntu<IP_ADDRESS>] (core) (sync)
[04:21] -queuebot:#ubuntu-release- Unapproved: intel-microcode (jammy-security/main) [3.20220510.0ubuntu<IP_ADDRESS> => 3.20220510.0ubuntu<IP_ADDRESS>] (core) (sync)
[04:21] -queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [sync] (bionic-security) [3.20220510.0ubuntu<IP_ADDRESS>]
[04:21] -queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [sync] (focal-security) [3.20220510.0ubuntu<IP_ADDRESS>]
[04:22] -queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [sync] (jammy-security) [3.20220510.0ubuntu<IP_ADDRESS>]
[05:19] -queuebot:#ubuntu-release- New binary: rust-combine [amd64] (kinetic-proposed/none) [4.6.4-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: rust-combine [s390x] (kinetic-proposed/none) [4.6.4-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New: accepted glom [arm64] (kinetic-proposed) [1.30.4-7]
[05:29] -queuebot:#ubuntu-release- New: accepted glom [ppc64el] (kinetic-proposed) [1.30.4-7]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-combine [amd64] (kinetic-proposed) [4.6.4-1]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-cookie [arm64] (kinetic-proposed) [0.16.0-1]
[05:29] -queuebot:#ubuntu-release- New: accepted glom [armhf] (kinetic-proposed) [1.30.4-7]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-combine [s390x] (kinetic-proposed) [4.6.4-1]
[05:29] -queuebot:#ubuntu-release- New: accepted glom [s390x] (kinetic-proposed) [1.30.4-7]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-cookie [riscv64] (kinetic-proposed) [0.16.0-1]
[05:29] -queuebot:#ubuntu-release- New: accepted blag [amd64] (kinetic-proposed) [1.3.1]
[05:29] -queuebot:#ubuntu-release- New: accepted i2masschroq [arm64] (kinetic-proposed) [0.4.54-1]
[05:29] -queuebot:#ubuntu-release- New: accepted i2masschroq [ppc64el] (kinetic-proposed) [0.4.54-1]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-cookie [amd64] (kinetic-proposed) [0.16.0-1]
[05:29] -queuebot:#ubuntu-release- New: accepted rust-cookie [s390x] (kinetic-proposed) [0.16.0-1]
[05:29] -queuebot:#ubuntu-release- New: accepted xtpcpp [armhf] (kinetic-proposed) [0.4.53-1]
[05:29] -queuebot:#ubuntu-release- New: accepted glom [amd64] (kinetic-proposed) [1.30.4-7]
[05:30] -queuebot:#ubuntu-release- New: accepted i2masschroq [s390x] (kinetic-proposed) [0.4.54-1]
[05:30] -queuebot:#ubuntu-release- New: accepted xtpcpp [arm64] (kinetic-proposed) [0.4.53-1]
[05:30] -queuebot:#ubuntu-release- New: accepted i2masschroq [armhf] (kinetic-proposed) [0.4.54-1]
[05:30] -queuebot:#ubuntu-release- New: accepted rust-cookie [ppc64el] (kinetic-proposed) [0.16.0-1]
[05:30] -queuebot:#ubuntu-release- New: accepted i2masschroq [amd64] (kinetic-proposed) [0.4.54-1]
[05:30] -queuebot:#ubuntu-release- New: accepted xtpcpp [ppc64el] (kinetic-proposed) [0.4.53-1]
[05:30] -queuebot:#ubuntu-release- New: accepted xtpcpp [amd64] (kinetic-proposed) [0.4.53-1]
[05:30] -queuebot:#ubuntu-release- New: accepted xtpcpp [s390x] (kinetic-proposed) [0.4.53-1]
[05:33] -queuebot:#ubuntu-release- New binary: rust-combine [arm64] (kinetic-proposed/none) [4.6.4-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: rust-combine [armhf] (kinetic-proposed/none) [4.6.4-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: rust-combine [ppc64el] (kinetic-proposed/none) [4.6.4-1] (no packageset)
[06:24] <amurray> RAOF: hey is it normal for the intel-microcode packages which you sponsored last week to still show as being in proposed - https://launchpad.net/ubuntu/+source/intel-microcode ?
[06:34] <RAOF> Hm. I'd expect them to get removed from -proposed after they finished phasing?
[06:34] <RAOF> amurray: That said, [this](https://people.canonical.com/~ubuntu-archive/pending-sru.html#cleanup) shows them as candidates for cleanup; there's nothing that *you* need to do.
[06:36] <amurray> RAOF: ok no worries - thanks for taking a look
[06:39] <RAOF> Yeah, everything is properly in -updates.
[08:47] <jibel> SRU team, could anyone review/approve golang-1.18 in the focal queue?
[08:47] <jibel> new queue
[09:57] <fheimes> @ubuntu-sru: hi, there is a pair of s390-tools / s390-tools-signed packages in the unapproved queue for jammy, would you mind having a look at it and ideally approve, please? thx
[11:17] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.8~18.04.1 => 27.9~18.04.1] (core)
[11:17] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.8~20.04.1 => 27.9~20.04.1] (core)
[11:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (impish-proposed/main) [27.8~21.10.1 => 27.9~21.10.1] (core)
[11:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (jammy-proposed/main) [27.8~22.04.1 => 27.9~22.04.1] (core)
[11:18] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.8~16.04.1 => 27.9~16.04.1] (no packageset)
[13:22] -queuebot:#ubuntu-release- New: accepted oem-somerville-beric-tgl-meta [sync] (focal-proposed) [20.04~ubuntu1]
[13:25] -queuebot:#ubuntu-release- New: accepted oem-somerville-bowen-meta [sync] (focal-proposed) [20.04~ubuntu1]
[13:33] -queuebot:#ubuntu-release- New: accepted oem-somerville-davos-adl-meta [sync] (focal-proposed) [20.04~ubuntu1]
[13:53] -queuebot:#ubuntu-release- New: accepted oem-somerville-kingdra-adl-wave2-meta [sync] (focal-proposed) [20.04~ubuntu1]
[13:56] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-baba-meta [sync] (focal-proposed) [20.04~ubuntu1]
[14:04] -queuebot:#ubuntu-release- New binary: oem-somerville-beric-tgl-meta [amd64] (focal-proposed/universe) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:04] -queuebot:#ubuntu-release- New binary: oem-somerville-davos-adl-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:04] -queuebot:#ubuntu-release- New binary: oem-somerville-bowen-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:06] -queuebot:#ubuntu-release- New binary: oem-somerville-kingdra-adl-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:06] -queuebot:#ubuntu-release- New binary: oem-sutton.simon-baba-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:06] -queuebot:#ubuntu-release- New binary: oem-somerville-kingdra-adl-wave2-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:20] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (jammy-proposed) [27.9~22.04.1]
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (focal-proposed) [27.9~20.04.1]
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (impish-proposed) [27.9~21.10.1]
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (bionic-proposed) [27.9~18.04.1]
[14:22] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cage-meta [sync] (focal-proposed) [20.04~ubuntu1]
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (xenial-proposed) [27.9~16.04.1]
[14:33] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-cage-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[14:37] -queuebot:#ubuntu-release- New: accepted oem-somerville-beric-tgl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-somerville-davos-adl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-somerville-kingdra-adl-wave2-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-baba-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-somerville-bowen-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-cage-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[14:37] -queuebot:#ubuntu-release- New: accepted oem-somerville-kingdra-adl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[15:06] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [amd64] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[15:06] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [s390x] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[15:08] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [ppc64el] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[15:08] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [armhf] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[15:11] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [arm64] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[15:38] -queuebot:#ubuntu-release- New binary: dd-opentracing-cpp [riscv64] (kinetic-proposed/universe) [1.3.1-2] (no packageset)
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [amd64] (kinetic-proposed) [1.3.1-2]
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [armhf] (kinetic-proposed) [1.3.1-2]
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [riscv64] (kinetic-proposed) [1.3.1-2]
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [arm64] (kinetic-proposed) [1.3.1-2]
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [s390x] (kinetic-proposed) [1.3.1-2]
[16:37] -queuebot:#ubuntu-release- New: accepted dd-opentracing-cpp [ppc64el] (kinetic-proposed) [1.3.1-2]
[16:38] -queuebot:#ubuntu-release- New: accepted rust-combine [arm64] (kinetic-proposed) [4.6.4-1]
[16:38] -queuebot:#ubuntu-release- New: accepted rust-combine [ppc64el] (kinetic-proposed) [4.6.4-1]
[16:38] -queuebot:#ubuntu-release- New: accepted rust-combine [armhf] (kinetic-proposed) [4.6.4-1]
[17:27] -queuebot:#ubuntu-release- New binary: sssd [amd64] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[17:27] <sergiodj> vorlon: FWIW: sssd uploaded (https://launchpad.net/ubuntu/+source/sssd/2.7.1-2ubuntu1/+build/24097136)
[17:29] -queuebot:#ubuntu-release- New binary: sssd [ppc64el] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[17:31] -queuebot:#ubuntu-release- New binary: sssd [s390x] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[17:34] -queuebot:#ubuntu-release- New binary: sssd [arm64] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[17:36] -queuebot:#ubuntu-release- New binary: sssd [armhf] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[18:43] <vorlon> sergiodj: whitelisted; jose should attempt a build shortly https://launchpad.net/ubuntu/+source/jose/11-2/+build/24097239
[18:47] -queuebot:#ubuntu-release- New binary: sssd [riscv64] (kinetic-proposed/main) [2.7.1-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[18:56] -queuebot:#ubuntu-release- Packageset: Removed libhash-fieldhash-perl from i386-whitelist in kinetic
[18:56] -queuebot:#ubuntu-release- Packageset: Removed libmoox-struct-perl from i386-whitelist in kinetic
[18:56] -queuebot:#ubuntu-release- Packageset: Removed libnamespace-autoclean-perl from i386-whitelist in kinetic
[18:56] -queuebot:#ubuntu-release- Packageset: Removed libobject-id-perl from i386-whitelist in kinetic
[18:56] -queuebot:#ubuntu-release- Packageset: Added jose to i386-whitelist in kinetic
[21:19] <athos_> Hi ubuntu-archive :) Could anyone please take a look at LP: #1931315 (it is a request to remove adldap2 from kinetic)?