[01:12] <Noskcaj> To fix https://launchpadlibrarian.net/176326322/buildlog_ubuntu-utopic-ppc64el.libsigc%2B%2B-2.0_2.2.11-3_FAILEDTOBUILD.txt.gz should i just mark that symbol as not of ppc64el?
[03:58] <Logan_> infinity: are you still around?
[04:57] <Noskcaj> cjwatson, Are we able to sync ntfs-3g? The only remaining diff is to keep compatibility with ancient versions of ubuntu. How long till they are too old?
[05:23] <pitti> Good morning
[05:24] <ion> that
[06:11] <infinity> Logan_: Am now, ish..
[06:12] <infinity> Noskcaj: Understanding why a symbol went away is usually a good idea before blindly applying the change.
[06:57] <infinity> Noskcaj: Investigated, fixed, and bug filed in Debian.  Thanks for the heads-up.
[07:48] <pitti> xnox: ah, we forgot to look into bug 1316804 last week; I take it you still get this?
[07:48] <ubottu> bug 1316804 in systemd (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Confirmed] https://launchpad.net/bugs/1316804
=== zequence_ is now known as zequence
[07:58] <xnox> pitti: yeap.
[08:04] <Noskcaj> infinity, ok, thanks.
[08:04] <Noskcaj> I'll just stay away from stuff like that unless i learn C
[08:05] <pitti> xnox: good morning
[08:05] <brendand> should 'sudo click chroot -a armhf -f ubuntu-sdk-13.10 begin-session saucy' work?
[08:05] <pitti> xnox: so which tasks do we still need to fix?
[08:05] <brendand> provided i create'd with the same options previously
[08:06] <xnox> brendand: looks correct.
[08:06] <xnox> pitti: i have comment from steve about giving "task" jobs a free pass in startpar.
[08:07] <brendand> xnox, http://paste.ubuntu.com/7571426/
[08:07] <xnox> brendand: (a) that doesn't look like complete paste (b) E: 10mount: mount: unknown filesystem type 'overlayfs' -> what system are you running this on?
[08:08] <brendand> xnox, utopic
[08:08] <pitti> xnox: ok; I'm not quite sure how to interpret slangasek's reply, but if that meant "ok", fine for me
[08:08] <xnox> brendand: also saucy is end-of-life, not much use building using it.
[08:09] <brendand> xnox, well there's a warning before that about the location field being depreccated but that's in relation to a different chroot
[08:09] <pitti> xnox: note that this also needs to be applied to the split-out startpar source in utopic-proposed
[08:09] <xnox> pitti: he wants me to rework the patch. such that we don't wait for tasks to start, but do wait for tasks to stop.
[08:09] <pitti> ah
[08:09] <brendand> xnox, ok fair enough. i'm having a different problem with 14.04 though
[08:09] <pitti> xnox: so we keep tasks as they are (your list of 6 affected packages)
[08:10] <brendand> xnox, it won't let me create it due to it appears some existing file
[08:10] <pitti> xnox: and I should revert the udev-finish one
[08:10] <xnox> pitti: yeah, we still want to fix those (with or without fixing startpar as well)
[08:10] <brendand> xnox, but it won't let me destroy it either because it "doesn't exist'
[08:10] <brendand> FileExistsError: [Errno 17] File exists: '/var/lib/schroot/chroots/click-ubuntu-sdk-14.04-armhf'
[08:11] <xnox> pitti: i gathered we want to keep changes we did, e.g. to udev-finish.
[08:11] <brendand> should i just delete that?
[08:11] <xnox> brendand: yeah.
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
[08:40] <brendand> xnox, so i still get the same error with trusty
[08:43] <xnox> brendand: can paste all messages it prints?
[08:43] <xnox> brendand: it did say before that overlayfs not supported, which sounds like either the kernel is borked or non-ubuntu kernel is used.
[08:43] <brendand> xnox, http://paste.ubuntu.com/7571612/
[08:44] <brendand> xnox, it's an rc kernel
=== morbid_florist is now known as lubko
[09:30] <cjwatson> Noskcaj: No, the problem with ntfs-3g is that there's no way to upgrade the relevant bit of configuration.  I'll merge it; please leave it alone.
=== vrruiz_ is now known as rvr
[09:47] <BluesKaj> 'Morning folks
[10:07] <seb128> Noskcaj, can you please test those GNOME components under Unity before filing update requests? Some of those you filed just don't work (like they don't even get decorations)
[10:13] <ev> can someone reject whoopsie 0.2.27 from trusty? I'm a muppet. Should've sent it to utopic
[10:16] <pitti> ev: done
[10:17] <ev> yay, thanks
[10:17] <pitti> ev: (FAOD, you can re-use the version number for utopic)
[10:17] <ev> yup, already done :)
[10:18] <pitti> ev: did that build for you? the buildds say otherwise (syntax error)
[10:18] <ev> yeah, looking into it
[10:20] <ev> fixed
[10:22] <pitti> hm, what is wrong with libsmbclient? seems uninstallable in -proposed
[10:23] <seb128> pitti, https://launchpad.net/ubuntu/+source/samba/2:4.1.6+dfsg-1ubuntu4
[10:23] <seb128> pitti, that ftbfs as well
[10:23] <pitti> Laney, Riddell: ^ that's causing the dbus-test-runner / ubiquity failures, in case you wonder
[10:23] <pitti> seb128: yes, but that shouldn't affect installability?
[10:24] <seb128> indeed not
[10:24] <pitti> oh
[10:24] <pitti>  samba-libs : Depends: libldb1 (< 1:1.1.17~) but 1:1.1.17-1 is to be installed
[10:24] <pitti> so it indeed seems to need a rebuild, and that "missing krb5.h" bug prevents that
[10:25] <pitti> Debian has:
[10:25] <pitti> * Add build-dep on libkrb5-dev, no longer pulled in by libcups2-dev.
[10:26] <pitti> * Build-depend on heimdal-dev instead of libkrb5-dev.
[10:26] <pitti> but our package already b-deps on heimdal-multidev
[10:27] <xnox> brendand: i see what you mean now. it appears that utopic kernel might be causing above issues.
[10:28] <brendand> xnox, i have 3.13
[10:30] <pitti> slangasek, zul: does either of you plan to merge samba?
[10:30] <pitti> slangasek, zul: current version is FTBFS and uninstallable
=== pete-woods is now known as pete-woods-away
[11:10] <Laney> bdmurray: will you be at DMB today?
[11:21] <Laney> ev: Looks like the source package wasn't clean
[11:21]  * Laney goes away
[11:24] <mapreri> pitti: isn't running autopkgtest in pbuilder as easy as https://gitlab.com/mapreri/settings/blob/master/pbuilder/hooks/B10autopkgtests ? (The only "issue" I saw so far is that in this way you run the tests always as root) (wrt #750137 you reply 50 minutes ago)
[11:25] <zul> pitti:  yeah i can do it
[11:26] <pitti> mapreri: yes indeed, it shuold be easy; that script looks good (some refinements perhaps, like for the grep, but that's the general idea)
[11:26] <pitti> zul: great, thanks
=== zumbi_ is now known as zumbi
[11:28] <mapreri> pitti: what's up with the grep? do you think would be far better checking for '^XS-Testsuite: autopkgtest$' ?
[11:29] <pitti> mapreri: something like grep -q 'Testsuite.*autopkgtest' debian/control
[11:30] <pitti> mapreri: i. e. -q to avoid printing the result (but nitpicks)
[11:30] <pitti> mapreri: I suppose an sbuild hook would look fairly similarly, I'm just not sure how to enable/disable it per run
[11:30] <pitti> I wouldn't want *all* pbuilder/sbuild runs to run tests
[11:34] <mapreri> pitti: a way could be asking the user if they want to (echo/read/if/then) but I don't want to be bothered during the build phase :) another way could be changing the x flag of the script but I prefer let pbuilder run some minutes longer than this...
[11:35] <pitti> mapreri: right; I mean if we ship such a hook by default, it needs an on/off switch; for personal hooks that's fine of course
[11:41] <ScottK> With pbuilder hooks they get used or not based on what's in --hookdir, so it's easy enough to control.
[11:50] <mapreri> pitti: looks like environment variables reaches hooks, so you can use a variable as a switch.
[12:32] <mdeslaur> xnox: what's the status of the gnutls migration? are we planning on demoting gnutls26 before u releases?
[12:41] <cjwatson> xnox: Are you likely to be able to fix libavg for libav 10 soon?
[12:42] <mlankhorst> cjwatson: hm you seem to be famous ;-) with your name on the airplane evacuation news article
[12:43] <cjwatson> Yeah, I noticed :)
[12:43] <cjwatson> 15 minutes of fame and all that
=== _salem is now known as salem_
[12:50] <pitti> where do we put our source/binary click apps for download? I'm interested in looking at a few while I read the click docs, to see how to autopkgtestify them
=== tedg is now known as ted
=== ted is now known as tedg
[13:00] <pitti> cjwatson: ^ do you know?
=== tedg is now known as ted
[13:08] <beuno> pitti, I don't think there's a good place to download them from the store at the moment. They get built from source by an uploader and pushed directly to the store.
=== ted is now known as tedg
[13:08] <beuno> downloads are authenticated, so until we release the web ui for the store, there's no good place to download random click apps
[13:09] <pitti> beuno: ah, but we certainly keep "our" (Canonical's) click apps somewhere in LP/bzr?
[13:09] <beuno> pitti, not the binaries, surely
[13:09] <pitti> beuno: I'm happy with downloading the source, I should be able to build the .click(s) myself
[13:09]  * beuno nods
[13:10] <mdeslaur> pitti: look here, on the right: https://launchpad.net/ubuntu-phone-coreapps/
[13:10] <mdeslaur> pitti: the links are all there
[13:11] <pitti> mdeslaur: perfect! that's what I was looking for, thanks!
[13:11] <mdeslaur> yw
[13:11] <pitti> cjwatson: unping
[13:11] <pitti> beuno: thanks
[13:16] <cjwatson> pitti: ok :)
[13:27] <mardy> cjwatson: hi! Can one have multiple versions of the same click app installed at the same time?
[13:27] <cjwatson> mardy: yes, although you should only expect one to be active and older ones may be GCed
[13:27] <cjwatson> mardy: (for any given user, that is)
[13:27] <pitti> so I'm still a bit puzzled by this: https://click.readthedocs.org doesn't talk about how to build packages, and man click only briefly explains "click build"
[13:27] <cjwatson> mardy: so I guess "sort of" is a better answer
[13:27] <mardy> cjwatson: how do I find which is the active one?
[13:28] <cjwatson> mardy: clicklist
[13:28] <cjwatson> er click list
[13:28] <cjwatson> pitti: click build is the only entry point provided by click itself; there's intentionally no source package format
[13:28] <pitti> I tried it on lp:ubuntu-calculator-app; "click build ubuntu-calculator-app/" complains about a missing manifest.json, and indeed there's only a click/manifest.json.in
[13:28] <cjwatson> pitti: so building is project-specific
[13:28] <pitti> so I suppose there is some pre-build magic to be run somehow
[13:29] <cjwatson> probably cmake for most of the core apps
[13:29] <pitti> aah; so perhaps I should try dpkg-buildpackage first (which will invoke cmake etc. in the right way, then click build
[13:30] <mardy> cjwatson: just to give a bit of background: Online Accounts requires apps to ship an .application file; the hoot pattern copies them in ${home}/.local/share/online-accounts-hooks/${id}.application, and then we have an "Exec" line to process these files and copy them (with slight modifications) into ~/.local/share/accounts/applications/
[13:30] <mardy> s/hoot/hook/ :-)
[13:30] <cjwatson> you only get one version of any given package as far as hooks are concerned
[13:31] <cjwatson> that's very much intentional
[13:31] <cjwatson> well, user-level hooks anyway, which yours is
[13:31] <pitti> hm, no, that got me .debs, but didn't build click/manifest.json
[13:31] <cjwatson> system-level hooks can have multiple versions since we expect multiple users to possibly be at different versions
[13:32] <mardy> cjwatson: yes. Cool, so it means that click removes the uninstalled/inactive files from ${home}/.local/share/online-accounts-hooks/${id}.application?
[13:32] <cjwatson> right
[13:32] <cjwatson> the hook will only see whatever is appropriate/current
[13:32] <cjwatson> including (nowadays) not seeing any packages that don't have their framework dependencies satisfied
[13:32] <mardy> cjwatson: excellent!
[13:33] <cjwatson> hooks should just make sure to sync up completely with the current state of the symlink farm each time they're run
[13:34] <cjwatson> a good general approach for that seems to be to make their generated files have timestamps matching those of the symlink given them by click, and then regenerate on any symlink mismatch
[13:34] <cjwatson> on any timestamp mismatch, I mean
[13:35] <cjwatson> and of course handle additions/removals
[13:35] <pitti> dpm: hey David! I'm trying to build a click package from an ubuntu app, like lp:ubuntu-calculator-app; how do I get click/manifest.json generated, so that I can run "click build"?
[13:35] <ogra_> pitti, is there any known issue with dbus-test-runner atm ? https://launchpadlibrarian.net/176785648/buildlog_ubuntu-utopic-i386.unity8_7.87%2B14.10.20140530.1-0ubuntu2_FAILEDTOBUILD.txt.gz i cant get unity8 to build
[13:37] <pitti> ogra_: yes, same for ubiquity; libsmbclient is uninstallable (and FTBFS)
[13:37] <pitti> ogra_: I asked earlier about merging, zul said he'll do it
[13:37] <dpm> hi pitti, I generally use Qt Creator to build them, but you can also use click-buddy to create the .click for calculator
[13:38] <ogra_> pitti, ugh ... that upload was an emergency fix ... pretty urgent to get it somehow through to make landing possible again for touch ... do you know a way around ?
[13:38] <pitti> ogra_: I suppose the release team can ignore the test
[13:38] <cjwatson> temporarily disable proposed in the archive dependencies for the relevant silo ppa?
[13:38] <cjwatson> we can't ignore a build failure :)
[13:38] <pitti> or that
[13:38] <ogra_> pitti, FTBFS :)
[13:38] <dpm> pitti, calculator is arch-independent, so 'click-buddy --dir $PATH_TO_CALC_SRC' should do
[13:38] <cjwatson> I'm assuming this is only broken in -proposed
[13:38] <pitti> dbus-test-runner itself (probably) builds, it's samba which is FTBFS and uninstallable
[13:39] <pitti> cjwatson: samba is only uninstallable in -proposed, yes (ldb sync), but FTBFS in utopic release
[13:39] <ogra_> cjwatson, emergency fix ... silos are broken as well :) ... this was a direct upload
[13:39] <ogra_> its "murphys monday" today :)
[13:39] <ogra_> what can fail fails
[13:39] <cjwatson> oh, err, well you can't tell the archive to not build -proposed against -proposed
[13:39] <pitti> ogra_: err .. there is no dbus-test-runner in -proposed
[13:40] <pitti> oh, in the silo, sorry
[13:40] <ogra_> there are no silos atm
[13:40] <ogra_> jenkins had issues ...
[13:40] <ogra_> not sure how far the infra is fixed yet
[13:40] <cjwatson> could upload a new version to a suitably configured PPA and copy back, but it might actually be easier and less risky to fix libsmbclient
[13:41] <pitti> dpm: ah, I'd really like to stick to CLI tools; for doing something like "build this bzr branch into a click and run its tests" we can't use interactive tools :)
[13:41] <pitti> dpm: where can I find click buddy?
[13:41] <seb128> hum
[13:41] <seb128> ubuntu-desktop-next daily build failed with
[13:41] <seb128> "Using ISOLINUX boot-disks image on CD1
[13:41] <seb128> W: Unable to read /srv/cdimage.ubuntu.com/scratch/ubuntu-desktop-next/utopic/daily-live/apt/utopic-i386/apt/preferences.d/ - DirectoryExists (2: No such file or directory)
[13:41] <seb128> cp: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu-desktop-next/utopic/daily-live/tmp/utopic-i386/CD1/../syslinux/usr/lib/syslinux/isolinux.bin': No such file or directory"
[13:42] <seb128> does anyone know what's the issue/where to look?
[13:42] <pitti> samba> it seems our pacakge uses heimdal-multidev while Debian's uses heimdal-dev; TBH I have no idea about the details about that, hence I pinged slangasek first instead of uploading a quickfix I don't fully understand
[13:42] <dpm> pitti, it's in the phablet-tools package in universe
[13:43] <pitti> dpm: ah, how odd :)
[13:44] <pitti> dpm: splendid, thanks!
[13:45] <dpm> pitti, cool, let me know if I can help with anything else. For other core apps such as reminders, file manager and terminal, you'll just need to specify the arch parameter, as they contain C++ QML plugins that are shipped with the .clicks
[13:46] <zul> pitti:  im not sure about it either..so if you want to upload a quick fix that would be fine for me and ill merge samba when i get a chance (im on a cricitical path here for a project)
[13:46] <cjwatson> seb128: oh, that'll probably be syslinux 6, will sort it out
[13:46] <seb128> cjwatson, thanks
[13:46] <cjwatson> surprised I don't have lots of mail about that
[13:47] <seb128> cjwatson, there is no iso since thursday but I didn't get build failure emails either...
[13:48] <pitti> dpm: so in general: apt-get install phablet-tools, bzr branch lp:whatever, apt-get install <build dependencies of that branch>, click-buddy --dir checkout-dir/ ?
[13:50] <dpm> pitti, essentially, yes, with a couple of caveats:
[13:50] <dpm> - You'll probably want to specify the --framework parameter, as the click-buddy help says that the default is still ubuntu-sdk-13-10
[13:51] <pitti> dpm: oh, why doesn't it read that from click/manifest.json.in? That says "framework": "ubuntu-sdk-14.04-qml-dev1",
[13:51] <dpm> - For file manager, terminal, reminders, you'll need to specify --arch
[13:51] <dpm> pitti, ah, good point, it probably does
[13:51] <dpm> so the help from click-buddy probably needs to clarify that
[13:52] <pitti> dpm: an automated test system could probably use --arch $(dpkg --print-architecture) to test on the native arch?
[13:52] <pitti> WARNING:root:Ignoring missing framework "ubuntu-sdk-14.04-qml-dev1"
[13:52] <pitti> dpm: oh, I got that from click-buddy output after package build
[13:52] <pitti> dpm: which at least confirms that it's trying to use the 14.04 one from the manifest.in :)
[13:53] <pitti> the warning updates when I change the .in file
[13:53] <dpm> ok, cool. Strange that that framework is missing. lool, any ideas? ^
[13:53] <pitti> dpm: well, I'm not currently using a click chroot; I figure I ought to
[13:53] <cjwatson> dpm,lool,pitti: it's a cosmetic click bug that it issues that warning on build
[13:53] <smoser> anyone seen this: http://paste.ubuntu.com/7573205/
[13:53] <cjwatson> you aren't required to have the framework present at build time
[13:53] <pitti> cjwatson: ah, thanks
[13:54] <dpm> ok, thanks cjwatson
[13:54] <pitti> dpm: ok, I think I know enough for now; thanks for your help!
[13:55] <dpm> ok, cool!
[13:55] <smoser> pitti, you touched sysvinit since i last upgraded, have you seen that failure above?
[13:56] <cjwatson> pitti,dpm: you need to pass -f to click-buddy if the package contains native code; IMO it's a bug that it doesn't pick that up from the package
[13:56] <cjwatson> it's indeed not required for architecture-independent packages
[13:57] <pitti> smoser: not that particular one, although it looks fairly similar to the fix from https://launchpad.net/ubuntu/+source/systemd/204-10ubuntu7; which udev version do you have?
[13:57] <smoser> 204-10ubuntu8
[13:57] <pitti> that seems fine
[13:58] <cjwatson> seb128: should be fixed now, and at least worked for Ubuntu; I've triggered a -desktop-next rebuild
[14:00] <pitti> smoser: can you pastebin the output of "sudo /usr/lib/insserv/insserv -vn"?
[14:01] <pitti> smoser: -vns even
[14:01] <smoser> http://paste.ubuntu.com/7573248/
[14:01] <pitti> smoser: uh, no error there?
[14:01] <seb128> cjwatson, thanks!
[14:01] <smoser> note the udev version is the new udev version. as upgrade failed. (iU state)
[14:02] <pitti> smoser: ah, so you still have the previous udev init.d file installed?
[14:02] <smoser> pitti, that returns zero
=== salem_ is now known as _salem
[14:02] <smoser> pitti, well.. http://paste.ubuntu.com/7573255/
[14:03] <pitti> smoser: so you might still be in that "my system fails" trap situation from last week :/ we had to apt-get download libudev1 udev and sudo dpkg -i those manually
=== _salem is now known as salem_
[14:03] <pitti> i. e. if you upgraded when we had a broken udev init.d script and switched to startpar (doesn't affect trusty -> utopic, just utopic last week -> utopic today)
[14:06] <smoser> k. that seems to get me out of it. thanks pitt. will everyone hit that ?
[14:06] <smoser> ah. ok.
[14:06] <pitti> smoser: most people who upgraded every day last week, I'm afraid
[14:06] <pitti> smoser: good, thanks
[14:06] <pitti> smoser: I just did a trusty -> current utopic upgrade in a schroot, and that went fine, FTR
=== salem_ is now known as _salem
[14:09] <smoser> pitti, thanks.
=== _salem is now known as salem_
=== oSoMoN_ is now known as oSoMoN
[14:18] <seb128> ev, whoopsie build seems still unhappy, I guess you noticed?
[14:19] <ev> yeah, trying to deal with it in the background
[14:19] <ev> I'll start throwing it at a PPA to reduce the noise
[14:19] <seb128> k
[14:20] <seb128> ev, seems like you are shipping some amd64 .so in the tarball,
[14:20] <seb128> ev, src/test/test_logging.test.o
[14:20] <ev> hm
[14:21] <seb128> .so -> .o
[14:21] <ev> yeah, so I am
[14:21] <ev> fixing
[14:21] <seb128> great
[14:22] <seb128> Riddell, apachelogger: is it normal that non kubuntu systems have pam errors about pam_kwallet.so?
[14:23] <Riddell> mm, I'm not sure, I don't run a non-kubuntu system :)
[14:23] <seb128> like "PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory"
[14:23] <Riddell> seb128: where's that?
=== andreas__ is now known as ahasenack
[14:24] <seb128> Riddell, in /var/log/auth.log on utopic isos (tested ubuntu-desktop-next and now xubuntu which has the same one)
[14:25] <seb128> well, I first noticed because ubuntu-desktop-next fails to log in
=== salem_ is now known as _salem
[14:26] <Riddell> seb128: is it listed in /etc/pam.d/lightdm ?
[14:27] <apachelogger> seb128: as normal as it is for pam_gnome_keyring.so anyway  ;)
[14:27] <seb128> apachelogger, that throws warnings as well?
[14:27] <seb128> Riddell, yes, but not installed
[14:27] <apachelogger> when it's not installed, sure
[14:27] <seb128> hum, k
=== _salem is now known as salem_
[14:27] <seb128> apachelogger, "sure" like it was obvious
[14:28] <seb128> if those are optional they could do nicer warnings (or none)
[14:28] <apachelogger> yeah, not sure why pam insist on warning about missing optionals
[14:28] <apachelogger> then again, I guess the warning would help with debugging why a pam modules is not working
[14:31] <seb128> Riddell, apachelogger: the issue is probably something else then, thanks for the reply, I keep debugging
[14:40] <cjwatson> zul,pitti: I'm attempting a local quick fix for samba
[14:40] <zul> cjwatson: ack
=== salem_ is now known as _salem
[14:43] <cjwatson> slangasek: ^-
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:05] <alexbligh1> If I have package A and package B, then modify package A to package A' so that it does the work of Package B (and B should no longer be installed when I upgrade A), then I think I should mark A as Provides: B, and Conflicts: B, right? Do I also need Replaces: B? IE all 3?
[15:05] <cjwatson> that sounds like a good case for all three
[15:06] <cjwatson> Conflicts+Replaces => "that other package should go away"
[15:06] <cjwatson> Provides is gold-plating so that dependencies on package B still work; not always necessary
[15:07] <alexbligh1> cjwatson, thanks
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:24] <seb128> cjwatson, ubuntu-desktop-next built, but it boots on an empty screen with a grey square in the bottom left corner instead of the list of languages
[15:24] <rbasak> alexbligh1: https://wiki.debian.org/PackageTransition is a handy reference
[15:25]  * seb128 downloads ubuntu daily to see if that has the same issue
[15:25] <rbasak> (for the future)
[15:25] <alexbligh1> rbasak, handy, thx
[15:27] <alexbligh1> rbasak, that says "Breaks/Replaces/Provides" for my scenario, not "Conflicts/Replaces/Provides", but I think I need "Conflicts/Replaces/Provides" if A and B have the same file in.
[15:31] <rbasak> alexbligh1: I think Breaks would suffice, rather than Conflicts, in that case.
=== pete-woods-away is now known as pete-woods
[15:33] <alexbligh1> rbasak, it's a bit confusing. I was going from https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts 7.4, "in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages) or that must prevent both packages from being unpacked at the same time, not just configured."
[15:33] <rbasak> alexbligh1: Debian policy 7.4: Normally, Breaks should be used instead of Conflicts since Conflicts imposes a stronger restriction on the ordering of package installation or upgrade and can make it more difficult for the package manager to find a correct solution to an upgrade or installation problem. Breaks should be used ...when moving a file from one package to another
[15:34] <alexbligh1> rbasak, well at least we are reading the same text then!
[15:35] <alexbligh1> I don't want them both unpacked at once (indeed I think having a file moved from B to A is sufficient reason for that)
[15:35] <alexbligh1> though the DPM doesn't agree with me on that it seems. For reasons I don't quite understand.
[15:38] <pitti> dpm: where does click buddy build the source? I see no built files in the original tree, so I still can't see a generated manifest.json
[15:40] <dpm> pitti, it runs cmake and IIRC it builds the files outside of the source tree. You can use the --no-clean argument to see the results of the build. It will point you to a directory in /tmp where it does the build IIRC
[15:41] <pitti> dpm: ah, thanks
[15:43] <pitti> dpm: do you see click-buddy as something which we can/should use in production testing, or does it change its behaviour often? (for once, it has a gazillion dependencies which are unnecessary for click-buddy and only needed for adb/phone bits)
[15:44] <pitti> this seems to me like the kind of tool which should be in "click" itself (perhaps with a more formal name) or in a separate package, it is very unrelated to the other bits in phablet-tools
[15:46] <pitti> ah, so this really just uses "cmake", "make install", and "click build"
[15:46] <pitti> I suppose that's easier to call directly than relying on click-buddy and parsing its output
[15:46] <dpm> pitti, I think probably cjwatson and sergiusens can probably better answer the question. I generally don't use it, as I tend to dogfood the graphical tools to make sure I use the same tools as app devs, but click-buddy is quite convenient when I need to use it and provision click apps to the phone quickly. However, it is indeed another layer on top of the click tools, so I agree that either having its functionality in click or using click for production
[15:46] <dpm>  testing might make more sense
[15:55] <xnox> cjwatson: libavg fix for libav 10 -> no, not soon. Best to demote to -proposed (similar to how it is/was removed from testing in debian)
[15:55] <xnox> mdeslaur: it's moving slowing, i'm pushing for it on debian side though. Will be done before utopic FF.
[15:55] <xnox> mdeslaur: if not completed, demoted to universe the least.
[15:56] <xnox> pitti: "cmake -DCLICK_MODE=on; make" is the typical way to build ubuntu core-apps into a click
[15:57] <pitti> xnox: right, I used something like that now (with extra -DINSTALL_TESTS=off -DBZR_REVNO=...)
[15:57] <pitti> all working now
[15:57] <pitti> with just click, ubuntu-sdk-libs, and the build deps
[15:57] <xnox> pitti: yeap, looks about right way to do it.
[15:58] <pitti> hah, and there I can run ubuntu-calculator-app with qmlscene from my install --root /tmp/c com.ubuntu.calculator_1.3.12_all.click
[15:59] <pitti> so I think I have all the building blocks now
[16:01] <cjwatson> seb128: right, will try to get a chance to look soon ...
[16:02] <pitti> cjwatson: ah, thanks for the samba fix; it sounded like heimdal-dev and heimdal-multidev would be alternatives, not being used together
[16:02] <pitti> (and meh @ i386 FTBFS)
[16:02] <pitti> anyway, gotta run, time for Taekwondo; good evening everyone!
[16:03] <seb128> cjwatson, thanks! (the iso boots, so the menu not showing is not blocking testing from our side, so no worry if it takes some days to resolve it)
[16:03] <seb128> pitti, enjoy!
[16:03] <cjwatson> pitti: mm, I saw that locally but had hoped it was cosmic rays :-/
[16:04] <cjwatson> just on 32-bit little-endian architectures, apparently; wonder if that's relevant
[16:04] <mdeslaur> xnox: cool, thanks
[16:38] <slangasek> xnox, pitti: right; I'm ok with the general thrust of that MP, but didn't mark it as an approval because of the unneccessary race on shutdown
[16:38] <slangasek> pitti: samba> no plans to merge that, no
[16:40] <xnox> slangasek: i'm trying to think of a case of a hanging/long-running task with no "stop on" which would cause a startpar hang on shutdown, but can't think of any, as all upstart task should well be task that complete.
[16:40] <xnox> *tasks
[16:52] <slangasek> xnox: it could be a task that runs only on shutdown?
[17:20] <infinity> cjwatson: Oh.  Haven't dug yet, but that xsltproc sigbus could be faketime, not xsltproc.
[17:20] <mhall119> hello everyone, I would like to get somebody to provide a session on how to get a new package into Ubuntu's archives, both directly and via Debian, we've had a request for that on Google+
[17:20] <infinity> cjwatson: debian/bin/xsltproc is a wrapper that wraps the real xsltproc in faketime.
[17:22] <infinity> Though, maybe not.
=== _salem is now known as salem_
=== timrc is now known as timrc-afk
=== lubko is now known as posessed
=== timrc-afk is now known as timrc
=== tedg is now known as ted
[18:46] <mhall119> slangasek: mdeslaur: please register for uos-1406 in summit so I can add you as track leads
[18:46] <mhall119> http://summit.ubuntu.com/uos-1406/registration/
[18:47] <mdeslaur> mhall119: done
[18:47] <slangasek> mhall119: done
[18:47] <mhall119> thanks guys
[19:27] <cjwatson> infinity: I checked in strace and the sigbus is from xsltproc proper
=== ted is now known as tedg
=== salem_ is now known as _salem
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc