[00:01] <menace> hi, i packaged a firefox-addon, but  i cannot add it to reprepro because of the Error: 'unmht_7.3.0.1-0ubuntu1.debian.tar.gz' has the wrong architecture to add it to trusty! any idea, what's wrong with my package? (package is here located is http://yac1912x.gbks.net/misc/)
[00:03] <menace> lintian does not really give me hints...
[00:04] <xnox> menace: debian.tar.gz is not a package, but one component of a debian source package....
[00:04] <xnox> menace: do you have "source" architecture enabled in the config?
[00:05] <xnox> menace: no probably want to add a .dsc or .debs or .changes (that reference a set of .dsc/.debian.tar.gz/.debs) into reprepro
[00:06] <slangasek> brainwash: hi, so you asked me about the xfce4 meta package... that seems like a reasonable change to me, but I'm not sure why you asked me in particular :)
[00:06] <menace> xnox: what does source architecture mean?
[00:07] <menace> i did try to add the changes file and so the dsc and deb file with that changes file
[00:08] <xnox> menace: .dsc is a debian source package - which is just metadata pointing to upstream tarball + debian packaging tarballs, those can be compiled (e.g. with dpkg-buildpackage) to create .debs. debs can be different architectures e.g. _all.deb / _i386.deb / _amd64.deb
[00:08] <menace> my distributions file seems normal: http://yac1912x.gbks.net/misc/distributions
[00:09] <menace> xnox: yes, im aware of that. but the debian.tar.gz file is part of the source files afaik?
[00:09] <xnox> menace: in practice repositories can publish one or more things typically refered to as source / all / i386 / amd64 etc. architectures.
[00:09] <xnox> menace: yes and no. by itself it's meaningless. only .dsc & .deb have meaning.
[00:10] <xnox> menace: one cannot publish a single ".debian.tar.gz" or attempt to do so.
[00:10] <xnox> menace: the distributions file is odd - it is allowed to only publish _amd64.deb and no other type of files.
[00:11] <xnox> and _all.deb (as that's implied)
[00:13] <xnox> menace: you should change that to Architectures: amd64 source, if you wish to publishes sources (one may have to do that depending on the license of software you are publishing)
[00:16] <menace> ah
[00:16] <menace> hm
[00:17] <menace> it works with amd64 source
[00:18] <menace> hrm
[00:19] <menace> thanks! :-)
[04:30] <Bobby___> Hello all. I am trying to get sound playback working on an Intel Bay Trail tablet. I do not get a sound device with any firmware except for with 5339.B in the Intel ChromiumOS repo. With this firmware I only get static or no sound at all though. I have played with all the alsamixer settings and tried the ASUS t100 state file that is commonly used still with no sound.  What can I do to fix this?
[04:31] <developerpenguin> he guys
[04:32] <developerpenguin> can someone please help me ? :)
[04:41] <Noskcaj> jtaylor, Could you please check if we can sync statsmodels now? debian has had a number of test fixes
[05:09] <pitti> Good morning
[05:09] <Unit193> Herro.
[05:34] <jtaylor> Noskcaj: probably not but I was planning on just syncing it and see
[08:10] <dholbach> good morning
[08:34] <LocutusOfBorg1> hi dholbach !
[08:34] <dholbach> hi LocutusOfBorg1
[08:56] <tjaalton> huh, cron is not running the jobs in /etc/cron.d/ on vivid?
[09:06] <pitti> stgraber: is there a trick to get sudo to work in a per-user container?
[10:05] <tseliot> pitti: hey, does your systemd service for gpu-manager also start when the display manager is shut down?
[10:06] <pitti> tseliot: you mean "does not start at all", or "gets shut down'?
[10:06] <pitti> tseliot: if it doesn't start at all, neither will gpu-manager
[10:06] <pitti> tseliot: the upstart script didn't do that, and it seems rather pointless to do that, no?
[10:07] <tseliot> pitti: the old upstart job would also launch gpu-manager on shutdown
[10:07] <pitti> tseliot: oh, how so?
[10:07] <pitti> it just has "start on starting lightdm or ..."
[10:07] <tseliot> pitti: or maybe lightdm took care of that, let me check
[10:08] <pitti> not that I can see
[10:08] <pitti> tseliot: i. e. it shoudl exactly mirror the upstart job right now
[10:08] <tseliot> pitti: ok, then it's a non issue, sorry for the noise
[10:09] <pitti> tseliot: no worries at all, thanks for double-checking!
[10:09] <tseliot> pitti: BTW are we going to have systemd by default in 15.04?
[10:10] <pitti> tseliot: that's the idea anyway; it now depends on how fast we can do the migration, and how fast the server team can migrate their upstart-only packages
[10:10] <pitti> tseliot: the idea was to have a virtual mini-sprint in January to convert the remaining bits
[10:10] <tseliot> pitti: ok, so for now I'll have to install it manually in Vivid
[10:10] <pitti> http://people.canonical.com/~jhunt/systemd/packages-to-convert/
[10:11] <pitti> tseliot: yes, either boot with init=/bin/systemd (no package changes) for an one-time test, or instlal systemd-sysv to boot with it by default
[10:11] <pitti> tseliot: in the latter case, init=/sbin/upstart will boot with upstart again
[10:11] <pitti> jodh: btw, it seems http://people.canonical.com/~jhunt/systemd/packages-to-convert/ doesn't update
[10:11] <pitti> jodh: I added systemd units to ubuntu-drivers-common two days ago; pollinate did disappear now (also from two days ago)
[10:12] <tseliot> pitti: do you mean init=... as a boot parameter?
[10:12] <pitti> tseliot: yes, in the kernel line in grub
[10:12] <Unit193> Or in /etc/default/grub if you're too lazy to install -sysv.
[10:13] <tseliot> pitti: I can see that nvidia-prime needs porting too
[10:13] <tseliot> yes, I know how to customise grub ;)
[10:14] <jodh> pitti: hmm, really? It's reading from the internal archive and the script auto-updates from bzr?
[10:14] <pitti> /lib/systemd/system/gpu-manager.service
[10:14] <pitti> /etc/init/gpu-manager.conf
[10:14] <pitti> jodh: that should match, no?
[10:16] <jodh> pitti: should do.
[10:17] <pitti> jodh: ok, let's check tomorrow then; yesterday pollinate was still in, so maybe something is just lagging
[10:34] <jodh> pitti: cron is now running hourly - I just re-ran manually so hopefully it now reflects your expectation.
[10:39] <pitti> jodh: oh, daily is certainly more than enough; I suppose it's not exactly cheap
[10:40] <pitti> jodh: vivid main package admin/ubuntu-drivers-common requires systemd migration (sysv=False, upstart=True, systemd=False)
[10:40] <pitti> jodh: hm, no, this should be systemd=True, and thus disappear entirely
[10:40] <pitti> jodh: unless there is some problem with having upstart+systemd but not sysvinit?
[10:41] <pitti> jodh: this only checks per-package, right? e. g. systemd is shipping /lib/systemd/system/hostname.service to shadow the one from the "hostname" package
[10:51] <cjwatson> xnox: syncio> if you want; my care levels about wubi are pretty low now :)
[10:54] <pitti> xnox: oh nice, that's our only remaining patch -- so we can sync again?
[10:55] <pitti> xnox: I did a (local) merge two days ago to test somethign (was fairly trivial, so not much work lost really), but didn't talk to you yet
[10:57] <jodh> pitti: can't debug right now I'm afraid. Here's the code: lp:~ubuntu-foundations-team/+junk/migration-to-systemd. You can run the shell script directly on people.c.c.
[10:57] <pitti> jodh: ah, thanks
[11:00] <brainwash> slangasek: I've asked you, because you are subscribed to the linked bug report :)
[11:01] <brainwash> slangasek: and my last comment in the report did not get any response so far
[11:01] <brainwash> bug 1080865
[14:05] <pitti> GunnarHj: should I build utopic langpacks now? or are there still some -docs to land?
[14:06] <GunnarHj> pitti: No, ubuntu-docs was built (in utopic-proposed) a few days ago. All set.
[14:06] <pitti> GunnarHj: ah right, https://launchpad.net/ubuntu/+source/ubuntu-docs/14.10.5; so off we go!
[14:07] <pitti> GunnarHj: .. or not -- we didn't get an export yet :( https://translations.launchpad.net/ubuntu/utopic/+language-packs
[14:08] <pitti> wgrant: ^ is something stuck, or just taking longer?
[14:08] <pitti> probably taking longer because of the full export
[14:09] <pitti> GunnarHj: ok, I'll try and build them on Monday then, but I won't have much time for testing
[14:15] <GunnarHj> pitti: Ok.. I don't know how all that works. Thought the build was what's needed.
[14:24] <pitti> GunnarHj: yes, but we should also have an up to date translation export
[14:25] <GunnarHj> pitti: I'm slowly understanding the nature of the problem. ;)
[14:26] <GunnarHj> pitti: It's LP which is slow, right?
[14:26] <pitti> GunnarHj: a full export just takes quite a bit longer, yes
[14:28] <cjwatson> It *looks* like it's still running (in that the log doesn't end in a crash of some kind), but it does seem to be taking unusually long
[14:29] <cjwatson> Normally seems to take in the general vicinity of an hour, and it's been running for nearly four now
[14:29] <shadeslayer> didrocks: can you retry bluedevil?
[14:30] <shadeslayer> didrocks: in the transitions PPA
[14:33] <didrocks> shadeslayer: sure, doing
[14:34] <shadeslayer> though I messed up and the build dep version should have be bumped
[14:35] <didrocks> shadeslayer: well, now we should have a publication cycle (so for next update ;))
[14:55]  * cjwatson wonders if it counts as patch piloting when he just spent five hours cleaning up after inscrutable test failures caused by a sponsorship request
[15:04] <stgraber> pitti: hmm, no, it should just work. Unless somebody regressed something recently.
[15:09] <pitti> sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
[15:09] <pitti> stgraber: that's what I get; it might of course be an artifact of running under systemd
[15:10] <pitti> stgraber: err *blush* sorry, my /home/.ecryptfs/martin/.Private is indeed nosuid
[15:12] <stgraber> pitti: right, ecryptfs does that :)
[15:12] <pitti> stgraber: yeah, quite plausible to have /home on nosuid, I figure
[15:13] <pitti> so, sorry for the noise
[15:19] <GunnarHj> pitti: Looks like it's there now. https://translations.launchpad.net/ubuntu/utopic/+language-packs
[15:19] <pitti> GunnarHj: ah, good!
[15:20] <cjwatson> Oh yes, it just took 4h39m for some reason.
[15:26] <sladen> `.
[15:29] <shadeslayer> question, what would be the value of uppderdir will be when using overlayfs such that any changes that are made are discarded
[15:59] <bdmurray> mvo_: Could you have a look at bug 1399455?
[16:06] <pitti> GunnarHj: I started the build, but that'll take a while, I can't test them today any more; I'll see to test/upload them on Monday then
[16:07] <GunnarHj> pitti: Ok, thanks for letting me know. Have a nice weekend!
[16:39] <slangasek> brainwash: I am?  I have no idea why I'm subscribed to such a bug report ;)  (bug #?)
[17:05] <tjaalton> is it possible to get sbuild work with a non-local (ldap) user? looks like it needs the user in the chroot passwd/group
[17:07] <brainwash> slangasek: bug 1080865
[17:17] <slangasek> brainwash: oh, indeed - yeah, that proposed solution seems fine, I was only involved in triaging that bug out of grub :-)
[17:21] <brainwash> slangasek: can you apply the solution? if no, I'm not sure who I could bother with this
[17:39] <slangasek> brainwash: it seems to me this should be done by the xubuntu devs?
[17:41] <brainwash> slangasek: maybe. the package is not actually part of xubuntu
[17:41] <brainwash> slangasek: it's just there to install the normal Xfce desktop environment, synced directly from debian
[17:43] <brainwash> slangasek: easiest solution would be to ignore the debian-ization caused by desktop-base and don't add a ubuntu delta -> won't fix
[17:45] <brainwash> it's only a recommended package after all, but it is pulled in by default unless you add --no-install-recommends
[18:06] <mark999> so what happens if I accidentally upload a package to upload.ubuntu.com? will it just get deleted if the package isn't signed?
[18:07] <infinity> brainwash: If xfce4 isn't pulled in by xubuntu (and it doesn't seem to be), I'd say it's a WontFix.  Rebranding every package we sync from Debian in case someone might install it and complain is probably a waste of time.
[18:07] <mark999> dput uploaded a package to my private repo... and then decided to also ftp it to upload.ubuntu.com
[18:07] <infinity> mark999: If it's unsigned, it just goes to /dev/null, yes.
[18:07] <mark999> whew!
[18:08] <mark999> its contents were somewhat sensitive, so I'm glad
[18:08] <mark999> should the default dput config upload to ubuntu? I was expecting it to do nothing by default, and didn't look at /etc/dput.cf
[18:08] <infinity> mark999: Is it a graphical frontend to your diary from puberty?  Cause man, I wouldn't want that out there.
[18:09] <mark999> shhhhhh
[18:09] <infinity> mark999: Default in Debian is to ftp-master and default in Ubuntu is to ubuntu, yes.  Feel free to remove the default (many do) to avoid shooting yourself in any feet, though.
[18:10] <mark999> I will! should it _really_ be the default, though?
[18:10] <infinity> mark999: I don't think you'll ever get a straight answer on that.
[18:10] <mark999> heh
[18:11] <infinity> mark999: People like me, who upload 99% of our uploads to Ubuntu or Debian tend to appreciate (and assume there should be) a default.
[18:11] <infinity> mark999: In Ubuntu, one could make the argument that dput's used more often for PPAs than for the archive, and maybe we shouldn't have a default.  Dunno.
[18:11] <infinity> mark999: The private repo argument likely doesn't factor at all, as almost no one runs such infrastructure, compared to people uploading to an official archive or ppa.lp.net
[18:11] <mark999> well, if unsigned stuff gets deleted by default, no harm done.
[18:12] <mark999> ah yea
[18:12] <mark999> my company is doing something similar to google's goobuntu
[18:12] <infinity> mark999: Well, unsigned stuff gets rejected (obviously), but no reject mail is sent, cause we don't have a way to validate who it came from.  So, effectively, it's like it never existed.  This is true for both launchpad and DAK.
[18:12] <mark999> cool
[18:16] <infinity> mark999: It does, however, sit around in a rejected/ directory for a while until a cron job or a human gets around to cleaning it out.  If it's super-sensitive to the point where you don't even want it sitting in a trash bin on a Canonical server, you could ask us nicely to go in and delete it without looking at it. :P
[18:17] <infinity> mark999: Probably not worth the effort, though.  The people with access to that machine is a tiny list, and not the sort that go reading random rejected upload for funsies.
[18:18] <infinity> mark999: (Again, true for an accidental upload to either Ubuntu or Debian... Different lists of people, different liabilities, but same general theory that none of them really care about reading it)
[18:19] <brainwash> infinity: can you please mark the report as won't fix?
[18:21] <mark999> infinity: thanks. not really *that* sensitive
[18:22] <cjwatson> mark999: it can be nuked easily enough if you like, see your /query from me
[18:22] <slangasek> brainwash: ah.  another option then would be to remove the package from Ubuntu altogether, if it's not the right experience on Ubuntu?
[18:24] <brainwash> slangasek: but it's needed to install the normal Xfce desktop environment (not the Xubuntu session)
[18:24] <infinity> slangasek: Ahh, indeed, xfce4 has no rdeps, blacklisting it would work too.
[18:24] <infinity> brainwash: Is this a valuable thing to do?
[18:25] <brainwash> some people prefer the normal Xfce experience, especially those who install ubuntu in the first place and then install Xfce on top of it
[18:25] <brainwash> so they just run "sudo apt-get install xfce4"
[18:26] <brainwash> and this pulls in desktop-base by default
[18:26] <infinity> Well, I commented on and closed the bug, per your request. :P
[18:27] <cjwatson> mark999: requested removal from sysadmin so it should happen soon; I can't wait around for it right now, but consider it done
[18:27] <brainwash> infinity: thanks you :)
[18:27] <infinity> I think if you actually expect Ubuntu users to intentionally install xfce4 (rather than accidentally), you might want to fix this.
[18:27] <brainwash> thank
[18:27] <mark999> I appreciate it!
[18:27] <infinity> But I have no strong opinion on the matter.
[18:29] <brainwash> infinity: the uproar is very small, so I guess that these users manage to remove the desktop-base package manually or prevent the installation in the first place
[18:29] <brainwash> IF they don't like the debianization
[18:29] <infinity> brainwash: Or that most people aren't installing "xfce4" :)
[18:30] <brainwash> we get quite few reports from users which are running ubuntu + xfce4 (not xubuntu)
[18:31] <brainwash> it's the obvious package choice if you've installed ubuntu first and then want to test a different DE like Xfce
[18:32] <brainwash> or "gnome" for the gnome DE
[19:06] <Unit193> Hello.  Is there a chance someone with super cow powers can sync gcalcli from experimental?  API changes fix, old version is unusable.
[19:12] <Noskcaj> Unit193, requestsync ?
[19:58] <Noskcaj> Can someone please check why banshee-community-extensions won't migrate?
[20:01] <infinity> Noskcaj: It makes banshee-extension-lyrics uninstallable.
[20:05] <infinity> Ahh.
[20:05] <infinity> Noskcaj:  banshee : Breaks: banshee-extension-lyrics (< 2.4.0-3~) but 2.4.0-2ubuntu1 is to be installed
[20:05] <infinity> Noskcaj: It needs a merge to the latest Debian version.
[20:36] <Noskcaj> hyperair, Should banshee go back to dbus# 2 now the LTS has been released?