[01:51] <shakaran> Is present some member of notify-osd team here? I would some dev comment about this bug https://bugs.launchpad.net/liferea/+bug/1189281
[03:12] <mwhudson> has anyone nicked the python systemtap support from fedora for debian/ubuntu?
[04:14] <vipzrx> hello
[04:15] <vipzrx> does anyone port the ubuntu core 12.04 to the pandaboard es ?
[04:16] <vipzrx> Guest68: hello
[04:18] <vipzrx> awz: hello
[04:21] <vipzrx> anybody here ?
[04:23] <foka> vipzrx, Hello!
[04:23] <vipzrx> foka: are you a robot ?
[04:24] <foka> vipzrx, Are you?  :-p
[04:24] <sarnold> vipzrx: I installed 12.04 LTS on my Pandaboard ES without trouble
[04:24] <vipzrx> ok ! I need your help
[04:25] <sarnold> I can try, but since the whole thing Just Worked, I didn't actually learn much about the pandaboard itself in the process :)
[04:25] <foka> vipzrx, It seems there are already many success stories of installing Ubuntu 12.04 on PandaBoard ES.  A quick Google search returns various articles, such as this one: http://softswagen.wordpress.com/2013/02/21/how-to-install-ubuntu-12-04-lts-on-pandaboard-es/
[04:25] <vipzrx> http://omappedia.org/wiki/OMAP_Ubuntu_Core
[04:25] <vipzrx> I follow this url
[04:25] <sarnold> (I've also upgraded to 12.10, so I don't have 12.04 LTS answers at the ready...)
[04:28] <sarnold> vipzrx: if you don't mind getting the full desktop environment instead, you can start here: http://cdimage.ubuntu.com/releases/12.04/release/
[04:29] <sarnold> vipzrx: Texas Instruments OMAP4 (Hard-Float) preinstalled desktop image -- you can just dd that to a CF card and boot
[04:30] <vipzrx> sarnold:  thank you for your answer in advance
[04:31] <vipzrx> the url you sent me is ok
[04:32] <vipzrx> and I have been successfully make the  ubuntu desktop version running on my panda4460
[04:32] <vipzrx> now I want to build from the ubuntu core to reduce the size of ubuntu
[04:32] <sarnold> vipzrx: aha :)
[04:33] <sarnold> vipzrx: are you doing this just for yourself, on the one machine, or for a product or something that must be easily rebuildable, for lots of people or products?
[04:33] <sarnold> vipzrx: you could just start with your desktop and apt-get purge packages that you do not want to keep.
[04:34] <vipzrx> I do it for myself
[04:35] <sarnold> okay :) and do you want to do it to learn more about the pandaboard, or do you just want the size reduction? :)
[04:39] <vipzrx> both
[04:40] <vipzrx> http://paste.ubuntu.com/5750547/  the log from the serial console
[04:40] <sarnold> aha, then going through the more complicated instructions on the omappedia website make sense..
[04:40] <vipzrx> when I boot the pandaboard
[04:40] <vipzrx> he he
[04:41] <sarnold> hrm, I wonder why you don't have a modules.dep file.
[04:43] <vipzrx> in the url，图和is
[04:43] <vipzrx> in the url I refered , there is nothing  about it
[04:45] <vipzrx> $ ls lib/modules/
[04:45] <vipzrx> $
[04:46] <sarnold> oh! you don't have -any- modules. that's definitely odd.
[04:46] <sarnold> the linux-image-3.2.0-1412-omap4 package should have installed the modules..
[04:46] <vipzrx> how can I do it to install the lost package ?
[04:48] <sarnold> vipzrx: normally, I'd say to stick the memory card into another computer, mount it, chroot there, and then run dpkg -i to install the package.. but that will be difficult if you do not have a second ARM board around..
[04:49] <sarnold> vipzrx: how much work would it be to start over? (at least, I assume their rules _can_ get you to a booted system)
[04:51] <vipzrx> ok
[04:51] <vipzrx> https://wiki.ubuntu.com/Core/InstallationExample
[04:51] <sarnold> vipzrx: sorry, it is time for me to go; have a good day, I hope you can solve this quickly :)
[04:52] <sarnold> vipzrx: oh! nice
[04:52] <sarnold> vipzrx: step #6 is very much like I suggested .. but I think it would really only work well if you have another ARM computer :)
[04:52] <vipzrx> ok thank you
[04:53] <sarnold> vipzrx: good luck :)
[05:24] <pitti> Good morning
[05:35] <ricotz> pitti, morning
[05:36] <ricotz> pitti, did you know about problems with network-manager after updating to systemd 204-0ubuntu3
[05:37] <pitti> ricotz: no, I don't; it seems to work fine here at least, and I didn't hear complaints yet
[05:37] <pitti> ricotz: ubuntu3 didn't change anything specific at runtime, that was just a d-i fix
[05:37] <ricotz> pitti, i see, i reverted to 204-0ubuntu2 at the weekend to make it work again
[05:37] <pitti> cjwatson: ^ thanks for this!
[05:38] <ricotz> could be related to using 3.10rc4 though
[05:38] <pitti> cjwatson: BTW, on Friday you said that pam_getenv was broken; it seems to work quite well here, what did you mean specifically? there's no debian or ubuntu bug about it
[05:39] <ricotz> pitti, ok, then it might be a glitch caused by something else
[07:09] <tvoss> cjwatson, ping
[07:17] <dholbach> good morning
[07:17] <tvoss> dholbach, guck guck :)
[07:17] <dholbach> hey tvoss :)
[07:20] <mlankhorst> morning
[08:03] <pitti> rbasak, cjwatson: I have http://paste.ubuntu.com/5750880/ now, tested in current sid and saucy; I can't see anything wrong with pam_getenv (but I protected the call against failures anyway)
[08:15] <mitya57> Mirv: Can we sync the new qtscript from Debian?
[08:17] <mitya57> (Or do you want to upload 5.1 instead?)
[08:18] <Mirv> mitya57: sure we could, at least that would get rid of ubuntu version number even though otherwise the -2 should be same as 0ubuntu1 (not sure about the symbols files)
[08:18] <Mirv> mitya57: current estimate is that we'd stick with 5.0.2 for a while, backporting patches, and maybe around 5.1.1 upgrade to 5.1
[08:18] <mitya57> Mirv: ok, syncing then
[08:19] <Mirv> that'd seem a safe route to stay about regression free when Qt5 most of all currently serves Ubuntu Touch efforts
[08:19] <Mirv> mitya57: thanks a lot!
[08:20] <mitya57> Error: The checksums of the Debian and Ubuntu packages mismatch — so it will probably be a fakesync
[08:20] <Mirv> ah, I couldn't get the same orig tarball from NEW :(
[08:21] <Mirv> is there a place to get the files uploaded to Debian NEW queue?
[08:22] <mitya57> Mirv: by the way, lisandro has mostly implemented .qch documentation building in submodules — I will try to merge those into Ubuntu when it's ready
[08:24] <mitya57> fakesync'd
[08:27] <mitya57> Mirv: I don't know of such place
[08:28] <Laney> no
[08:28] <Laney> not in general, but many teams use a VCS which you can use to get such things out of
[08:30] <mitya57> We know contents of the tarball, we need the tarball itself...
[08:32] <Mirv> mitya57: yep, I've followed the doc efforts
[08:33] <Laney> that's what pristine-tar does for you
[08:34] <mitya57> No, pkg-qt-kde has debian-dir-only git
[08:35] <Laney> so you see where I said "not in general, but many teams"
[08:35] <Laney> that means that it doesn't work in all cases.
[08:36] <cjwatson> <cjwatson@amber ~>$ pam_getenv LANG
[08:36] <cjwatson> <cjwatson@amber ~>$
[08:36] <cjwatson> pitti: ^-
[08:37] <cjwatson> I'd expect en_GB.UTF-8, since that's what /etc/default/locale says for LANG
[08:37] <cjwatson> Well, even with -l
[08:37] <cjwatson> Ah, pam_getenv works for /etc/environment but *not* for /etc/default/locale, even with -l
[08:38] <cjwatson> My memory is that -l was supposed to abstract across that transition, but maybe nobody got round to doing that
[08:38] <cjwatson> tvoss: hi
[08:39] <tvoss> cjwatson, hey there :) do you remember our discussion on the symbol versioning topic? You mentioned a magic linker line
[08:39] <cjwatson> tvoss: What about symbol versioning, exactly?
[08:39] <tvoss> cjwatson, for the platform api, we wanted to do something similar to glibc, with per-symbol versioning
[08:42] <cjwatson> I expect you want a version script, then
[08:42] <cjwatson> http://sourceware.org/binutils/docs-2.23.1/ld/VERSION.html#VERSION
[08:45] <pitti> cjwatson: right, the manpage says that -l currently doesn't do anything
[08:46] <pitti> cjwatson: so I use pam_getenv to read /etc/environment, and source /etc/default/locale
[08:46] <cjwatson> Yeah, your code looks OK for this
[08:47] <cjwatson> Perhaps I should say that pam_getenv is not living up to its intended purpose, rather than "broken"
[08:47] <pitti> cjwatson: ok, thanks; I didn't want to commit it before knowing what kind of breakage you meant
[08:47] <cjwatson> I wasn't very clear, sorry :)
[08:47] <pitti> cjwatson: ack; the manpage says it's just for parsing /etc/environment
[08:47] <pitti> cjwatson: no worries; thanks a lot!
[08:48] <cjwatson> Right, I realise the man page says that, but I remember the discussions when that command was introduced too :-)
[08:52] <rbasak> pitti: thanks!
[10:15] <Vdragon> Hi, I would like to ask why Ubuntu don't pre-install all language packs (with/without input methods) on the standard installation media.  Since ISO image can no longer fit into CDs we have nearly 4GBs free space to make Live image more usable to those people not prefer en_US.
[10:17] <cjwatson> While we don't have the CD constraint any more, there's still a trade-off.  The larger the image is, the more unattractive it is to download.
[10:17] <cjwatson> So we don't want to instantly grow by a considerable amount.
[10:18] <cjwatson> We might start gradually trickling in some more common languages, but not all of them.
[10:18] <cjwatson> There are also performance problems at installation time to consider; language packs preinstalled in the squashfs should generally be removed for installations in other languages, but that takes time (and perhaps a surprising amount of it).
[10:32] <cousteau> I miss the old days where you could put virtually anything in a single CD image
[10:33] <Vdragon> cjwatson: Thanks for your answer, however I didn't think the tradeoff is very considerable if we take account average speed of internet(mirror) and disk(USB 3s, SSD) in recent days.
[10:34] <cjwatson> I'm afraid I respectfully disagree
[10:35] <Vdragon> @cousteau: I prefer using LiveUSB if available ;)
[10:35] <udevbot> Error: "cousteau:" is not a valid command.
[10:35] <Vdragon> cousteau: I prefer using LiveUSB if available ;)
[10:35] <cousteau> ...@ as a bot trigger?  weird, never seen that
[10:36] <Vdragon> cjwatson: Me too.  Anyway have a good day :)
[10:36] <cjwatson> (Speaking as somebody at the wrong end of a pretty slow connection, even in a supposedly developed country)
[10:37] <Vdragon> cousteau: my fault :P
[10:37] <cousteau> Back in the day I carried a Knoppix 5.1 CD.  That thing carried EVERY PROGRAM you could think of!  Compilers, manpages...  it was pretty nice.
[10:38] <cousteau> there was also Musix, with lots of multimedia programs (I think it basically had all Linux multimedia programs I've ever known about)
[10:38] <cousteau> and, of course, Ubuntu
[10:38] <cousteau> but times change and software seems to get huger for no apparent reason
[10:44] <Vdragon> cousteau: cool!
[10:45] <cousteau> no, not cool.  I miss the old days of Hardy. It looked so nice...
[10:56] <mok0> Ah, the Hardy Heron. I remember it well
[13:48] <smb> infinity, I updated bug 1064475 and added several backports of crash to my 4infinity folder on chinstrap (backports are saucy version minus the armhf in the control file). Raring is not necessarily broken but I thought it might be less pain to have them all the same. Up to your decision I guess. And yeah, xen is also there.
[13:50] <infinity> smb: Any reason to remove armhf from the control file on backport?
[13:50] <infinity> smb: Do only 3.8+ kernels support crash on ARM?
[13:50] <smb> infinity, Well I thought we had not built it for arm back then and only start with S
[13:52] <infinity> smb: Sure, but was that because the package didn't work back then (and does now), because of silly historical cruft, or because it won't work with those kernels?
[13:52] <infinity> smb: If it's either of the first two reasons, there's no reason to continue to prevent it building.
[13:54] <smb> infinity, I could not say. It probably builds back then but I had no way of testing. And I thought starting to build a package for an architecture it was not build on release was a reason not to start with it on a backport.
[13:54] <infinity> smb: Nah, there's no such rule.  If an FTBFS or some other backported upstream code fix/change makes it magically work on a new arch, artificially limiting it to not build on that arch is silly.
[13:55] <infinity> smb: If anyone has written such a rule, it should be found and purged with fire as a case of "overly strict rules being user-hostile".
[13:55] <infinity> smb: "You could have this package, but we won't let you, nyah nyah" wouldn't look good in a changelog. ;)
[13:56] <cjwatson> Also, there's no reason to be strict about that, because a package that simply didn't exist at all before is exceedingly unlikely to constitute a regression by appearing
[13:57] <smb> infinity, There isn't a written down rule I know of. It was more an assumption not to introduce something new into the archive as a backport would be better. And the changlog just does not say "added armhf". So who would know... :-P
[13:57] <infinity> cjwatson: Rare corner-cases where this isn't true, like if that package is in a recommends-chain from something people generally have installed, and now it magically gets pulled in.
[13:57] <infinity> cjwatson: But it would have to be severely broken *and* in a recommends chain for that to be a regression.
[13:58] <smb> infinity, Maybe you can try to sbuild the saucy package on your arm box on r,q,p and if that works, I recreate the source debs with the armhf back in...?
[13:58] <cjwatson> infinity: indeed
[14:20] <tvoss> slangasek, around?
[14:21] <jibel> pitti, in bug 1189485 apport retracer added a comment but didn't set it as duplicate, is this a known issue ?
[14:33] <pitti> jibel: hm, did you mark it as dupe yourself?
[14:33] <jibel> pitti, I did after the retracer said he did but didn't
[14:34] <pitti>     self.close_duplicate(report, id, master_id)
[14:34] <pitti> [...]
[14:34] <pitti> lazr.restfulclient.errors.ServerError: HTTP Error 504: Gateway Time-out
[14:34] <pitti> jibel: so, LP glitch :/
[14:34] <pitti> jibel: thanks for cleaning it up
[14:34] <jibel> pitti, ok, np
[14:34]  * pitti restarts the amd64 retracer then
[14:53] <pitti> thomi: would you mind adding me to the ~autopilot team? I'm currently reviewing the -gtk bugs, and would like to do some triaging there, but I can't do that properly without being a team member
[15:01] <slangasek> tvoss: hi
[15:03] <Riddell> pitti: any ideas on what's upsetting pkgbinarymangler on this build? https://launchpadlibrarian.net/142096598/buildlog_ubuntu-saucy-amd64.opencolorio_1.0.8%2Brepack1-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:07] <infinity> Riddell: "Found files in /usr/lib/python2.7/site-packages (must be in dist-packages for python2.7)"?
[15:09] <cjwatson> Using dh_python2 would probably sort that out.
[15:09] <cjwatson> You don't seem to be using any Python helper at all there right now, which is very likely a mistake.
[15:10] <OdyX> tkamppeter: did you see http://bugs.debian.org/711868 ? Apparently we never re-applied colord-support.patch in cups 1.6.2 . Is it still neededor would Alexey's patch be sufficient now.
[15:10] <OdyX> tkamppeter: also, to you have informations regarding the cups upstream bugtracker ? It's quite cumbersome to get issues reported/fixed without any other tracker than the Apple ID $thing that I refuse to touch with a remote stick,
[15:12] <Riddell> infinity: mm yes
[15:12] <infinity> Riddell: See Colin's comments.
[15:13] <Riddell> yep
[15:30] <pitti> Riddell: at first sight, sounds like the change of default paths in saucy's automake? (that's a huge pain in the butt indeed)
[15:30] <pitti> Riddell: (in meeting, haven't looked into details yet)
[15:31] <cjwatson> pitti: see scrollback, we've dealt with it
[15:31] <pitti> Riddell: doko added that plausibility check, so it's a deliberate build failure
[15:31] <pitti> cjwatson: ah, right
[15:31] <cjwatson> pitti: dh_python2 fixes these things up if it's actually run, regardless of what automake does, and dh_python2 ought to be run here anyway I'd have thought ...
[15:31] <pitti> yes, absolutely
[15:32] <Riddell> yep, fix uploaded, thanks pitti,cjwatson
[15:37] <lool> pitti: hey, stgraber kindly pointed me at https://blueprints.launchpad.net/ubuntu/+spec/community-s-testing-technologies as the closest matching QA effort for the ofono / NM CP testing; would it be ok to list explicit tests for a) SIM card + optional XML db provisioning and b) binary SMS (DM/DS) based provisioning in there?  the latter is meant to allow us to add hooks for opcos that don't support a), but I think it's currently untested code
[15:47] <pitti> lool: re (meeting)
[15:47] <pitti> lool: I'm afraid I don't know what either of that means, but sure, please feel free to add some WIs
[15:47] <pitti> lool: but as a starter we need to figure out how to do the most basic stuff (like detection and making a call/making a connection)
[15:57] <pitti> good night everyone
[15:58] <didrocks> have a good night pitti!
[16:23] <lool> pitti: Yup, this all makes sense
[16:23] <lool> pitti: I agree that simpler stuff is needed first, just wanted to have a place to list some high-level goals for testing the CP
[16:24] <lool> pitti: thanks!
[17:02] <tkamppeter> OdyX, I was assuming that CUPS 1.6.x had adopted colord-support.patch upstream. Is this not the case? Perhaps there are bugs in the adoption. What is Alexey's patch about? Perhaps it can fix these bugs?
[17:09] <tkamppeter> OdyX, I have contacted Mike, telling him that it is really important to get the STR database back.
[17:10] <tkamppeter> OdyX, for the time being please report bugs and submit patches by contacting Mike directly.
[17:52] <bdmurray> stgraber: I think I am experiencing bug 981461
[17:53] <stgraber> bdmurray: do you have ethtool installed?
[17:54] <stgraber> bdmurray: ethtool eth0 | grep "Wake"
[17:55] <bdmurray>         Supports Wake-on: pumbg
[17:55] <bdmurray>         Wake-on: g
[17:55] <bdmurray> I've tested with tcpdump and the system is receiving the magic packet when powered on
[17:56] <stgraber> bdmurray: and wake on lan is enabled in the BIOS?
[17:56] <bdmurray> Additionallly, there is no BIOS setting for it
[17:56] <bdmurray> And I swear it used to work in 12.10 but I reinstalled recently and put 12.04 on that system
[17:57] <stgraber> ok, odd. I haven't used wake on lan much since precise, but I have a dozen precise machines that certainly have it working
[17:57] <stgraber> IIRC the only thing I had to add to some of those was a "ethtool -s eth0 wol g" but what you pasted earlier already looks good and shouldn't need that workaround
[17:57] <bdmurray> its a mythbuntu system fwiw
[18:00] <stgraber> bdmurray: just rechecked, the systems that have working wol here only have one extra setting which is "ethtool -s $1 wol g || true" as post-up command in ifupdown but you apparently don't need that in your case
[18:00] <stgraber> bdmurray: when the machine is off, do you see a link on the network card?
[18:00] <bdmurray> checking
[18:02] <bdmurray> hmm, nope
[18:02] <stgraber> ok, so something is being a bit too efficient at shutting down the machine
[18:03] <stgraber> bdmurray: so are you actually using ifupdown on that machine? as in, are you network interfaces defined in /etc/network/interfaces instead of NetworkManager?
[18:04] <bdmurray> stgraber: no, I was not but then I added the interface to /e/n/i and nothing changed
[18:05] <stgraber> ok, I was just wondering if maybe ifupdown was doing something to bring the link down, but if you get the same under NetworkManager then that's not the case (the machines I use with wol use NetworkManager)
[18:05] <bdmurray> hmm, okay I can wake it up from suspend
[18:07] <stgraber> bdmurray: if you use "halt" to shut down the machine (but not cut power), do you see a link?
[18:11] <bdmurray> stgraber: yes
[18:11] <stgraber> bdmurray: ok, then it's not Ubuntu shutting down the link as the only difference between halt and poweroff is the final kernel call to cut power
[18:12] <stgraber> so extremely unlikely to be an issue with ifupdown or our init scripts
[18:12] <stgraber> bdmurray: what kernel are you using on those 12.04 systems?
[18:12] <stgraber> *that 12.04 system
[18:12] <bdmurray> stgraber: I just upgraded to the latest 12.04 one
[18:13] <stgraber> bdmurray: ok, so the non-backport 3.2 kernel then
[18:13] <stgraber> bdmurray: might be interesting to retry with the quantal and raring backport, see if that makes any difference
[18:14] <bdmurray> stgraber: okay, thanks
[18:24] <OdyX> tkamppeter: for the colord support, cups 1.6 upstream indeed has a bug, which Alexey fixes. I'll drop colord-support.patch from the source package as it's deprecated.
[18:26] <OdyX> tkamppeter: great for cups' str, thanks. How are you in contact with Michael btw, msweet@ Apple ?
[19:24] <smoser> slangasek, you have any idea what would 'start networking' on a system that was seemingly failing to bringup networking on boot ?
[19:24] <smoser> ie, this bug https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1189571
[19:24] <smoser> was stoping networking from coming up on network-device-added
[19:25] <smoser> but /var/log/upstrat would still have a 'networking' file with data in it.
[19:26] <slangasek> smoser: not sure I understand the question. /etc/init/networking.conf is the catch-all job for network devices that don't generate network-device-added events.
[19:26] <slangasek> it runs unconditionally on boot.
[19:26] <smoser> it does ?
[19:27] <slangasek> yes
[19:27] <smoser> bah.
[19:27] <slangasek> as per the start condition, start on (local-filesystems and (stopped udevtrigger or container)) or [...]
[19:27] <smoser> well that is it then
[19:27] <smoser> :)
[19:27] <smoser> yeah
[19:27] <smoser> duh
[19:32] <smoser> i had left over stuff in my head from https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1031065
[19:32] <smoser> and thought that that was basically not supposed to be run other than manually
[19:51] <smoser> anyone know what might have changed ...
[19:52] <smoser> is swear that i used to be able to do:
[19:52] <smoser> bzr bd -S -- -us -uc
[19:52] <smoser> then sbuild -d saucy-amd64 --arch-all file.dsc
[19:52] <smoser> but recently, i've been getting
[19:52] <smoser> E: E: Failed to copy '../isc-dhcp_4.2.4.orig.tar.gz' to '/«CHROOT»/«BUILDDIR»': No such file or directory
[19:54] <infinity> Well, does the file exist?
[19:55] <smoser> the file *doesn't* exist, because i didnt build with '-sa'
[19:55] <smoser> but i swear some magic used to make that work
[19:55] <infinity> Well, how do you expect sbuild to find the source if you don't have source?
[19:55] <infinity> I'm a bit puzzled. :P
[19:55] <infinity> -sa has nothing to do with it.
[19:55] <infinity> -sa defines what's in .changes, not in .dsc
[19:56] <infinity> So, let's back up, and tell me what bzr bd is producing, and how.
[19:57] <jbicha> smoser: you don't need to make a .dsc for sbuild to work; sbuild -A -d saucy-amd64 is sufficient
[19:58] <smoser> jbicha, well, it was just my normal work flow. i didn't know that i didn't eed a .dsc. but its nice.
[19:59] <smoser> infinity, well, doing -sa would tell (i think) bz rbd to copy its exported .orig.tar.gz to the same place it put the .dsc
[19:59] <smoser> no?
[20:02] <jbicha> smoser: one step further, in your ~/.bzr/builddeb.conf
[20:02] <jbicha> [BUILDDEB]
[20:02] <jbicha> builder = sbuild -A -d saucy-amd64
[20:02] <jbicha> then bzr bd without arguments will build with your sbuild
[20:03] <kees> jcastro: tb meeting happening now, if you have a moment.
[20:03] <smoser> i didn't know about htat. but i'm not bothered too much by my wrapper 'sbuild-it' that reads .dsc or .changelog and picks the right release based on that.
[20:04] <kees> jcastro: ah, nm, found RT for brainstorm
[20:04] <infinity> smoser: Oh, sure, bzr bd copies things around based on the changes, probably.  I dunno.  I don't use it.
[20:04] <infinity> smoser: My point was more that a source package without all the components isn't actually a source package, so sbuild can't magically find the missing bits.
[20:04] <smoser> I WANT MAGIC!
[20:04] <smoser> :)
[20:05] <jcastro> kees: I can answer questions if you want
[20:05] <smoser> so i guess it could have bee na change in bzr builddep (version upgraded in saucy)
[20:06] <kees> jcastro: I was just checking on the status of the request, cjwatson found the RT. we're all good. :) thanks!
[20:06] <jcastro> ack
[20:14] <kees> can someone besides me verify this, I'd like to get this closed: https://bugs.launchpad.net/bugs/1177218
[20:20] <Sarvatt> kees: done
[20:20] <kees> Sarvatt: thanks!
[20:27] <DrFoo> Is there a known issue with mounting cifs share w/ a credentials file?
[20:27] <DrFoo> 12.04
[20:30] <smoser> jdstrand, ping
[20:30] <jdstrand> smoser: hey
[20:32] <smoser> is there a reason your release at https://lists.ubuntu.com/archives/saucy-changes/2013-May/001104.html is 'saucy-proposed' ?
[20:32] <smoser> jdstrand.
[20:33] <infinity> smoser: Cause Jamie's weird and never got the memo about pocket rewriting? :)
[20:33] <smoser> i'm guessing it was inadvertant, but i'm uploading and wanted to make sure I wasn't wrong.
[20:33] <smoser> i think it might have caused the bzr importer to fail also
[20:33] <jdstrand> smoser: istr an email from cjwa tson explaining how the new proposed mechanism worked that -proposed is technically correct, but that there is a redirection from saucy to saucy-proposed for people who don't use -proposed
[20:34] <jdstrand> if 'saucy' is actually correct, I'll stop
[20:34]  * smoser doesn' tknow.
[20:34] <infinity> jdstrand: Both are "correct", but you're one of the few people still using -proposed (and I'm trying to discourage it).
[20:34] <jdstrand> seems infinity may have some insight
[20:34] <jdstrand> heh, funny
[20:34]  * jdstrand shrugs
[20:35] <jdstrand> I guess I'll stop then, or maybe I'll continue to be an individual :)
[20:38] <smoser> jdstrand, infinity thanks.
[20:41] <cjwatson> smoser: I don't really know its inner workings, but I'd be surprised if it made any difference either way to the importer.
[20:41] <smoser> i wouldnt have thoguht so either.
[20:41] <smoser> but somethign busted it.
[20:41] <smoser> :-(
[20:41] <smoser> i import-dsc and pushed it
[20:42] <cjwatson> I'm not going to try to guess at the cause :)
[21:38] <kees> stgraber: do you happen to know how to tell kvm to load an external kernel to a specific location in memory when it acts as the boot loader?
[21:39] <stgraber> kees: nope, but maybe hallyn does
[21:39] <stgraber> hallyn: 21:38 < kees> stgraber: do you happen to know how to tell kvm to load an external kernel to a specific location in memory when it acts as the boot loader?
[21:39] <kees> hallyn: all I see is just "-kernel", but it'd be nice to bump it around in memory when I've built with CONFIG_RELOCATABLE
[21:50] <DrFoo> Can someone test mounting a cifs share using a credentials file. I've followed all the instructions and syntax I could find on the web and it's telling me I haven't specified a username. There is an old bug for this, but it must have been resolved by now.
[22:07] <zyga> hey it's after midnight
[22:08] <zyga> and this is the wrong channel
[22:10] <hallyn> kees: sorry, i don't
[22:10] <hallyn> i do, however, need to talk to the cable chaps about why around 4pm (when it gets hot) my internet gets flaky
[22:12] <kees> hallyn: heh
[22:12] <hallyn> yeah you'd think that'd be an option.  not finding it
[22:33] <bkerensa> jbicha: can you pop into #ubuntu-meeting?


[03:04] <mmikowski> Eickmeyer: sorry, i was afk myself for quite a bit.
[03:08] <mmikowski> arraybolt3: Excellent! sudo apt install plasma-discover-notifier, right?
[09:38] <RikMills> Mantic Minotaur
 will start to try mantic in a few weeks or earlier (re @IrcsomeBot: <RikMills> Mantic Minotaur)
 does it state somewhere "whats new in mantic minotaur"
 😉
 will stick to lunar for a while .. until there is something new to tried on mantic
[13:00] <BluesKaj> Hi all
 Forwarded from RikMills: 23.10 Release schedule up https://discourse.ubuntu.com/t/mantic-minotaur-release-schedule/34989
 Forwarded from RikMills: 23.10 Release schedule up https://discourse.ubuntu.com/t/mantic-minotaur-release-schedule/34989


[00:05] <BUGabundo> nixternal: ping
[00:05] <BUGabundo> humm still blocked!
[00:05] <BUGabundo> did you get that last reply?
[00:05] <BUGabundo> seems not! its not on your page
[00:05] <BUGabundo> http://identi.ca/nixternal/replies
[00:05] <BUGabundo> "bugabundo: @nixternal ahaha i just got your reply so it should be working! now: can u handle >30 dents/day ?"
[01:01] <micahg> ping hggdh
[01:04] <micahg> I want to run a reply by someone to make sure it's not too harsh
[01:05] <BUGabundo> micahg: shoot
[01:05] <BUGabundo> I'm sleepy so don't expect a much clear answer
[01:05] <micahg> then maybe I should wait for someone else :)
[01:06] <micahg> http://pastebin.ubuntu.com/195991/ answer to bug
[01:06] <micahg> bug 355476
[01:06] <ubot4> Launchpad bug 355476 in firefox-3.0 "32-bit firefox should be included in AMD64 (x86-64) distribution" [Wishlist,Triaged] https://launchpad.net/bugs/355476
[01:07] <bcurtiswx-mini> micahg: i don't think its a bad response
[01:08] <BUGabundo> humm
[01:08] <BUGabundo> waint that a WontFix ?
[01:08] <BUGabundo> speacially for 3.0

[01:09] <BUGabundo> well he _can_ run it!
[01:09] <micahg> nah, it can just sit there, otherwise, we'll get constant back and forth which I'm trying to mitigate with my response
[01:09] <BUGabundo> as long as he has ia32libs
[01:09] <BUGabundo> and FORCE the install for 32 bits for firefox, it should be installabel
[01:10] <BUGabundo> micahg: tell him this ^
[01:10] <bcurtiswx-mini> make him to the work for the "complaining"
[01:11] <micahg> BUGabundo: I've never done it before, so I cannot advise him on how to do it
[01:11] <micahg> you're welcome to post that in the morning
[01:11] <micahg> but I don't know if we support it
[01:11] <BUGabundo> eheh nice ending "in the morning"
[01:12] <BUGabundo> well I don't think we don't NOT support it
[01:12] <BUGabundo> I mean, its in the archive
[01:12] <BUGabundo> hey asac
[01:12] <micahg> ping asac_
[01:13] <micahg> His client probably just reconnected
[01:16] <BUGabundo> yeha
[01:30] <hggdh> micahg, pong
[01:31] <micahg> oh, hi
[01:31] <hggdh> hi :-)
[01:31] <micahg> I wanted feedback on something
[01:31] <hggdh> shoot
[01:31] <micahg> but I think I got it
[01:31] <hggdh> heh. Nothing better than being late, I guess ;-)
[01:31] <micahg> I just wanted to know if this was over the top
[01:31] <micahg> http://pastebin.ubuntu.com/195991/
[01:31] <hggdh> looking at it, micahg
[01:32]  * micahg already sent it, so I hope it's not bad :)
[01:32] <hggdh> well, not really. It is sort of direct to the point (er, just a bit on the dry side)
[01:33] <micahg> ok
[01:33] <BUGabundo> ahh
[01:33] <micahg> is dry bad?
[01:33]  * BUGabundo offers some ice
[01:33] <BUGabundo> micahg: well it may not calm him down as much as you wanted
[01:34] <hggdh> micahg, no, dry is not bad. It is just I feel a 'please', or 'thank you' thrown in may look nicier
[01:34] <micahg> oh well
[01:34] <micahg> ah
[01:34] <micahg> I usually do
[01:35] <hggdh> but -- I guess -- you had it with this one
[01:35] <hggdh> :-)
[01:35] <micahg> others probably would've done what BUGabundo suggested and just mark Won't Fix
[01:35] <micahg> yeah
[01:36] <hggdh> let me look at the bug
[01:37] <micahg> I know what it's like working on software
[01:37] <micahg> it's just annoying when people get pushy demanding things in free software
[01:37] <BUGabundo> micahg: either wontfix or invaled
[01:37] <hggdh> its part of the game
[01:37] <BUGabundo> the user *can* install 32 bits
[01:37] <micahg> but I do endeavor to be polite
[01:38] <hggdh> I think wishlist is still correct. There are some valid points (probably) on the request
[01:39] <micahg> hggdh: I consulted you originally on this
[01:40] <hggdh> yes, I saw my entry there
[01:40] <micahg> he can make a proposal and see the feedback he gets
[01:40] <micahg> my guess is there will be a lot of people like BUGabundo saying it's unnecessary
[01:41] <micahg> and then we don't look like the bad guy :)
[01:42] <hggdh> well, this is (some sort of) democracy...
[01:43] <hggdh> gotta walk the dogs. BRB
[01:44] <BUGabundo> hggdh: post pics of them latter!!
[02:30] <Wellichen> Does anyone knows if I it is possible  Reading OpenPGP E-mail on hotmail.
[03:30] <dman1> Hello.  What markup is used in launchpad when reporting a bug?
[06:21] <dholbach> good morning
[06:21] <theyeti> morning
[09:15] <askand> kklimonda: http://pastebin.com/m716938ce ;)
[09:15] <kklimonda> askand: 1.72 was released ;)
[09:16] <kklimonda> but I have sent it to developer
[09:17] <kklimonda> askand: Försäkran "tr_isAddress( b )" falsk. <- Does it mean something like "Assertion "tr_isAddress( b )" failed." ?
[09:18] <kklimonda> yeah, looks like it
[10:05] <askand> kklimonda: yes, that is correct :) I will try 1.72 then
[15:03] <bddebian> Boo
[17:23] <hggdh> bdmurray, any idea of when LP will support classified attachments (i.e., plublic/private)?
[17:24] <bdmurray> hggdh: no, and I'm not familiar with a bug for that
[17:27] <hggdh> will search -- I found it some time ago.
[17:28] <hggdh> bdmurray, anyway -- I am considering adding two new attachments -- anonimised ThreadStacktrace and Stacktrace, and leaving the originals for verification by the triager
[17:29] <bdmurray> hggdh: and those could be removed by a bug control member?
[17:29] <hggdh> so that if the cleanup is, er, excessive, we can go back; if it is good, we can just delete the originals
[17:29] <hggdh> yes
[17:29] <bdmurray> maybe a diff would be easier?
[17:29] <hggdh> adding also a diff?
[17:30] <bdmurray> Maybe just an anonimized and a diff
[17:30] <bdmurray> It'd be hard to make the original again though...
[17:30] <hggdh> ah. Cool, yes, much better
[17:30] <hggdh> well, you can always run patch against it
[17:31] <bdmurray> But you'd have to add a whole new attachment to the bug report
[17:31] <hggdh> with a -R
[17:31] <bdmurray> I think that'd be the exception though
[17:32] <hggdh> probably, yes. But I worry about initial implementation, until we are sure I am not messing too much
[17:33] <bdmurray> In that case add the diff and the original
[17:33] <bdmurray> then just drop the original
[17:33] <hggdh> ok
[17:33] <bdmurray> I think the diff will be easier to inspect than 2 attachments
[17:34] <hggdh> a
[17:34]  * hggdh nods
[19:13] <BUGabundo> boas tardes
[19:13] <BUGabundo> hey bencrisford
[19:13] <bencrisford> hey
[19:36] <hggdh> bdmurray, I just sent you the new source_evolution.py
[19:36] <BUGabundo> hey hggdh
[19:36] <hggdh> learning a new language by programming is fun ;-)
[19:37] <hggdh> hey BUGabundo
[19:37] <BUGabundo> aahah
[21:37] <charles_> was someone here reporting trouble with Transmission?
[21:38] <BUGabundo> charles_: talk to kklimonda! he _tries_ to maintain it
[21:39] <kklimonda> BUGabundo: tries? tries?!!! ;)
[21:40] <BUGabundo> don't you ?
[21:40] <BUGabundo> btw HIIII
[21:41] <kklimonda> hey, what's up? How is a weather in portugal? :)
[21:41] <BUGabundo> sunny today
[21:41] <BUGabundo> yesterday was a drag
[21:58] <mrooney> Anyone know if bugs in gnome-panel's weather go against gnome-applets or gnome-panel?
[22:01] <BUGabundo> not me
[22:04] <MagicFab_> libgweather-common or libgweather AFAIK - but double check by looking at existing bugs
[22:04] <MagicFab_> mr_pouit, ^
[22:04] <MagicFab_> mrooney, ^ - sorry mr_pouit
[22:04] <mrooney> MagicFab_: so it would be against the library even if it could be a UI issue?
[22:06] <MagicFab_> mr_pouit, "depends". As I said, check existing closed bugs to see which most closely matches
[22:06] <pedro_> mrooney: the right component is gnome-panel for weather issues
[22:07] <mrooney> MagicFab_: looks like you need a better IRC client ;)
[22:07] <BUGabundo> hey MagicFab_ seb128 pedro_
[22:07] <pedro_> mrooney: if you're having problems with the locations, like latitude not being correct etc , that's a libgweather issue
[22:07] <seb128> hi BUGabundo
[22:07] <pedro_> salut seb128
[22:07] <pedro_> hey BUGabundo
[22:08] <mrooney> pedro_: ah okay so bug 387477 is probably a libgweather?
[22:08] <ubot4> Launchpad bug 387477 in ubuntu "weather 2.26.1 doesn't show temperature anymore" [Undecided,New] https://launchpad.net/bugs/387477
[22:08] <hggdh> seb128, how do we add an apport package hook to Evolution?
[22:09] <pedro_> mrooney: yep looks like it is
[22:09] <mrooney> okay thanks I shall mark it as such!
[22:10] <pedro_> no problem :-)
[22:19] <seb128> re
[22:19] <seb128> hggdh, hi, you were asking?
[22:19] <BUGabundo> ro
[22:21] <hggdh> hi seb128 yes. I have coded a package-hook for Evo (mostly anonimyser on the stacktrace), and I am unsure on how to propose it
[22:22] <seb128> hggdh, the hooks are used when reporting bugs, I doubt you manage to change the coredump which is a binary do you?
[22:22] <seb128> hggdh, that seems a good tool to run on the retracers though
[22:23] <hggdh> seb128, no, the package hook is called after apport-retrace gets done with it, so all I change is the generated BTs
[22:26] <seb128> hum
[22:26] <seb128> I don't know about those hooks
[22:26] <hggdh> or apport itself.... Anyway, the hooks get called when the report is prepared
[22:26] <seb128> I know about apport hooks to include informations in a bug report
[22:27] <seb128> well, usually you get the bug sent to the server
[22:27] <seb128> the first version contain the coredump and non debug stacktraces
[22:27] <hggdh> yes, then apport-retrace does it magic
[22:27] <seb128> then the retracer do their job and upload retraced stacktraces
[22:27] <hggdh> and, as far as I can understand, it then calls any hooks available
[22:27] <bdmurray> oh, both the retraced and non-retraced ones would need to be scrubbed...
[22:27] <seb128> but it doesn't include the apport hook informations
[22:28] <seb128> I doubt of it but better to ask pitti
[22:28] <hggdh> will ask him tomorrow. Actually, let me run a retrace here & upload a new bug
[22:28] <seb128> the information collecting happens usually on the client machine
[22:29] <seb128> non on the datacenter retracer
[22:29] <seb128> non -> not
[22:29] <bdmurray> right, and the package hook is used on the client machine
[22:29] <bdmurray> so the non-retraced Stacktrace.txt would be scrubbed but not the retraced one
[22:29] <bdmurray> using the package hook that hggdh has
[22:30] <hggdh> oy vey
[22:30] <seb128> that's my understanding too but that's not what we want
[22:31] <bdmurray> well its half of what we'd want
[22:33] <hggdh> but not enough. I will sigsegv my Evo, and try
[22:33] <hggdh> with apport-retrace
[22:42] <hggdh> nah
[22:42] <hggdh> will ping ping pitti tomorrow
[22:42] <bdmurray> nah?
[22:43] <BUGabundo> bdmurray: aka not working
[22:43] <hggdh> it seems apport-retrace knows the difference on being run on the canonical servers or on my machine :-(
[22:43] <hggdh> so will have to dig into it, and talk with pitti
[22:43] <BUGabundo> a very common sentence in Portuguese, right hggdh
[22:43] <hggdh> yes :-)
[22:45] <hggdh> generically meaning did not, will not, should not <something>, or <something> is is just plain wrong
[22:45] <hggdh> like did not work
[22:46] <bdmurray> I'm familiar with the word just wanted more information ;-)
[22:46] <BUGabundo> ahahha
[22:47] <BUGabundo> yeah it can be *very* ambigous
[22:47] <BUGabundo> even in context
[22:49] <hggdh> bdmurray, so we are sort of stuck right now. This needs to be run on both the local machine and on the retracer. We will need a change in apport-retrace, methinks
[22:53] <bdmurray> Right, I think this is good though as it can be used by other packages too
[22:54] <bdmurray> the Miscellaneous part of the hook is still useful too
[22:56] <hggdh> I agree. Obviously, the BT anonymiser has to be customised for each package
[23:05] <BUGabundo> any one know the dupe of bug 387529 ?
[23:05] <ubot4> Launchpad bug 387529 in gnome-power-manager "screen goes black after a while even when typing" [Undecided,New] https://launchpad.net/bugs/387529
[23:08] <BUGabundo> kklimonda: were you or was it cwillu who asked me this week about a similar bug?
[23:08] <kklimonda> BUGabundo: not me
[23:10] <BUGabundo> then it was cwillu
[23:14] <wellichen> hello everybody, I'm starting today!
[23:15] <wellichen> Anyone can help me with some doubts on BugTracking
[23:16] <BUGabundo> hey wellichen. welcome
[23:16] <BUGabundo> what can we do for you?
[23:17] <wellichen> I want to know if you follow some kind of plan to seek for bugs.
[23:17]  * BUGabundo thinks over and over should apply for team, too. wanna join kklimonda?
[23:17] <BUGabundo> wellichen: well no
[23:17] <kklimonda> BUGabundo: too lazy.. ;)
[23:17] <kklimonda> j/k
[23:17] <BUGabundo> everyone does as they like more
[23:17] <kklimonda> BUGabundo: I think i'll apply soon as in next few weeks
[23:17] <BUGabundo> kklimonda: I'm not.! im too lazy too
[23:17] <BUGabundo> drag me along
[23:18] <wellichen> Um I understand.
[23:18] <BUGabundo> wellichen: some check the list of most recent bugs, others their fab packages, etc
[23:18] <BUGabundo> you can even join on #ubuntu-bugs-announce
[23:18] <BUGabundo> and see new bugs coming in
[23:19] <kklimonda> ehehehe, I was idling there for few days.. lost of noise ;)
[23:19] <kklimonda> lots*
[23:21] <BUGabundo> I know
[23:21] <BUGabundo> I stop beeing there
[23:21] <BUGabundo> too much for even a _spammer_ like me
[23:24] <wellichen> BUGabundo : From where are you from?
[23:24] <BUGabundo> PT
[23:25] <wellichen> Portugal?
[23:25] <BUGabundo> yes
[23:26] <wellichen> Cool!
[23:26] <BUGabundo> Hot. but okay
[23:26] <wellichen> :)
[23:27] <wellichen> Lisboa?
[23:27] <BUGabundo> ah no
[23:27] <BUGabundo> Gondomar (Porto). conheces?
[23:28] <BUGabundo> ahh um compatriota do brasil
[23:28] <wellichen> Nao, nunca estive em Portugal
[23:29] <BUGabundo> hggdh: um dias deste renomeamos o canal para $ubuntu-bugs-pt
[23:29] <BUGabundo> lolol
[23:29] <wellichen> Ah sim Brasileiro :)
[23:29] <wellichen> hahaha
[23:30] <wellichen> Tem muitos que falam portugues por aqui, neh?
[23:30] <kklimonda> wiecie czemu językiem "urzędowym" kanału jest Angielski?
[23:31] <kklimonda> because it's the only language we all have in common :P
[23:32] <BUGabundo> wellichen: yeah there are few of us
[23:32] <BUGabundo> afaik, im the only in Portugal, dough
[23:33] <BUGabundo> kklimonda: luv you too **
[23:33] <virtuald> D'OH
[23:34] <wellichen> kklimonda : sorry I just get happy in finding a fellas that speak Portuguese too!
[23:37] <BUGabundo> +  * When membership expires you should put yourself down for the next membership board for reapproval every 2 years.
[23:37] <BUGabundo> humm
[23:37] <BUGabundo> the membership rules changed ?
[23:37] <kklimonda> why?
[23:37] <BUGabundo> hggdh: now we need to retake it ?
[23:37] <BUGabundo> kklimonda: now idea! just got that email
[23:38] <kklimonda> and what has changed?
[23:39] <BUGabundo> just that
[23:39] <BUGabundo> http://wiki.ubuntu.com/Membership
[23:40] <BUGabundo> need to ping jorge on that
[23:42] <pace_t_zulu> can someone please confirm bug Post-Boards Debauchery
[23:43] <pace_t_zulu> oops... bad paste
[23:43] <BUGabundo> ahaahahaahaha
[23:43] <pace_t_zulu> con someone please confirm bug 387548
[23:43] <ubot4> Launchpad bug 387548 in ubuntu "Could not display "computer:///"." [Undecided,New] https://launchpad.net/bugs/387548
[23:43] <BUGabundo> I've done worse, don't worry pace_t_zulu
[23:43] <pace_t_zulu> BUGabundo: hehe
[23:43] <BUGabundo> pace_t_zulu: I can't!
[23:43] <pace_t_zulu> BUGabundo: you're not getting the same behavior?
[23:44] <BUGabundo> haven't read it
[23:44] <BUGabundo> but if it is what you asked yesterday, I can't
[23:45] <pace_t_zulu> BUGabundo, i wasn't asking anything yesterday... i just filed it
[23:45] <pace_t_zulu> BUGabundo, this is for current Karmic
[23:45] <BUGabundo> then someone did
[23:46] <hggdh> BUGabundo, retake what?
[23:46] <BUGabundo> hggdh: membership meeting every two years
[23:46] <pace_t_zulu> hggdh: can you reproduce bug 387548 ?
[23:46] <ubot4> Launchpad bug 387548 in ubuntu "Could not display "computer:///"." [Undecided,New] https://launchpad.net/bugs/387548
[23:47] <pace_t_zulu> hggdh: nm... i recall you aren't using ubuntu+1
[23:47] <BUGabundo> pace_t_zulu: no logs???
[23:47] <BUGabundo> pace_t_zulu: $ apport-collect 387548 -p nautilus
[23:48] <pace_t_zulu> BUGabundo: will do
[23:48] <BUGabundo> no package... that's a very poor bug!
[23:48] <hggdh> pace_t_zulu, I am running Karmic
[23:48] <hggdh> pace_t_zulu, I cannot reproduce it
[23:49] <pace_t_zulu> hggdh, thank you... i hope i didn't file a bogus bug
[23:50] <BUGabundo> humm no bug is bogus
[23:51] <BUGabundo> could just be _your_ configuration
[23:51] <BUGabundo> trigging something not obvious
[23:51] <BUGabundo> seb128: still around ?
[23:51] <BUGabundo> is this a nautilus bug?
[23:51] <seb128> what?
[23:51] <pace_t_zulu> BUGabundo: did the apport-collect
[23:52] <BUGabundo> seb128: pace_t_zulu bug https://bugs.edge.launchpad.net/bugs/387548
[23:52] <ubot4> Launchpad bug 387548 in ubuntu "Could not display "computer:///"." [Undecided,New]
[23:53] <seb128> rather gvfs
[23:53] <seb128> try if gvfs-ls computer: is working
[23:54] <seb128> and run /usr/lib/gvfs/gvfsd -r on a command line
[23:54] <seb128> then try to open computer
[23:54] <seb128> and copy the log from the command line on the bug
[23:57] <pace_t_zulu> seb128, did those steps and added comments to the bug report
[23:58] <seb128> running /usr/lib/gvfs/gvfsd-computer work?
[23:58] <pace_t_zulu> from #ubuntu+1 Sarvatt: pace_t_zulu: ah you're missing /usr/lib/gvfs/gvfsd-computer --spawner :1.6 /org/gtk/gvfs/exec_spaw/3 in your ps aux for some reason
[23:58] <seb128> the gvfs processes are autospawned when required
[23:59] <seb128> it could be crashing for you for some reason
[23:59] <pace_t_zulu> seb128: /usr/lib/gvfs/gvfsd-computer produces "Segmentation fault"


[08:10] <didrocks> hey sil2100 ;) good work! for yesterday
[08:36] <sil2100> didrocks: hi! Thanks, wouldn't do it without cyphermox ;)
[08:36] <didrocks> :)
[13:11]  * mterry is surprised to see that daily builds actually landed last night for the unity stack.  Our luck day!
[13:24] <didrocks> mterry: I had to work on it :/
[13:24] <didrocks> mterry: UTAH failed
[13:26] <mterry> didrocks, ah, well, it was a nice few minutes of thinking things worked
[13:26] <didrocks> :)
[13:26] <didrocks> mterry: btw, I'm still working on having the 2 releases in parallel
[13:26] <didrocks> mterry: so head is still disabled
[13:26] <mterry> didrocks, and it seems that Head correctly didn't run last night?  yup
[13:26] <didrocks> (commit counting and so on)
[13:26] <didrocks> mterry: it correctly didn't run rather :p
[13:27] <didrocks> mterry: also, even if I reenable it, remember that all the branches are disabled ;)
[13:27] <didrocks> until you https://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Diverging_.22trunk.22_and_a_.22maintenance.22_branch
[13:27] <didrocks> in accordance with upstream
[13:40] <kgunn>  didrocks ...i'm building unity/phablet...hadn't had a problem...but, now when i run setup (for updates) its saying temp failure to resolve 'ports.ubuntu.com'
[13:40] <didrocks> kgunn: hum, what is setup? :-)
[13:41] <kgunn> didrocks: setup is just an option on the build to update dependencies on the device
[13:41] <kgunn> (or that is one step anyway)
[13:41] <kgunn> didrocks: and i shouldn't say build...its actually run_on_device script
[13:43] <didrocks> kgunn: do you have the script somewhere? that would help me know what this is trying to do
[13:44] <kgunn> didrocks: http://bazaar.launchpad.net/~unity-team/unity/phablet/view/head:/run_on_device
[13:44] <kgunn> i think its this line exec_with_ssh $SUDO apt-get -y install build-essential rsync bzr ccache
[13:45] <kgunn> didrocks: normally i would suspect i did something stupid :)
[13:45] <didrocks> kgunn: I don't think you are the guilty, ports.ubuntu.com is available here
[13:46] <didrocks> kgunn: but looking at the script I would do some modifications
[13:46] <didrocks> like     exec_with_ssh $SUDO apt-get -y install build-essential rsync bzr ccache
[13:46] <didrocks> avec the apt-get update line
[13:46] <didrocks> for instance
[13:46] <didrocks> kgunn: can you do that and relaunch?
[13:46] <kgunn> didrocks: i actually thot maybe it was the script....so i opened shell on the device (ubuntu_chroot shell)
[13:47] <kgunn> didrocks: did apt-get update
[13:47] <kgunn> didrocks: and it still said "couldn't resolve"
[13:47] <didrocks> during the apt-get update?
[13:47] <kgunn> didrocks: right
[13:47] <didrocks> do you have network on your device?
[13:47] <didrocks> like if you ping google?
[13:47] <kgunn> didrocks: let me check that...
[13:48] <kgunn> didrocks: should've done that prior...
[13:48] <kgunn> :)
[13:48] <didrocks> no worry ;)
[13:48] <didrocks> but yeah, ports.ubuntu.com is working, the archives are accessible
[13:48] <kgunn> didrocks: dammit...thing had network a minute ago...sorry
[13:48] <kgunn> :)
[13:48] <didrocks> no worry at all ;)
[13:49] <kgunn> didrocks: couldn't see forest for the trees
[13:49] <didrocks> kgunn: well, another eye generally help for that! :)
[13:49] <kgunn> didrocks: and so much for my overpriced verizon fios router !
[13:50] <kgunn> flakey piece of junk
[13:50] <didrocks> kgunn: sometimes, the "boxes" we have in France are a blessing TBH. No need for another router, pretty reliable… cheap Internet
[13:50] <didrocks> at least this thing is positive :)
[13:51] <kgunn> didrocks: good ol' americans...figure out how to charge a premium for something that "sort of works" :)
[13:52] <didrocks> kgunn: how to say without being rude that I'm not surprized? :)
[13:53] <kgunn> didrocks: :)
[13:55] <olli> didrocks, I wouldn't be worried about _sounding_ rude... seems impossible for French
[13:55] <mterry> didrocks, let's say a package has typical autopilot tests in tests/autopilot.  What do you expect to see in that second-to-last column on that touch spreadsheet
[13:56] <didrocks> olli: tsssss, how ironic after the "excuse my French" and other similar expressions I'm hearing ;)
[13:57] <olli> never made sense to me
[13:57] <olli> ;)
[13:57] <didrocks> heh ;)
[13:57] <didrocks> mterry: the package name shipping those autopilot tests (so <foo>-autopilot for instance), all the required packages to run it (maybe a manual run on a guest session for ensuring it's working is best) and the command that needs to be run to start them
[13:57] <didrocks> mterry: making sense?
[13:59] <didrocks> sil2100: FYI, everything is now published
[13:59] <didrocks> sil2100: I just promoted in raring-proposed appmenu-qt5 and dbusmenus-qt5 to main
[13:59] <didrocks> (as they are installed by default)
[13:59] <mterry> didrocks, yeah
[14:01] <mmrazik> didrocks: me and fginther are wondering if this is good to go: https://code.launchpad.net/~mrazik/cupstream2distro-config/webcred/+merge/155541
[14:02] <didrocks> mmrazik: should check with kenvandine, and upstream if they agree with moving their branches now
[14:02] <didrocks> mmrazik: you have duplicated btw
[14:03] <didrocks> like target_branch: lp:libaccounts-qt
[14:03] <didrocks> in raring
[14:03] <didrocks> libaccounts-qt:
[14:03] <didrocks> in head
[14:03] <didrocks> oh
[14:03] <didrocks> sorry, it's in to_transition
[14:03] <didrocks> to yeah, excellent, just ensure with kenvandine and upstream that their branches moved :)
[14:03] <mmrazik> didrocks: do we actually need to check something with upstream? Can we just move stuff from to_transition as upstream creats the branches?
[14:03] <kenvandine> so upstream needs to create branches for raring right?
[14:04] <didrocks> mmrazik: I mean, checking for the /13.04 branches
[14:04] <mmrazik> didrocks: but can't that be done independently? I.e. the current merge proposal should just work or not?
[14:04] <mmrazik> and as soon as we have 13_04 we would move stuff out of to_transition
[14:04] <kenvandine> didrocks, but we don't have to have those branches...
[14:04] <didrocks> let me rephrase:
[14:04] <didrocks> target_branch: lp:account-plugins/13.04
[14:04] <didrocks> for instance
[14:04] <kenvandine> until upstream needs them for some reason
[14:04] <didrocks> you need to ensure upstream wants and has a lp:account-plugins/13.04
[14:04] <didrocks> right
[14:05] <didrocks> that's what I mean :)
[14:05] <didrocks> fginther: mmrazik:  ^
[14:05] <kenvandine> ok, so we don't need to create those branches for everyone project :)
[14:05] <kenvandine> just as needed
[14:05]  * mmrazik still confused
[14:05] <mmrazik> do I need to do anything?
[14:05]  * kenvandine is too
[14:05] <kenvandine> i think
[14:06]  * fginther confused +1
[14:06] <mmrazik> so my idea with that MP was the following:
[14:06] <kenvandine> upstream has created lp:account-plugins/13.04
[14:06] <mmrazik> -everything from head/webcred.cfg will be ignored except account-plugins
[14:06] <kenvandine> but not for others yet, because they haven't needed to
[14:06] <mmrazik> we will have autolanding jobs for lp:account-plugins
[14:06] <didrocks> so, if upstream has created lp:account-plugins/13.04, fine
[14:06] <didrocks> the MP is good
[14:06] <didrocks> that what just the thing I wanted to ensure ^
[14:06] <kenvandine> ok
[14:07] <mmrazik> - evreything in raring/webcred.cfg will be used to generate autolanding jobs
[14:07]  * kenvandine isn't confused anymore
[14:07] <kenvandine> :)
[14:07] <didrocks> mmrazik: so yeah, you can go ahead :)
[14:07] <mmrazik> for account-plugins an autolanding job for lp:account-plugins/13.04 will be create
[14:07] <didrocks> right :)
[14:07] <mmrazik> didrocks: oh
[14:07] <mmrazik> didrocks: understood
[14:07] <kenvandine> we just won't autoland anything else for raring, since they don't have 13.04 branches
[14:07] <kenvandine> trunk will go to head
[14:07] <didrocks> kenvandine: the elements have daily_release: False
[14:07] <didrocks> so they won't autoland
[14:07] <kenvandine> right
[14:07] <kenvandine> in this case
[14:08] <kenvandine> i was thinking bigger picture :)
[14:08] <mmrazik> uh oh
[14:08] <didrocks> apart from signon-keyring-extension: of course ;)
[14:08] <mmrazik> we are overloading the "autoland" term
[14:08] <kenvandine> mmrazik, yes.... yes we are
[14:08] <didrocks> mmrazik: that's part of the issue for quite some months :)
[14:08] <didrocks> hence I'm talking about
[14:08] <mmrazik> shall we talk about about "autoland" and "upstream merge"?
[14:08] <didrocks> "upstream merge"
[14:08] <mmrazik> ack
[14:08] <didrocks> and "daily release"
[14:08] <mmrazik> ok
[14:08] <kenvandine> we need a new term :)
[14:09] <didrocks> kenvandine: let's avoid the confusing term :-)
[14:09] <mmrazik> didrocks: so I'll top approve that merge proposal and will generate the jobs
[14:09] <kenvandine> automerge and autopackage?
[14:09] <mmrazik> fginther: ^^
[14:09] <didrocks> mmrazik: perfect ;)
[14:09] <fginther> mmrazik, ack
[14:09] <didrocks> kenvandine: that works too
[14:09] <kenvandine> and stop using the term autoland complete
[14:09] <kenvandine> +ly
[14:09] <didrocks> +1
[14:09] <kenvandine> so if we here someone use the term, we know they are confused :)
[14:10] <didrocks> kenvandine: so you don't really need to redeploy, as all the changes are either in to_transition or daily_release = False
[14:10] <didrocks> (for autopackage)
[14:10] <mterry> didrocks, libhybris isn't in the touch blueprint.  Are we upstream for that?
[14:10] <kenvandine> didrocks, and what do you mean by redeploy?
[14:10] <kenvandine> :)
[14:10] <kenvandine> we need a dictionary of terms here :)
[14:10] <didrocks> mterry: it's on that one: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-ubuntu-touch-porting
[14:10] <didrocks> mterry: because yeah, we are not upstream for it
[14:11] <didrocks> kenvandine: did you read my wiki page I pointed the other day? :)
[14:11] <didrocks> there are even links!
[14:11] <kenvandine> yes
[14:11] <didrocks> kenvandine: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Deploy_both_stacks_you_modified
[14:11] <mterry> didrocks, OK, so I'll just put that in our PPA then
[14:12] <didrocks> mterry: yep ;)
[14:17] <sil2100> \o/
[14:39] <kenvandine> didrocks, since the platform stack isn't deployed yet, i am just updating the stack in head removing the to_transition, and disabling it in raring until they have a branch for raring
[14:39] <kenvandine> didrocks, does that make sense?
[14:45] <didrocks> kenvandine: we can still have daily release for it in raring, you think? or it will never happen?
[14:45] <kenvandine> maybe
[14:45] <kenvandine> i need to talk to them about maintaining a bug fix branch for raring
[14:45] <didrocks> so, keep it like that for now, and let's see once we are sure :)
[14:46] <kenvandine> i am sure they are going to want fixes to land in raring
[14:46] <didrocks> we can deploy it after the fact
[14:46] <kenvandine> ok... so keep it for raring and go ahead and deploy?
[14:46] <didrocks> kenvandine: hum, why do you want to deploy it until it's ready?
[14:47] <kenvandine> i am anxious to get it deployed :)
[14:47] <didrocks> I don't get it :)
[14:47] <didrocks> if it's not ready for daily release
[14:47] <kenvandine> i figured letting it release to next would be a good start
[14:47] <kenvandine> not to raring :)
[14:47] <didrocks> but trunk is ready?
[14:47] <didrocks> bootstrapped, etc?
[14:47] <kenvandine> it just needs the bootstrap commit
[14:47] <didrocks> we have integration tests running?
[14:47] <kenvandine> which i wanted to do today
[14:47] <kenvandine> yes
[14:48] <didrocks> ok, fine by me to go that in head then
[14:48] <didrocks> kenvandine: so bzr rm it on raring
[14:48] <kenvandine> ok, i figured better to start with head and not enable daily release on raring
[14:48] <kenvandine> ok
[14:48] <didrocks> to avoid catastrophees ;)
[14:48] <kenvandine> indeed
[14:48] <didrocks> ok
[14:48] <didrocks> FYI
[14:48] <didrocks> #schedule: 0 3 * * 1-5
[14:48] <didrocks> it's disabled by default
[14:48] <didrocks> kenvandine: I'm still working on cupstream2distro to support parallel release
[14:49] <didrocks> (in term of commits collect)
[14:49] <didrocks> terms*
[14:49] <didrocks> kenvandine: so you won't have it yet, but soon, I hope to finish on Monday
[14:50] <kenvandine> ok
[16:08] <didrocks> mterry: btw, I've fixed and tested a bug (due to multiple manual uploads) that prevented unity-asset-pool to release its last commit. It was a new icon for 100scopes, do as you wish (it's not used, so technically doesn't break UIF)
[16:09] <didrocks> mterry: just be prepare if infinity is going to close the archive as he told on the email in 12 hours that the manual review otherwise will reject it :)
[16:17] <mterry> didrocks, awesome.  You mean it will land next time unity stack runs?
[16:18] <didrocks> mterry: yep, so either you can do it today, or you can see what they will tell if infinity is going to freeze the archive :)
[16:18] <mterry> didrocks, might as well try today
[16:18] <didrocks> great ;)
[16:18] <mterry> didrocks, I thought freeze was yesterday though
[16:19] <didrocks> mterry: read ubuntu-devel (ML)
[16:19] <mterry> didrocks, I hate reading
[16:19] <didrocks> mterry: but but… you read my "read ubuntu-devel (ML)"
[16:19] <didrocks> mterry: I'm puzzled, afraid and lost now :p
[16:20] <mterry> didrocks, i actually don't see it
[16:20] <mterry> will check archive
[16:21] <didrocks> oh
[16:21] <didrocks> it's in ubuntu-release ML
[16:21] <didrocks> mterry: sorry ^
[16:21] <didrocks> (they just end up in the same folder)
[16:23] <mterry> sure
[17:59] <slangasek> hi, can anyone here tell me how I can run the tests in the compiz package?
[17:59] <slangasek> (trying to fix a bug I filed a while back, and wanting to do it right with a new test case)
[18:03] <slangasek> the package has a build-dep on libxorg-gtest-dev, but seems to be completely unused... debian/rules overrides the dh_auto_test target, but dh_auto_test doesn't do anything anyway...
[18:03] <bschaefer> slangasek, in your build dir for compiz, you should be able to do make test
[18:11] <slangasek> bschaefer: hmm; why is this not being done by default in the package build?  Also, there seem to be some bits missing wrt gtest support (-DCOMPIZ_BUILD_TESTING=OFF, google-mock not a build-dependency), is this relevant?
[18:12] <slangasek> right, so it seems that after twiddling both of those things, the tests are building
[18:12] <slangasek> but I wonder why that's off by default
[18:13] <bschaefer> slangasek, hmm im not sure why its turned off by default, smspillaz or didrocks would be ones that would have a better answer for that :)
[18:13] <slangasek> ok


[09:44] <ara> slangasek, did you check if the testcase review session conflicts with any other session you may have?
[09:44] <ara> slangasek, it is today at 1700
[11:51] <slangasek> ara: I'll be there
[11:51] <ara> slangasek, ok, great, thanks
[11:55] <slangasek> in general, marking people as attendance essential is supposed to DTRT in the summit software, though apparently I had one yesterday that overlapped and I didn't notice :(