[00:12] -queuebot:#ubuntu-release- New binary: pytorch [amd64] (jammy-proposed/universe) [1.8.1-3] (no packageset)
[00:24] -queuebot:#ubuntu-release- New binary: pytorch [ppc64el] (jammy-proposed/universe) [1.8.1-3] (no packageset)
[02:35] -queuebot:#ubuntu-release- New binary: pytorch [arm64] (jammy-proposed/universe) [1.8.1-3] (no packageset)
[05:08] -queuebot:#ubuntu-release- New sync: oem-somerville-charmander-meta (focal-proposed/primary) [20.04~ubuntu1]
[05:09] -queuebot:#ubuntu-release- New sync: oem-somerville-pidgeot-meta (focal-proposed/primary) [20.04~ubuntu1]
[05:10] -queuebot:#ubuntu-release- New sync: oem-somerville-pidgeot-14-meta (focal-proposed/primary) [20.04~ubuntu1]
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-charmander-meta to canonical-oem-metapackages in bionic
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-pidgeot-14-meta to canonical-oem-metapackages in bionic
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-pidgeot-meta to canonical-oem-metapackages in bionic
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-charmander-meta to canonical-oem-metapackages in focal
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-pidgeot-14-meta to canonical-oem-metapackages in focal
[05:16] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-pidgeot-meta to canonical-oem-metapackages in focal
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-kakuna-meta to canonical-oem-metapackages in bionic
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-sutton.newell-caesar-meta to canonical-oem-metapackages in bionic
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-sutton.simon-carlisle-meta to canonical-oem-metapackages in bionic
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-somerville-kakuna-meta to canonical-oem-metapackages in focal
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-sutton.newell-caesar-meta to canonical-oem-metapackages in focal
[05:46] -queuebot:#ubuntu-release- Packageset: Added oem-sutton.simon-carlisle-meta to canonical-oem-metapackages in focal
[05:52] -queuebot:#ubuntu-release- New sync: oem-somerville-kakuna-meta (focal-proposed/primary) [20.04~ubuntu1]
[08:03] <LocutusOfBorg> doko_, -queuebot:#ubuntu-release- New: rejected djbdns [sync] (jammy-proposed) [1:1.05-15]
[08:04] <LocutusOfBorg> was that a mistake?
[08:04] <LocutusOfBorg> I can't find reasons for the reject and the queue logs says "accepted by doko"
[08:19] <LocutusOfBorg> hello ubuntu-archive, with the new syncs from Debian, we can finally drop sources for (binaries are already taken over by the syncs) src:dwarves-dfsg src:libfli1 src:hvac
[08:41] -queuebot:#ubuntu-release- New: accepted fonts-homecomputer [amd64] (jammy-proposed) [1.0-1]
[08:41] -queuebot:#ubuntu-release- New: accepted pytorch [arm64] (jammy-proposed) [1.8.1-3]
[08:41] -queuebot:#ubuntu-release- New: accepted ruby-gitlab-license-finder [amd64] (jammy-proposed) [<IP_ADDRESS>-1]
[08:41] -queuebot:#ubuntu-release- New: accepted ruby-memo-wise [amd64] (jammy-proposed) [1.5.0+dfsg-1]
[08:41] -queuebot:#ubuntu-release- New: accepted pytorch [amd64] (jammy-proposed) [1.8.1-3]
[08:41] -queuebot:#ubuntu-release- New: accepted ruby-gitlab-license-finder [amd64] (jammy-proposed) [<IP_ADDRESS>-2]
[08:41] -queuebot:#ubuntu-release- New: accepted pytorch [ppc64el] (jammy-proposed) [1.8.1-3]
[14:33] <xnox> apw:  please remove libzpool4linux binary on all arches, from jammy-proposed (because it moved to libzpool5linux)
[14:33] <xnox> it is jammy-proposed only NBS
[15:25] <ricotz> hello, could someone retry the failed llvm13 build please? https://launchpad.net/ubuntu/+source/llvm-toolchain-13/1:13.0.1~+rc3-1~exp1
[15:26] <schopin> ricotz: on it.
[15:26] <schopin> Dang. It made Firefox crash? oO
[15:27] <ricotz> oh, firefox 96.0 or 96.0.2?
[15:27] <schopin> the about window only tells me 96.0
[15:28] <schopin> I'm on impish, I believe FF is a snap
[15:28] <ricotz> I see, the 96.0.2 update needs to be processed https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages
[15:29] <ricotz> the snap was updated afaics
[15:29] <ricotz> "processed" as in binary copied by the security team
[15:29] <apw> xnox, done
[15:29] <schopin> I think the crash occured with the 96.0 but the snap was refreshed at the time of the crash.
[15:30] <ricotz> schopin, thanks for restarting the builds
[15:30] <ricotz> schopin, I see, I think this is known problem
[15:35] -queuebot:#ubuntu-release- Unapproved: neutron (impish-proposed/main) [2:19.1.0-0ubuntu1 => 2:19.1.0-0ubuntu2] (openstack)
[15:48] <LocutusOfBorg> why is everything on "ubuntu software" listed as "proprietary" license?
[15:48] <LocutusOfBorg> I checked emacs -> proprietary, hedgewars -> proprietary
[15:48] <LocutusOfBorg> only snaps are listead as free
[15:48] <ogra> bug ?
[15:49] <LocutusOfBorg> is this happening on your system too?
[15:49] <LocutusOfBorg> I can reproduce on 20.04
[15:52] <LocutusOfBorg> https://bugs.launchpad.net/snap-store-desktop/+bug/1878924
[16:15] <LocutusOfBorg> looks like a serious political bug
[16:21] <vorlon> LocutusOfBorg: sounds like a serious bug, but also probably not a matter for the release team (or SRU team) per se to fix; have you talked to the Desktop Team?
[16:22] <LocutusOfBorg> moving to #ubuntu-desktop
[17:36] -queuebot:#ubuntu-release- New binary: openmm [amd64] (jammy-proposed/universe) [7.7.0+dfsg-3] (no packageset)
[17:39] <enyc> https://gitlab.com/kalilinux/documentation/kali-docs/-/issues/87
[17:39] <enyc> oops
[17:42] -queuebot:#ubuntu-release- New binary: openmm [ppc64el] (jammy-proposed/universe) [7.7.0+dfsg-3] (no packageset)
[17:57] <bryceh> ubuntu-archive, could someone add a hint for php8.0 to remove it from php-default's blocker list?
[17:57] <bryceh> https://code.launchpad.net/~bryce/britney/+git/britney/+merge/414327
[18:09] <vorlon> bryceh: sorry for the delays on this, I know I had asked questions last week and then dropped the ball on your answers due to my capacity. I need to dig back through the chat history and I'll review today and get this addressed
[18:17] <bryceh> vorlon, don't worry about digging back through past discussions, things have moved on.  One item I was able to work around myself.   The other thing you had a question about actually has become a bigger problem (circular dependency with symfony/doctrine) than just a bad test.
[18:17] <bryceh> vorlon, the php8.0 blocker is simple and an easy fix to get it off the list
[18:18] <bryceh> the symfony/docker circular dependency we need AA assistance on since several packages need versions pulled.  The good news is I think that's the last major issue before php8.1 can transition (knock on wood)
[18:21] <bryceh> utkarsh mentioned this in his +1 maintenance updated and I think had plans to follow up with lucasz
[18:28] -queuebot:#ubuntu-release- New binary: openmm [arm64] (jammy-proposed/universe) [7.7.0+dfsg-3] (no packageset)
[18:36] <bdmurray> sil2100: Could you look at releasing ubiquity for Focal?
[18:49] -queuebot:#ubuntu-release- New binary: cmark-gfm [amd64] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[18:49] -queuebot:#ubuntu-release- New binary: cmark-gfm [s390x] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[18:49] -queuebot:#ubuntu-release- New binary: cmark-gfm [ppc64el] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[18:50] -queuebot:#ubuntu-release- New binary: cmark-gfm [arm64] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[18:51] -queuebot:#ubuntu-release- New binary: cmark-gfm [armhf] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[19:09] -queuebot:#ubuntu-release- New binary: cmark-gfm [riscv64] (jammy-proposed/universe) [0.29.0.gfm.2-2] (no packageset)
[19:59] <vorlon> bryceh: fair enough, merging!
[20:04] -queuebot:#ubuntu-release- Unapproved: neutron (impish-proposed/main) [2:19.1.0-0ubuntu1 => 2:19.1.0-0ubuntu2] (openstack)
[20:05] <coreycb> hello sru team, I've uploaded a new version of neutron to the impish unapproved queue that fixes a regression in a recent SRU. the most recent upload in the queue has a .changes file that includes the current version in impish-proposed. the other one in the queue can be rejected.
[20:06] <bdmurray> coreycb: is the regression being fixed in -updates or -proposed i.e. is it important to get this reviewed right away?
[20:07] <coreycb> bdmurray: the regression is already in updates
[20:07] <coreycb> bdmurray: there is a work-around but sooner is better
[20:09] <bdmurray> Okay, I'll have a look.
[20:09] -queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (impish-proposed) [2:19.1.0-0ubuntu2]
[20:14] <coreycb> bdmurray: thank you
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (impish-proposed) [2:19.1.0-0ubuntu2]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [riscv64] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [amd64] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [armhf] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [s390x] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted openmm [arm64] (jammy-proposed) [7.7.0+dfsg-3]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [arm64] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted openmm [amd64] (jammy-proposed) [7.7.0+dfsg-3]
[20:15] -queuebot:#ubuntu-release- New: accepted cmark-gfm [ppc64el] (jammy-proposed) [0.29.0.gfm.2-2]
[20:15] -queuebot:#ubuntu-release- New: accepted openmm [ppc64el] (jammy-proposed) [7.7.0+dfsg-3]
[20:17] <bryceh> vorlon, thanks
[20:26] <vorlon> apw: heya, crda is listed as a kernel team package, it's seeded, and Debian has just removed it as 'obsolete'; do you know if we should be following suit?
[20:28] <apw> vorlon, i don't know definatively.  cirtainly right now, that would cause chaos because we continue to depend on it, but perhaps incorrectly
[20:28] <vorlon> apw: where would you like me to open a bug for tracking?
[20:29] <apw> vorlon, i think linux; i am assuming (without checking) that the kernel does this itself.
[20:30] <apw> vorlon, indeed their ROM says "due to kernel changes"
[20:30] <vorlon> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1958918
[20:31] <apw> vorlon, ta
[20:35] <sergiodj> bdmurray: heya.  are you planning to work on https://bugs.launchpad.net/ubuntu/+source/pyyaml/+bug/1958720 perhaps?
[20:36] <bdmurray> sergiodj: I tagged it so the Foundations team can discuss it at our weekly meeting.
[20:37] <sergiodj> bdmurray: ACK.  it showed up in my triaged today, so I just wanted to check that it's being monitored.  thanks
[20:37] <sergiodj> s/triaged/triage/
[20:54] <vorlon> bdmurray, waveform, jawn-smith: ^^ per the above, it looks like the crda package is going away; given there have been conversations about default wireless reg domains before particularly in the context of rpi, I guess folks should at least be aware that this package is obsolete
[20:55] <waveform> vorlon, wow ... guess I better read up on what the replacement is
[20:55] <vorlon> waveform: 'the in-kernel firmware interface'
[20:56] <waveform> yes, but more specifically "how that gets configured" (and whether our intentions with netplan/cloud-init for inclusion of configuration of this are affected)
[20:56] <vorlon> yep
[22:19] -queuebot:#ubuntu-release- New: accepted lib2geom [source] (focal-backports) [1.1-2~bpo20.04.1]
[22:34] -queuebot:#ubuntu-release- New binary: lib2geom [amd64] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)
[22:34] -queuebot:#ubuntu-release- New binary: lib2geom [s390x] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)
[22:34] -queuebot:#ubuntu-release- New binary: lib2geom [ppc64el] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)
[22:39] -queuebot:#ubuntu-release- New binary: lib2geom [armhf] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)
[22:39] -queuebot:#ubuntu-release- New binary: lib2geom [arm64] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: qdmr [amd64] (jammy-proposed/none) [0.10.1-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: qdmr [ppc64el] (jammy-proposed/none) [0.10.1-1] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: epics-base [amd64] (jammy-proposed/none) [<IP_ADDRESS>-2] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: qdmr [armhf] (jammy-proposed/universe) [0.10.1-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: qdmr [arm64] (jammy-proposed/universe) [0.10.1-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: lib2geom [riscv64] (focal-backports/universe) [1.1-2~bpo20.04.1] (no packageset)


[16:33] <tsimonq2> wxl: chrisccoulson broke Firefox on Lubuntu 16.04 :P
[16:33] <tsimonq2> wxl: Subscribed Lubuntu Packages Team to bug 1671273
[16:33] <wxl> no one's maintaining alsa?
[16:35] <tsimonq2> wxl: Don't get me started. YOU, sir, have said MANY times that Pulseaudio sucks, go ALSA... :P :P :P
[16:35] <tsimonq2> wxl: And not in upstream Firefox, no
[16:35] <wxl> tsimonq2: that's beside the point. i'm disagreeing with the wording that it's not maintained.
[16:35] <wxl> oh i see support in firefox is unmaintained
[16:35] <wxl> ah well
[16:35] <tsimonq2> wxl: Maybe Alsa is still maintained, but not in Firefox anymore
[16:35] <tsimonq2> Yeah
[16:35] <wxl> itme to switch browsers
[16:35] <tsimonq2> Bah bah bah
[16:35] <tsimonq2> No no no
[16:36] <tsimonq2> Make pulseaudio a hard dep :P
[16:36] <wxl> you'd rather have a crap load of pulse additions than keep the footprint small?
[16:36] <wxl> i can't say i agree
[16:36] <wxl> i'd put that up for discussion on the mailing list
[16:37] <tsimonq2> wxl: I will.
[16:37] <wxl> we CAN still do chrom*IUM* on i386
[16:37] <wxl> really though i'd also consider figuring out a solution to not using recommends
[16:38] <wxl> it's really a difficult to sustain policy
[18:12] <tsimonq2> wxl: So I think this whole ALSA thing makes one thing clear
[18:12] <wxl> ?
[18:13] <tsimonq2> wxl: We should really pay someone with the technical ability to poke around in Firefox and know what they are doing to help maintain ALSA
[18:13] <tsimonq2> wxl: And for that we need donations.
[18:13] <tsimonq2> wxl: Status update?
[18:14] <tsimonq2> wxl: (or in general be able to throw money at things so that they can be maintained)
[18:14] <wxl> oh man that's still a ways away
[18:14] <tsimonq2> wxl: How far away?
[18:15] <wxl> months, years
[18:15] <tsimonq2> Aghhhhhhhhhh
[18:17] <tsimonq2> wxl: What are you waiting on?
[18:17] <wxl> tsimonq2: legal help
[18:17] <wxl> unless you have money to pay for it
[18:17] <tsimonq2> No I don't
[18:17] <wxl> well there you go
[18:17] <wxl> wait
[18:17] <tsimonq2> wxl: Like a FSF lawyer or something like that?
[18:18] <wxl> https://www.softwarefreedom.org/
[19:21] <lynorian>  bug 1675127 looks really nasty
[19:23] <tsimonq2> lynorian: Can you confirm it?
[19:23] <lynorian> I reported it
[19:23] <tsimonq2> Oh :P
[19:24] <tsimonq2> wxl: Thoughts? ^^^^^^^^^^^^^^^
[19:25] <lynorian> this might be hardware specific to a wierd setup should I try to install with no network first
[19:28] <wxl> tsimonq2: i'd suggest trying to reproduce it again
[19:29] <lynorian> I did try to reproduce it again and was able to before I even reported it with the exact same setup
[19:30] <wxl> ok so it' snot a fluke
[19:31] <wxl> and we know that we can't reproduce it with older versions, right?
[19:31] <lynorian> I have not tried in a bit on that hardware in that setup with usb wifi
[19:31] <lynorian> I have for like 16.04 or 16.10 but not recent dailies
[19:31] <wxl> try alpha 2
[19:32] <lynorian> ok
[19:32] <lynorian> not beta 1?
[19:32] <wxl> well
[19:32] <wxl> should be the same i imagine
[19:32] <wxl> this failed on 17.04.7
[19:33] <wxl> alpha 2 is 17.04.4
[19:33] <wxl> beta 1 is also 17.04.7
[19:33] <lynorian> ah version of ubiquity now I get it
[19:34] <wxl> same with daily
[19:34] <wxl> so i can assume beta 2 is also 17.04.7
[19:35] <lynorian> wxl yes my bug report shows that
[19:38] <wxl> lynorian: this occured when trying to connect to wireless, right? no problem otherwise?
[19:38] <lynorian> yes I could not see if there were other problems
[19:38] <lynorian> as it crashed ubiquity entirely
[19:38] <wxl> did you try with ethernet only to confirm you did not have the problem if wifi wasn't being employed?
[19:39] <lynorian> not quite yet
[19:39] <wxl> let's double check that
[19:39] <wxl> looks like an update of netcfg happened in 17.0.3 http://changelogs.ubuntu.com/changelogs/pool/main/u/ubiquity/ubiquity_17.04.7/changelog
[19:40] <lynorian> wxl I was able to connect to internet with the cable to report the bug
[19:41] <wxl> and unfortunately, we don't really have an iso with 16.10.14<version<17.04.4
[19:41] <wxl> yes but it would be good to know that it doesn't happen at all, just to be extra sure
[19:42] <wxl> if we can confirm it is indeed with wireless, then i'd ensure that it also happens with other flavors, especially ubuntu proper
[19:42] <lynorian> wxl got to partitioning at least
[19:42] <wxl> and if it fails there, then we can sound the alarm all around the world :)
[19:43] <wxl> is there a way to have virtualbox directly access the wifi card?
[19:44] <lynorian> wxl not on this box with amd=64 no vtx
[19:44] <lynorian> hence why I built my awesome hypervisor
[19:44] <wxl> well i was thinking of a testcase we may be able to build to allow a wider range of users to do things
[19:44] <lynorian> I have not done much to get physical passthrough working
[19:45] <lynorian> I know this desktop supports it probably just have not done it
[19:45] <wxl> well actually
[19:46] <wxl> this happens early.. before the actual partitioning
[19:46] <wxl> so anyone should be able to run it on any machine without affecting their existing install
[19:46] <lynorian> wxl yep
[19:46] <wxl> that said, i'll try to do something tonight
[19:46] <wxl> but tsimonq2 could help too :)
[19:46] <lynorian> I have another laptop I could try but argh did I not charge that
[19:47] <lynorian> it has one quite bad wifi card that I hate but I could use the same usb one
[19:51] <lynorian> wxl booted into install on ethernet
[19:54] <lynorian> this probably might explain why no one ran into this earlier though
[19:58] <lynorian> it did pass running the test with ethernet on same hardware so should I put that on the tracker?
[20:00] <wxl> yes plese
[20:01] <wxl> looks like this is a nm issue of some kind https://launchpadlibrarian.net/311914177/UbiquityDebug.txt
[20:08] <lynorian> wxl I agree with that or in how ubiquity tries to integrate nm into the installer
[20:09] <wxl> lynorian: can you check alpha 2?
[20:09] <lynorian> I will
[20:29] <lynorian> this may be my usb wifi is breaking
[20:29] <lynorian> hard time even getting power to it
[20:36] <wxl> that's why it would be good to test on another machine
[20:41] <lynorian> wxl yeah I mean I could use the network on this desktop with it
[20:41] <wxl> lynorian: with built in wifi?
[20:42] <lynorian> wxl I am starting to wonder if that ancient wifi still is picking up electrical signal
[20:43] <lynorian> I was testing it on a 7.5 year old really heavily used laptop with an even older wifi adapter like 12 years we have had it well it is I think technically proprity of time warner to get wifi working with a computer my mom used with windows ME on it
[20:43] <wxl> oh wow
[20:43] <wxl> suffice it to say it's probably at least an edge case XD
[20:52] <lynorian> time to test the laptop with the really wierd aweak attena
[20:52] <lynorian> but is a ton newer
[20:57] -queuebot:#lubuntu-devel- Unapproved: makedev (zesty-proposed/universe) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2] (lubuntu)
[21:09] <lynorian> wxl well this laptop I did not research and has a bad wifi chip but the installer did not crash
[21:09] <lynorian> well at least that is better
[21:28] <lynorian> oh wow I need to force it to use the right attena
[22:09] <wxl> lynorian: so not reproducible on other hardware?
[22:10] <lynorian> wxl yes
[22:10] <lynorian> I cannot reproduce on any other hardware I have
[22:10] <wxl> annoying
[22:10] <wxl> hat ethose kind
[22:17] <wxl> lynorian: just make sure there's comments on the bugs, thx :)
[22:28] <lynorian> wxl thank you
[22:57]  * tsimonq2 stretches
[22:57] <tsimonq2> I needed that nap.
[22:57] <tsimonq2> Anyways...
[22:59] <tsimonq2> wxl: I really really hate this schedule. Do not divorce from your wife, and if you were to ever even think about it, not until Sierra is 18.  I'm at my mom's stuck on this Chromebook until Friday
[23:00] <wxl> tsimonq2: well, we're almost done anyways. but release notes are yours! :)
[23:00] <wxl> tsimonq2: tl;dr on lynorian's bug i think it's very specific to that hardware
[23:01] <tsimonq2> wxl: Oh shoot, did I tell you about Rafael messing with the slideshow?
[23:01] <wxl> uh
[23:01] <wxl> no
[23:02] <tsimonq2> wxl: Well it's out of date.
[23:02] <wxl> i knew that
[23:02] <wxl> henk's email was very complete in that regard :)
[23:02] <tsimonq2> wxl: So I guess we'll still have a slideshow that has 16.10 and lubuntu.me and LSC still on there :/
[23:02] <tsimonq2> s/me/net/
[23:02] <wxl> yep
[23:02] <wxl> so he IS fixing it?
[23:03] <tsimonq2> He's working on it.
[23:03] <lynorian> Oh I have a bug on needing to get the new website on it
[23:05] <tsimonq2> wxl: So I wanted to ask you. I had zero clue about this pulse/alsa thing before this Firefox bug. I know the basics on our stack (kernel, core utilities, GTK, GUI applications)) but what's the breakdown on other parts of the stack?
[23:06] <wxl> well you're asking about the sound stack essentially right?
[23:06] <tsimonq2> wxl: I'm being broad here but that's a good start :)
[23:08] <wxl> well
[23:08] <wxl> i guess it doesn't have too be too complicated
[23:09] <wxl> i guess x is kind of similar
[23:09] <wxl> it's a server that takes clients and serves as a bridge to the kernel modules for display, keyboard, mouse, etc.
[23:09] <wxl> the "sound server" does the exact same thing
[23:10] <wxl> but the clients are generally applications, e.g. audacious
[23:10] <wxl> and the kernel modules only relate to audio hardware
[23:10] <wxl> ultimately, across the whole of the linux domain, i know of only two actual sound servers
[23:10] <wxl>  1. ALSA
[23:10] <wxl>  2. OSS
[23:11] <wxl> the others "sound servers" basically use those actual sound servers as middleware
[23:11] <wxl> two of those are:
[23:11] <wxl>  1. PulseAudio
[23:11] <wxl>  2. JACK
[23:11] <wxl> although JACK can also work with PA, too
[23:12] <tsimonq2> Ah, ok.
[23:12] <tsimonq2> wxl: How bloated is Pulse compared to just using ALSA directly?
[23:12] <wxl> tsimonq2: is it a lot? no. but it counts for something
[23:13] <tsimonq2> wxl: Then sell it to me -- why do we need to use ALSA and not Pulseaudio + ALSA?
[23:13] <wxl> installed size is 6 times greater with pulseaudio
[23:14] <wxl> but installed size of alsabase is 500 so XD
[23:14] <wxl> pulseaudio can better handle complex cases including mutiple clients simultaneously accessing the devices
[23:14] <Unit193> wxl: Don't forget about the whole "When PA works, it's great.  When it breaks, good freaking luck" part. :P
[23:14] <wxl> totally that
[23:15] <wxl> i cannot tell you how many sound issues i've fixed by removing PA :)
[23:15] <wxl> the fact that it is a layer on top of ALSA can lead to a great degree of confusion
[23:15] <Unit193> Well the good news is if it's a dep of things, you can still keep it from autospawning, thus getting the same result.
[23:16] <wxl> :)
[23:16] <wxl> i see that ALSA is generally a good choice for the average user
[23:16] <wxl> it is complex cases that require something like PA or JACK
[23:16] <wxl> or depending on what they are, some hardcore asoundrc hacking
[23:17] <Unit193> JACK is more for the audio advanced group, UbuntuStudio people.  PA is useful if you have bluetooth audio or whatever.
[23:18] <tsimonq2> wxl: So if Pulseaudio is the thing with bluetooth audio or whatever, why do we ship bluetooth support? :P
[23:18] <wxl> yeah i haven't found it any more helpful with bluetooth
[23:18] <tsimonq2> wxl: You can do it with ALSA?
[23:19] <wxl> sure
[23:19] <wxl> like i said, i do
[23:20] <tsimonq2> Oh
[23:20] <tsimonq2> Ok
[23:20] <wxl> but i'll tell you what, when it comes to doing audio production, i 1000000% use JACK
[23:20] <tsimonq2> Gotcha :)
[23:20] <wxl> the only reason i've ever installed pulseaudio was because i couldn't find any easy way to route web browser strems through JACK using ALSA only
[23:20] <wxl> but no one does goofy crap like that besides me :)
[23:21] <Unit193> wxl: With PA I can use another computer's sound system, can you do that with Alsa?! :---D
[23:21] <wxl> right right
[23:21] <wxl> could with JACK :)
[23:21] <wxl> Unit193: can you do it with 0 latency??? XD
[23:23] <wxl> honestly though i don't consider PA totally evil. it's (generally) worked well for me in kubuntu. but i generally recommend to people not to install it unless they have to or unless their particular flavor of their particular distro really supports it
[23:23] <tsimonq2> wxl: Ok, I get the whole ALSA thing now. Now, as a Firefox user, I think we should continue shipping Firefox because it's bore lightweight than that RAM hog that is Chromium. So... why Chromium?
[23:23] <lynorian> I do not notice that much difference but have really simple setups
[23:23] <wxl> also keep in mind that bluetooth is not ONLY used for audio
[23:23] <tsimonq2> s/bore/more/
[23:23] <lynorian> yeah there are bluetooth keyboards and mice
[23:24] <wxl> i've seen lots of tests on firefox/chromium and ultimately have found every one of them to be biased in some way or another
[23:24] <wxl> i think the conclusion i've come to reach is that they're both ram hogs
[23:25] <lynorian> or the content to run in javascript is too bloated and not simple
[23:25] <wxl> also i have had better experiences in general with chromium than firefox
[23:25] <wxl> right
[23:25] <lynorian> if more people used static site generators would we have this problem?
[23:25] <wxl> here here lynorian :)
[23:26] <tsimonq2> Hahahaha
[23:28] <tsimonq2> wxl: So why a browser that is a RAM hog? Why can't we just go with a lightweight browser?
[23:29] <tsimonq2> lynorian: Hey, any chance you can knock out the last ISO test?
[23:30] <tsimonq2> lynorian: http://iso.qa.ubuntu.com/qatracker/milestones/374/builds/144355/testcases/1301/results
[23:30] <lynorian> tsimonq2, I just did
[23:30] <tsimonq2> lynorian: Oh ok
[23:30] <tsimonq2> lynorian: Yay
[23:32] -queuebot:#lubuntu-devel- Builds: Lubuntu Alternate amd64 [Zesty Beta 2] has been marked as ready
[23:32] -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Zesty Beta 2] has been marked as ready
[23:32] -queuebot:#lubuntu-devel- Builds: Lubuntu Alternate i386 [Zesty Beta 2] has been marked as ready
[23:32] -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop i386 [Zesty Beta 2] has been marked as ready
[23:32] <tsimonq2> wxl, lynorian: Done :) ^
[23:32] <wxl> tsimonq2: we can go with a lightweight browser. it has been suggested many times
[23:33] <wxl> um
[23:33] <wxl> ok now everyone go test kubuntu :)
[23:33] <wxl> tsimonq2: it's called xombrero
[23:36] <tsimonq2> wxl: Ok, so, Mr. QA guy, go ask the list for testing. :)
[23:37] <wxl> tsimonq2: for testing what? i thought you were done mr. release manager? :)
[23:37] <tsimonq2> wxl: For your browser pick.
[23:37] <wxl> yeah not going down that road again
[23:37] <wxl> ultimately people are just going to pick whta they like
[23:37] <wxl> i've done this before
[23:38] <tsimonq2> wxl: But why switch off of Firefox then? :))
[23:38] <wxl> tsimonq2: cuz ppl being booboo butts about alsa
[23:39] <tsimonq2> wxl: Then how do we do that?
[23:39] <tsimonq2> wxl: Should we just go for it? :P
[23:39] <Unit193> Because wxl likes chromium.  "< wxl> ultimately people are just going to pick whta they like" :--D
[23:39] <wxl> exactly!!!
[23:40] <wxl> tsimonq2: well, right now we have pulseaudio so i guess it doesn't matter :/
[23:40] <tsimonq2> Unit193: So we just switch and when people complain, say "sudo apt install chromium-browser"? :P
[23:40] <wxl> we really should get rid of PA
[23:40] <wxl> and if infinity's going to make chrisccoulson stick the ALSA code back in, then we should be good
[23:41] <wxl> at least until we start having problems
[23:41] <tsimonq2> wxl: You know what would be just awful? If we hacked Ubiquity to make the user pick the browser they want installed by default. XD
[23:43] <wxl> tsimonq2: just get rid of PA, would you?
[23:44] <tsimonq2> wxl: Oh, that's right. Is this something I can just make an executive decision and be done with?
[23:46] <tsimonq2> wxl: I mean, I'll talk with Julien
[23:47] <tsimonq2> wxl: But we're not gonna be like you-know-who here... :|
[23:47] <tsimonq2> wxl: "If Julien says it works, then it works, he knows best" - yeah nope let's not do that again
[23:49] <wxl> well julien can offer advice on why it may or may not be good
[23:49] <wxl> he's someone good to bounce technical ideas off of
[23:49] <wxl> ultimately he knows lubuntu best
[23:50] <tsimonq2> wxl: Sure, so I'll ask him, but we're gonna talk about it, not say, "let's just not touch it at all because Julien is the wise one he knows best he knows everything about the flavour of Lubuntu"
[23:50] <wxl> :)
[23:50] <Unit193> And he is the dev team...
[23:51] <tsimonq2> Unit193: Technically, yeah. But if I can research and we can have an intelligent conversation about the aspects of some things, then I'd rather do that than not touch it at all.
[23:51] <wxl> Unit193: i think what tsimonq2 is saying is that he's part of a team of people rather than the emperor
[23:52] <tsimonq2> Yeah.
[23:52] <tsimonq2> That.
[23:52] <wxl> not like julien has ever acted like he was in that role
[23:52] <wxl> he's ALWAYS been very willing to work with others
[23:52] <wxl> but there was someone.....
[23:52] <tsimonq2> You-know-who...
[23:52] <wxl> he-who-shall-not-be-named


[00:15] <TheMuso> Natty is open.
[00:16] <micahg> \o/
[01:08] <highvoltage> TheMuso: whohoo!
[04:21] <coolbhavi> hello...isnt PPA for natty activated yet?
[04:23] <persia> Quite possibly not, but ask #launchpad: they host PPAs (and we don't even all use them).
[04:23] <persia> You can set up a pbuilder or sbuild today though.
[04:23] <coolbhavi> sure thanks persia
[05:06] <nigelb> hyperair: HAPPY BIRTHDAY!
[05:06] <hyperair> thanks =)
[05:06] <hyperair> how did you know?
[05:06] <nigelb> The Force :p
[05:07] <nigelb> Facebook, you added me remember? ;)
[05:07] <hyperair> ahahahahaha
[05:07] <hyperair> right
[05:07] <hyperair> now i remember
[05:07]  * hyperair got flooded with facebook mails this morning
[05:08]  * nigelb adds to the flood
[05:09]  * hyperair gets flattened by facebook mails
[05:11] <nigelb> hahaha
[06:52] <micahg> lucidfox: ping
[07:26] <lucidfox> micahg, pong
[07:26] <micahg> lucidfox: hi, did you want to merge chmsee?  I noticed you were the last uploader
[07:32] <lucidfox> Eh... to be honest, I'm done with it. If you want to upload, feel free to proceed
[07:33] <micahg> lucidfox: k, thanks
[07:33] <persia> And this is why we don't have maintainers in Ubuntu : makes it easier to just fix stuff with certain confidence that someone else on the team will pick it up later if you're done with it.
[07:34] <micahg> persia: we're still supposed to ask, right?
[07:34] <persia> Depends.
[07:34] <bilalakhtar> micahg: I have uploaded chmsee!
[07:34] <bilalakhtar> micahg: Please don't!
[07:34] <persia> If you've a burning need to do something, because it's blocking your work, same rules apply for merges and non-merge uploads.
[07:34] <micahg> bilalakhtar: ?
[07:35] <bilalakhtar> micahg: no, wait, I haven't uploaded it yet
[07:35] <bilalakhtar> micahg: Its lying in my directory
[07:35] <persia> Once we hit DIF, anything not done is essentially up for grabs.
[07:35] <micahg> bilalakhtar: ah, you grabbed it...that's one of the few things I can upload at the moment :(
[07:35] <persia> We tend to follow TIL rules between archive-open and DIF just because most folk who are TIL are willing to do the merges.
[07:36] <bilalakhtar> micahg: Do you want to do it? I have done the merge, but will do a test-build, run and upload
[07:36] <micahg> bilalakhtar: nah, go ahead
[07:36] <persia> bilalakhtar, As much as I harp on Ubuntu-does-not-have-maintainers-!!!! It's considered polite to ask the last uploader about it between archive-open and DIF: lots of times people have other out-of-archive stuff they are doing, and quick merges interfere with their work.
[07:36] <persia> Once we reach DIF, all bets are off.
[07:37] <bilalakhtar> ohk
[07:37]  * micahg would also think MOTU should focus on unseeded unless it's a pet package
[07:38] <persia> Indeed, but the LP stuff to block MOTU uploading to packagesets isn't done yet, sadly.
[07:39] <micahg> persia: I don't think they should be blocked necessarily, just focus on the unseeded
[07:39] <persia> And the UI for MOTU to *know* what isn't in a packageset is still fuzzy.
[07:39] <micahg> yeah, that's the bigger issue :)(
[07:39] <persia> micahg, Intent is to block it: packages that have interested folks aren't MOTU responsibility.  MOTU who happen to be interested should join the relevant devteam.
[07:40] <micahg> persia: ah, ok, so me going for MOTU will then be in addition to mozilla stuff :)
[07:40] <persia> Ideally, MOTU grants no upload rights, but that takes a lot more active developers :)
[07:40] <persia> micahg, Right.  MOTU is an additional grant, and it's supposed to be about dedication to archive quality.
[07:41] <persia> And for work concentrated in areas that don't have any group caring for them.
[07:41] <bilalakhtar> I am interested in desktop packages, some of which are in universe. However, before touching a desktop package, I ask in #ubuntu-desktop
[07:43] <persia> When you say "desktop package", how are you defining that?
[07:45] <micahg> is the current preference to file merge bugs or not to file merge bugs?
[07:46] <persia> micahg, I'm still a fan of filing merge bugs, just as a means to declare who is merging it.
[07:46] <Rhonda> micahg: It's to check wether the difference still makes sense and rather to help Debian release, otherwise natty won't get any new packages.
[07:47] <persia> That said, LP bugs are now so cluttered, I don't think most folk even look at bugs for a package when merging (sadly), making this less useful.
[07:47] <persia> (plus what Rhonda said)
[07:48] <micahg> Rhonda: how do merge bugs help to see if the diff makes sense or help Debian?
[07:49] <persia> micahg, The point being that it's probably better to focus on squeeze release than worry about merges.
[07:49] <micahg> persia: ah, right, ok
[07:49] <persia> The chances that any merge done now will not have to be redone when squeeze comes out and everyone uploads is tiny.
[07:49] <persia> So the faster we get squeeze released, the sooner it makes sense to do any merges.
[07:49] <Rhonda> micahg: The other way round. If the diff doesn't make sense there is no need for a merge bug, rather sync request. :)
[07:49] <micahg> hmm, makes sense, but I'm not sure how much I can do to help squeeze release, alas, I'll give it another whirl
[07:50] <persia> A better focus is probably UEHS stuff, for folks who don't want to help Debian.
[07:50] <micahg> UEHS?
[07:50] <micahg> persia: should I unmark the merges I marked for myself or just claim them and do them when the new version come out?
[07:51] <persia> micahg, Your choice :)
[07:51] <persia> !uehs
[07:51] <persia> ($#"W~)("#
[07:51] <persia> http://qa.ubuntuwire.com/uehs/
[07:51] <Rhonda> I'd like to throw in this URL which gives a list of bugs that are in need of getting addressed: http://udd.debian.org/bugs.cgi?release=squeeze&patch=ign&pending=ign&security=ign&notmain=ign&notsqueeze=ign&merged=ign&done=ign&fnewerval=7&rc=1
[07:52] <persia> ubottu, uehs is <reply> the Ubuntu External Health System is hosted at http://qa.ubuntuwire.com/uehs and lists many upstream projects with which Ubuntu is not currently in sync.
[07:52] <micahg> persia: I didn't know about that one, thanks
[07:53] <micahg> persia: I want to help squeeze release, I guess I need to dig deeper in the RC list to see if something is fixed upstream or something I can do
[07:57] <dholbach> good morning! :)
[07:58] <ajmitch> hi
[07:58] <dholbach> hey ajmitch
[07:58] <ajmitch> yay for friday evening
[07:58]  * ajmitch can sleep now
[07:59] <nigelb> dang, timezones are unfair
[07:59] <nigelb> another 10 hours at least before I can sleep
[07:59] <ajmitch> well it's only 8pm here, but I just walked home after a long day :)
[07:59] <nigelb> aha
[08:01]  * micahg is going to sleep now, timezeones are interesting
[08:03] <persia> nigelb, So, um, consider what time ajmitch gets up.
[08:03] <nigelb> persia: Considering what time I got up today, makes not much of difference :/
[08:04]  * micahg got up 19 hrs ago, definitely time to go to sleep
[08:04]  * persia is amused when 7:30 of timezone difference makes little effective difference in diurnal cycles
[08:05]  * ajmitch isn't really going to sleep yet :)
[08:11] <bilalakhtar> persia: What's the time at your place?
[08:11] <persia> bilalakhtar, UTC+9 today
[08:12] <bilalakhtar> oh
[10:22] <ari-tczew> when autosync is starting?
[10:23] <persia> A few minutes ago.
[10:33] <ari-tczew> can I see which packages are autosyncing right now? is it in  Latest uploads  ?
[10:33] <persia> https://launchpad.net/ubuntu/natty/+queue?queue_state=3 lets you see what just got processed.
[10:34] <ari-tczew> thanks persia
[10:55] <ari-tczew> persia: hmm, syncs are not coming :/
[10:56] <persia> Some will, but not so many, because of the squeeze freeze.
[10:57] <ari-tczew> persia: I see that 1700+ packages should be synced.
[10:57] <ari-tczew> (autosynced)
[10:58] <persia> Are you working on something that is blocked on one of them/
[10:58] <persia> s:/:?:
[11:10] <ari-tczew> persia: I would wait to moment, when all packages are synced. then I can test build packages on fresh build-depends
[11:11] <persia> Most build-depends ought be done: that's the point of the toolchain freeze.
[11:11] <ari-tczew> aha
[11:12] <persia> It is believed that anything not already uploaded isn't supposed to affect how stuff builds significantl.
[11:12] <persia> This may not be a correct assumption, but it's safe for you to also assume it.
[11:27] <ari-tczew> persia: ok, now packages are going to be uploaded by autosync.
[11:28] <persia> Yep.
[11:28] <ari-tczew> builders will be clogged
[11:29] <persia> Yep
[11:54] <gusnan> pdebuilding my GTK program I get the following: http://paste.ubuntu.com/513757/ during build - does someone know anything about this? It doesn't help to depend on libgdk-pixbuf2.0-dev oddly enough...
[13:02] <geser> gusnan: try adding -I/usr/include/gdk-pixbuf-2.0 to the CFLAGS
[13:10] <gusnan> ah, that seems to work... Thanks geser!
[13:39] <jariq> When i run "dh_make -s" it generates rules file with just three lines (#!/usr/bin/make -f \ %: \ dh $@).. I am not sure if this can be used for my applicaiton :) How can i get the "old style behaviour" with normal rules file ?
[13:41] <tumbleweed> jariq: there's an easy way to find out if the minimal dh rules will work :)
[13:41] <tumbleweed> jariq: also (#ubuntu-packaging)
[13:41] <jariq> tumbleweed: minimal dh rules does not work for me.. how can I generate longer version ?
[13:43] <tumbleweed> jariq: don't know of an easier way than writing them out by hand. dh_make doesn't ship them any more.
[13:43] <tumbleweed> jariq: why don't they work?
[13:45] <jariq> tumbleweed: i am installing into non standard location
[13:46] <jariq> tumbleweed: your answer "dh_make doesn't ship them any more" is enough for me.. thank you very much
[13:46] <tumbleweed> jariq: you know about dh overrides, right?
[13:46] <tumbleweed> so much for that...
[14:14] <ari-tczew> huh, builder is blocked till 2 days, at the moment
[14:19] <persia> heh, lots of packages, and powerpc is unfortunately not very fast right now.
[14:19] <persia> Be nice to put new powerpc hardware in the DC, but that kinda requires someone to make some and sell it at reasonable prices.
[14:24] <AlanBell> how do I find out who should review this? https://code.launchpad.net/~alanbell/dasher/bugfix-lp-579181/+merge/37528
[14:24] <AlanBell> so I reported a bug, took a branch, made the fix, done a merge request . . . now what? How do I make it happen?
[14:26] <vish> AlanBell¦ set the sponsor team as the reviewer
[14:26] <vish> dasher is in Ubuntu right?
[14:26]  * vish checks..
[14:27] <AlanBell> yes, it is in ubuntu
[14:27] <AlanBell> ok, done that I think
[14:28] <AlanBell> !info dasher
[14:28] <vish> AlanBell¦ hmm, wait, i think you might have fixed the wrong branch..  thats a vcs import branch
[14:28] <AlanBell> err ok, not sure what that means
[14:29] <vish> AlanBell¦ https://code.launchpad.net/~vcs-imports/dasher/trunk , thats automatically imported
[14:29] <vish> AlanBell¦ if you want to fix only in Ubuntu, grab the Ubuntu branch
[14:30] <AlanBell> found that from here https://launchpad.net/dasher
[14:30]  * persia notes that bzr diff may produce a patch suitable for application into the Ubuntu branch
[14:31] <AlanBell> sorry, I am going round in circles here, where is the ubuntu branch?
[14:32] <persia> Usually at lp:ubuntu/${package}
[14:32] <vish> AlanBell¦ https://code.launchpad.net/ubuntu/+source/dasher
[14:32]  * persia thinks, but doesn't use bzr for packaging, so may be mistaken
[14:32] <vish> AlanBell¦ so its for lp:ubuntu/dasher , that the sponsors can upload
[14:33] <vish> also, i think you'd need to file a bug too..
[14:33] <persia> No, it shouldn't need a bug.
[14:33] <AlanBell> hmm, ok, most of the links on that page take me back to the upstream dasher
[14:33] <AlanBell> there is a bug
[14:33] <persia> A merge proposal should show up in the sponsoring report.
[14:34] <persia> If there's a bug, just link the branch to the bug and subscribe ubuntu-sponsors.
[14:34] <AlanBell> bug 579181
[14:34] <persia> You'll still need to base the branch on the Ubuntu tree, but that'S separate.
[14:34] <vish> persia¦ i meant a bug for mentioning what we are changing and for the changelog..
[14:35] <persia> vish, No point.  Best to use the bug that is the problem.
[14:35] <persia> Adding new bugs just for sponsoring is a waste of bug IDs.
[14:35] <vish> nah, i dint mean new bugs :)
[14:35] <persia> And we only have a limited number of those.
[14:35] <persia> OK. :)
[14:36] <AlanBell> subscribe sponsors to the bug, or the branch?
[14:37] <vish> AlanBell¦ branch
[14:37] <vish> AlanBell¦ if you have made the changes for lp:ubuntu/dasher , they can merge/upload
[14:37] <vish>  lp:dasher they cant..
[14:38] <AlanBell> hmm, odd
[14:38] <vish> think of lp:dasher as the upstream branch, its just a mirror now of the svn from gnome
[14:39] <vish> sponsors can upload upload to Ubuntu branches
[14:39] <vish> upload only* to
[14:40] <persia> Well, sponsors can upload whatever they want to Ubuntu, whether it has any relation to an Ubuntu branch or not.
[14:40] <persia> But sponsors can only process merge proposals against Ubuntu branches.
[14:40] <persia> and upstream patches tend to get sent upstream rather than sponsored.
[14:40] <AlanBell> ok, so I need to bzr branch lp:ubuntu/dasher, redo my changes, commit, push and do a new merge request?
[14:41] <vish>  yup
[14:41] <vish> AlanBell¦ would sending the patch upstream not be helpful?
[14:41] <AlanBell> what have I just done then?
[14:42] <vish> AlanBell¦ the branch will fix the bug in Ubuntu alone, [if sponsored]
[14:42] <AlanBell> isn't the issue that I *did* send it upstream?
[14:43] <vish> the upstream code you pulled is actually mirrored from  http://svn.gnome.org/svn/dasher/trunk/
[14:44] <persia> AlanBell, You based the patch on upstream code (good), but didn't send it to actual upstream (maybe needed, maybe not).  You're now working to reapplyy the patch (bzr diff is good to extract it) to the Ubuntu branch with the intent to request someone to upload it to Ubuntu.
[14:44] <vish> so i'm *guessing* they file their bugs in gnome bugzilla, not sure though
[14:44] <AlanBell> ok, so where does that pull from?
[14:45] <AlanBell> http://svn.gnome.org/ says GNOME has changed to using Git for version control. Current GNOME sources can be found on git.gnome.org. All content on this site is obsolete
[14:46] <vish> from " https://code.launchpad.net/~vcs-imports/dasher/trunk   "This branch is an import of the Subversion  branch from http://svn.gnome.org/svn/dasher/trunk. "
[14:47] <vish> last sync was 30mins ago
[14:47] <vish> import rather
[14:47] <AlanBell> indeed, so why is it pulling from a site that claims to be obsolete
[14:48] <vish> right,  and the Ubuntu package is also a sync from debian.. 0.o
[14:48] <vish> auto-sync
[14:52] <AlanBell> http://www.inference.phy.cam.ac.uk/dasher/Develop.html
[14:52] <AlanBell> so looks like the real upstream is indeed on gnome
[14:53] <AlanBell> but should be git clone git://git.gnome.org/dasher
[14:53] <vish> if the svn is obsolete then https://code.launchpad.net/~vcs-imports/dasher/trunk might be a waste ?  why does that keep trying there?  maybe we should close/stop that?
[14:53] <vish> persia¦ ^
[14:53] <AlanBell> they might be syncing git to svn and launchpad is pulling from that
[14:54] <vish> heh! musical chairs! ;p
[14:54] <AlanBell> but debian will get releases from gnome, ubuntu gets packages from debian, I can't see where that lp:dasher is actually used
[14:55] <AlanBell> right now it is just causing multi-cycle delays in getting fixes done
[14:56] <persia> vish, better to just ask in #launchpad to get it updated
[14:57] <vish> yea..
[15:01] <vish> AlanBell¦ phew! » https://bugzilla.gnome.org/browse.cgi?product=dasher
[15:02] <vish> the bugs seem to go there, and sending the patch there would probably nice as well, but seeing that the package has not been updated since 04/2009  not sure where the log is, debian or bugzilla
[15:03] <persia> log?
[15:03] <persia> lag?
[15:03] <persia> quite possibly related to the squeeze freeze.
[15:04] <vish> err, yeah, lag
[15:06] <AlanBell> ok, so I need to register and file a bug in gnome or something?
[15:09] <ScottK> If it's upstream Gnome, it won't be the squeeze freeze that's the cause of delay I wouldn't think.
[15:09] <vish> AlanBell¦ yup, file a bug in gnome and send the patch there,  also trying to find out why the package was not updated for a while might be the real clue ;), the latest version /might/ have the problem fixed..
[15:12] <AlanBell> doubt it, given what the issue is
[15:12] <AlanBell> when using IRC to control dasher it is very hard to type /window 3<return>
[15:13] <vish> AlanBell¦ there is dasher 4_11 in git
[15:13] <AlanBell> because digit followed directly by return isn't in the training data
[15:13] <vish> http://git.gnome.org/browse/dasher/tag/?id=DASHER_4_11_0
[15:15] <vish> hrm! but seems nothing new in it, just a welcome message :D
[15:16] <AlanBell> http://git.gnome.org/browse/dasher/log/ wow, lots of stuff happening
[15:16] <vish> nope, someone is working on it
[15:17] <vish> heh , yeah, was just looking at the same link
[15:18] <AlanBell> ok, so the current ubuntu situation is a bit sucky
[15:18] <AlanBell> bugs get reported, they are not being passed upstream, it was *hard* to discover where the upstream actually was
[15:19] <bilalakhtar> A package is facing the DSO link failure problem and I am trying to fix it. The package uses cmake. Any idea how do I get it to use the -lX11 flag when it calls gcc ?
[15:20] <AlanBell> and I am fairly sure when I fixed that bug in the first place I used ground control to fix the bug number and it downloaded the vcs branch for me, totally inappropriately
[15:20] <bilalakhtar> got it
[15:22] <vish> AlanBell¦ yeah, just noticed that none of those bugs got triaged
[15:22] <vish> AlanBell¦ adopt upstream? < enter jcastro »
[15:23] <jcastro> I can help!
[15:23] <jcastro> give me a few minutes to finish this call
[15:24] <vish> j-castro¦  https://bugs.launchpad.net/ubuntu/+source/dasher seems to be fairly important for accessibility, but has got no attention
[15:25] <bilalakhtar> | ?
[15:25] <bilalakhtar> Why the pipe character, vish?
[15:26] <vish> bilalakhtar¦ just so that people ask about it! :)
[15:26] <AlanBell> vish: ¦ is not | or : but somewhere inbetween
[15:27] <vish> AlanBell¦ yup, i came across it while we were looking for the Rs sign ;)
[15:27] <AlanBell> ah, you mean ₹
[15:28] <bilalakhtar> vish: Ubuntu supports the rupee symbol
[15:28] <vish> AlanBell¦ yup, the other day, so you are to be blamed! ;p
[15:28] <AlanBell> #blamealan
[15:37] <jcastro> vish: the bug tracker seems set correctly in launchpad to me?
[15:40] <AlanBell> https://bugs.launchpad.net/dasher says that bugs are tracked in gnome, and also ubuntu
[15:42] <AlanBell> so do the dasher packages come from debian, or from gnome?
[15:43] <jcastro> the code comes from gnome, the packages from debian most likely
[15:46] <AlanBell> so where do I file a bug, and where do I fix it, and how should I have found this out for myself?
[15:48] <tumbleweed> AlanBell: you file a bug in Ubuntu if it's something we want to track in ubuntu (i.e. important or visible). You fix it in gnome. If we can't wait for the fix from gnome, we fix it with a patch in Ubuntu (or better, Debian) but still pass the patch to gnome
[15:49] <AlanBell> right, OK, so I did file a bug in Ubuntu, and then got in a mess trying to fix it in ubuntu against the pseudo upstream branch at lp:dasher
[15:50] <tumbleweed> AlanBell: https://wiki.ubuntu.com/Bugs/HowToFix covers some of this
[15:50] <AlanBell> now I have the git tree from Gnome and I am fixing it there
[15:50] <vish> jcastro¦ yea, but AlanBell seems fairly interested in the package, so i thought you could sweet talk him into adoption it ;)
[15:50] <vish> adopting*
[15:50] <jcastro> indeed
[15:55] <jcastro> AlanBell: I would fix it in gnome, and then ping the DD and a MOTU about carrying it back down
[16:00] <AlanBell> yay, I have a git patch
[16:00] <persia> yay!
[16:04] <jcastro> AlanBell: please make a mental note of how brutal it will be getting the fix back down, I am always interested in that kind of data
[16:06] <AlanBell> gnome bug 632226
[16:07] <jcastro> \o/
[16:08] <AlanBell> bug filed in gnome, ubuntu bug attached to gnome bug, patch attached to gnome bug
[16:16] <Pendulum> AlanBell: I think I owe you a drink next time I see you :)
[16:27] <vish> Pendulum¦ hey! AlanBell owes me that drink! i literally handheld him through it! ;p
[16:36] <Pendulum> vish: or I owe you both drinks :P
[16:40] <vish> \o/
[18:46] <micahg> SpamapS: you might want to wait for me to merge 1.6.3 before you request the backport
[18:47] <micahg> SpamapS: actually, since you TIL, were you planning on merging mongodb?
[18:59] <SpamapS> micahg: oo that would be sweet actually. :)
[18:59] <micahg> SpamapS: which one?
[18:59] <SpamapS> micahg: 1.6 in backports
[19:00] <micahg> SpamapS: k, do you want me to merge it, or do you want to?
[19:00] <SpamapS> micahg: I don't mind merging it at all. I'm a little bit perplexed at what they're planning for 1.7 though.. mongodb is planning to embed pcre and boost in their distribution.
[19:00] <SpamapS> micahg: and they're going to be statically linking by default.
[19:01] <SpamapS> "rapidly changing xulrunner and boost versions cause too many problems for our users"
[19:01] <SpamapS> They really don't understand that they are cutting off their nose to spite their face.
[19:01] <micahg> SpamapS: k, well, they can switch to webkit :-/
[19:02] <ScottK> Boost and stable ABI are oxymorons.
[19:06] <SpamapS> micahg: does webkit have a more stable js library?
[19:07] <micahg> SpamapS: er, I don't know for sure, but I think they do
[19:10] <micahg> chrisccoulson: can you speak to the stability of the webkit JS API?
[19:19] <chrisccoulson> micahg - i'm not sure about that
[19:22] <SpamapS> micahg: Oh, and if I wasn't clear.. yes I will do the mongodb merge
[19:23] <micahg> SpamapS: feel free to ping me when you're ready for sponsorship
[19:23] <SpamapS> micahg: will do, thanks. :)
[23:13] <ari-tczew> bdrung: hey, which command can I use for fakesync?
[23:29] <SpamapS> micahg: should I bother to subscribe ubuntu-sporsor for the mongodb merge, or do you just want to take it? bug #661513
[23:30] <micahg> SpamapS: nah, that's ok, just subscribe me and I'll upload Sat night
[23:31] <SpamapS> seems like the 'subscribe someone else' link on launchpad has gotten slower lately :(
[23:31] <SpamapS> micahg: thanks!
[23:31] <micahg> nm, I'm already subscribed :)
[23:32] <micahg> oh, well, all good
[23:32] <micahg> SpamapS: np
[23:44] <micahg> SpamapS: only comment on your debdiff is you fix up the dep3 patch headers for the ubuntu_hacks workaround
[23:45]  * micahg will be back in 25 hours
[23:46] <SpamapS> micahg: oh, those are the result of the 3.0 source format.. I always forget to fix those. ;)
[23:47] <ScottK> SpamapS: Here's a hint - Read your debdiff before you ask for sponsorship.  Then this kind of stuff leaps out at you.
[23:53] <SpamapS> I did read it. I don't ever notice those, because they're just boilerplate stuff. The 3.0 format does make it kind of weird. The Debian maintainer didn't remove their boilerplate stuff either. ;)
[23:54] <SpamapS> in fact.. I'm not really even sure how to edit the generated patches


[11:57] <nickoe> How long time does it take before packages appear on a ppa I just created and pushed with dput?
[12:05] <wgrant> nickoe: Just a minute or two, normally. In this case, you've received a rejection email.
[12:06] <nickoe> wgrant: ahh yes, I got mail.
[12:06] <nickoe>  Unable to find distroseries: unstable
[12:06] <nickoe> mm
[12:06] <wgrant> unstable is a Debian series, not an Ubuntu one.
[12:06] <wgrant> You'll need to fix debian/changelog to specify the Ubuntu series that you want to target.
[12:07] <nickoe> wgrant: mm, currently I am testing on ubuntu LTS.
[12:08] <nickoe> but I just used apt-get source to gram some package and build some more packages from it.
[12:08] <nickoe> wgrant: How should I do it if I want to target both ubuntu LTS and deb stable?
[12:08] <nickoe> I am new in deb packaging.
[12:08] <wgrant> nickoe: Launchpad PPAs only build for Ubuntu, not Debian.
[12:08] <nickoe> I usually use arch.
[12:08] <nickoe> but I have seen some building for deb also.
[12:09] <wgrant> Documentation under https://help.launchpad.net/Packaging/PPA may be of interest.
[12:09] <wgrant> launchpad.net cannot build for Debian.
[12:10] <nickoe> mm, whatever, i need to makeit work for ubuntu in the first place
[12:14] <nickoe> mmm, wgrant if I just modify it to trusty, it will reject the upload saying it has already been uploaded
[12:16] <wgrant> nickoe: What are you trying to do? Backport a newer package to trusty?
[12:17] <wgrant> If so, look at the backportpackage tool in ubuntu-dev-tools.
[12:17] <wgrant> Anyway, I need to sleep.
[12:17] <nickoe> wgrant: mmm, kind of. wx3.0 does not include python-wxgtk3.0 in its wx3.0 release.  It only has python-wxgtk2.8.  KiCad requires wx3.0 now, and depends on wxpython.
[17:29] <nickoe> mmm, http://dpaste.com/2NQQR5M     add-apt-repository fails with utf8 char.   I see similar bugs about this, https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1012901   but that was long ago.
[17:31] <nickoe> mmm https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1165569