[00:01] <maxb> There probably isn't a place in launchpad to report bugs with http://people.canonical.com/~ubuntu-archive/madison.cgi
[00:02] <maxb> Alternatively, rmadison could fix up the columns client side
[00:07] <twb> Mm, what puzzle[sd] me is that it's only the ubuntu side
[00:09] <tumbleweed> twb: ubuntu is running madison-lite (which is a package in the archive)
[00:10] <twb> OK.  I'll see if I can remember how to use launchpad
[00:10] <twb> ...and report it against that.
[00:17] <infinity> twb: Oh hey, I've never noticed the difference in prettiness.  We could certainly fix that.
[00:18] <twb> Cool.
[00:18] <twb> piping into column -ts'|' doesn't DTRT because of the spaces on the LHS of the release name
[00:18] <twb> I sent the bug to malone
[00:19] <twb> Buuuuut I fat-fingered the package name.  Oopsie.
[00:19] <infinity> Hrm.  I was going to look at what raw 'dak ls' output looks like, but ries seems... Down?  Or something?
[00:19] <infinity> Irksome.
[00:19] <twb> infinity: dunno.  alioth was sick last week
[00:19] <twb> Might still be a little sick
[00:19] <infinity> Yeah, the two don't relate at all.
[00:24] <infinity> twb: FWIW, your bug is https://bugs.launchpad.net/ubuntu/+source/madison-lite/+bug/315833
[00:25] <twb> Cool
[00:25] <twb> I stupidly did affects/rmadison instead of devscripts
[00:26] <infinity> twb: Where's your bug, I'll dupe it to this one.
[00:26] <twb> infinity: it didn't get created AFAIK.
[00:26] <infinity> Oh.
[00:26] <infinity> Kay.
[00:27] <twb> http://sprunge.us/KLMG is the malone error message
[00:27] <twb> I got confused by you saying "this is your bug" ;_)
[00:29] <twb> I was also about to add "how curious that the last correspondent also picked the same options as me" until I looked at the timestamp :P
[00:29] <infinity> *laugh*
[00:29] <twb> Anyway, it looks like this is all under control.  Thanks for your help.
[05:57] <pitti> Good morning
[06:27] <pitti> StevenK, wgrant: can we enable https://translations.launchpad.net/ubuntu/trusty/+language-packs early in the cycle?
[06:30] <wgrant> pitti: With the usual schedule (ie. each series back one level)?
[06:31] <pitti> wgrant: yes, that WFM; we don't need to produce saucy updates twice a week any more
[06:31] <pitti> wgrant: in fact, I think we could/should even switch quantal/raring to "on demand", it's very unlikely that we'll ever do an official update
[06:46] <Mirv> any core-dev up for acking a packaging change from cu2d? http://pastebin.ubuntu.com/6477621/ - because upstream touched debian/changelog manually, it now misses the mention of "Adds a test suite for the libupstart-app-launch code."
[06:46] <Mirv> otherwise looks ok, although no explanation why as part of re-enabling zeitgeist the -Wno-error=unused-function was added
[06:48] <Mirv> I checked also that the new tests were really run as part of the build in daily-build PPA
[06:53] <pitti> Mirv: LGTM
[06:55] <Mirv> thank you
[07:56] <BrotherBrick> morning
[08:42] <dholbach> good morning
[09:11] <DktrKranz> infinity: ries is no more, now you want to login to coccia.d.o
[09:49] <mlankhorst> looking for sru team https://bugs.launchpad.net/ubuntu/precise/+source/libdrm/+bug/1253041
[09:49] <mlankhorst> :P
[09:55] <itsme_> Hello everyone,  When I clicked on my Ubuntu power button on the top-right corner, a user account by the name of "J Random User" appeared on the list of users . I restarted my computer and now the user account has disappeared. Should I be worried that my computer has been compromised by someone/something, or is there a logical explanation for this?
[09:56] <itsme_> I'm currently using Ubuntu 13.10
[10:08] <pitti> itsme_: hm, my initial thought was "this is a test string in indicator-session", but it isn't
[10:08] <pitti> itsme_: was it exactly "J Random User"? (capitalization, periods, etc.)
[10:09] <itsme_> It was exactly "J Random User"
[10:10] <itsme_> pitti: No periods or comma
[10:11] <pitti> itsme_: I cannot find this string anywhere on my system, so no immediate idea; you can check "last" for some implausible logins
[10:12] <lotuspsychje> pitti: i also sugested him a peak at auth.log, nothing there neither
[10:13] <itsme_> pitti: Shll I paste (pastebin) the output of the command "last"? Nothing unusaull in here
[10:13] <pitti> itsme_: won't help then
[10:17] <diwic> pitti, hi, just a quick question - do you know if a dbus activated service (on the session bus) can talk to the GUI? The idea is to be able to pop up a dialog without having a daemon running all the time just for that
[10:18] <pitti> diwic: yes, it can; session bus services retain all environment variables like $XDG_*, $DISPLAY, etc.
[10:18] <pitti> diwic: (unlike the system bus, where services have zero env)
[10:20] <diwic> pitti, sounds good, thanks!
[10:21] <lotuspsychje> itsme_: do you have any card reader on ubuntu?
[10:21] <itsme_> No I don't
[10:21] <lotuspsychje> hmm
[10:22] <lotuspsychje> i found a thread with that j random user, not sure it has something to do with this
[10:22] <lotuspsychje> http://menari.eu/post/42508697963/feitian-epass2003-with-opensc-on-archlinux
[10:23] <lotuspsychje> maybe its used in same way of John doe
[10:23] <lotuspsychje> cant find any related stuff for ubuntu...
[10:23] <itsme_> lotuspsychje :  varunendra: "Secure Boot" or UEFI feature was widely implemented in 2012 and its an Intel technology. My motherboard (Gigabyte) and processor is AMD and I haven't updated my Bios since 2008
[10:30]  * cjwatson notices the discussion of bug 315833 overnight, and tidies up rmadison output
[10:45] <mlankhorst> why is https://launchpad.net/ubuntu/+source/xorg-server/2:1.14.3-5ubuntu1 still in proposed?
[10:45] <Laney> mlankhorst: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xorg-server
[10:45] <mlankhorst> oh fu firefox tests
[10:48] <Laney> Quite
[10:48] <Laney> It's not exactly ideal having those fail all the time
[10:49] <mlankhorst> you could say that :-)
[10:49] <mlankhorst> can you override it?
[10:51] <Laney> okay
[10:51] <mlankhorst> thanks
[10:52] <Laney> done
[10:54] <mlankhorst> it has a fix for loading mesa 10 :)
[10:56] <mlankhorst> ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_bo.o): In function `radeon_bo_map':
[10:57] <mlankhorst> /build/buildd/mesa-10.0.0~rc2/build/dri/src/gallium/winsys/radeon/drm/../../../../../../../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:520:(.text+0xf34): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `radeon_bo_do_map' defined in .text section in ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_bo.o)
[10:58] <mlankhorst> hm what is that error in english?
[11:56] <pete-woods> didrocks: hi! Is there somewhere I can read about how to make package releases now? Is every landing still supposed to go through the spreadsheet, or are some projects still automatically daily releasing?
[11:57] <didrocks> pete-woods: it's still the spreadsheet for now
[11:57] <didrocks> pete-woods: so nothing really knew
[11:57] <didrocks> new*
[12:07] <pete-woods> didrocks: okay, and that applies to like every project? whether it's phone related or not?
[12:08] <didrocks> pete-woods: only everything that is seeded in the phone image
[12:08] <vood> Hello, I have a probleb with developer.ubuntu.com/publish - I added my application and uploaded source archive but app still appear as "Draft". How can I fix it or send to the review&?
[12:09] <pete-woods> didrocks: so, specifically I have two libraries for testing dbus stuff (libqtdbustest/mock), but they aren't auto-releasing, and they aren't on the phone image, either
[12:10] <didrocks> pete-woods: are they used by phone components?
[12:10] <didrocks> pete-woods: like build-deps or in the tests?
[12:10] <pete-woods> didrocks: yeah, they're build deps, does that count me as part of the image then?
[12:10] <didrocks> pete-woods: so yeah, they are in this rule :)
[12:11] <pete-woods> didrocks: okay, I will get them added to the spreadsheet then
[12:11] <pete-woods> :)
[12:11] <didrocks> thanks!
[12:43] <pitti> for the C++ types here: If I have "std::string dest_string;", and don't do anything else with that, woudl that potentially crash at the end of the function when it gets auto-freed?
[12:43] <pitti> (because it's not initialized or something?)
[12:44] <cjwatson> not that I'm willing to admit to being a C++ type, but I would expect that to use the default std::string constructor
[12:44] <pitti> yes, me too
[12:44] <cjwatson> which constructs an empty string
[12:44] <pitti> I was looking into bug 1254996, and fixed it with https://code.launchpad.net/~pitti/autopilot-gtk/fix-1254996/+merge/196703
[12:45] <pitti> but it's still rather inexplicable to me
[12:45] <pitti> aside from the ugliness of tossing some bits of C++ into an otherwise C function, I can't see anything wrong with the original code
[12:45] <cjwatson> it might be something to do with the str != NULL case causing dest_string to refer to something which is now out of scope
[12:46] <pitti> also, it's excruciatingly painful to reproduce
[12:46] <pitti> cjwatson: string's = operator makes a copy of teh assigned C string, though
[12:46] <cjwatson> yeah
[12:46] <pitti> that was actually my first thought, but that seems fine to me
[12:47] <pitti> I ran the tests through valgrind, it didn't have anything to complain about; and we never saw it with anything else that uses ap-gtk, just with the recent ubiquity tests
[12:47] <pitti> and on top of that, it doesn't seem to happen on today's image even, just on yesterday's
[12:48]  * cjwatson cops out with "how strange"
[12:48] <pitti> cjwatson: yeah, I settle with that, too
[12:48] <pitti> cjwatson: thanks
[12:48] <cjwatson> afraid it's been over ten years since I wrote C++ professionally, and I'm quite happy with this state of affairs :-)
[12:48] <pitti> heh, likewise
[12:49] <pitti> (well, not even professionally, I just touched it a bit during uni)
[12:50] <cjwatson> I did quite a bit in $job-2, but not with the STL
[12:51] <pitti> presumably it only crashes on Tuesdays anyway
[12:55] <kfunk> yofel: any idea about https://bugs.launchpad.net/ubuntu/+source/icecc/+bug/1182491 -- i see that you have an updated version of icecc in your PPA.
[12:55] <kfunk> can't we just ship a more recent version of icecc?
[12:55] <kfunk> we're using icecream at the office, some people are using ubuntu 13.04. and right now we were wondering why the overall performance of our icecream network degraded :)
[13:02] <mlankhorst> yeah
[13:02] <mlankhorst> toolchain bug \o/
[13:03] <mlankhorst> mesa FTBFS on arm if I don't add -fno-optimize-sibling-calls to cflags
[13:23] <rbasak> pitti: it looks to me as if you've got something else stomping on the stack and writing over dest_string's space, which causes its destruction to blow up.
[13:23] <rbasak> pitti: I suspect convert_value.
[13:23] <rbasak> pitti: I'm not sure valgrind would catch this necessarily.
[13:24] <rbasak> pitti: if you can reproduce this in gdb, you could set up a watch over dest_string's stack space. Then you might get a break where dest_string isn't supposed to be being accessed.
[15:05] <infinity> DktrKranz: Oh, that would explain it.  machines.cgi doesn't seem to reflect that.
[15:48] <barry> xnox, doko this autopkgtest failure in trustyp py33 is very strange.  it shouldn't be happening afaict :/
[16:37] <zul> barry:  ping how do you use tox with dh_python?
[16:38] <barry> zul: pybuild has a --test-tox option
[16:38] <barry>           --test-tox
[16:38] <barry>                  use  tox command in test step, remember to add python-tox to
[16:38] <barry>                  Build-Depends. Requires tox.ini file
[16:38] <barry>  
[16:39] <zul> barry:  do you have an example package that uses pybuild?
[16:39] <barry> zul: i do, but not yet one that also uses tox
[16:40] <zul> barry:  the pybuild example is good enough for me right now :)
[16:40] <barry> zul: :)  here's two:
[16:40] <barry> http://anonscm.debian.org/viewvc/python-modules/packages/enum34/trunk/debian/
[16:41] <barry> http://anonscm.debian.org/viewvc/python-modules/packages/flufl.i18n/trunk/debian/
[16:41] <zul> barry:  cool thanks
[16:45] <alexbligh> I'm trying to package a library (distributed as binary+headers - yuck) into a libxyz and libxyz-dev package. I'm trying to do it from scratch with dh_make. This calls fakeroot debian/rules build (which runs Makefile) and fakeroot debian/rules binary. I /thought/ the Makefile was meant to put its output into debian/libxyz (etc.), but fakeroot debian/rules binary then runs dh_prep which clears this. How is this me
[16:45] <alexbligh> ant to work?
[16:50] <xnox> alexbligh: remove all makefiles (since you can't re-compile/install binary) & simply list files where they need to go in debian/libxyz.install & debian/libxyz-dev.install
[16:51] <alexbligh> xnox, I need the makefiles to expand the stupid tar format thing, rename stuff etc. etc.
[16:51] <xnox> alexbligh: build, typically compiles. And binary stage usually does $ rm -rf debian/$pkg && make install DESTDIR=debian/$pkg
[16:51] <xnox> (roughly, it's actually more than that)
[16:52] <alexbligh> xnox, right, so my 'Compile' step is actually a copy, rename, some perl etc., but the question is 'where should its output go'?
[16:52] <xnox> alexbligh: what are the binaries?
[16:52] <alexbligh> xnox, parallels-virtualisation-sdk - the binaries are some .so files
[16:52] <xnox> alexbligh: the output should go anywhere, e.g. a dir called "build/" that you create and clean up.
[16:52] <xnox> alexbligh: anywhere, as long as ./debian/rules clean, cleans all of the temp outputs.
[16:53] <alexbligh> OIC. So why does dh_make tell me to put it in debian/libxyz? (which is what dh_prep unhelpfully deletes)?
[16:53] <alexbligh> I'll just change the makefile back then!
[16:53] <alexbligh> So I should just just put them in (e.g.) build, and then make the .install file install them from build/ to /usr/include etc.
[16:54] <xnox> i don't think that's what dh_make meant =)
[16:54] <xnox> alexbligh: correct.
[16:55] <alexbligh> "Done. Please edit the files in the debian/ subdirectory now. You should also check that the libparallelssdk Makefiles install into $DESTDIR and not in / ."
[16:55] <psusi> xnox: fyi, I looked at switching dmraid to the new driver.. it's a bit more complicated than we thought.  It seems that the new driver lacks the offset parameters ( to specify where in the disk the array begins )
[16:55] <alexbligh> xnox, thanks
[16:55] <psusi> so it will need to create a linear dm target to create the offset and insert it between the raid target and the disk
[16:55] <psusi> that exceeded my pain threshold so I gave up
[16:57] <xnox> alexbligh: "install into DESTDIR" means that "make install" will be called with a variable DESTDIR=$something. Which could be debian/$pkg for a single package, or debian/tmp for a multi-binary package. So "upstream Makefile" may not assume anything about $DESTDIR variable.
[16:58] <xnox> alexbligh: but e.g. install headers into $DESTDIR/usr/include/
[16:58] <xnox> alexbligh: later dh_install can be used to split what goes into what package.
[16:58] <alexbligh> xnox, the trouble is if you do that, it runs dh_prep afterwards which deletes $DESTDIR/usr/include. But anyway, I will just do it manually!
[17:16] <xnox> alexbligh: make build -> may not create anything in debian/[$pkg|tmp], make install -> may not be called as part of build target, ./debian/rules binary -> calls dh_prep (to clean everything) and then calls `make install DESTDIR=debian/pkg` to do a clean fresh installation of build-targets to $DESTDIR
[17:16] <alexbligh> ah! so the real fix is that I should be doing the install under the install target. Doh.
[17:17] <xnox> alexbligh: try experimenting with bear minimal Makefile. E.g.: build: "echo hello > myfile" install: mv myfile $DESTDIR/myinstalledfile
[17:17] <xnox> alexbligh: that's what dh_make meant by install =) the "install:" target =) and make sure it's _not_ the first target in your Makefile. So your first target must be e.g. "build:" and the second one "install:"
[17:18] <alexbligh> xnox, doh. Thanks
[17:18] <xnox> alexbligh: setting export DH_VERBOSE=1 also helps, cause that dh would actually print what it is invoking, and it makes troubleshooting easier.
[17:20] <catbus1> srinira: ping
[17:27] <srinira> catbus1 ping
[17:27] <catbus1> srinira: pong
[17:45] <happyaron> wanna have some talk about input methods? and damned I got some "jet lag" now...
[17:47] <alexbligh> If I am building a library package and a -dev package, what is it that is meant to create the relevant symlinks? Is there some handy howto guide on this?
[17:57] <xnox> alexbligh: usually upstream build-system does (e.g. libtool etc). in your case, you can create them by-hand.
[17:57] <alexbligh> xnox, ah :-/
[17:57] <xnox> alexbligh: e.g. just drop debian/$pkg.links
[17:57] <xnox> alexbligh: $ man dh_link
[17:58] <alexbligh> xnox, yeah there's a pile of them. I was going to read the SONAME out the elf table and work out what they should be dynamically so when $upstream upgrades their stuff it works it out
[17:58] <alexbligh> xnox, do I need to do the ldconfig myself on .postinst etc.?
[18:01] <xnox> check your packages with lintian, it will tell you if there are too many or missing ldconfig calls.
[18:02] <alexbligh> xnox, thanks
[18:11] <seb128> ev, is e.u.c using trust-proposed for dbgsym? I'm wondering why the most reported trusty issue doesn't have a valid retracting (it's happening with a proposed version)
[18:56] <ev> seb128: nope, trusty-proposed is commented out: http://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/files/head:/retracer/config/Ubuntu%2014.04/
[18:57] <seb128> ev, can we get it added? (should I open a bug/where?)
[18:58] <ev> seb128: I *think* that breaks things. pitti do you remember more about this? I vaguely recall us saying that we get broken retraces on crashes from package versions that predate the version in proposed because apport complains that there's a newer version
[18:58] <ev> this is why we've been only flipping on proposed once the release is out the door
[18:58] <ev> for the daisy retracers, that is
[18:59] <seb128> hum, k
[18:59] <seb128> I though apport was smart enough to find the right version when it's available in the index
[18:59] <seb128> or one of the index/sources
[19:00] <seb128> let's wait for pitti to reply, I guess that's going to be for tomorrow
[19:00] <seb128> ev, thanks
[19:00] <ev> sure thing - keen on getting this resolved in a more long term way :)
[19:03] <seb128> ;-)