[16:05] <blackboxsw> look out, It's that time again.
[16:05] <blackboxsw> #startmeeting bi-weekly status meeting
[16:05] <meetingology> Meeting started Mon Apr  2 16:05:50 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:05] <meetingology> Available commands: action commands idea info link nick
[16:06] <blackboxsw> Welcome to the post-Easter episode of cloud-init's status meeting 🐰
[16:06] <blackboxsw> Today's meeting will probably be light as we are fairly light on attendees given various holiday schedules
[16:07] <rharper> o/
[16:07] <rharper> nice rabbit ears
[16:07] <blackboxsw> heya! As always, we'll go through recent changes, in progress work and ~30 minutes of office hours
[16:08] <blackboxsw> feel free to interject and ask quesitons at any time.
[16:08] <blackboxsw> #topic Recent Changes
[16:09] <blackboxsw> Here's a brief run down of what we have committed to master in the last couple weeks
[16:10] <blackboxsw> - Support for setting hostname from metadata prior to network bringup.
[16:10] <blackboxsw>   This fixes vsphere multi-vm deployments all coming up with the same
[16:10] <blackboxsw>   'ubuntu' hostname. [LP: #1746455](http://pad.lv/1746455)
[16:10] <blackboxsw> - Support initramfs iscsi root so network devices aren't disconnected
[16:10] <blackboxsw>   before shutdown
[16:10] <blackboxsw> - Added cloud-config module `cc_snap` which enables loading snap
[16:10] <blackboxsw>   assertions, configuring snapd and installing snap packages on Ubuntu.
[16:10] <blackboxsw>   Deprecated `cc_snappy` and `cc_snap_config` modules.
[16:10] <blackboxsw> - Make salt minion work on FreeBSD (Dominic Schlegel)
[16:10] <blackboxsw>   [LP:#1721503](http://pad.lv/1721503)
[16:10] <blackboxsw> - Simplify compound conditionals (Rémy Léone)
[16:10] <blackboxsw> - Change some list creation and population to literals (Rémy Léone)
[16:10] <blackboxsw> - Add puppet 4 support configurable in `cc_puppet` module (Romanos
[16:10] <blackboxsw>   Skiadas)
[16:10] <blackboxsw> - Fix datasouce Azure `get_hostname` function for hostname bounce
[16:10] <blackboxsw>   (Douglas Jordan) [LP:#1754495](http://pad.lv/1754495)
[16:10] <blackboxsw> - OpenNebula datasource now uses network config v2 to support IPv6
[16:10] <blackboxsw>   config (Akihiko Ota)
[16:10] <blackboxsw> - Add Hetzner Cloud datasource support (Markus Schade)
[16:11] <blackboxsw> The highlights of this work that will affect various clouds:   hostname setting before network bringup, in cloud-init's init-local stage.
[16:12] <blackboxsw> so if your cloud's metadata provides hostname information (per your instance creation) that hostname gets set before any potential dhcp discovery on the instance. This is a big win for Azure and may allow us to avoid/deprecate some of the hostname_bounce functionality
[16:13] <blackboxsw> which was baked in to re-dhcp in order to publish updated hostname information to DDNS
[16:14] <blackboxsw> We also have landed support for two new clouds: Hetzner Cloud and IBMCloud. A big thanks to Markus Schade for the Hetzner work there and smoser for the IBMCloud datasource
[16:15] <blackboxsw> do3meli (Dominic Schlegel) has also been on a blitz fixing and updating a lot of FreeBSD support in cloud-init tip so thank you sir for that work as well.
[16:16] <blackboxsw> We've just also landed some zfs resize support by rharper as well that should be making it's way into your friendly neighborhood Ubuntu Bionic series in a cloud near you
[16:16] <blackboxsw> anything else I'm missing on rharper or powersj ?
[16:16] <blackboxsw> ahh hold the phone
[16:16] <rharper> blackboxsw: well, not my zfs-resize
[16:17] <rharper> but I do have some fixes for it
[16:17] <rharper>  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root
[16:17] <blackboxsw> We officially released cloud-init 18.2  in master. There is an 18.2 tag in the repo for folks wanting to take an early cut of it.
[16:17] <rharper> our ci-test backend normally runs with zfs, it's not right now so it missed a couple edge cases that we need to handle
[16:18] <blackboxsw> Per cloud-init 18.2 here is an email sent to the cloud-init mailing list describing the details: https://lists.launchpad.net/cloud-init/msg00145.html
[16:18] <blackboxsw> #link https://lists.launchpad.net/cloud-init/msg00145.html
[16:18] <blackboxsw> #link https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root
[16:19] <blackboxsw> #topic In-progress Development
[16:20] <blackboxsw> The upstream team has released 18,2 to Bionic as of last week, and we started an Ubuntu SRU process into Xenial and Artful.
[16:21] <blackboxsw> We expect the 18.2 to be present in Xenial and Artful within 2 weeks in your cloud, so if you are waiting on a feature, it won't be very long.
[16:22] <blackboxsw> Also in-progress are some of rharper's zfs fixes, and some exception callback cleanup that will affect Azure, EC2, OpenStack and  Scaleway clouds.
[16:22] <blackboxsw> #link  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root
[16:22] <blackboxsw> #link https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342007
[16:23] <blackboxsw> And we are doing our part to finally purge net-tools dependencies from cloud-init (in favor of iproute2)
[16:23] <blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342428
[16:24] <rharper> blackboxsw: I responded to your ip -6 route q from last week, did you see that ?
[16:24] <blackboxsw> rharper: haven't yet, but I'll grab those comments today for sure (I think I missed some of your earlier review comments)
[16:24] <rharper> ok
[16:25] <rharper> the tl;dr for that one is that you want this: ip -6 route list table all
[16:25] <blackboxsw> ahh excellent, I was wondering why we were missing content for local routes etc
[16:25] <rharper> right
[16:25] <blackboxsw> thanks
[16:26] <rharper> np
[16:26] <blackboxsw> also, on our continuous integration front , powersj  has put up a branch that I'd like to see us land with some ssh improvements
[16:26] <blackboxsw> #link https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/342010
[16:26] <powersj> :) yep
[16:26] <blackboxsw> any other in-progress work worth noting?
[16:27] <blackboxsw> Intereseted parties can always track our public trello board for a glimpse of what we are working on
[16:27] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[16:27] <blackboxsw> #topic Office Hours (next ~30 minutes)
[16:28] <blackboxsw> We'll all have eyes glued to the screen for the next 30 minutes for rants, feature discussion and bug work.
[16:29] <blackboxsw> With that, the floor is open for any topics. Thanks for tuning in.
[16:30] <blackboxsw> My day today will be Ubuntu SRU(stable release update)-related, so I'm getting on rharper's zfs branch now and they running a couple manual tests on ec2/azure/openstack
[16:30] <rharper> +1
[16:30] <rharper> oh, the ntp-spec update is ready for review and testing
[16:31] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438
[16:32] <blackboxsw> ahh +1 we want that in too
[16:32] <blackboxsw> #link https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438
[17:02] <blackboxsw> Alrighty, happy spring break all.
[17:02] <blackboxsw> Next meeting will be two weeks from today.
[17:03] <blackboxsw> powersj: rharper 4/16 look good for folks?
[17:03] <powersj> +1 from me
[17:03] <blackboxsw> #endmeeting
[17:03] <meetingology> Meeting ended Mon Apr  2 17:03:58 2018 UTC.
[17:03] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-04-02-16.05.moin.txt
[18:26] <blackboxsw> rharper: done with https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/342467
[18:26] <blackboxsw> minor nit
[18:26] <rharper> k
[18:32] <rharper> blackboxsw: added
[18:32] <rharper> pushed update
[19:25] <rharper> blackboxsw: ci says yes, are you going to run the lander or should I for the merge ?
[19:26] <blackboxsw> rharper: yep, yep, I'll run the lander.  I was just getting through your ntp one
[19:26] <rharper> cool
[19:27] <blackboxsw> couple doc nits (on all schema dedent) I'll just post that now. How do I ascertain on timsyncd that the proper settings were honored, systemctl status systemd-timesyncd is not really too helpful
[19:27] <blackboxsw> default timsync service detection looks to work fine on ubuntu
[19:27] <blackboxsw> just going though a couple of tests
[19:34] <blackboxsw> landed https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/342467
[19:36] <rharper> blackboxsw: we *cant* really
[19:37] <rharper> so the ci-test checks that we wrote the conf file correctly
[19:37] <blackboxsw> hrm, also when I have ntp installed, should I expect timesyncd to also report that it is configured and running?
[19:37] <rharper> via journalctl -u systemd-timesyncd.service, if you know the ips, it shows you stuff, but there is no *direct* way to confirm configuration
[19:37] <blackboxsw>    Active: active (running) since Mon 2018-04-02 19:34:37 UTC; 2min 15s ago
[19:37] <rharper> so, in containers, no
[19:38] <rharper> ntp is special in that it just continues even if it can't modify host clock (you'll see a failure due to missing CAP_SYS_TIME)
[19:38] <rharper> but, timesyncd and chrony both have a CondtionContainer!
[19:38] <rharper> which prevents them from actually starting in a container
[19:38] <rharper>  % journalctl -o short-precise -u systemd-timesyncd
[19:38] <rharper> -- Logs begin at Thu 2018-03-15 18:44:40 CDT, end at Mon 2018-04-02 14:38:12 CDT. --
[19:38] <rharper> Mar 20 16:07:20.165833 neipa systemd-timesyncd[1962]: Timed out waiting for reply from [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).
[19:39] <blackboxsw> I'm on ec2 instances which is xen right.
[19:40] <rharper> ah, that should work fine
[19:40] <blackboxsw> https://www.irccloud.com/pastebin/rZTvr122/
[19:40] <rharper> yeah, vms are OK
[19:41] <rharper> containers which share the same kernel (and time) don't need to sync themselves
[19:41] <blackboxsw> yeah, I just forgot if there was a conflict issue w/ timesyncd or ntp where one or the other realizes that another client is running an falls over
[19:41] <rharper> vms maintain their own clock offset due to how time is kept (in registers)
[19:41] <rharper> so, xenial only, timesyncd won't stop if ntp or any other client is installed
[19:41] <blackboxsw> ok yeah I'm on xenial and seeing that
[19:41] <rharper> in bionic, there is a conficts in timesyncd config which forces timesyncd to stop if ntp/chrony is installed
[19:42] <blackboxsw> thanks for the context. had forgotten
[20:45] <blackboxsw> rharper: another round on ntp https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438
[20:45] <blackboxsw> I'm almost there.
[20:45] <blackboxsw> but I'll probably have a few more comments
[20:45] <rharper> sure
[20:52] <rharper> blackboxsw: ok, I already pushed the rebase to drop the zfs, and I *think* all of the doc changes;  working on the rest of your comments
[20:56] <rharper> blackboxsw: maybe you can help, the decode_text() is subtly different than decode_binary(); note we testing if the input is a six.binary_type  and if so decode, where as the other case test if it's a string-type and converts;
[20:56] <blackboxsw> s/check_exec/check_exe/ throughout
[20:56] <blackboxsw> oops, I may have misread those functions. looking again
[20:57] <rharper> blackboxsw: generally this was to work around the fact that if we util.load_file() on our chrony template, we get a UTF-8 char that's not decodeable without specifying the encoding value, py27 needed this before we call the jinja template render code
[21:16] <blackboxsw> hrm, not specifically hitting the problem just on load_file but you are talking during template render we hit this issue?
[21:17] <blackboxsw> load_file in py27 on all template files worked for me the additional decode_text. and I see you folded that into the detect_template call; will check
[21:20] <blackboxsw> rharper: dpb1 I know I'm not going to be able to wrap up the ntp spec branch reviews today and I'd like to get both that and powersj branch in before we re-upload to bionic and start a refresh on the SRU into xenial and artful. So, can we wait to post a bionic upload on zfs fixes until tomorrow?
[21:21] <blackboxsw> rharper: I'm looking to you for "criticality" on zfs resize how much do we want to do two uploads to bionic today and tomorrow?
[21:22]  * dpb1 parses
[21:22] <rharper> blackboxsw: tox -e py27 blows up without the decode_text wrapper when redendering from the "real" templates in tree
[21:23] <dpb1> blackboxsw: rharper, I mean, we should put all those in the upload to bionic, why waste cycles?
[21:23] <dpb1> tomorrow sounds like a better target
[21:23] <blackboxsw> right, I'm for waiting on uploads to bionic until we get everything we want
[21:23] <dpb1> on one hand, there is no reason to wait
[21:23] <dpb1> it's like "committing" your source code
[21:23] <rharper> right, push what we want (or can) to master today, and then prepare an upload tomorrow
[21:23] <dpb1> however
[21:24] <dpb1> in this case, we don't have the upload rights at work
[21:24] <blackboxsw> right, commiting the source code is easy, but upload rights being the 'hard' at the moment
[21:24] <dpb1> so, let's just be a bit judicious
[21:24] <blackboxsw> :)
[21:24] <blackboxsw> ok thx
[21:24] <blackboxsw> will continue on ntp spec branch review/assessment
[21:24] <dpb1> ok
[21:24] <dpb1> yes, lining it up for tomorrow: +1
[21:24] <blackboxsw> instead of changing gears for upload
[21:25] <blackboxsw> tomorrow it is
[21:52] <blackboxsw> ok rharper I think I'm done on ntp config comments. a couple more timeconsuming changes requested for ntp config validation.
[21:53] <rharper> sure


[02:54] <handsome_feng> Hi, kc2bez, dbungert, bdmurray, franksmcb, thanks a lot for your testing  on Ubuntu Kylin. 💐
[06:49] <ginggs> mwhudson: i suspect some of them were already FTBFS due to gcc 11.  I'm going to compare those to the FTBFS report
[07:27] <LocutusOfBorg> vorlon, doko trying to enable flang and upload in ppa
[07:32] <LocutusOfBorg> vorlon, lack of time to enable and make it build lol :D
[08:15] <kc2bez> Of course handsome_feng happy to help out.
[08:26] <handsome_feng> :)
[09:40] <xnox> Eickmeyer:  i'm not sure how it could be a race condition; because nvidia driver is linked in a postinst; and initramfs is rebuilt as a trigger at the end of transaction. note that during apt run all calls to update-initramfs are diverted to a trigger.
[09:40] <xnox> Eickmeyer:  nvidia driver postinst should interest the initramfs trigger it is harmless / correct thing to do.
[09:40] <xnox> especially since we have done nvidia-only respins before
[13:43] <rbasak> slyon: success. Thank you for trying it! https://git.launchpad.net/ubuntu/+source/cdbs/log/
[13:45] <slyon> rbasak: uhh, nice! Kudos to you for putting it all together :)
[15:07] <Eickmeyer> xnox: I agree, but the question is why we're not rebuilding initramfs for *all* installed kernels ala "update-initramfs -u -k all".
[15:10] <Eickmeyer> xnox: bug 1947043
[15:11] <Eickmeyer> xnox: This is something the company I work for and I have identified, not just me as an individual. :)
[15:12] <Eickmeyer> xnox: Long-story short, a recent kernel upgrade coupled with nvidia driver upgrade at the same time in people's systems created this condition where their nvidia drivers failed to function following a reboot, and this was identified as the culpret.
[15:12] <Eickmeyer> s/people's/customer's
[15:17] <xnox> Eickmeyer:  the choice to rebuild current initrd only, or all initrds is scary.
[15:17] <xnox> Eickmeyer:  we have had regression in e.g. busybox; and then you don't want to rebuild all initrds, cause then none of them will work.
[15:18] <xnox> Eickmeyer:  and also we have not been rebuilding many initrds due to changes of things that are vendored into it. I.e. i think there have been things that are included into initrd (without their knowledge) but do not update the initrd
[15:18] <xnox> i.e. security upgrades of shared libraries that are linked to binaries in the initrd i don't think currently universally trigger initramfs rebuilds.
[15:24] <Eickmeyer> xnox: True, but it's really disheartening when we're receiving support emails that their system has broke because the nvidia driver and kernel updated in the same "apt update". We'd rather err on the side of usability.
[15:24] <Eickmeyer> The fix has 90% been "update-initramfs -u -k all".
[15:28] <xnox> Eickmeyer:  how did the machines ended up with nvidia dkms, instead of pre-signed lrm modules?
[15:28] <xnox> Eickmeyer:  did you run ubuntu-drivers to install matching pre-built and pre-signed nvidia modules _instead of_ having dkms instaled?
[15:32] <Eickmeyer> xnox: They install nvidia-drivers-470. They're running focal, and we preinstall for machines that ship.
[15:34] <Eickmeyer> xnox: The flavor is Kubuntu in this case.
[15:47] <Eickmeyer> xnox: nvidia-drivers-470 pulls-in the dkms modules.
[15:48] <xnox> Eickmeyer:  that's the wrong way to install nvidia-drivers which breaks things =/
[15:49] <Eickmeyer> xnox: Isn't that what ubunutu-drivers does?
[15:49] <xnox> Eickmeyer:  one must use ubuntu-drivers to install, cause then it will not install dkms; and install the prebuilt & presigned kernel modules that are updated in lock step
[15:49] <xnox> Eickmeyer:  no it finds the correct meta to install prebuilt drivers; and it configures nvidia prime; and configures support for power management of nvidia gpus; and makes things work on boot
[15:50] <Eickmeyer> xnox: Noted, I'll figure out how to implement this for our customers.
[15:50] <xnox> i.e. even installing things that $ ubuntu-drivers list => is not enough
[15:50] <xnox> Eickmeyer:  i.e. $ ubuntu-drivers list
[15:50] <xnox>  for me offers
[15:50] <xnox> nvidia-driver-470, (kernel modules provided by linux-modules-nvidia-470-generic-hwe-20.04)
[15:50] <xnox> without having dkms, becuase prebuilt modules linux-modules-nvidia-470-generic-hwe-20.04 will be used
[15:51] <xnox> Eickmeyer:  and ubuntu-drivers install also configures nvidia-prime and power management
[15:51] <xnox> Eickmeyer:  thus one should always do ubuntu-drivers install to get the right set of nvidia for the right gpu and the right config that affects initramfs.
[15:52] <xnox> Eickmeyer:  note this is supported by cloud-init too
[15:52] <xnox> can be preseeded in ubiquity and maas
[15:52] <xnox> and used in the clouds too
[15:53] <Eickmeyer> xnox: I'll relay this to the CTO, he has historically not been keen to trust processes he hasn't developed.
[15:57] <vorlon> LocutusOfBorg: no worries, just wanted to draw attention to it to someone who might be able to answer authoritatively :)
[16:17] <xnox> Eickmeyer:  using ubuntu-drivers is the only way to have nvidia drivers, signed with Canonical keys, possible to use with SecureBoot on, and with support for nvidia-prime, improved power management, and ability to dynamically switch from/to nvidia drivers, and is the correct thing to do on laptops, desktops, servers, cloud.
[16:18] <xnox> Eickmeyer:  and you still have ability to choose which series you are after, if one doesn't want to use the latest recommended one. But note that you will remain supported as things are rolled over.
[16:19] <Eickmeyer> xnox: I'm noticing that it sets to on-demand mode, and historically that mode has been problematic for our customers, we've recommended nvidia mode since most of our customers are data scientists for AI and deep learning.
[16:22] <xnox> Eickmeyer:  we enable the modes that we have worked with nvidia to provide. Note if you want drivers not for UI/Graphics, but for AI/ML only, you can opt into -server variant of the drivers. Those are only menat to be used as gpgpu accelerator without using nvidia for graphics.
[16:22] <xnox> Eickmeyer:  this improves the ML/AI performance without affecting (wasting) gpu for Ubuntu Desktop Gui
[16:23] <Eickmeyer> xnox: The reason we haven't gone with the -server variant is that we want people to be able to do both, so that wouldn't work for our use case.
[16:23] <xnox> -server has a lot less depenedencies, does not install many utils, and is what we use in our k8s deployments on MAAS and Public Cloud k8s offerings.
[16:24] <xnox> Eickmeyer:  if you need/want/may have both, please use ubuntu-drivers with on-demand, as that's the only way Ubuntu and nVidia supports things for recent cards.
[16:24] <Eickmeyer> The computers we sell are laptops.
[16:25] <xnox> all Canonical Certified machines are configured with nvidia graphics drivers as installed with ubuntu-drivers in ondemand mode; and it is also the default way things are configured when installing nvidia drivers using nvidia.com scripts.
[16:25] <Eickmeyer> xnox: Good to know, we're working on getting Canonical certification.
[18:12] <jawn-smith> bdmurray, dbungert: I'll take a look at LP: #1873565 since I've worked with gnutls before
[18:12] <bdmurray> jawn-smith: okay, I'll finish the netkit-telnet one
[18:17] <jawn-smith> bdmurray: It looks like this bug (LP: #1873565) needs an SRU to bionic, but no patch has been uploaded so I think the sponsors team could be unsubscribed
[18:18] <bdmurray> jawn-smith: what's in comment #2?
[18:18] <dbungert> bdmurray: jawn-smith: looking at LP: #1840348
[18:18] <jawn-smith> Sorry I'm mixing terms. It's a patch, not a debdiff. I meant that no Bionic debdiff has been uploaded
[18:19] <jawn-smith> I'd be happy to work on the SRU (filling out the template and creating a debdiff) if that's in scope for this "trim the sponsoring queue" exercise
[18:20] <bdmurray> Well we could create a debdiff, so the next question is does it have enough information that you feel comfortable SRU'ing it? e.g. test case
[18:20] <jawn-smith> It seems to include enough detail to recreate it, though I'd of course need to fill out the SRU template still. Shall I proceed with that?
[18:22] <bdmurray> Yeah, let's try and do the right thing here
[18:23] <jawn-smith> on it, thanks!
[18:24] <bdmurray> FYI there's a tool which can produce this comment https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/1891021/comments/2
[18:29] <bdmurray> looking at bug 1581594
[18:31] <dbungert> looking at bug 1794194
[18:34] <dbungert> bdmurray: would you unsubscribe sponsors from bug 1794194?  We can pick this up in the next package merge.
[18:35] <dbungert> looking at bug 1886809
[18:59] <bdmurray> dbungert: done, thanks!
[19:08] <bdmurray> I've commented on bug 1891110
[19:20] <dbungert> bdmurray: we should probably remove sponsors from bug 1886809, I've added a comment with some suggestions.
[19:20] <dbungert> looking at bug 1890572
[19:30] <bdmurray> looking at bug 1871306
[19:37] <dbungert> bdmurray: for bug 1890572, upstream declined it and we've already asked the submitter to work with new upstream.  I think this is another one to drop sponsors from.
[19:37] <jawn-smith> bdmurray FWIW the patch that was uploaded doesn't apply cleanly in bionic at all, and needs a bit of work to get working in bionic. I'm working on it now
[19:39] <bdmurray> jawn-smith: well in that case it'd probably be a better use of time to ask for them to redo the patch
[19:39] <jawn-smith> okay! I'll add a comment to the bug
[19:41] <jawn-smith> bdmurray: done, but now sponsors should be unsubscribed right?
[19:46] <jawn-smith> Looking at LP: #1903548 now. Looks like a community member uploaded a debdiff so I'll give it a test
[19:47] <bdmurray> jawn-smith: yes, I'll unsubscribe them
[19:48] <jawn-smith> thanks
[19:53] <bdmurray> dbungert: Did you look at the cups source wrt bug 1890572?
[19:54] <dbungert> bdmurray: no, I was relying on the comment at https://github.com/apple/cups/pull/5818#issuecomment-796685862
[19:55] <bdmurray> dbungert: well it looks fixed to me, I'll follow up
[19:59] <dbungert> looking at bug 1892825
[20:02] <dbungert> that one looks fine, looking at 1890491
[20:02] <bdmurray> looking at bug 1820083
[20:03] <dbungert> bdmurray: jawn-smith had that one I think
[20:04] <jawn-smith> hmm nope I havne't looked at that one
[20:05] <jawn-smith> different tls related bug :)
[20:05] <bdmurray> ddstreet: is there a reson bug 1820083 hasn't been sponsored?
[20:05] <bdmurray> oh maybe because sts-sponser is spelled wrong
[20:06] <sarnold> hmm, I've seen two bugs recently in the installer that had problems resolving archive hosts moments after downloading packages from those archive hosts: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1946784 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1947061
[20:07] <bdmurray> maybe there are too many clients?
[20:11] <jawn-smith> bdmurray: I've asked the bug reporter on LP: 1903548 for more information, if you feel like unsubscribing sponsors
[20:15] <jawn-smith> Looking at LP: 1913656 I think it should also have the sponsors team unsubscribed. It's an SRU assigned to a Canonical employee. There is a link to an upstream commit that fixes the issue
[20:15] <bdmurray> I'm looking at bug 1898005
[20:15] <bdmurray> I wonder if we should send a report to ubuntu-devel whenever we "finish"
[20:17] <bdmurray> jawn-smith: do you want to subscribe to the bug which asked for more information in? ;-)
[20:18] <bdmurray> there's no patch in that ghostscript bug so unsubscribing
[20:18] <jawn-smith> bdmurray: seeing as how it's been assigned to a member of the Desktop team since Feb, would it be appropriate for me to prepare the SRU for LP: 1913656 ?
[20:19] <jawn-smith> I'd ask the desktop team member but it's quite late in central Europe and they are therefore not online at the moment
[20:19] <seb128> jawn-smith, I think if you want to go ahead with the SRU that would be welcome
[20:27] <bdmurray> I'll be sponsoring the patch in the bug I'm working on
[20:31] <bdmurray> I unsubscribed sponsors from bug 1754069
[20:34] <bdmurray> looking at bug 1916250
[20:44] <dbungert> looking at bug 1882998
[20:45] <bdmurray> mwhudson: could you have another look at the MP associated with bug 885086?
[20:46] <mwhudson> oh yeah i have scripts to make testing initramfs changes much easier now!
[20:48] <bdmurray> mwhudson: thanks! we are trying to have a look at the sponsorship queue and cleaning it up a bit
[21:30] <jawn-smith> seb128: I prepared that SRU. If you have time would you be able to review it?
[21:42] <vorlon> rbasak: /snap/bin/git-ubuntu.merge-changeloges  - oops
[21:50] <jawn-smith> bdmurray: (or any other member of ubuntu-sponsors) it appears racb requested more information in LP: #1472288 a few months ago and hasn't heard anything, so it seems that the sponsors team could be unsubscribed for now.
[21:52] <rbasak> vorlon: thanks. That shows how many users are actually using that entry point then? Or maybe they all autocomplete?
[21:55] <rbasak> https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/410255 - I'll land as soon as CI passes.
[21:58] <rbasak> jawn-smith: thanks! I've commented and unsubscribed sponsors.
[22:01] <jawn-smith> rbasak: thanks! We're trying to help clean up the sponsoring queue
[22:08] <rbasak> Appreciated!
[22:22] <vorlon> bdmurray noticed that sway was accepted into impish-proposed despite not having been signed off by a member of the SRU team; https://launchpad.net/ubuntu/impish/+queue?queue_state=3&queue_text=sway shows that the Ubuntu Archive Robot accepted it.  I've disabled the auto-accept cronjob on snakefruit, looking to see where that is missing from our process
[22:22] <vorlon> also, removing sway from impish-proposed
[22:30] <vorlon> impish-changes shows other packages were wrongly accepted the same way; gsmlib ( slyon ), checkinstall, cdbs, osinfo-db ( jbicha ), I've removed each of these now.  They can potentially be copied into JJ-proposed when it opens, please let me know if you want that to happen
[23:34] <vorlon> bdmurray: to prevent this in the future: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-scripts/trunk/revision/313
[23:35] <ddstreet> bdmurray re: lp:1820083 it's because the customer asking us for it frequently gets distracted by shiny things right after asking for something, so they've been unresponsive when we asked for testing; usually, they get back around to things they ask for after a few months or so
[23:36] <ddstreet> i'll check back with the customer contact to see if they're ready to test before we upload it


[00:06] <nacc> ahasenack: and it would be good to put the conclusion on the wiki page
[00:14] <slangasek> Laney: "You submitted an invalid request: freedombox-setup/0.10 is not published in artful" seems an unexpected result for http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=armhf&package=freedombox-setup&trigger=freedombox-setup/0.10
[00:14] <slangasek> Laney: any insight?
[00:17] <nacc> slangasek: hrm, why does update_excuses say freedombox-setup/unknown?
[00:17] <jbicha> we've had problems with unknown armhf autopkgtests since Friday
[00:17] <nacc> jbicha: ah ok, i wasn't aware, sorry
[00:18] <jbicha> retrying works most of the time
[00:18] <nacc> slangasek: fwiw, i don't believe that retrigger will end up succeeding (I don't see why it's invalid) because mod-gnutls hasn't built on non-amd64 for some time
[00:19] <jbicha> it's ok, I don't think there's anything tracking the armhf problem yet
[00:24] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu6 => 2.02~beta3-4ubuntu6] (core)
[02:46] <slangasek> nacc: ah, is mod-gnutls the source of the problem?  thanks, that was non-obvious why things were showing uninstallable.  Still, I don't think that explains freedombox-setup showing as "not published"
[02:48] <slangasek> nacc, jbicha: fwiw the "/unknown" is the result of Laney's fix to make early-aborted autopkgtests show up in the index instead of disappearing into the void, so is not necessarily a sign of armhf runners having regressed (these are the tests that previously would have shown up indefinitely as 'In progress')
[04:54] -queuebot:#ubuntu-release- Unapproved: mythtv (yakkety-proposed/multiverse) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2 => 2:0.28.0+fixes.20160413.15cf421-0ubuntu<IP_ADDRESS>] (mythbuntu)
[05:00] -queuebot:#ubuntu-release- Unapproved: rejected mythtv [source] (yakkety-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu<IP_ADDRESS>]
[05:01] -queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (yakkety-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu<IP_ADDRESS>]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [amd64] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [armhf] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [powerpc] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [s390x] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [arm64] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [ppc64el] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[05:16] -queuebot:#ubuntu-release- New: accepted libinput [i386] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
[06:33] -queuebot:#ubuntu-release- Unapproved: accepted xfonts-utils [source] (xenial-proposed) [1:7.7+3ubuntu<IP_ADDRESS>]
[07:25] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.3-1ubuntu1~16.04.1]
[12:36] <slashd> good day sil2100, do you have some cycle to approve the upload of 'ksh' in Trusty ? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ksh
[12:38] <slashd> sil2100, I'm re-sending my message, since I just notice you quit/join
[12:38] <slashd> good day sil2100, do you have some cycle to approve the upload of 'ksh' in Trusty ? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ksh
[12:45] <sil2100> slashd: hey! I can try looking into that after lunch if that's ok :)
[12:48] <ogra_> sil2100, when you decided to pick the gross hack for ubuntu-image that classic snaps are, you already gave up on the elegance bit ;) (just read your PR commit) ... I woulldnt care about elegance anymore ;)
[12:48] <slashd> sil2100, sure thank you
[12:49] <jibel> Hi, there is no desktop image today. Can someone have a look? There is a livefs but the ISO failed to build
[12:49] <sil2100> ogra_: yeah, but this involves ugly things happening in the part-install of snapcraft.yaml ;p Like, moving lib files around
[12:49] <sil2100> jibel: let me take a look
[12:49] <jibel> sil2100, thanks
[12:49] <ogra_> sil2100, as long as you dont copy them over system libs outside of the snap (which classic can actuallly do as well)
[13:12] -queuebot:#ubuntu-release- Unapproved: python-cinderclient (xenial-proposed/main) [1:1.6.0-2 => 1:1.6.0-2ubuntu1] (openstack, ubuntu-server)
[13:21] -queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.2 => 1.34.0-0ubuntu8.4] (no packageset)
[13:21] -queuebot:#ubuntu-release- Unapproved: s390-tools (zesty-proposed/main) [1.37.0-0ubuntu3 => 1.37.0-0ubuntu3.1] (core)
[13:25] -queuebot:#ubuntu-release- Unapproved: s390-tools (yakkety-proposed/main) [1.36.1-0ubuntu2 => 1.36.1-0ubuntu2.2] (no packageset)
[14:27] -queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.12-0ubuntu1~14.04.1 => 2.2.14-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
[14:28] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.12-0ubuntu1~16.04.1 => 2.2.14-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
[14:28] -queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.12-0ubuntu1~17.04.1 => 2.2.14-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
[14:28] -queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.12-0ubuntu1~16.10.1 => 2.2.14-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
[14:38] <jbicha> slangasek: oh, that makes sense for the armhf autopkgtests, it is a nice improvement to have the retry buttons at least :)
[14:47] -queuebot:#ubuntu-release- New binary: gnome-control-center [amd64] (artful-proposed/main) [1:3.24.2-0ubuntu3] (edubuntu, ubuntugnome)
[14:51] -queuebot:#ubuntu-release- New: rejected gnome-control-center [amd64] (artful-proposed) [1:3.24.2-0ubuntu3]
[14:55] -queuebot:#ubuntu-release- New binary: gnome-control-center [amd64] (artful-proposed/main) [1:3.24.2-0ubuntu4] (edubuntu, ubuntugnome)
[14:57] -queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (trusty-proposed) [93u+20120801-1ubuntu<IP_ADDRESS>]
[14:58] -queuebot:#ubuntu-release- New: accepted gnome-control-center [amd64] (artful-proposed) [1:3.24.2-0ubuntu4]
[14:58] <slangasek> infinity: these xenial image build failure emails that look like a partially-broken x stack, is that known and in progress in -proposed right now?
[14:59] -queuebot:#ubuntu-release- Unapproved: borgbackup (xenial-proposed/universe) [1.0.7-0ubuntu<IP_ADDRESS> => 1.0.10-2~16.04.1] (no packageset)
[15:01] <infinity> slangasek: Yep, drivers will go in this morning and should fix it.
[15:03] -queuebot:#ubuntu-release- New binary: tpm-tools [ppc64el] (artful-proposed/universe) [<IP_ADDRESS>-0.2ubuntu1] (no packageset)
[15:03] -queuebot:#ubuntu-release- New binary: tpm-tools [s390x] (artful-proposed/universe) [<IP_ADDRESS>-0.2ubuntu1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: tpm-tools [amd64] (artful-proposed/universe) [<IP_ADDRESS>-0.2ubuntu1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: tpm-tools [i386] (artful-proposed/universe) [<IP_ADDRESS>-0.2ubuntu1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: tpm-tools [arm64] (artful-proposed/universe) [<IP_ADDRESS>-0.2ubuntu1] (no packageset)
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (yakkety-proposed) [93u+20120801-2ubuntu<IP_ADDRESS>]
[15:06] <ahasenack> hi, can someone please accept my xenial nomination for https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1664566 ? Thanks
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (xenial-proposed) [93u+20120801-2ubuntu<IP_ADDRESS>]
[15:15] <rbasak> chiluk: regarding intel-microcode, did you see the discussion in ubuntu-release@ and in the bug? I see the same issues. It's not a minimal cherry-pick.
[15:16] <chiluk> rbasak: looking
[15:18] <chiluk> rbasak you are going to have to be more specific I have seen all the discussion...
[15:19] <rbasak> chiluk: for example, why is debhelper compat being bumped?
[15:20] <chiluk> it is but we have sufficient version in xenial so I considered it a non-issue
[15:21] <nacc> ahasenack: done
[15:21] <ahasenack> thx
[15:24] <rbasak> chiluk: I don't think you understood my point in the thread then? These are unnecessary packaging changes.
[15:24] <chiluk> rbasak: the functionality change of depending on the newer version when the underlying isn't changing should be a non-issue
[15:24] <rbasak> chiluk: no, the compat level changed. That's different from just depending on a newer version. That's specifically *asking* for different behaviour.
[15:25] <chiluk> rbasak: they might be unnecessary packaging changes, but in my opinion on a blanket pull-back like this, I think it's more appropriate to stay close to the new version than to start ripping out stuff because it's "new"
[15:26] <rbasak> chiluk: we had this discussion already on the thread. Three members of the SRU team, the only ones who opined, have asked for either a minimal cherry-pick of only the blob update and nothing else, or a full documented exception for ongoing backports. I'd expect the latter to include a comprehensive testing plan. In this case that'd require different CPU types, etc, IMHO.
[15:26] <chiluk> rbasak... If you want Henrique is commenting in the public bug we could ask him
[15:27] <rbasak> chiluk: why is a minimal blob update so difficult?
[15:27] <rbasak> chiluk: see Trusty for an example of it being done in the past.
[15:28] -queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20170511.1~ubuntu16.04.0]
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (zesty-proposed) [93u+20120801-2ubuntu1]
[15:29] <chiluk> rbasak I don't remember seeing that consensus was reached.
[15:29] -queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (yakkety-proposed) [3.20170511.1~ubuntu16.10.0]
[15:29] <chiluk> but if we must I'll pull back just the blobs...
[15:29] <rbasak> chiluk: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1700373/comments/27
[15:34] <chiluk> yeah I missed the ML thread... all my subscriptions got dropped when I lost my canonical.com email address.
[15:42] <LocutusOfBorg> cjwatson, sorry, is armhf real hardware or qemu stuff?
[15:42] <LocutusOfBorg> because I'm tracing down notmuch failures and I see in my qemu ptrace is giving unsupported syscall
[15:51] <chiluk> thanks rbasak for alerting me to that thread... There's a lot of background discussion that I was missing.. I'll investigate more thoroughly later today...*(meetings).
[15:52] <slangasek> LocutusOfBorg: it is real hardware
[15:52] <LocutusOfBorg> thanks
[15:53] <LocutusOfBorg> nice, so I can't debug on my machine notmuch failures because I use qemu
[15:53] <LocutusOfBorg> and there is no porterbox in Ubuntu
[15:53] <LocutusOfBorg> and for some reasons gdb+Ubuntu+notmuch sucks
[15:53] <LocutusOfBorg> "sucks much"
[15:56] <rbasak> "I should also mention that we will be following Debian's lead and not updating this for Trusty." -- who is "we" there, please?
[15:56] <rbasak> chiluk: ^
[15:57] <rbasak> Is that an Ubuntu Foundations team discussion? Or if not, which team?
[15:57] <rbasak> s/discussion/decision/
[16:00] <slangasek> LocutusOfBorg: what is the failure?
[16:01] <slangasek> I don't see any notmuch waiting to migrate
[16:07] <LocutusOfBorg> slangasek, I had to disable testsuite on armhf
[16:08] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/notmuch/0.24.2-2
[16:14] <LocutusOfBorg> slangasek, illegal instruction
[16:14] <LocutusOfBorg> https://launchpadlibrarian.net/327045619/buildlog_ubuntu-artful-armhf.notmuch_0.24.2-2ubuntu7_BUILDING.txt.gz
[16:14] <LocutusOfBorg> in my ppa there is the debug in the instruction
[16:15] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+files/notmuch_0.24.2-2ubuntu7.dsc
[16:15] <LocutusOfBorg> something smells like a glibc issue?
[16:50] -queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (yakkety-proposed) [5.3.3-1ubuntu0.1]
[16:52] -queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (xenial-proposed) [5.1.13-0ubuntu3]
[17:15] -queuebot:#ubuntu-release- New binary: gmime [amd64] (artful-proposed/main) [3.0.1-2] (core)
[17:15] -queuebot:#ubuntu-release- New binary: gmime [ppc64el] (artful-proposed/main) [3.0.1-2] (core)
[17:16] -queuebot:#ubuntu-release- New binary: gmime [s390x] (artful-proposed/main) [3.0.1-2] (core)
[17:18] -queuebot:#ubuntu-release- New binary: gmime [armhf] (artful-proposed/main) [3.0.1-2] (core)
[17:19] -queuebot:#ubuntu-release- New binary: libratbag [s390x] (artful-proposed/universe) [0.9-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: gmime [arm64] (artful-proposed/main) [3.0.1-2] (core)
[17:20] -queuebot:#ubuntu-release- New binary: libratbag [amd64] (artful-proposed/universe) [0.9-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: gmime [i386] (artful-proposed/main) [3.0.1-2] (core)
[17:20] -queuebot:#ubuntu-release- New binary: libratbag [ppc64el] (artful-proposed/universe) [0.9-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: libratbag [i386] (artful-proposed/universe) [0.9-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: python-daiquiri [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: python-coverage-test-runner [amd64] (artful-proposed/universe) [1.13.1-1] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: python-bitcoinlib [amd64] (artful-proposed/none) [0.7.0-1] (no packageset)
[17:24] <infinity> doko: Hrm, LocutusOfBorg just disabled the notmuch testsuite on armhf due to it throwing SIGILL.  That sounds fishy.
[17:24] <infinity> doko: (Well, disabling the testsuite because it's doing its job is very fishy, but I mean the SIGILL could perhaps relate to new toolchain)
[17:27] -queuebot:#ubuntu-release- New binary: qbs [s390x] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: qbs [ppc64el] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [amd64] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [armhf] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [ppc64el] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted libratbag [amd64] (artful-proposed) [0.9-1]
[17:28] -queuebot:#ubuntu-release- New: accepted libratbag [ppc64el] (artful-proposed) [0.9-1]
[17:28] -queuebot:#ubuntu-release- New: accepted python-bitcoinlib [amd64] (artful-proposed) [0.7.0-1]
[17:28] -queuebot:#ubuntu-release- New: accepted python-daiquiri [amd64] (artful-proposed) [1.0.1-1]
[17:28] -queuebot:#ubuntu-release- New: accepted qbs [s390x] (artful-proposed) [1.8.1+dfsg-1]
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [arm64] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [s390x] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted libratbag [s390x] (artful-proposed) [0.9-1]
[17:28] -queuebot:#ubuntu-release- New: accepted qbs [ppc64el] (artful-proposed) [1.8.1+dfsg-1]
[17:28] -queuebot:#ubuntu-release- New: accepted gmime [i386] (artful-proposed) [3.0.1-2]
[17:28] -queuebot:#ubuntu-release- New: accepted python-coverage-test-runner [amd64] (artful-proposed) [1.13.1-1]
[17:28] -queuebot:#ubuntu-release- New: accepted libratbag [i386] (artful-proposed) [0.9-1]
[17:28] -queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: dolfin [s390x] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: qbs [amd64] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: qbs [i386] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: dolfin [amd64] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: dolfin [i386] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[17:51] <doko> infinity: we currently only have new binutils
[17:52] <infinity> doko: Yes.  Which could very well be responsible for generating bad instructions.
[17:53] -queuebot:#ubuntu-release- New: accepted tpm-tools [amd64] (artful-proposed) [<IP_ADDRESS>-0.2ubuntu1]
[17:53] -queuebot:#ubuntu-release- New: accepted tpm-tools [i386] (artful-proposed) [<IP_ADDRESS>-0.2ubuntu1]
[17:53] -queuebot:#ubuntu-release- New: accepted tpm-tools [s390x] (artful-proposed) [<IP_ADDRESS>-0.2ubuntu1]
[17:53] -queuebot:#ubuntu-release- New: accepted tpm-tools [arm64] (artful-proposed) [<IP_ADDRESS>-0.2ubuntu1]
[17:53] -queuebot:#ubuntu-release- New: accepted tpm-tools [ppc64el] (artful-proposed) [<IP_ADDRESS>-0.2ubuntu1]
[18:00] -queuebot:#ubuntu-release- New binary: dolfin [armhf] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[18:07] -queuebot:#ubuntu-release- New binary: dolfin [arm64] (artful-proposed/universe) [2016.2.0-4] (no packageset)
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [amd64] (artful-proposed) [2016.2.0-4]
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [armhf] (artful-proposed) [2016.2.0-4]
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (artful-proposed) [2016.2.0-4]
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [arm64] (artful-proposed) [2016.2.0-4]
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [s390x] (artful-proposed) [2016.2.0-4]
[18:37] -queuebot:#ubuntu-release- New: accepted dolfin [i386] (artful-proposed) [2016.2.0-4]
[18:38] -queuebot:#ubuntu-release- New: accepted qbs [amd64] (artful-proposed) [1.8.1+dfsg-1]
[18:38] -queuebot:#ubuntu-release- New: accepted qbs [i386] (artful-proposed) [1.8.1+dfsg-1]
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu6]
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu6]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xf86-input-mtrack-hwe-16.04 [source] (xenial-proposed) [0.3.1-1build2~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-void-hwe-16.04 [source] (xenial-proposed) [1:1.4.1-1build3~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau-hwe-16.04 [source] (xenial-proposed) [1:1.0.14-0ubuntu1~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-trident-hwe-16.04 [source] (xenial-proposed) [1:1.3.8-1build1~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vmware-hwe-16.04 [source] (xenial-proposed) [1:13.2.1-1build1~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xf86-input-wacom-hwe-16.04 [source] (xenial-proposed) [1:0.34.0-0ubuntu2~16.04.1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl-hwe-16.04 [source] (xenial-proposed) [0.1.5-2build1~16.04.1]
[21:02] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-dummy-hwe-16.04 [source] (xenial-proposed) [1:0.3.8-1build1~16.04.1]
[21:02] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vesa-hwe-16.04 [source] (xenial-proposed) [1:2.3.4-1build3~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-evdev-hwe-16.04 [source] (xenial-proposed) [1:2.10.5-1ubuntu1~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-16.04 [source] (xenial-proposed) [1.3.0-0ubuntu1~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-fbdev-hwe-16.04 [source] (xenial-proposed) [1:0.4.4-1build6~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics-hwe-16.04 [source] (xenial-proposed) [1.9.0-1ubuntu1~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel-hwe-16.04 [source] (xenial-proposed) [2:2.99.917+git20170309-0ubuntu1~16.04.1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-16.04 [source] (xenial-proposed) [1:7.9.0-0ubuntu1~16.04.1]
[21:39] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-siliconmotion-hwe-16.04 [source] (xenial-proposed) [1:1.7.9-2ubuntu1~16.04.1]
[21:39] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-tdfx-hwe-16.04 [source] (xenial-proposed) [1:1.4.7-1build1~16.04.1]
[21:39] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-sisusb-hwe-16.04 [source] (xenial-proposed) [1:0.9.7-1build1~16.04.1]
[22:03] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-mach64-hwe-16.04 [source] (xenial-proposed) [6.9.5-1build3~16.04.1]
[22:03] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-openchrome-hwe-16.04 [source] (xenial-proposed) [1:0.5.0-3build1~16.04.1]
[22:03] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-savage-hwe-16.04 [source] (xenial-proposed) [1:2.3.9-1ubuntu1~16.04.1]
[22:03] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-neomagic-hwe-16.04 [source] (xenial-proposed) [1:1.2.9-1build3~16.04.1]
[22:03] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-r128-hwe-16.04 [source] (xenial-proposed) [6.10.2-1build1~16.04.1]
[22:16] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-joystick-hwe-16.04 [source] (xenial-proposed) [1:1.6.3-1build1~16.04.1]
[22:16] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode-hwe-16.04 [source] (xenial-proposed) [2.11.19-2~16.04.1]
[22:16] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput-hwe-16.04 [source] (xenial-proposed) [0.25.0-0ubuntu1~16.04.1]
[22:29] -queuebot:#ubuntu-release- Unapproved: accepted xorg-hwe-16.04 [source] (xenial-proposed) [1:7.7+16ubuntu3~16.04.1]
[22:37] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (zesty-proposed/main) [5.7.1+dfsg-2ubuntu4~1 => 5.7.1+dfsg-2ubuntu4~<IP_ADDRESS>] (kubuntu, qt5, ubuntu-desktop)


[00:51] <knome> i added the xubuntu feed to planet ubuntu 20 seconds ago.
[01:12] <charlie-tca> thank you
[01:17] <micahg> charlie-tca: I'm sorry, but I haven't heard back from persia about the ARM installers, I could test next week and we could release it late if you're interested
[01:17] <charlie-tca> heh, at the rate it is going, ARM might not be ready anyway
[01:18] <charlie-tca> I think they are rebuilding the image again
[01:18] <charlie-tca> We did not have them for us this time. Maybe we can start building and testing them, and plan for beta release?
[01:18] <charlie-tca> That is only a month away
[10:38] <PsynoKhi0> heya
[10:38] <ochosi> hi
[10:40] <PsynoKhi0> I've just tried the daily build for xubuntu natty, really impressed by the polished look
[10:43] <PsynoKhi0> though did I miss it or has the desktop switcher applet been removed from the default layout?
[10:44] <mr_pouit> The workspace switcher will probably come back, after the alpha 3 release
[10:44] <PsynoKhi0> great :)
[10:46] <ochosi> thanks for the nice feedback PsynoKhi0
[10:47] <PsynoKhi0> np, you deserve it guys! almost making me want to drop KDE4 heh
[10:49] <PsynoKhi0> there's only one thing that kind of bugs me, it's the menu icon
[10:49] <ochosi> yeah, that's work in progress
[10:50] <PsynoKhi0> though only if it take it from a "first time user"'s perspective
[10:50] <PsynoKhi0> it's like the smallest icon of all with no rel clue that it's a menu icon unless you hover the mouse over it
[10:50] <PsynoKhi0> no real*
[10:51] <PsynoKhi0> mind you, this more or less plagues any recent DE
[10:53] <ochosi> currently we were thinking to make it monochrome
[10:53] <PsynoKhi0> hell even MS seem to think they can get away with nothing but an icon - they prolly believe they can afford that because of the windows mindshare
[10:53] <ochosi> but tbh i don't really know how the icon could suggest "menu"
[10:53] <PsynoKhi0> I think it should contrast with the rest of the desktop
[10:54] <ochosi> as in: make it pink? :)
[10:54] <PsynoKhi0> URGH
[10:54] <ochosi> well, it kinda does contrast with the rest of the DE atm because it's not monochrome
[10:56] <PsynoKhi0> hmm well take the start button in XP... dault is a green button with a big fat START on it, over a blue taskbar... what would a brand new computer user do when seeing the desktop for the first time?
[10:56] <PsynoKhi0> hard to miss, isn't it?
[10:56] <PsynoKhi0> dault -> default
[10:57] <ochosi> probably, but tbh when i was still using windows i always thought: "why the heck does it say 'start'"?
[10:58] <PsynoKhi0> dunno... but it has pretty strong "whenever you have no clue what to do next, try pressing here" semantics
[10:59] <ochosi> ok, so assuming we stick with only the icon, no text, what would you suggest?
[11:00] <PsynoKhi0> hmm do you have a screenshot of the current dafault layout?
[11:00] <PsynoKhi0> oh boy, gotta learn to type default right
[11:00] <ochosi> lol, yeah :)
[11:01] <PsynoKhi0> a pic of the top left corner will do
[11:01] <ochosi> this is approx the default http://imagebin.org/140898
[11:02] <PsynoKhi0> awesome ty! gonna slaughter it a bit ;P
[11:02] <ochosi> sure, go ahead
[11:10] <mark76> Is that xfce4-panel with alpha transparency at the bottom?
[11:11] <ochosi> mark76: yes
[11:23] <mark76> Nice
[11:34] <PsynoKhi0> sigh I suck at GIMP....
[11:37] <PsynoKhi0> http://img593.imageshack.us/i/panelit3bigmenubutton.png/ anyway something like this
[11:38] <PsynoKhi0> but professionally done >.<
[11:38] <ochosi> woah
[11:38] <ochosi> so you want to make it ellipse-shaped
[11:38] <PsynoKhi0> yes it's butt ugly
[11:38] <ochosi> ?
[11:39] <PsynoKhi0> nah, dunno, couldn't get the corners round
[11:39] <PsynoKhi0> :|
[11:39] <ochosi> we were considering something like the lubuntu menu-button
[11:39] <ochosi> but not sure yet whether it's possible in xfce-panel
[11:40] <PsynoKhi0> ah
[11:40] <ochosi> https://wiki.ubuntu.com/Lubuntu/Artwork/Incoming/Natty/Ozone
[11:40] <ochosi> > panel
[11:41] <PsynoKhi0> anyway you could have the icon bigger ieven if the top and buttom are slightly cut off?
[11:41] <ochosi> probably
[11:41] <ochosi> not sure whether the icon will be cut off or scaled
[11:43] <PsynoKhi0> hmm lubuntu might be on the right track, though still not sold on flat menu buttons with no text... doesn't really scream "CLICK MEH!!!" but it could be just me hehe
[11:44] <PsynoKhi0> oh well, I guess users CAN learn too :)
[11:44] <ochosi> yeah, the install-slideshow will highlight the app-menu and the button
[11:44] <ochosi> so it's not necessarily a problem
[11:44] <PsynoKhi0> true
[11:44] <ochosi> and i don't want a button that screams at me for everyday-work
[11:44] <PsynoKhi0> hehe
[11:46] <PsynoKhi0> so you're assuming that people know their way around, or watch the slideshow, or get help for the first post install steps, I guess it's fair enough
[11:46] <ochosi> mr_pouit: btw, i asked again in #xfce-dev about thunar's startup-lag and jannis and nick still seem to be convinced that adding the daemon to autostart solves the issue
[11:47] <ochosi> PsynoKhi0: yep, and there are also users that might get what that button does by a) intuition or b) trying to click it ;)
[11:47] <PsynoKhi0> if they do understand it's a button :P
[11:48] <ochosi> well, if they're too afraid to click anywhere, how will they even install the system?
[11:49] <PsynoKhi0> well I'm using the following scenario as a starting point: someone who gets a computer/tablet/whatever as a present with any *buntu flavor preinstalled... what are the first reactions?
[11:50] <PsynoKhi0> oh and that person has not heard let alone used *buntu before
[11:50] <ochosi> sure, it's a valid (even not exactly the standard) scenario
[11:50] <ochosi> +if
[11:50] <PsynoKhi0> though yes it might not be your target audience :)
[11:50] <ochosi> yeah, maybe not ;)
[11:51] <ochosi> but in the end i don't think there's a clear audience for xubuntu
[11:51] <PsynoKhi0> still wishing for some big OEM putting *buntu systems on local electronics shop :D
[11:51] <ochosi> good luck with that
[11:51] <PsynoKhi0> I know...
[11:51] <ochosi> sry, g2g, lunch ->
[11:51] <ochosi> bbl
[11:51] <PsynoKhi0> every bit helps though
[11:51] <PsynoKhi0> kk cya!:)
[11:52] <ochosi> yep, cu
[12:03] <mr_pouit> ochosi: clearly not, because Thunar --daemon is already launched by default by xfce4-session here :/
[13:08] <PsynoKhi0> ochosi?
[13:09] <PsynoKhi0> ah nvm
[13:29] <mr_pouit> ochosi: imho, it is slow to start, because it needs to start all gio network daemons (gvfsd-{smb,dns}, etc.)
[13:29] <mr_pouit> if you compare ps output before and after, you can see more of them
[13:30] <mr_pouit> ah, and tumbler of course
[13:32] <mr_pouit> if you compare with nautilus: nautilus loads them only when you click on the "network" shortcut
[13:33] <mr_pouit> (so it's faster to start the first time)
[14:44] <charlie-tca> Good morning
[15:06] <mr_pouit> ochosi: yay, I think I identified the cause of the startup lag: the "Network" bookmark
[15:50] <ochosi> mr_pouit: let's hope we can fix that! :)
[15:51] <mr_pouit> for 4.8, I'm not sure :}
[15:51] <ochosi> for 11.04? ;)
[15:51] <ochosi> i mean can we patch it
[16:01] <mr_pouit> well, if what I wrote is not too wrong, I don't see any unintrusive way of patching :/
[16:01] <ochosi> arrh
[16:10] <ochosi> g2g, sry, i won't be able to attend the meeting tonight i'm afriad
[16:10] <ochosi> not many updates from my side anyway, apart from xfwm4 finished and all
[16:10] <ochosi> ->
[16:34] <charlie-tca> well, I forgot to tell vinnl we need a news release for alpha3
[18:17] <charlie-tca> Natty Alpha3 released!
[18:17] <charlie-tca> Congratulations for a well-done effort
[18:34] <charlie-tca> Xubuntu community meeting in #ubuntu-meeting in 25 minutes. Everyone is invited to attend. Agenda is at https://wiki.ubuntu.com/Xubuntu/Meetings
[18:34] <charlie-tca> if freenode settles down enough
[18:46] <micahg> charlie-tca: I'll be a little late for the meeting
[18:46] <charlie-tca> heh
[18:47] <charlie-tca> no problem, I don't know if I will make it at the rate the splits are going


[09:32] <head_victim> sagaci: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable - you might be interested in covering how to set up a dev environment?
[09:33]  * benonsoftware would attend a session like that :)
[09:36] <benonsoftware> head_victim: I will not be able to attend the next IRC meeting (school) but could I add a note to http://is.gd/YCbG3z asking for ideas for a Melbourne release party?
[09:37] <head_victim> If all you're doing is brainstorming the ML might be a better avenue to catch more people with ideas
[09:37] <benonsoftware> Ok, thanks
[09:41] <benonsoftware> Email sent :P
[09:41] <head_victim> Just trying to get the most out of it all :)
[09:41] <head_victim> Basically you pick a time and place and put it on loco.u.c and it's set to be honest. It can be fine tuned if need be later on :)
[09:41] <benonsoftware> Ok
[09:42] <benonsoftware> First we need to find a place :P
[09:44] <head_victim> Cool, on that note, I'm off for a while
[09:44] <benonsoftware> See you
[10:02] <sagaci> head_victim: I'd much rather the masters of #ubuntu-devel or #ubuntu-motu to take that
[10:03] <sagaci> I think I could do a basic session but other than that, I'd rather have something who knows what they're talking about if things go awry
[11:17] <head_victim> sagaci: fair enough, I just thought after watching your youtube vids you might be up for an intro class :D
[11:17] <head_victim> No pressure, just making sure you knew it existed.
[12:16] <sagaci> besides, dholbach is already doing it


[09:15] <suvadeep> hi
[10:27] <michagogo> 15:17:00 <ogra_> better changeyour password now ;) <-- Why? What damianr accidentally sent in here isn't sensitive, and didn't include his password, email address, or anything else of concern.
[10:28] <ogra_> i could write a bot spamming as his account ;)
[10:29] <ogra_> and this channel is publically logged ...
[10:32] <michagogo> ogra_: huh?
[10:32] <michagogo> That wasn't an identify command
[10:32] <michagogo> not a register command
[10:33] <michagogo> Nor a setpass command
[10:33] <michagogo> It was a VERIFY REGISTER command, which is just the email verification token
[10:33] <michagogo> You can't use that for anything
[14:09] <damianr> Hi there once again, I have a doubt. When fixing bugs which are also present in the upstream. After Informing the upstream, the upstream package fixes not just that bug but couple of other bugs or introduce features do I have include those in the bug patch.?
[14:13] <geser> it depends: for a stable update: only the changes for that bug; for development versions: the new upstream version
[14:16] <damianr> Thanks and one more, patch attached and branch avaliable in launchpad bug means the fix is commited by someone in different medium ie through a patch file and through a different launchpad branch ?
[15:55] <arun_> guys how do I use a pbuilder ?
[16:03] <arun_> hello
[16:13] <damianr> arun_ https://wiki.ubuntu.com/PbuilderHowto
[16:14] <arun_> damianr: I didn't get the .deb file using "sudo pbuilder create --debootstrapopts --arch --debootstrapopts i386
[16:17] <arun_> damianr:
[16:18] <damianr> I am new around here too.
[16:18] <arun_> damianr: ohh !!! thanks for the help though
[16:19] <damianr> i think u should indicate the package u want to build
[16:19] <damianr> normally i am guessing pbuilder works with dsc file
[16:26] <shadeslayer> debfx: thx for backporting btw
[16:27] <arun_> how can I get 32 bit deb file from 64 bit VPS compiling in it
[16:27] <shadeslayer> arun_: use pbuilder
[16:27] <shadeslayer> !pbuilder > arun_
[16:28] <arun_> shadeslayer: it seems really hard to do
[16:28] <debfx> shadeslayer: yw
[16:28] <shadeslayer> arun_: not really
[16:28] <shadeslayer> arun_: just read the wiki?
[16:28] <debfx> I'll approve anything that contains those beautiful unicode check marks ;)
[16:28] <shadeslayer> hahaha
[16:28] <shadeslayer> <3 unicode checkmarks
[16:28] <arun_> shadeslayer: no, I did, but didn't obtained the deb file
[16:29] <shadeslayer> arun_: well, depends on what was defined in BUILDRESULT
[16:30] <shadeslayer> ( a var in pbuilderrc _


[00:04] <reflexrg> that didn't work
[00:04] <reflexrg> this works
[00:04] <reflexrg> #!/bin/bash
[00:04] <reflexrg> Date=$(date +"%m-%d-%Y")
[00:04] <reflexrg> echo "Creating Checksum with Today's date! : $Date.md5"
[00:04] <reflexrg> md5sum * > $Date.md5
[00:04] <reflexrg> :)
[00:19] <reflexrg> finished
[00:19] <reflexrg> here's my script
[00:19] <reflexrg> http://pastebin.com/raw.php?i=46i8MkyS
[00:19] <reflexrg> :)
[00:43] <psychx-> :O
[01:55] <theredbaron_> Anyone know how to get the pulse-applet to work with ad2p? It works fine with my HDMI output, but not ad2p.
[03:58] <ankur> I have HP Deskjet F2235. The printing and scanning functionality were both working fine when I was using Ubuntu 11.04. Then I switched to lubuntu 11.10. And now 'Simple Scan' doesn't detect my scanner, but it used to before. Please help!
[04:00] <ankur> It is a MFD.
[07:53] <Mr_EE1> good morniing everyone
[07:55] <Mr_EE1> guys i have an ATI graphic but dont want to make compiz and cairo dock, when i enable them it freezes or dont do them whats the problem or what should i do?
[07:57] <Mr_EE1> i am using 11.10
[12:14] <xsaidx> hello guys
[13:55] <Mr_EE1> hello
[13:57] <Mr_EE1> hey guys i need to use compiz in lubuntu 11.10
[14:00] <Mr_EE1> hello guys i want to use compiz at lubuntu 11.10 how do i it
[14:12] <holstein> Mr_EE1: need?... ive never thought of it as a need
[14:13] <holstein> i like it though... let me get a few things for you
[14:14] <Mr_EE1> holstein: ok thanks
[14:14] <holstein> what i would suggest.. install compiz and the settings manager... run this from the terminal to test
[14:14] <holstein> compiz --replace
[14:15] <holstein> then, you can look into adding that command at startup with LXDE, or however you want to do it
[14:58] <elz89> I am still having problems with bluetooth, every other *buntu sees it, lunbuntu does not.
[14:58] <elz89> Not sure where to start with this one.
[15:04] <holstein> elz89: are you certain its the same version? the same kernel?
[15:07] <elz89> yes
[15:07] <elz89> holstein: yes
[15:08] <elz89> holstein: uname -a
[15:08] <elz89> Linux toshiba-nb200 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux
[15:08] <holstein> i would probably load up a live CD its working in, and look around at the packages... maybe just searching bluetooth in synaptic, and do the same from the installed lubuntu
[15:08] <elz89> holstein: yes it worked live cd, kinda...
[15:22] <Cort> how can I make LXDE the default?
[15:23] <Cort> anyone?
[18:17] <Mr_EE1> holstein: i have done that about the compiz--replace but it dreezes what shoul i do now
[18:17] <Mr_EE1> it doesnt show the panel now
[18:18] <Mr_EE1> anyone help
[18:24] <me-1> hi...is Lubuntu adored by canononical
[18:54] <bekor> anyone here?
[18:54] <bioterror> I am
[18:54] <bekor> how are you?
[18:54] <bioterror> fine thanks, I gues
[18:54] <bioterror> s
[18:54] <bioterror> my back is getting a little better
[18:55] <bekor> what version are you using?hey i got a bad back to four floating ribs for one
[18:56] <bekor> ever use compiz in lubuntu
[18:56] <bioterror> nope
[18:56] <bioterror> xcompmgr yes
[18:56] <bekor> is that better?
[18:59] <bioterror> probably depends what you're looking for
[18:59] <bioterror> okay
[19:53] <Gege71> anyone use pidgin there ?
[20:02] <bioterror> Gege71, any issues?
[20:19] <xsaidx> Gege71: hello me
[20:19] <xsaidx> bioterror: you dont ?
[20:38] <Gege71> bioterror> sorry :)
[20:38] <Gege71> yes i have the buddy list permanently blinking
[20:40] <xsaidx> Gege71: uhm im sorry but i didnt get you
[20:46] <bioterror> Gege71, does any other window blink?
 : xsaidx helped me with plugin config, i will do some test. but no only buddy list was blinking.
[20:53] <Gege71> it seems now to work, but not sure what is did :)
[20:57] <xsaidx> Gege71:  its self explanatory tho you ticked the box you wanted thats it ; ]
[22:16] <_3st_> No Software center in Lubuntu ?
[22:16] <xsaidx> _3st_: theres you have to add the lubuntu ppa first
[22:17] <_3st_> ppa ?
[22:17] <xsaidx> _3st_: hang on
[22:19] <_3st_> https://help.ubuntu.com/community/Lubuntu/Documentation/FAQ/Guides#How_to_install_Lubuntu_Software_Center_.28LSC.29
[22:19] <_3st_> ahh ok :)
[22:23] <xsaidx> yesh thts it
[23:23] <RidDrib> Hi
[23:48] <lubuntu1986> when is the next *buntu release gonna be?
[23:54] <lubiana> 12.04


[04:20] <elky> drive by...
[04:21] <Corey> I missed what it was.
[04:21] <Corey> APparently fell out of #ubuntu
[04:22] <Flannel> join, ubottu call, part
[04:32] <elky> ops call to boot
[05:09] <vibhav> Is there any way to stop a guy who is sending me offensive messages??
[05:09] <pangolin> /ignore
[05:10] <vibhav> And if the guy is changing his nicks everytime
[05:10] <pangolin> just leave the message window minimized and don't look at it (soft ignore)
[05:11] <pangolin> nothing we can do about it unless it is onjoin spam in one of the channels we monitor
[05:11] <vibhav> thok
[05:11] <vibhav> Ill ignore it
[05:11] <vibhav> Thanks
[14:25] <bazhang> * [DemonWitch] (~DemonWitc@<IP_ADDRESS>.dsl.dyn.forthnet.gr): DemonWitch
[14:54] <bazhang> * ede Ping | Could not be resolved to an IP address  <-- in response to !ping


[19:22] <tubbo> this might be better for #ubuntu...but on ubu 12.04 what's the best way to make a "master process" upstart init config?
[19:22] <tubbo> i am running a bg job queue (resque) and it requires 4 workers. i'd like 1 master process to manage those 4 workers, also managed via upstart
[19:22] <tubbo> the main process, however, i'm forced to put in a pre-start script otherwise upstart fails to track its PID (guess because it doesn't actually have one)


[23:47] <bazhang> al_nz1, no need, just install the lubuntu-desktop package. xubuntu is not lighter by much, if any
[23:47] <jstarcher> I run: git svn clone --no-metadata -A ~/users.txt -t tags -b branches -T trunk<EMAIL_ADDRESS>and get svn-git died of signal 4
[23:47] <jstarcher> any ideas?
[23:47] <jstarcher> How can I debug this
[23:47] <floogy> HSL, so it might be one of those
[23:48] <HSL> floogy: http://paste.ubuntu.com/660149/
[23:48] <al_nz1> bazhang: I already have a ubuntu machine, and I need to have clients PXE boot a lite and fast linux flavour - just to command line
[23:48] <anvo> Why am I not having the option to change to Enlightenment on the login screen...?
[23:49] <anvo> How do I manage to set this option...?
[23:49] <Nashenas> hello again, I've switch my 11.04 into gnome, and when I activated my compiz settings so I can have a desktop cube effect I lost my window borders. Disabling the cube did not bring them back. Any ideas?\
[23:51] <al_nz1> bazhang: were you saying no need to PXE boot?
[23:51] <bazhang> al_nz1, that was before you provided the last bit of info
[23:52] <al_nz1> bazhang: k.
[23:52] <Barzogh> hello , can someone tell where i can found the rpurge application for ubuntu?
[23:52] <Barzogh> please
[23:53] <bazhang> Barzogh, does not exist
[23:53] <Barzogh> oO
[23:54] <JZApples> Is this row in my fstab file bad?  /dev/mapper/cryptswap1 none swap sw 0 0    Does that mean my swap file is just a file and not on its own partition?
[23:55] <HSL> floogy: ok,.. it wasn't fetchmail :)
[23:55] <HSL> I'm not going to disaple grub-common :P
[23:55] <HSL> disable
[23:56] <floogy> on.denand rc.local?
[23:56] <floogy> m
[23:56] <HSL> yeah, they look quite important ;)
[23:56] <VxQf> JZApples, no
[23:56] <VxQf> Are you using LVM?
[23:56] <VxQf> Also
[23:57] <VxQf> In unix-like systems, everything is a file.
[23:58] <hp_> My wireless interface is hard-blocked according to rfkill. The manual switch on my laptop is broken. How can I remedy to that?
[23:58] <JZApples> VxQf, right, but that means its not on its own partition, correct?  wouldn't it be wiser to put that on it's own partition?  And if so, is there any way to shrink the partition my OS is on and create another one strictly for the swap?
[23:59] <mega1_> How do I add user as administrator
[23:59] <VxQf> I am not sure what you are talking about, tbh. The fact that it's being shown under the mapper means it's a partition
[23:59] <VxQf> probably on a raid array or LVM


[01:11] <skellat> If anybody is looking for a conundrum to fiddle with: http://askubuntu.com/questions/282213/is-there-a-guide-to-debian-lives-seemingly-undocumented-ubuntu-extension


[03:50] <jea> head_victim: I received a response, so confirmed the membership
[03:50] <jea> I agree with the ISO. We should get on to doing the customisation properly
[03:51] <jea> then we just need somewhere to host it, unless jellyware can build it himself and use it
[03:51] <jea> Maybe we can put instructions on the website on how to build it to start off with
[09:28] <ikt> heya head_victim
[09:28] <ikt> is it possible to make the panel at the bottom of lubuntu bigger?
[09:29] <ikt> it is bigger but not as one panel
[09:29] <ikt> it seems to seperate


[00:13] <fbond> Can anyone remove a package from my PPA for me?
[00:14] <fbond> I made a versioning error and I need to wipe out the old version of a package to correct it.
[00:15] <Fujitsu> fbond: Please ask a question on the launchpad project.
[00:15] <fbond> Fujitsu: will do.
[04:27] <jamesh> PPAs are pretty cool unless you get stuck behind the ubuntu-langpack builds
[04:28] <Hobbsee> heh :)
[04:28] <Hobbsee> jamesh: nothing you can do about them either, unless you have root access to those buildds.
[04:29] <jamesh> I've just been playing round with packaging a newer version of bzr-pqm
[04:31]  * Hobbsee wasn't aware that that was public.
[04:31] <jamesh> Hobbsee: bzr-pqm is just a plugin to submit PQM messages
[04:32] <jamesh> an old version of it is even packaged in Ubuntu
[04:32] <Hobbsee> ahh
[04:32] <jamesh> the actual PQM server software is available at https://launchpad.net/pqm
[04:32] <spiv> Both bzr-pqm and PQM have always been public.
[04:32] <jamesh> I don't know if that is packaged, since it is a pain to set up
[04:34] <Hobbsee> neat!
[05:09] <Hobbsee> jamesh: it appears you're in luck.  this appears to be the last lot of langpacks
[05:09] <Hobbsee> as in, the 3 building now
[05:37] <poolie> is there a shortcut url for ~me?
[05:37] <poolie> i thought it was launchpad.net/+me but that doesn't work
[05:38] <Fujitsu> poolie: /people/+me
[06:35] <poolie> thanks
[06:35]  * poolie tries a PPA upload
[06:35] <poolie> how exciting
[06:38] <Fujitsu> Have you activated it yet? I can't see it, though LP might be hiding it from me because it has no uploads.
[06:43] <poolie> woot
[06:43] <poolie> https://edge.launchpad.net/~bzr/+archive
[06:50] <poolie> so to get a package built for multiple ubuntu versions
[06:50] <poolie> do i need to upload several times?
[07:00] <Fujitsu> poolie: Correct. With different version numbers.
[07:00] <Fujitsu> Appending ~gutsy1, ~feisty1, etc. is the norm.
[07:01] <poolie> lifeless says those should be omitted
[07:01] <Fujitsu> I say they shouldn't be.
[07:01] <Fujitsu> The packages share the same pool, so the versions must be different.
[07:03] <Fujitsu> Also, why is it a native package?
[07:05] <poolie> it's not, or at least it's not meant to be ?
[07:05] <lifeless> shouldn't be
[07:05] <lifeless> oh, if PPA has one pool then yes you need different qualifiers.
[07:05] <lifeless> Yet another reason not to use PPA :(. I hope they get this fixed soon.
[07:06] <Fujitsu> It is, but shouldn't be. You need the .orig.tar.gz in the parent directory, and to have a hyphen somewhere in the version.
[07:06] <Fujitsu> This is intended behaviour.
[07:06] <Fujitsu> I wouldn't call it a bug.
[07:06] <lifeless> Fujitsu: thats ok, I'll do that.
[07:06] <Fujitsu> Allowing the same version in multiple distroseries is evil.
[07:06] <Fujitsu> (unless they're inherited from lower ones)
[07:06] <poolie> oh, i see, it's the missing hyphen
[07:07] <poolie> so what would be a better name? 1.0-1bazaar1?
[07:07] <Fujitsu> 1.0-1~bazaar1
[07:07] <poolie> ok
[07:07] <lifeless> Fujitsu: if you have distro contents files it's functional but ugly to require the person requesting the build to manage the set of target distros. Bad UI.
[07:08] <lifeless> poolie: if you are reusing my packaging you want 1.0-1~bazaar1~gutsy1
[07:08] <lifeless> erm
[07:08] <Fujitsu> lifeless: Different distros have different build environments. There's no other way to do it.
[07:08] <lifeless> 1.0-1~bazaar1gutsy1
[07:08] <lifeless> etc
[07:08]  * Fujitsu would use ~bazaar1~gutsy1
[07:08] <poolie> 1.0-1~bazaar1-gutsy1
[07:08] <lifeless> Fujitsu: Consider it a challenge not something to lay down the law on
[07:08] <lifeless> poolie: no -
[07:09] <lifeless> Fujitsu: gutsy isn't before baazaar. only one ~
[07:09] <poolie> because the digits implicitly separate parts
[07:09] <poolie> ?
[07:09] <Fujitsu> lifeless: I would normally upload 1.0-1~bazaar1 to Hardy, then 1.0-1~bazaar1~gutsy1 to Gutsy, etc.
[07:09] <Fujitsu> It's how backports are done, and consistency is good.
[07:10] <lifeless> poolie: also, I wouldn't suggest sorting below debian/ubuntu builds
[07:10] <lifeless> poolie: because you're wanting to override, not underride
[07:10]  * Fujitsu would definitely advise sorting below them.
[07:10] <lifeless> Fujitsu: is today your 'disagree with everything' day?
[07:10] <Fujitsu> Isn't the purpose to just backport 1.0 to previous releases?
[07:10] <lifeless> no
[07:10] <lifeless> or at least it hasn't been for the last X period.
[07:10] <lifeless> sigh, I've been sucked into work.
[07:11] <lifeless> BYE
[07:11] <poolie> i want to be above eg 0.91, but below the "official" 1.0
[07:11] <poolie> bye!
[07:11] <Fujitsu> That's what I thought you were trying to do, right.
[07:13] <Fujitsu> So 1.0-1~bazaar1~gutsy1, with the use of the second tilde being debatable.
[07:25] <ubotu> New bug: #177087 in soyuz "+archive has headings mixed up" [Undecided,New] https://launchpad.net/bugs/177087
[07:26] <jamesh> Fujitsu: is there any reason for using Ubuntu release codenames rather than version numbers?
[07:27] <jamesh> Fujitsu: since that makes 1.0-1~bazaar1~gutsy1 older than 1.0-1~bazaar1~warty1, which seems wrong
[07:28] <jamesh> (not that people are going to be building new warty packages, but the point still stands)
[07:37] <poolie> otoh that's a good reason for ubuntu to stick to alpha numbers
[07:37] <poolie> leaving open the issue of what happens after the zesty zebra
[08:56] <peepo> anyone about?
[08:56] <peepo> I filed various inkscape bugs as "peepo"
[08:56] <peepo> but launchpad doesn't recognise my email address
[08:57] <peepo> is that 'normal'
[08:57] <peepo> ie do I need separate accounts, to file and review bugs?
[09:00] <peepo> hello?
[09:00] <peepo> there's no wfm so what's next best?
[09:00] <BjornT> peepo: you have to activate your account in launchpad
[09:00] <BjornT> peepo: if you go to https://edge.launchpad.net/~peepo/, you'll see there's a "Hey, I'm Peepo" link
[09:00] <peepo> later
[09:00] <peepo> https://bugs.launchpad.net/inkscape/+bug/165804
[09:00] <ubotu> Launchpad bug 165804 in inkscape "GTK-quartzvm detached toolbar stay on top even when inactive" [Low,Incomplete]  - Assigned to Mjwybrow (mjwybrow)
[09:40] <ubotu> New bug: #177108 in malone "Bug pages do not show project/distro logo any more" [Undecided,New] https://launchpad.net/bugs/177108
[10:30] <Fujitsu> jamesh: I didn't define the standard. It has been used by backports for a number of years. Besides, releases are in alphabetical order since Breezy, and will remain so.
[10:30] <jamesh> Fujitsu: ... until Z
[10:31] <jamesh> as poolie said
[10:31] <Fujitsu> jamesh: True. Which is a while off.
[10:32] <jamesh> Fujitsu: it seems stupid to rely on a convention that will eventually break, and we haven't even consistently followed in the past
[10:32] <Fujitsu> Right. (though it's not so much not following it as it didn't exist)
[10:32] <jamesh> especially when there is an alternative that has been consistently followed and won't break (i.e. that Ubuntu's version number will always increase)
[10:32] <Fujitsu> I'm not sure why version numbers aren't used, and it seems strange not to.
[10:32] <Fujitsu> Right.
[10:41] <ubotu> New bug: #177119 in malone "checkwatches fails trying to updated a conjoined bugtask" [High,Confirmed] https://launchpad.net/bugs/177119
[10:41]  * Fujitsu wonders where one would have a conjoined task with a watch.
[10:42] <Fujitsu> Ah, so it shouldn't be allowed. I see.
[10:46] <kiko> yeah, it's a bug
[10:46] <kiko> as usual :)
[11:20] <ubotu> New bug: #177125 in malone "update-manager crashes" [Undecided,New] https://launchpad.net/bugs/177125
[11:35] <ubotu> New bug: #177131 in launchpad "No way to delete or remove a release" [Undecided,New] https://launchpad.net/bugs/177131
[11:36] <frenchy> Re 177131: Oh, I hear that!
[11:39] <frenchy> Why don't we show a list of current bugs when we click on the bugs tab?  It seems inconsistent with the rest of the site.
[11:40]  * Fujitsu likes the way sourcepackages work (ie. like that, without the graph etc.)
[12:02] <frenchy> Don't get me wrong, I like the graph, it could go above "Key contacts".
[12:02]  * Fujitsu thought the graph was going away soon anyway.
[13:05] <Hobbsee> kiko: ping
[13:07] <mtaylor> funny, I was just going to also say kiko: ping
[13:08] <kiko> mtaylor, Hobbsee: oink
[13:09] <Hobbsee> kiko: would have thoguht that with using ppa as a component name...commercial partners may not like it, for the private repositories.
[13:09] <Hobbsee> no idea how public you wan't that
[13:10] <Hobbsee> (or discussions about it)
[13:22] <mtaylor> kiko, Hobbsee: ppa in the component name doesn't bother me so much...
[13:22] <kiko> me neither
[13:22] <mtaylor> could also stand for "private package archive" :)
[13:22] <kiko> nor do I think it'd bother commercial partners
[13:22] <kiko> but we'll need to investigate that further
[13:22] <kiko> it has some unwanted soyuz consequences
[13:23] <mtaylor> kiko: so did the things in that other mail all sound doable?
[13:23] <mtaylor> and/or make sense?
[13:23] <kiko> mtaylor, the one with a large number of concerns?
[13:23] <mtaylor> yes
[13:23] <kiko> I didn't read that one :) I just read the reply
[13:23] <mtaylor> hehe
[13:23] <mtaylor> it's too long
[13:23] <mtaylor> I think I started to ramble
[13:23] <kiko> yeah. but somebody else should read it -- bigjools or cprov-out
[13:23] <kiko> and if not holler
[13:24] <mtaylor> kiko: statik told me I should get you to comment on it
[13:24] <mtaylor> kiko: wait. perhaps we're talking about different mails
[13:26]  * Hobbsee notes that the docs could really do with a rewrite, now that the target audience has changed.
[13:27] <mtaylor> kiko: I was talking about the email in the "Re: Monty in Brazil and PPAs" thread
[13:28] <Hobbsee> mtaylor: oh, that one.
[13:29] <kiko> mtaylor, oh! I think that's all doable
[13:29] <mtaylor> kiko: ok - great! :)
[13:29] <kiko> we are talking about different emails.
[13:30] <mtaylor> it started to seem that way
[13:30] <kiko> it does require some rather minor engineering work on our end -- the debian import in particular
[13:30] <kiko> but we have wanted to do that anyway, so having some pressure on it would be good.
[13:30] <mtaylor> glad I can help, then
[13:31] <mtaylor> anything else you'd like me to add to the list of things we need?
[13:31] <kiko> hah! not right now -- this has been a busy december as it is
[13:32] <mtaylor> good. well I'm going to chat this week with statik and the businessy folks on my side hopefully and see what we can get worked out
[13:32] <Hobbsee> FWIW, i gave mrevell a list of questions that would be good to answer in a ppa faw
[13:32] <kiko> mtaylor, okay, am very much looking forward to that.
[13:32] <Hobbsee> er, faq
[13:32] <Hobbsee> no idea if you guys will find it useful.
[13:32] <kiko> Hobbsee, you did? I'll see that julian and cprov look at it and make it happen
[13:33] <Hobbsee> kiko: cool, although i suspect it'll be mroe useful for someone to write who *doesn't* know soyuz inside out, and who is more of a new person looking in
[13:34] <bigjools> well give me a chance to do it and then you can decide that
[13:34] <Hobbsee> bigjools: by all means.
[13:35] <bigjools> cool
[13:35] <Hobbsee> bigjools: http://rafb.net/p/9eO3Kc15.html was the list.
[13:35]  * Hobbsee can email it, etc
[13:35] <bigjools> I got it, thanks
[13:36] <kiko> good ole rafb
[13:37] <Hobbsee> looks like there's the ppa documentation thread with a few more bits in it, too
[14:00] <ubotu> New bug: #177162 in loggerhead "codebrowse doesn't show content of added files on revision page" [Undecided,New] https://launchpad.net/bugs/177162
[15:13] <MvG> Hi! There is a bug in the inkscape bug database on launchpad, which was written by me ages ago. However the system doesn't seem to have an account for me, at least for any of the mail addresses I usually use. Were the inkscape bugs migrated from somewhere else? If so, what happened to accounts?
[15:15] <ubotu> New bug: #177167 in launchpad "Incorrect email subject when user joins an open team" [Undecided,New] https://launchpad.net/bugs/177167
[15:23] <radix> MvG: I suggest reading the paragraph at https://edge.launchpad.net/people and probably clicking the link in it
[15:23] <radix> hmm, actually
[15:23] <radix> if you don't already have another account...
[15:23] <radix> there's probably a way to claim an account without creating a separate one
[15:24] <radix> MvG: actually, I bet if you try to register with the email address that they already have for you it'll ask if you want to claim the account
[15:25] <MvG> radix: OK, I had a closer look at the last mail I got from the system, and found it was sent to my sourceforge mail address. With that I could claim the account. Thanks.
[15:26] <radix> MvG: I'm not a LP dev, so these are mostly guesses :)
[16:23] <MattCampbell> If I initially pushed a branch to LP using bzr+ssh using bzr 1.0rc3, is there any risk of braking it if I then bind to it using sftp, again running bzr 1.0rc3, and commit that way?
[16:23] <MattCampbell> keeping in mind that LP is running bzr 0.92
[16:37] <MattCampbell> It should be documented somewhere that bzr 1.0 users need to use sftp, not bzr+ssh, to commit to bzr branches at LP.
[16:38] <mwhudson> launchpad will be running 1.0 by, uh, tomorrow i think
[16:38] <MattCampbell> Cool, thanks.
[16:38] <MattCampbell> the joys of being an early adopter :)
[16:41] <mwhudson> yar
[16:55] <ubotu> New bug: #177188 in malone "+editstatus doe not check that the bug was converted into a question" [High,In progress] https://launchpad.net/bugs/177188
[18:14] <jonasbjork> hi ppl!
[18:14] <jonasbjork> i am trying to import a cvs-repo into launchpad
[18:14] <jonasbjork> no sucess at all
[18:14] <jonasbjork> cvs-repo: :pserver:anonymous@cvs.fritis.berlios.de:/cvsroot/fritis
[18:15] <mwhudson> jonasbjork: what project/series?
[18:15] <mwhudson> jonasbjork: oh, https://edge.launchpad.net/pyrisk/java-deprecated right?
[18:15] <jonasbjork> mwhudson: no?
[18:16] <mwhudson> oops
[18:16] <jonasbjork> or, well that seems to be kind of what i want
[18:16] <jonasbjork> but for another project ;)
[18:16] <mwhudson> pretend i didn't mention that project
[18:16] <mwhudson> jonasbjork: which?
[18:16] <jonasbjork> that you linked to
[18:16] <mwhudson> jonasbjork: i am a vcs-imports operator
[18:16] <jonasbjork> seems to be a cvs imported project
[18:16] <mwhudson> jonasbjork: tell me which project you are trying to set up an import for
[18:16] <jonasbjork> cvs-repo: :pserver:anonymous@cvs.fritis.berlios.de:/cvsroot/fritis
[18:17] <jonasbjork> my launchpad project is "Fritis"
[18:18] <mwhudson> jonasbjork: you need to enter the details on https://edge.launchpad.net/fritis/trunk/+source
[18:19] <jonasbjork> ok found it
[18:20] <jonasbjork> may i ask, can i import the cvs-code and start use bazaar instead of berlios-cvs?
[18:21] <kiko-phone> yes!
[18:22] <mwhudson> jonasbjork: that's the idea :)
[18:23] <jonasbjork> as far as i understand my project will be mirrored from berlios
[18:23] <mwhudson> yes
[18:23] <jonasbjork> but launchpad makes an own repository for it and i can work with that?
[18:23] <jonasbjork> i'm a total newbie at this as you might understand ;)
[18:24] <mwhudson> what you say is true, though not necessarily a helpful way of saying things
[18:24] <mwhudson> jonasbjork: have you used bazaar at all?
[18:24] <jonasbjork> mwhudson: nope, i'm a cvs/svn guy
[18:25] <jonasbjork> read some tutorial that explained how to use bazaar
[18:25] <jonasbjork> bzr command that is
[18:25] <mwhudson> so yes, launchpad makes its own repository containing a mirror of the cvs repository
[18:26] <mwhudson> then you will get a copy of this repository and can commit to it, pull in changes from the cvs mirror, push it to launchpad etc
[18:26] <mwhudson> so you use launchpad's repository as a data source, but you won't be writing to it
[18:27] <jonasbjork> ok, so i still commit to cvs.berlios.de ?
[18:27] <mwhudson> uh
[18:27] <mwhudson> maybe
[18:27] <mwhudson> depends what you're trying to achieve
[18:27] <radix> you *can* still commit to the CVS server, and the launchpad mirror will be updated regularly
[18:28] <radix> or, you can make branches from the LP mirror and use bzr to do your work.
[18:28] <kiko-phone> if you want to migrate and then abandon berlios
[18:28] <kiko-phone> then mwhudson can help you more. :)
[18:28] <jonasbjork> but i should start using my bazaar repo when it is imported from cvs?
[18:28] <jonasbjork> ok, think i get it now
[18:29] <jonasbjork> i'll just wait for my repo to be imported and try then
[18:30] <mwhudson> jonasbjork: i've started the import
[18:30] <mwhudson> it can take anything from a few minutes to several days
[18:30] <jonasbjork> ok
[18:30] <jonasbjork> Import status:  Processing
[18:30] <jonasbjork> it changed ! :)
[18:30] <jonasbjork> mwhudson: thanks for your help
[18:30] <mwhudson> jonasbjork: np
[19:04] <bdmurray> I'm looking at the upstream watch for bug 84603 and it seems to be out of sync
[19:04] <ubotu> Launchpad bug 84603 in linux "Hard disk I/O randomly freezes when hald is running and optical drive is empty" [Unknown,Confirmed] https://launchpad.net/bugs/84603
[19:05] <bdmurray> Any malone people around?
[19:42] <mwhudson> jonasbjork: your import is failing in a mysterious (to me) way
[19:43] <mwhudson> jonasbjork: i'll have to look at it tomorrow
[19:51] <ubotu> New bug: #177230 in malone "upstream bug watch for bug 84603 is incorrect" [Undecided,New] https://launchpad.net/bugs/177230
[19:51] <ubotu> New bug: #177232 in malone "linux-source-2.6.24 package shouldn't allow bug reports" [Undecided,New] https://launchpad.net/bugs/177232
[19:53] <jonasbjork> mwhudson: ok, thanks for beeing helpful
[20:39] <JordanC> Hey folks
[20:39] <JordanC> Anyone else have any troubles with clearsigning the Ubuntu CoC
[20:39] <JordanC> I did it, but when I paste the file contacts there are errors
[20:40] <JordanC> (7, 9, 'No public key')
[20:40] <ubotu> New bug: #177241 in launchpad "It's difficult to tell that your application for official mirror status was declined" [Undecided,New] https://launchpad.net/bugs/177241
[22:18] <soren> JordanC: Did you upload your key first?
[22:18] <soren> #launchpad - where all your patience are belong to us
[22:19] <JordanC> It's done now
[22:19] <soren> JordanC: Oh, cool.
[22:19] <JordanC> oh
[22:19] <JordanC> No it's not
[22:19] <JordanC> :/
[22:29] <poolie> does anyone know if there's a limit on the size of release download files?
[22:42] <Rinchen> bac, ^^
[23:15] <poolie> Rinchen, fyi, Szilveszter did successfully upload his 30MB mac installer
[23:15] <poolie> but when john tried, he got a 400 error
[23:15] <Rinchen> interesting
[23:15] <poolie> which hopefully turned into an oops
[23:16] <poolie> maybe it'd be good to have either a faq or display in the upload dialog about the limit, if any
[23:16] <JordanC|Code> Hey sexy launchpadders
[23:17] <bac> poolie: the upload limit is 30Mb
[23:17] <Rinchen> I knew bac is faster than grep ;-)
[23:17] <poolie> heh
[23:18] <poolie> bac, Rinchen, it's a nice feature btw
[23:18] <Rinchen> I'm still greping to find the answer :-)
[23:18] <bac> Rinchen: you're just lucky.  i only woke up 2 minutes ago
[23:18] <Rinchen> bac where do we set that limit? hardcode, config, or zope-thing?
[23:18] <bac> bac@sapa:~/canonical/lp-branches/feeds-branches/configs/default$ grep size launchpad.conf
[23:18] <Rinchen> ah thanks
[23:19] <bac>  max_productrelease_file_size 31457280
[23:19] <Rinchen> well, that's why I don't see it.. I don't have feeds-branches, only trunk
[23:20] <poolie> it looks like we just scraped under this time
[23:20] <bac> Rinchen: no, no...it's been in trunk for ages
[23:20] <poolie> there are open source releases which are larger...
[23:20] <bac> that's just the branch i was sitting in
[23:20] <Rinchen> ah..ok, I'll keep looking. my interest is piqued
[23:21] <bac> poolie:  we can bump that up.  the survey i did at the time seemed to indicate 30Mb was a good limit.  i think we based it off the openoffice installer size
[23:21] <poolie> this one is kind of surprisingly large
[23:21] <poolie> but the convention for mac stuff is to ship all the dependencies in one blob
[23:22] <poolie> so it's big
[23:22] <bac> poolie:  ah, ok.  mac stuff we didn't take into account
[23:22] <bac> poolie:  want to throw out a number?
[23:23] <Rinchen> bac, ok, I found it ...and also realized the pain of the config system in the process
[23:23] <poolie> i'd say, take the largest example you've heard of and double it
[23:23] <poolie> so, 60MB?
[23:24] <poolie> is anything going to break if it gets larger?
[23:24] <poolie> i see there's some potential for abuse, whatever the size
[23:24] <bac> poolie: i assume nothing would break but that hasn't been tested yet...
[23:24] <Rinchen> bac, db timeouts?
[23:25] <bac> Rinchen: doubtful.  the blob is stored on the file system with only references to it in the db, as done by the librarian
[23:25] <Rinchen> ah, nifty