[00:01] 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] lintian does not really give me hints... [00:04] menace: debian.tar.gz is not a package, but one component of a debian source package.... [00:04] menace: do you have "source" architecture enabled in the config? [00:05] 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] 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] xnox: what does source architecture mean? [00:07] i did try to add the changes file and so the dsc and deb file with that changes file [00:08] 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] my distributions file seems normal: http://yac1912x.gbks.net/misc/distributions [00:09] xnox: yes, im aware of that. but the debian.tar.gz file is part of the source files afaik? [00:09] menace: in practice repositories can publish one or more things typically refered to as source / all / i386 / amd64 etc. architectures. [00:09] menace: yes and no. by itself it's meaningless. only .dsc & .deb have meaning. [00:10] menace: one cannot publish a single ".debian.tar.gz" or attempt to do so. [00:10] menace: the distributions file is odd - it is allowed to only publish _amd64.deb and no other type of files. [00:11] and _all.deb (as that's implied) [00:13] 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] ah [00:16] hm [00:17] it works with amd64 source [00:18] hrm [00:19] thanks! :-) === timrc is now known as timrc-afk [04:30] 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] he guys [04:32] can someone please help me ? :) [04:41] jtaylor, Could you please check if we can sync statsmodels now? debian has had a number of test fixes [05:09] Good morning [05:09] Herro. [05:34] Noskcaj: probably not but I was planning on just syncing it and see === mfisch is now known as Guest45087 [08:10] good morning [08:34] hi dholbach ! [08:34] hi LocutusOfBorg1 [08:56] huh, cron is not running the jobs in /etc/cron.d/ on vivid? [09:06] stgraber: is there a trick to get sudo to work in a per-user container? === mfisch is now known as Guest3214 [10:05] pitti: hey, does your systemd service for gpu-manager also start when the display manager is shut down? [10:06] tseliot: you mean "does not start at all", or "gets shut down'? [10:06] tseliot: if it doesn't start at all, neither will gpu-manager [10:06] tseliot: the upstart script didn't do that, and it seems rather pointless to do that, no? [10:07] pitti: the old upstart job would also launch gpu-manager on shutdown [10:07] tseliot: oh, how so? [10:07] it just has "start on starting lightdm or ..." [10:07] pitti: or maybe lightdm took care of that, let me check [10:08] not that I can see [10:08] tseliot: i. e. it shoudl exactly mirror the upstart job right now [10:08] pitti: ok, then it's a non issue, sorry for the noise [10:09] tseliot: no worries at all, thanks for double-checking! [10:09] pitti: BTW are we going to have systemd by default in 15.04? [10:10] 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] tseliot: the idea was to have a virtual mini-sprint in January to convert the remaining bits [10:10] pitti: ok, so for now I'll have to install it manually in Vivid [10:10] http://people.canonical.com/~jhunt/systemd/packages-to-convert/ [10:11] 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] tseliot: in the latter case, init=/sbin/upstart will boot with upstart again [10:11] jodh: btw, it seems http://people.canonical.com/~jhunt/systemd/packages-to-convert/ doesn't update [10:11] jodh: I added systemd units to ubuntu-drivers-common two days ago; pollinate did disappear now (also from two days ago) [10:12] pitti: do you mean init=... as a boot parameter? [10:12] tseliot: yes, in the kernel line in grub [10:12] Or in /etc/default/grub if you're too lazy to install -sysv. [10:13] pitti: I can see that nvidia-prime needs porting too [10:13] yes, I know how to customise grub ;) [10:14] pitti: hmm, really? It's reading from the internal archive and the script auto-updates from bzr? [10:14] /lib/systemd/system/gpu-manager.service [10:14] /etc/init/gpu-manager.conf [10:14] jodh: that should match, no? [10:16] pitti: should do. [10:17] jodh: ok, let's check tomorrow then; yesterday pollinate was still in, so maybe something is just lagging [10:34] pitti: cron is now running hourly - I just re-ran manually so hopefully it now reflects your expectation. [10:39] jodh: oh, daily is certainly more than enough; I suppose it's not exactly cheap [10:40] jodh: vivid main package admin/ubuntu-drivers-common requires systemd migration (sysv=False, upstart=True, systemd=False) [10:40] jodh: hm, no, this should be systemd=True, and thus disappear entirely [10:40] jodh: unless there is some problem with having upstart+systemd but not sysvinit? [10:41] 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] xnox: syncio> if you want; my care levels about wubi are pretty low now :) [10:54] xnox: oh nice, that's our only remaining patch -- so we can sync again? [10:55] 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] 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] jodh: ah, thanks === saurik_ is now known as saurik [11:00] slangasek: I've asked you, because you are subscribed to the linked bug report :) [11:01] slangasek: and my last comment in the report did not get any response so far [11:01] bug 1080865 [11:01] bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865 === _salem is now known as salem_ === salem_ is now known as _salem [14:05] GunnarHj: should I build utopic langpacks now? or are there still some -docs to land? [14:06] pitti: No, ubuntu-docs was built (in utopic-proposed) a few days ago. All set. [14:06] GunnarHj: ah right, https://launchpad.net/ubuntu/+source/ubuntu-docs/14.10.5; so off we go! [14:07] GunnarHj: .. or not -- we didn't get an export yet :( https://translations.launchpad.net/ubuntu/utopic/+language-packs [14:08] wgrant: ^ is something stuck, or just taking longer? [14:08] probably taking longer because of the full export [14:09] GunnarHj: ok, I'll try and build them on Monday then, but I won't have much time for testing [14:15] pitti: Ok.. I don't know how all that works. Thought the build was what's needed. [14:24] GunnarHj: yes, but we should also have an up to date translation export [14:25] pitti: I'm slowly understanding the nature of the problem. ;) [14:26] pitti: It's LP which is slow, right? [14:26] GunnarHj: a full export just takes quite a bit longer, yes [14:28] 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] Normally seems to take in the general vicinity of an hour, and it's been running for nearly four now [14:29] didrocks: can you retry bluedevil? [14:30] didrocks: in the transitions PPA [14:33] shadeslayer: sure, doing [14:34] though I messed up and the build dep version should have be bumped [14:35] 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 === Guest3214 is now known as mfisch [15:04] pitti: hmm, no, it should just work. Unless somebody regressed something recently. [15:09] 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] stgraber: that's what I get; it might of course be an artifact of running under systemd [15:10] stgraber: err *blush* sorry, my /home/.ecryptfs/martin/.Private is indeed nosuid [15:12] pitti: right, ecryptfs does that :) [15:12] stgraber: yeah, quite plausible to have /home on nosuid, I figure [15:13] so, sorry for the noise [15:19] pitti: Looks like it's there now. https://translations.launchpad.net/ubuntu/utopic/+language-packs [15:19] GunnarHj: ah, good! [15:20] Oh yes, it just took 4h39m for some reason. [15:26] `. === and`_ is now known as and` [15:29] question, what would be the value of uppderdir will be when using overlayfs such that any changes that are made are discarded === roadmr is now known as roadmr_afk [15:59] mvo_: Could you have a look at bug 1399455? [15:59] bug 1399455 in ubuntu-release-upgrader (Ubuntu Vivid) "distribution upgrade from utopic uses DistUpgradeViewText" [High,Triaged] https://launchpad.net/bugs/1399455 === fenris- is now known as ejat [16:06] 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] pitti: Ok, thanks for letting me know. Have a nice weekend! === roadmr_afk is now known as roadmr [16:39] brainwash: I am? I have no idea why I'm subscribed to such a bug report ;) (bug #?) [17:05] 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] slangasek: bug 1080865 [17:07] bug 1080865 in xfce4 (Ubuntu) "Debian instead of Ubuntu grub splash" [Low,Triaged] https://launchpad.net/bugs/1080865 [17:17] brainwash: oh, indeed - yeah, that proposed solution seems fine, I was only involved in triaging that bug out of grub :-) [17:21] slangasek: can you apply the solution? if no, I'm not sure who I could bother with this [17:39] brainwash: it seems to me this should be done by the xubuntu devs? [17:41] slangasek: maybe. the package is not actually part of xubuntu [17:41] slangasek: it's just there to install the normal Xfce desktop environment, synced directly from debian [17:43] 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] it's only a recommended package after all, but it is pulled in by default unless you add --no-install-recommends [18:06] 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] 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] dput uploaded a package to my private repo... and then decided to also ftp it to upload.ubuntu.com [18:07] mark999: If it's unsigned, it just goes to /dev/null, yes. [18:07] whew! [18:08] its contents were somewhat sensitive, so I'm glad [18:08] 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] mark999: Is it a graphical frontend to your diary from puberty? Cause man, I wouldn't want that out there. [18:09] shhhhhh [18:09] 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] I will! should it _really_ be the default, though? [18:10] mark999: I don't think you'll ever get a straight answer on that. [18:10] heh [18:11] 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] 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] 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] well, if unsigned stuff gets deleted by default, no harm done. [18:12] ah yea === brainwash_ is now known as brainwash [18:12] my company is doing something similar to google's goobuntu [18:12] 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] cool [18:16] 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] 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] 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] infinity: can you please mark the report as won't fix? [18:21] infinity: thanks. not really *that* sensitive [18:22] mark999: it can be nuked easily enough if you like, see your /query from me [18:22] 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] slangasek: but it's needed to install the normal Xfce desktop environment (not the Xubuntu session) [18:24] slangasek: Ahh, indeed, xfce4 has no rdeps, blacklisting it would work too. [18:24] brainwash: Is this a valuable thing to do? [18:25] 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] so they just run "sudo apt-get install xfce4" [18:26] and this pulls in desktop-base by default [18:26] Well, I commented on and closed the bug, per your request. :P [18:27] 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] infinity: thanks you :) [18:27] I think if you actually expect Ubuntu users to intentionally install xfce4 (rather than accidentally), you might want to fix this. [18:27] thank [18:27] I appreciate it! [18:27] But I have no strong opinion on the matter. [18:29] 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] IF they don't like the debianization [18:29] brainwash: Or that most people aren't installing "xfce4" :) [18:30] we get quite few reports from users which are running ubuntu + xfce4 (not xubuntu) [18:31] it's the obvious package choice if you've installed ubuntu first and then want to test a different DE like Xfce [18:32] or "gnome" for the gnome DE [19:06] Hello. Is there a chance someone with super cow powers can sync gcalcli from experimental? API changes fix, old version is unusable. [19:12] Unit193, requestsync ? [19:58] Can someone please check why banshee-community-extensions won't migrate? [20:01] Noskcaj: It makes banshee-extension-lyrics uninstallable. [20:05] Ahh. [20:05] Noskcaj: banshee : Breaks: banshee-extension-lyrics (< 2.4.0-3~) but 2.4.0-2ubuntu1 is to be installed [20:05] Noskcaj: It needs a merge to the latest Debian version. === roadmr is now known as roadmr_afk [20:36] hyperair, Should banshee go back to dbus# 2 now the LTS has been released? === roadmr_afk is now known as roadmr === timrc-afk is now known as timrc