[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?