[03:25] <micahg> dh_python3 seems to creating a depends on python3-pyflakes in Ubuntu only which is messing up the build of python-flake8, I'm not sure where to file this bug now that we have dh-python as a separate source or if that's even the cause
[03:26] <micahg> hrm, Debian is affected as well, so it's not Ubuntu specific
[03:33] <pitti> Good morning
[06:23] <ScottK> micahg: Please try it again with this weekend's dh-python upload and see if it's fixed.
[07:02] <dholbach> good morning
[07:16] <darkxst> anyone able to sponsor bug 1219148 for me
[07:16] <darkxst> ?
[07:16] <darkxst> 1212408
[07:17] <darkxst> that should have been bug 1212408
[07:21] <darkxst> Also 1189309
[07:21] <darkxst> bug 1189309
[08:49] <brendand> hey - i can see my package build has put the files into debian/tmp, but they aren't getting installed when i install the .deb file that is created
[08:50] <brendand> so for example in the build environment i see debian/tmp/usr/bin/my-app
[08:50] <brendand> and in the .install file i have
[08:50] <brendand> usr/bin/my-app
[08:51] <brendand> so i should get /usr/bin/my-app installed (shouldn't i?)
[08:51] <Laney> brendand: export DH_VERBOSE=1 in debian/rules then rebuild and you'll be able to see what dh_install is doing
[08:52] <brendand> Laney, thanks for the tip
[08:54] <lool> ev: hey, would you mind pointing me at the docs on how to connect errors.u.c reports with LP bugs?
[08:54] <lool> ev: the libgpod-common one is the one I'd like to connect to LP #1212546
[08:55] <ev> lool: this one? https://errors.ubuntu.com/problem/28836a9ab5fd3bac86aa699f4c2be0a7d52b61cf
[08:57] <ev> lool: just make sure you're logged in, then hit the Create link for the relevant problem on this page: https://errors.ubuntu.com/?package=libgpod-common&period=year
[08:57] <lool> ev: yes this one
[08:58] <lool> ev: ah I was looking for a login, but it was hidden by my browser's search box!
[08:58] <ev> :D
[09:00] <lool> ev: ah so I can't link to an existing one?  ok, marked the new one as a dup -- it will still be able to track status updates?
[09:01] <Sp4rKy> W 36
[09:03] <ev> lool: correct - you cannot yet link to an existing one. Marking as the dup is the right approach, but lp:daisy doesn't seem to have the smarts for that yet. Please feel free to file a bug: http://launchpad.net/errors/+filebug
[09:03] <ev> smarts to follow the bug to its parent when dup'ed, that is
[09:06] <lool> ev: LP #1219706 -- thanks!
[09:06] <ev> thanks!
[09:11] <ritz> tjaalton ping, wrt https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/985202
[09:20] <tjaalton> ritz: ok, needs reopened?
[09:20] <tjaalton> uh, what's using .cache/friends/avatars?
[09:21] <tjaalton> I have 45k files there, 1.7GB
[09:21] <ritz> tjaalton yes
[09:21] <ritz> libfolks/empathy ?
[09:22] <ritz> the patch needs to be updated to the "correct" fix
[09:23] <seb128> tjaalton, friends is using that dir, I though Ken said the new version was supposed to manage those better though
[09:24] <tjaalton> seb128: ok, newest entries there seem to be a couple of weeks old. I had raring before that
[09:24] <tjaalton> so, friends on raring is still busted I guess
[09:24] <seb128> likely
[09:25] <pitti> wgrant, StevenK: we might have discussed this already, but I forgot: how much effort would bug 1201485 be on the LP side? duplicating the whole import logic in langpack-o-matic would be a lot of effort, and also rather brittle I guess
[09:26] <tjaalton> ritz: right, I can pull the upstream commit directly with less effort, if that's ok
[09:26] <ritz> tjaalton perfectly fine :) thank you
[09:27] <seb128> wgrant, StevenK, pitti: our current translations situation is getting really suboptimal, all stuff under daily release (which is most of unity) don't get updated translations due to that
[09:28] <pitti> wgrant, StevenK: i. e. those translation tarballs would need to be fed to translations as if they were an actual ubuntu upload; or the tarballs need to be copied along with the package on PPA copy
[09:29] <cjwatson> I think that's probably not that hard now.  In fact I vaguely remember us talking about it at the releng sprint
[09:31] <cjwatson> We have mechanisms to copy custom uploads in general, so it's just a matter of whether there are any translations-specific gotchas
[09:32] <cjwatson> It might be necessary to factor PackageUploadCustom.publishRosettaTranslations out to archivepublisher so that it can fit into the scheme expected by the custom upload copier, perhaps
[09:39] <ekarlso->  https://launchpad.net/~endre-karlson/+archive/libra/+sourcepub/3458679/+listing-archive-extra < anyone know why this only does i386 ?
[09:41] <wgrant> pitti, seb128: As cjwatson says, it's probably not terribly hard now.
[09:41] <cjwatson> ekarlso-: Because it's an Architecture: all package.
[09:41] <cjwatson> ekarlso-: They only need to build on one architecture (i386), but are published to all architectures.
[09:42] <cjwatson> ekarlso-: Also, your versioning of that package is rude.  You shouldn't reuse the Debian namespace
[09:42] <cjwatson> Append something to the version rather than bumping it to -2 ...
[09:43] <cjwatson> Though, wait, was this package not based on the gearman package in Debian?  (If not, why not?)
[09:43] <sil2100> gusch: hi!
[09:43] <cjwatson> From the version number I assumed that it was a rebuild of the version in Debian.
[09:43] <ekarlso-> cjwatson: I think it's due to a not upstream yet support of ssl
[09:43] <sil2100> gusch: the gallery-app failing-AP-tests merge still has problems it seems: https://code.launchpad.net/~schwann/gallery-app/gallery-atest-toolbar-opened/+merge/183195
[09:43] <cjwatson> ekarlso-: Bumping the upstream version doesn't require throwing away all the Debian history.
[09:44] <ekarlso-> cjwatson: again, I didn't do that
[09:44] <sil2100> gusch: while this failure is still blocking the apps stack from releasing ;)
[09:44] <ekarlso-> I just bootstrapped the package from a source tar
[09:44] <cjwatson> ekarlso-: OK, but you did bump it from -1 to -2
[09:44] <ekarlso-> cjwatson: because I haven't done much packaging before :)
[09:44] <ekarlso-> but noted for the next bump
[09:44] <cjwatson> Right, which is why I'm explaining that there are conventions for versions to reduce confusion ...
[09:44] <ekarlso-> :)
[09:45] <ekarlso-> optimally I wouldn't do packaging at all to avoid this
[09:45] <cjwatson> In fact it's even more confusing.  Debian's gearman package comes from a gearmand source package
[09:45] <gusch> sil2100: the problem is, that the fix for the share component seems to not have landed there
[09:45] <cjwatson> So it looks as though Matthew Tai entirely repackaged it from scratch
[09:46] <ekarlso-> hmmms ok ? :p
[09:47] <cjwatson> Ah well, people do strange things
[09:47] <ekarlso-> ;p
[09:47] <ekarlso-> cjwatson: the geamrna stuff is only temp until the changes we need go into trunk
[09:48] <sil2100> gusch: so we need also some other fix for this one to work? In which branch?
[09:48] <cjwatson> Anyway, your i386 build will have been published to all architectures; if you want to check, look in the dists/ subdir of your published PPA for some other architecture
[09:50] <gusch> sil2100: https://code.launchpad.net/~ken-vandine/ubuntu-ui-extras/friends0.2/+merge/182895
[10:04] <sil2100> gusch: so, this is causing the fails-to-merge? I actually thought that it should be ok if that's merged in, hm
[10:04] <dpm> cking, morning! On bug 1199073 do you have any suggestions on how to reduce the overhead?
[10:05] <sil2100> Since the upstream merger should use dialy-build PPA
[10:07] <cking> dpm, i guess only via analysing it via tools like strace to see what system calls are being used to figure out why it is so busy
[10:08] <cking> dpm, I've got no knowledge of how this app works or any qml know-how, so I have no immediate idea why
[10:08] <dpm> ok, thanks cking
[10:09] <gusch> sil2100: it seems the fix is not yet in the saucy package - but it's quite weired, as it only fails for mako ...
[10:09] <sil2100> gusch: and even if not, that change is already released into release
[10:10] <gusch> sil2100: can you check if the mako setup has an issue?
[10:10] <sil2100> gusch: it should be, it got released on the 29th - I'll try checking that
[11:53] <gusch> I'm trying to use libupstart-app-launch
[11:53] <gusch> but the library does not contain any symbols
[11:54] <gusch> it seems dh_strip removes them during pakage build
[11:54] <gusch> but I don't see a resaon why this could happen
[11:54] <gusch> does anyone have an idea?
[11:56] <seb128> gusch, hey, what do you call "symbols"? debug symbols?
[11:56] <gusch> seb128: I mean by what "nm" reports for the library
[11:57] <gusch> seb128: result is, that I can't link to that library
[11:57] <seb128> gusch, on what arch?
[11:57] <seb128> $ nm -D /usr/lib/i386-linux-gnu/libupstart-app-launch.so.1.0.0 | grep " T upstart"
[11:57] <seb128> 00002500 T upstart_app_launch_get_primary_pid
[11:57] <seb128> 00002450 T upstart_app_launch_list_running_apps
[11:57] <seb128> 00002390 T upstart_app_launch_observer_add_app_start
[11:57] <seb128> ...
[11:58] <seb128> gusch, ^ that's what I get on saucy (i386)
[11:58] <gusch> seb128: for amd64 saucy: nm: /usr/lib/x86_64-linux-gnu/libupstart-app-launch.so.1.0.0: no symbols
[11:59] <seb128> weird
[11:59] <seb128> dpkg - l | grep libupstart-app-launch1
[11:59] <gusch> seb128: oh - I get the symbols when using "-D"
[12:00] <gusch> seb128: but why am I not able to link to the library?
[12:00] <seb128> gusch, can you copy the exact error/build log?
[12:00] <seb128> gusch, or share a vcs with your code?
[12:02] <gusch> seb128: lp:~schwann/content-hub/content-start-exporter
[12:03] <seb128> gusch, there is no libupstart code in there?
[12:04] <seb128> gusch, can you share the code that fails to build?
[12:04] <gusch> seb128: grrr - fogot to commit before ...
[12:04] <gusch> seb128: pushed - sorry for that
[12:05] <seb128> gusch, no worry, I got it, trying to build
[12:10] <seb128> gusch, the issue is that you don't have the libupstart build flags
[12:10] <gusch> seb128: argh
[12:10] <seb128> gusch, the check is in the sourcedir but that doesn't seem included in that CMakeLists.txt of that subdir
[12:11] <gusch> seb128: I used it to get the library, but not for the build flags
[12:12] <gusch> seb128: thx - I'd never had guessed that
[12:13] <seb128> gusch, yw
[12:26] <gusch> seb128: somehow I still don't get it to link
[12:27] <seb128> gusch, can you push what you did?
[12:29] <gusch> seb128: pushed
[12:29] <seb128> gusch, in that same file you changed did you try to add to
[12:29] <seb128> include_directories(
[12:29] <seb128>   ${CMAKE_SOURCE_DIR}
[12:29] <seb128> gusch, it only includes src/ atm
[12:29] <mardy> seb128: hi! About the shotwell update, do you know if someone has a branch with the updated debian/ stuff (apart from the online accounts parts)?
[12:30] <seb128> gusch, but the check is in the main dir
[12:30] <seb128> mardy, I do
[12:30] <seb128> mardy, let me push that
[12:30] <mardy> seb128: thanks!
[12:30] <seb128> gusch, the issue is that this subdir doesn't include the main config so it doesn't have the variable for the stuff that are checked in there
[12:36] <gusch> seb128: no difference
[12:36] <seb128> gusch, I don't know much about cmake, but the issue is clearly that the UPSTART check you do in the main file isn't carried over to the subdir
[12:37] <seb128> gusch, try maybe moving that check line to the subdir CMakeFile?
[12:37] <gusch> seb128: MESSAGE (${UPSTART_LAUNCH_LDFLAGS}) prints "-lupstart-app-launch-lglib-2.0"
[12:38] <mardy> seb128: please ping me once you have pushed your branch
[12:38] <gusch> seb128: so it's carried over (using _LDFLAGS or _LIBRARIES is not much of a difference)
[12:39] <seb128> gusch, did you typo that or is that really the value? you miss a space between the flags
[12:39] <seb128> mardy, I've a diff for the debian dir there http://people.canonical.com/~seb128/shotwell.diff
[12:39] <seb128> mardy, does that work for you or do you want a vcs rather?
[12:40] <mardy> seb128: I think it should be OK
[12:40] <gusch> seb128: no typo, but cmake sets it correctly in the link.txt
[12:40] <seb128> mardy, great; let me know if you need something else
[12:41] <seb128> gusch, let me have a look here
[12:50] <mardy> seb128: I always forget how to do it; was there a tutorial online?
[12:50] <seb128> mardy, how to do what?
[12:50] <mardy> seb128: to update the patch; I think I was using "bzr bd-do", but I cannot remember the steps
[12:51] <seb128> mardy, well, you can do
[12:51] <seb128> - comment from the debian/patches/series
[12:51] <seb128> - bzr bd-do
[12:51] <seb128> - renable it in the serie
[12:51] <seb128> - quilt push -f
[12:51] <seb128> - resolve conflicts/update
[12:51] <seb128> - quilt refresh
[12:51] <seb128> - ctrl-D
[12:52] <seb128> mardy, but just updating the diff is fine, use whatever method you prefer, if you do that over upstream git that works for me
[12:52] <mardy> seb128: excellent, thanks! I think I was following the steps you wrote now, last time, so I'll stick to that
[12:57] <ogra_> pitti, hey ... i would like to get rid of http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/99-remove-documentation.chroot from the ubuntu touch buildss, i remember you implemented something like that in a clean way, but forgot how to achieve it
[12:58] <ogra_> (and google isnt very informative or my skills are failing me today)
[13:00] <pitti> ogra_: you mean https://wiki.ubuntu.com/ReducingDiskFootprint#Drop_unnecessary_files ?
[13:01]  * ogra_ hugs pitti 
[13:01] <pitti> ogra_: *hug back*, kein Problem :)
[13:01] <ogra_> :)
[13:01] <pitti> ogra_: got a meeting with ev now, can explain details afterwards if necessary
[13:02] <ogra_> the wiki is pretty clear, implementing it at the right place of the build will be the tricky part :0
[13:02] <ogra_> :)
[13:03] <ogra_> pitti, hmm, that doesnt adjust the /var/lib/dpkg/info/*.md5sum files i suspect ?
[13:11] <seb128> gusch, yeah, I don't know about that build issue, it's probably an issue with the order of arguments/libs in the linker command but I can't figure out which one
[13:12] <gusch> seb128: thx for checking
[13:13] <JackYu> hi, any one know what's the new name of apt.progress? it seems that it was changed in these days.
[13:13] <xnox> ogra_: no need generally, why shoud it? or do you thing that will be a saving as well?
[13:13] <ogra_> xnox, heh, no ...
[13:14] <JackYu> apt.progress from python 2.7...
[13:14] <seb128> gusch, hum
[13:14] <seb128> gusch, doing
[13:14] <seb128> extern "C" {
[13:14] <seb128> #include <libupstart-app-launch-1/upstart-app-launch.h>
[13:14] <seb128> }
[13:14] <xnox> ogra_: i use localepurge, which uses same mechanics (dpkg include/exclude flags) and yes md5sums is "pristine" (which may or may not be complete, and have extra files listed)
[13:14] <ogra_> xnox, i'm trying to set up an md5sum check to check the installed files before and after tests ...
[13:14] <seb128> gusch, works
[13:14] <seb128> gusch, in app_manager.cpp
[13:15] <gusch> seb128: you are right - I should have thought of that ... thx
[13:15] <ogra_> xnox, so i was planning to do something like:  cat /var/lib/dpkg/info/*.md5sums  >tmp/md5sum.log &&  md5sum -c /tmp/all.md5sums >/tmp/md5sum.log
[13:15] <xnox> ogra_: $ debsums $pkgname, since it's all dpkg settings, it just works to verify as well.
[13:15] <ogra_> would that omit deleted files ?
[13:16] <ogra_> debsums would require me to iterate over all packages
[13:16] <xnox> ogra_: yeap, or simply run $ debsums, to do alll =)
[13:16] <ogra_> that would be very slow i guess
[13:16] <seb128> gusch, yw, I should have tried that earlier, I was focussed on the linker side ...
[13:16] <ogra_> root@ubuntu-phablet:/# time md5sum -c /tmp/all.md5sums >/tmp/md5sum.log 2>&1
[13:16] <ogra_> real	0m7.853s
[13:16] <ogra_> thats quite acceptable :)
[13:16] <xnox> ogra_: you don't have to. you can do $ debsums pkga pkgb
[13:17] <ogra_> root@ubuntu-phablet:/# tail -2 /tmp/md5sum.log
[13:17] <ogra_> md5sum: WARNING: 3870 listed files could not be read
[13:17] <ogra_> md5sum: WARNING: 133 computed checksums did NOT matc
[13:17] <JackYu> seb128,  hi, do you know what's the new name of apt.progress in Python 2.7?
[13:17] <ogra_> thats my problem  ...
[13:17] <seb128> JackYu, hey, I've no idea, maybe pitti or cjwatson can help you though
[13:17] <ogra_> (4003 files from /usr/share/doc get deleted during build)
[13:18] <xnox> ogra_: well debsums on my install, reports all OK and exit 0, despite having translation files removed the same way as in that wiki page.
[13:18] <cjwatson> I'm not aware of apt.progress having been renamed.
[13:18] <cjwatson> Perhaps you could state your actual original problem.
[13:18] <JackYu> seb128, thanks.
[13:18] <xnox> ogra_: use debsums ;-) it's awesome and supports all of that.
[13:18] <ogra_> well, can i use "debvsums *" ?
[13:18] <ogra_> :)
[13:18] <ogra_> -v
[13:18] <xnox> yes.
[13:18] <cjwatson> JackYu: ^-
[13:19] <xnox> just "$ debsums" iterates across all installed packages.
[13:19] <JackYu> cjwatson, hi, we use apt.progress in youker-assistant.
[13:19] <ogra_> oh, cool
[13:19] <ogra_> lets see how slow that is :)
[13:19] <JackYu> cjwatson, but it dosen't work now.
[13:20] <xnox> it's perl.... =) and supports options, e.g. it can list missing stuff if you want etc....
[13:20] <cjwatson> You use specific things from the package apt.progress.
[13:20] <cjwatson> apt.progress still exists, but the specific classes you're using need to be adjusted.
[13:21] <JackYu> cjwatson, we use InstallProgress, TextFetchProgress from apt.progress
[13:21] <cjwatson> Yes, those have been obsolete for several years.  It's not about Python 2.7, it's about the new python-apt interface that came in somewhere around Lucid.
[13:22] <pitti> ev: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:23] <JackYu> cjwatson, ok, thanks. I will check soon.
[13:24] <cjwatson> JackYu: You probably want something roughly along the lines of http://paste.ubuntu.com/6055145/
[13:28] <JackYu> cjwatson, wow, correct, thanks:)
[13:46] <pitti> ogra_: md5sums> hm, I thought I did that
[13:46] <pitti> ogra_: but it's been a while
[13:47] <ogra_> pitti, well, the second code definitely doesnt ... (thats what we use now)
[13:47] <ogra_> (on the wikipage that is)
[13:47] <pitti> ogra_: ah no, it doesn't adjust md5sum files
[13:48] <ogra_> if the first one does, that would help
[13:49] <pitti> ogra_: what is first and second here? --path-exclude and live-build?
[13:49] <ogra_> there are two ways of removing the docs in the wikipage ...
[13:50] <ogra_> livecd-rootfs currently uses the second during ubuntu touch build
[13:50] <ogra_> (talking about https://wiki.ubuntu.com/ReducingDiskFootprint#Drop_unnecessary_files)
[13:51] <pitti> ogra_: they need to be applied together, though
[13:51] <ogra_> but that leaves us with inconsistent md5 files
[13:51] <ogra_> ah
[13:51] <ogra_> hmm
[13:51] <ogra_> i dont think the first one is ...
[13:51]  * ogra_ checks the code
[13:51] <pitti> ogra_: --path-exclude (dpkg) for installing/upgrades packages, and the live-build adjustment to clean up the files from bootstrapping before your dpkg conf file gets installed (if you care about those)
[13:52] <pitti> ogra_: but yes, they both leave the md5sums file untouched
[13:52] <pitti> that just didn't come up back then
[13:55] <Peace-> can someone help me to understand thsi error ?  [60238.145947] mmc0: error -110 whilst initialising SD card
[14:06] <tjaalton> nfs mounts don't seem to get mounted on boot on saucy
[14:10] <tjaalton> doing manually what mountall-net.conf doesn't seem to fix things
[15:15] <ekarlso-> cjwatson: what's the best practice when re-building a package that is upstream and has the same version ?
[15:15] <cjwatson> ekarlso-: dch -R
[15:15] <ekarlso-> I mean, so my package will get prioritized over the upstream one
[15:16] <ekarlso-> change the version nr to a higher version ?
[15:17] <cjwatson> dch -R will do the right thing
[15:17] <cjwatson> Assuming it's a no-change rebuild
[15:17] <cjwatson> If you're making source changes, then dch -i
[15:18] <cjwatson> Actually, if this is for a PPA
[15:18] <cjwatson> ekarlso-: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
[15:19] <cjwatson> That has specific advice which is more detailed than I want to reproduce in IRC :)
[15:59] <mitya57> ScottK: Do you have anything against syncing new dh-python from Debian? The changes are our forwarded tests, couple of minor pybuild changes and bugfixes.
[16:09] <ScottK> mitya57: I think it needs an FFe as I don't think it's all bugfix.  In principal, I think we want it, but it ought to go through the process.
[16:16] <pitti> jibel: hm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has enough fodder for replicating this RUNNING bug again -- we have zero running tests right now, and pygobject is being held back by umpteen RUNNING ones
[16:17] <pitti> jibel: (we are in freeze anyway, so it's not urgent at all)
[16:18] <mitya57> ScottK: filed as bug 1219900 (will subscribe -release when the linked build is done)
[16:18] <ScottK> Great.
[16:19] <pitti> jibel: I just re-run the update-manager test, as that ran with 0.191 and 0.193 fixes the pep8 errors
[16:19] <pitti> wrt. to syncing, did anyone else notice that LP seems to take awfully long these days to import new packages from sid? it used to take about an hour after Debian's mirror pulse, now it takes about a day
[16:20] <xnox> the timings did change. and it has been <= 6h since appearing on the uk debian mirror so far as I could spot.
[16:20] <xnox> which is consistent with 4 daily dinstalls.
[16:23] <cjwatson> pitti: The machine that runs the imports is currently down
[16:24] <cjwatson> It apparently needs physical intervention
[16:25] <pitti> cjwatson: ah, thanks
[16:34] <ScottK> mitya57: See #d-python.  We want to wait for another upload today.
[16:36] <mitya57> OK.
[16:51] <cjwatson> pitti: https://rt.admin.canonical.com/Ticket/Display.html?id=64293
[16:51] <cjwatson> (Sorry, internal only)
[18:30] <ekarlso-> canæt I pin to a version like this? python-gearman (==2.0.2-2libra1)
[19:06] <ekarlso-> cjwatson: ?
[19:42] <cjwatson> ekarlso-: just one "=" - see the policy manual
[19:43] <ekarlso-> cjwatson: but can I only pin to a version numerically ?
[19:43] <ekarlso-> or can I add stuff like libra1 ?
[19:44] <cjwatson> If you want a range, use something like "python-gearman (>= 2.0.2-2), python-gearman (<< 2.0.2-3)"
[19:45] <cjwatson> You can use anything that's a valid version number in there (again, *please* see the Debian policy manual for this), but you should only use exactly-equals dependencies for things within the same source package as otherwise you have to keep remembering to change them