[16:00] <Daviey> utlemming: Are you happy to chair?
[16:00] <utlemming> Daviey: sure
[16:01] <smb> \o
[16:02] <adam_g> o/
[16:02] <Daviey> utlemming: Are you getting my pm's?
[16:02] <zul> helo
[16:03] <Ursinha> o/
[16:03] <hallyn> \o
[16:03] <utlemming> #startmeeting
[16:03] <MootBot> Meeting started at 11:03. The chair is utlemming.
[16:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:04] <RoAkSoAx> o/
[16:04] <utlemming> [TOPIC] follow up from last meeting
[16:04] <MootBot> New Topic:  follow up from last meeting
[16:04] <utlemming> sommer, j1mc: to look at doc presentation (continued x 2)
[16:04] <utlemming> What is the status on the doc presentation?
[16:05] <utlemming> And it looks like neither are in...so
[16:05] <utlemming> [ACTION] sommer and j1mc to look at doc presentation (continued x 3)
[16:05] <MootBot> ACTION received:  sommer and j1mc to look at doc presentation (continued x 3)
[16:06] <utlemming> [TOPIC] Oneiric Development
[16:06] <MootBot> New Topic:  Oneiric Development
[16:06] <utlemming> Anyone have any topics here?
[16:07] <Daviey> o/
[16:07] <Daviey> Full cycle tracking: - http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-server-overview.html
[16:07] <Daviey> We seem to be pretty much on target, with:
[16:07] <Daviey> Bugs currently being tracked for Oneiric Release: - http://people.ubuntu.com/~davewalker/release-bugs.html
[16:07] <Daviey> If there is a bug you are aware of, or currently working on that isn't on that list - please can you raise it here, or with me afterwards.  Thanks.
[16:07] <Daviey> Sync's/Merges: - http://people.ubuntu.com/~davewalker/server-sid-new.html (We are doing ok!  But please be conservative!)
[16:08] <Daviey> (boot experience Clint is currently working hard on)
[16:08] <Daviey> LXC is expected to catch up at the LXC sprint.
[16:08] <Daviey> Anything else to note?
[16:08] <hallyn> conservative?
[16:08] <hallyn> meaning don't do any more synca than we feel we really need to?
[16:09]  * hallyn confused
[16:10] <utlemming> Daviey: can you clarify for hallyn?
[16:11] <Daviey> hallyn: We just need to start stabilising
[16:11] <Daviey> We can still break stuff, but there is added presure to resolve.
[16:11] <hallyn> Daviey: oh, i was loking at it a bit differently...
[16:11] <hallyn> figuring we should sync to the last possible minute in this cycle,
[16:11] <hallyn> and be extra-conservative in 12.04
[16:11] <zul> agreed
[16:12] <hallyn> was particularly hoping not to sync libvirt at all during 12.04 cycle if possible
[16:12] <Daviey> hallyn: Well we /can/ do that.. but be more aware of issues it might cause.
[16:12]  * hallyn nods
[16:12] <Daviey> (hallyn, note that next cycle may be syncing from debian testing, rather than unstable)
[16:12] <hallyn> ah
[16:13] <Daviey> hallyn: I wonder if we can reduce our delta regarding libvirt?
[16:13] <hallyn> Daviey: that's not the issue.  (well, it's a bear, but not the issue ;)
[16:13] <Daviey> That seems to be moving quite fast in Debian, and regular sync would be easier if a smaller delta.
[16:14] <hallyn> it's moving fast upstream.
[16:14] <hallyn> too fast, imo, to safely track during lts cycle.
[16:16] <Daviey> hallyn: agreed, we'll discuss that at UDS
[16:16] <hallyn> cool
[16:17] <jdstrand> fwiw, it does move very fast
[16:17] <jdstrand> (imo)
[16:17] <Daviey> jdstrand: We'll nab you for a session regarding core component versioning session at UDS btw :)
[16:17] <Daviey> utlemming: I think we can move on.
[16:17] <utlemming> [TOPIC] Ubuntu Server Team Events
[16:17] <MootBot> New Topic:  Ubuntu Server Team Events
[16:17] <jdstrand> Daviey: cool
[16:17]  * jdstrand quiets down
[16:18] <utlemming> Do we have any events this week?
[16:19] <utlemming> SpamapS (Clint Byrum) will be speaking at OSCON July 28
[16:19] <utlemming> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[16:19] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[16:20] <hggdh> any questions for me?
[16:20] <hggdh> otherwise...
[16:20] <hggdh> ..
[16:21] <utlemming> hggdh: we'll take silence as no questions
[16:21] <Daviey> hggdh: None at the moment!
[16:21] <utlemming> [TOPIC] Weekly Updates & Questions for the Kernel Team (smb)
[16:21] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (smb)
[16:21] <smb> Hi
[16:21] <smb> Not think there so much updates this week
[16:21] <Daviey> one mo
[16:22] <smb> Found some missing deps for the xen build which zul is taking care of
[16:22] <smb> Daviey, yes?
[16:22] <Daviey> smb / utlemming: Any news on bug #791850 ?
[16:22] <utlemming> Daviey: beat me to the punch there...
[16:23] <smb> Daviey, Not so much from my side, I was using the comment of Amazon looking to provide data as a SEP field
[16:23] <utlemming> There has been some AWS forum activity going with Oneiric -- so we might need to spend some time there. Amazon reports that the instance dies almost immediately.
[16:23] <Daviey> utlemming: I assigned it to you, purely as the point of contact - as you were talking to Amazon about it.
[16:24] <adam_g> i've got a question regarding Bug #799630 and similar, where DKMS packages are updated against backported kernels and fail. is this kinda stuff supported, especially on LTS?
[16:24] <utlemming> Yes, I've talked with Amazon a couple of times, but haven't made any in roads there yet.
[16:24] <Daviey> utlemming: ok.. what can we do to progress this?
[16:25] <Daviey> adam_g: dkms should not build a kernel module if it notices the kernel has a >= to what is in the dkms payload.
[16:25] <utlemming> I'll work with smb on this -- we'll likely need to get a dump on this or repro this in house
[16:26] <Daviey> utlemming: sounds good!
[16:26] <utlemming> [ACTION] smb and utlemming to work on Bug #791850
[16:26] <MootBot> ACTION received:  smb and utlemming to work on Bug #791850
[16:26] <smb> adam_g, I guess at least for LTS and when providing backported kernels I think it should be taken care of
[16:27] <adam_g> Daviey: so that mentioned bug looks more like a packaging issue than anything else?
[16:27] <RoAkSoAx> adam_g: yes it does, though you'd also have to start updating user-space tools to match the kernel module
[16:27] <Daviey> adam_g: can't comment really, first time i've looked at it
[16:27] <Daviey> We'll take it out of meeting.
[16:27] <utlemming> [ACTION] Daviey and adam_g to address Bug #791850
[16:28] <MootBot> ACTION received:  Daviey and adam_g to address Bug #791850
[16:28] <utlemming> Any other topics for smb?
[16:28] <smb> Ok. Otherwise I also don't have more.
[16:28] <adam_g> drbd is one example, but there are other modules that we maintaind out-of-tree and later merged mainline, but in doing so caused out of tree modules to fail to build against later kernels
[16:28] <Daviey> smb: thanks!
[16:28] <Daviey> adam_g: Yeah, that sounds like a dkms bug, as it should not build.
[16:29] <Daviey> Thankfully, the dkms upstream is a ubuntu developer - we'll jump on him if we get blocked. :)
[16:29] <adam_g> Daviey: ok great, ill be happy to look at it with you later
[16:29] <smb> Daviey, just note that in some cases you only have the dkms module
[16:30] <Daviey> yah
[16:30] <utlemming> [TOPIC] Weekly Updates & Questions regarding Ubuntu ARM Server (NCommander)
[16:30] <MootBot> New Topic:  Weekly Updates & Questions regarding Ubuntu ARM Server (NCommander)
[16:31] <utlemming> NCommander: you're up
[16:33] <utlemming> Okay, moving on
[16:33] <utlemming> [TOPIC] Weekly Updates & Questions from the Ubuntu Community
[16:33] <MootBot> New Topic:  Weekly Updates & Questions from the Ubuntu Community
[16:34] <utlemming> Any questions or comments to or from our community?
[16:34] <utlemming> Moving on then
[16:34] <utlemming> [TOPIC] Open Discussion
[16:34] <MootBot> New Topic:  Open Discussion
[16:35] <Daviey> I have nothing to raise.
[16:35]  * NCommander is here now (sorry, TASP call)
[16:36] <utlemming> NCommander: glad to have you join
[16:36] <utlemming> Any updates for us?
[16:36] <NCommander> Unattended installation with preseeds is now know to work on pandaboard which should help satisfy the requirements of ensebmle
[16:37] <NCommander> In addition, heavy QA efforts are underway to make sure common sets of server packages work properly on ARM (such as kerberous, ruby-on-rails, etc.)
[16:37] <NCommander> any help with QA testing of any sort would be greatly appericated
[16:37] <Daviey> NCommander: Is there docs on using uboot to PXE boot?
[16:38] <Daviey> NCommander: Where is the QA effort being co-ordinated?
[16:38] <NCommander> Daviey: more like a loose collection of notes, GrueMaster is the expert on this
[16:38] <NCommander> Daviey: on two specs in LP
[16:38] <Daviey> NCommander: I wonder if you'd be able to ask GrueMaster to document this?
[16:38]  * NCommander tries to get the links
[16:39] <NCommander> Daviey: he probably has it documented, I just haven't been around to poke him about it
[16:39] <NCommander> https://blueprints.launchpad.net/ubuntu/+spec/server-o-arm-image-validation
[16:39] <NCommander> https://blueprints.launchpad.net/ubuntu/+spec/server-o-arm-image-qa
[16:39] <hallyn> wiki.ubuntu.com/ArmServer ?
[16:39] <NCommander> hallyn: there's a landing page on the wiki but I don't have a link handy
[16:40] <hallyn> ah ok
[16:40] <Daviey> NCommander: This probably needs to be better vocalised.
[16:40] <NCommander> Daviey: the QA bits?
[16:40] <Daviey> NCommander: both parts :)
[16:40] <NCommander> I'll make a posting on my blog about it, though I'm unsure how many people actually read it :-(
[16:41] <Daviey> NCommander: We'll all read it :)
[16:41] <Daviey> it will be well recieved. :)
[16:41] <Daviey> Thanks NCommander !
[16:41] <NCommander> np
[16:43] <utlemming> [TOPIC] Announce next meeting date and time
[16:43] <MootBot> New Topic:  Announce next meeting date and time
[16:43] <utlemming> Tuesday 2011-08-02 at 1600 UTC here in #ubuntu-meeting
[16:43] <utlemming> Thank you everyone and have a good week
[16:43] <utlemming> #endmeeting
[16:43] <MootBot> Meeting finished at 11:43.
[16:44] <Daviey> thanks utlemming
[16:44] <utlemming> :)
[16:59] <ppisati> o/
[17:00] <smb> \o
[17:00] <bjf> #
[17:00] <bjf> # lets "get 'er done"!
[17:00] <bjf> #
[17:00] <bjf> #startmeeting
[17:00] <MootBot> Meeting started at 12:00. The chair is bjf.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00] <bjf> ##
[17:00] <bjf> ## This is the Ubuntu Kernel Team weekly status meeting.
[17:00] <bjf> ##
[17:00] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Oneiric
[17:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Oneiric
[17:00] <bjf> # Meeting Etiquette
[17:00] <bjf> #
[17:00] <bjf> # NOTE: '..' indicates that you are finished with your input.
[17:00] <bjf> #       'o/' indicates you have something you'd like to add (wait until you are recognized)
[17:00] <bjf> #
[17:00] <bjf> [TOPIC] ARM Status (ppisati)
[17:00] <MootBot> New Topic:  ARM Status (ppisati)
[17:00] <ppisati> Oneiric/ti-omap4: finally pushed out the first oneiric 3.0 + TI BSP kernel (3.0.0-1200.2), and there's already a BSP update in the pipe.
[17:00] <ppisati> Oneiric/tegra: forward ported/triaged around ~600 patches from 2.6.38 to 3.0 - basically video/ and arch/arm/mach-tegra/, plus some glue functions here and there. The kernel doesn't compile yet.
[17:00] <ppisati> ..
[17:01] <bjf> [TOPIC] Release Metrics and Incoming Bugs (ogasawara)
[17:01] <MootBot> New Topic:  Release Metrics and Incoming Bugs (ogasawara)
[17:01] <ogasawara> [17:01] <ogasawara> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <MootBot> LINK received:  http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <ogasawara> [17:01] <ogasawara>  * 26 linux kernel bugs (up 6)
[17:01] <ogasawara> [17:01] <ogasawara>  * 2 linux kernel bugs (up 2)
[17:01] <ogasawara> [17:01] <ogasawara>  * 0 oneiric linux kernel bugs (no change 0)
[17:01] <ogasawara>  * 22 natty linux kernel bugs (down 1)
[17:01] <ogasawara>  * 3 maverick linux kernel bugs (no change 0)
[17:01] <ogasawara>  * 7 lucid linux kernel bugs (no change 0)
[17:01] <ogasawara>  * 0 hardy linux kernel bugs (no change 0)
[17:01] <ogasawara> [17:01] <ogasawara>  * 65 oneiric bugs (up 3)
[17:01] <ogasawara>  * 1425 natty bugs (up 5)
[17:01] <ogasawara>  * 1092 maverick bugs (down 11)
[17:01] <ogasawara>  * 927 lucid bugs (down 41)
[17:01] <ogasawara>  * 32 hardy bugs (down 1)
[17:01] <ogasawara> [17:01] <ogasawara> [17:01] <ogasawara>  * 0 oneiric bugs (no change 0)
[17:01] <ogasawara>  * 12 natty bugs (up 6)
[17:01] <ogasawara>  * 41 maverick bugs (down 2)
[17:01] <ogasawara>  * 74 lucid bugs (down 8)
[17:01] <ogasawara>  * 0 hardy bugs (no change 0)
[17:01] <ogasawara> [17:01] <ogasawara>  * 1 oneiric bugs (up 1)
[17:01] <ogasawara>  * 440 natty bugs (down 4)
[17:02] <ogasawara>  * 242 maverick bugs (no change 0)
[17:02] <ogasawara>  * 208 lucid bugs (down 9)
[17:02] <ogasawara>  * 2 hardy bugs (no change 0)
[17:02] <ogasawara> [17:02] <ogasawara>  * 0 oneiric bugs (no change 0)
[17:02] <ogasawara>  * 2 natty bugs (no change 0)
[17:02] <ogasawara>  * 1 maverick bugs (down 1)
[17:02] <ogasawara>  * 0 lucid bugs (no change 0)
[17:02] <ogasawara>  * 0 hardy bugs (no change 0)
[17:02] <ogasawara> ..
[17:02] <bjf> [TOPIC] Blueprints: Oneiric Delta Review (ogasawara)
[17:02] <MootBot> New Topic:  Blueprints: Oneiric Delta Review (ogasawara)
[17:02] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/other-kernel-o-ubuntu-delta-review
[17:02] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/other-kernel-o-ubuntu-delta-review
[17:02] <ogasawara> apw, lag, rsalveti: you have work items to review your set of Ubuntu patches.  I've pushed these out to Alpha-3 for you.  Please take a moment to review when you have a chance. See https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview for your specific set of patches.  Note, these are the only remaining work items for this blueprint.
[17:02] <ogasawara> ..
[17:02] <bjf> [TOPIC] Status: General Oneiric (ogasawara)
[17:02] <MootBot> New Topic:  Status: General Oneiric (ogasawara)
[17:03] <ogasawara> Last week we uploaded the 3.0.0-7.8 kernel.  This most notably enabled overlayfs as well as rebased to upstream v3.0 final.  Alpha-3 is next Thurs, Aug 4th.  I intend to upload our final Alpha-3 this Friday, July 29th.  If there are any patches that need to land for Alpha-3, get them sent to the kt-ml asap.
[17:03] <ogasawara> ..
[17:03] <bjf> [TOPIC] Status: CVE's (apw)
[17:03] <MootBot> New Topic:  Status: CVE's (apw)
[17:03] <apw> [17:03] <apw> After hitting 0 CVEs open on all branches but Hardy at the start of the week we have seen, one CVE has resurface and 8 new ones have been added.  Luckily a large number of the new CVEs are already fixed in Lucid and later.
[17:03] <apw> [LINK] http://people.canonical.com/~apw/cve/pkg/CVE-linux.txt
[17:03] <MootBot> LINK received:  http://people.canonical.com/~apw/cve/pkg/CVE-linux.txt
[17:03] <apw> Currently open CVEs for each supported branch:
[17:03] <apw> || Package                                  || Open ||
[17:03] <apw> ||                                          ||      ||
[17:03] <apw> || linux Hardy                              ||   12 ||
[17:03] <apw> || linux Lucid                              ||    3 ||
[17:03] <apw> || linux Maverick                           ||    3 ||
[17:03] <apw> || linux Natty                              ||    3 ||
[17:04] <apw> || linux Oneiric                            ||    2 ||
[17:04] <apw> || linux-ec2 Lucid                          ||    3 ||
[17:04] <apw> || linux-fsl-imx51 Lucid                    ||    9 ||
[17:04] <apw> || linux-mvl-dove Lucid                     ||    3 ||
[17:04] <apw> || linux-mvl-dove Maverick                  ||    3 ||
[17:04] <apw> || linux-ti-omap4 Maverick                  ||    9 ||
[17:04] <apw> || linux-ti-omap4 Natty                     ||    3 ||
[17:04] <apw> || linux-ti-omap4 Oneiric                   ||    2 ||
[17:04] <apw> || linux-lts-backport-maverick Lucid        ||    3 ||
[17:04] <apw> || linux-lts-backport-natty Lucid           ||    3 ||
[17:04] <apw> ..
[17:04] <bjf> [TOPIC] Status: Stable Kernel Team (sconklin)
[17:04] <MootBot> New Topic:  Status: Stable Kernel Team (sconklin)
[17:04] <sconklin> ||== Status of kernels ==
[17:04] <sconklin> ||
[17:04] <sconklin> || This is kernel verifiation,
[17:04] <sconklin> || Kernel status for each series is as follows:
[17:04] <sconklin> ||
[17:04] <sconklin> || * [[http://people.canonical.com/~kernel/reports/sru-report.html|Detailed Information Here]]
[17:04] <sconklin> ||
[17:04] <sconklin> ||[17:04] <sconklin> || * [[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/812360|Hardy Tracking Bug]]
[17:04] <sconklin> || * A new kernel is in -proposed, ready for  QA (early)
[17:04] <sconklin> ||
[17:04] <sconklin> ||[17:05] <sconklin> || * [[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813507|Lucid Tracking Bug]]
[17:05] <sconklin> || * A new kernel was built to include one additional patch, and has completed testing
[17:05] <sconklin> ||   It is ready to be published
[17:05] <sconklin> ||
[17:05] <sconklin> ||[17:05] <sconklin> || * [[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/808934|Maverick Tracking Bug]]
[17:05] <sconklin> || * Kernel in -proposed from the last cycle is awaiting regression testing.
[17:05] <sconklin> ||
[17:05] <sconklin> ||[17:05] <sconklin> || * [[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/811180|Natty Tracking Bug]]
[17:05] <sconklin> || * Verification has begun for this kernel, with two bugs remaining to be verified
[17:05] <sconklin> ||
[17:05] <sconklin> ..
[17:05] <bjf> [TOPIC] Security & bugfix kernels - Natty/Maverick/Lucid/Hardy (sconklin)
[17:05] <MootBot> New Topic:  Security & bugfix kernels - Natty/Maverick/Lucid/Hardy (sconklin)
[17:05] <sconklin> ||
[17:05] <sconklin> || Current Kernel versions are always available here: http://people.canonical.com/~kernel/reports/versions.html
[17:05] <sconklin> ||
[17:05] <sconklin> || Package                                    || Upd/Sec              || Proposed             ||  TiP || Verified ||
[17:05] <sconklin> ||                                            ||                      ||                      ||      ||          ||
[17:05] <sconklin> || hardy    linux                             || 2.6.24-29.91         || 2.6.24-29.92         ||    0 ||        0 ||
[17:05] <sconklin> || lucid    linux-meta-lts-backport-maverick  || <IP_ADDRESS>.36         || <IP_ADDRESS>.38         ||    0 ||        0 ||
[17:05] <sconklin> || ---      linux-lts-backport-maverick       || 2.6.35-25.44~lucid1  || 2.6.35-30.56~lucid1  ||   22 ||       22 ||
[17:05] <sconklin> || ---      linux-firmware                    || 1.34.7               || 1.34.10              ||    0 ||        0 ||
[17:05] <sconklin> || ---      linux                             || 2.6.32-33.70         || 2.6.32-33.71         ||    0 ||        0 ||
[17:05] <sconklin> || maverick linux-firmware                    || 1.38.6               || 1.38.8               ||    1 ||        0 ||
[17:06] <sconklin> || ---      linux                             || 2.6.35-30.54         || 2.6.35-30.56         ||    1 ||        1 ||
[17:06] <sconklin> || natty    linux-meta-ti-omap4               ||                      || <IP_ADDRESS>9.7        ||    0 ||        0 ||
[17:06] <sconklin> || ---      linux-backports-modules-2.6.38    || 2.6.38-10.6          || 2.6.38-11.7          ||    0 ||        0 ||
[17:06] <sconklin> || ---      linux-firmware                    ||                      || 1.52.1               ||    0 ||        0 ||
[17:06] <sconklin> || ---      linux                             || 2.6.38-10.46         || 2.6.38-11.47         ||   18 ||       16 ||
[17:06] <sconklin> || ---      linux-ti-omap4                    ||                      || 2.6.38-1209.13       ||   10 ||       10 ||
[17:06] <sconklin> || ---      linux-meta                        || <IP_ADDRESS>.25         || <IP_ADDRESS>.26         ||    0 ||        0 ||
[17:06] <sconklin> ||
[17:06] <sconklin> ..
[17:06] <bjf> [TOPIC] Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:06] <MootBot> New Topic:  Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:06] <bjf> thanks everyone
[17:06] <bjf> #endmeeting
[17:06] <MootBot> Meeting finished at 12:06.
[17:06] <sconklin> thanks
[17:06] <kamal> thanks bjf
[17:07] <apw> bjf thanks


[00:05] <Cheesehead> h00k: dang.
[00:05] <Cheesehead> I can recreate them, but ugh if it happens again!
[00:12] <h00k> 17:54 <        mhall119 > cjohnston: h00k: looks like we're missing all meetings with id 164-176
[00:12] <h00k> standby, Cheesehead
[00:12] <h00k> bigbash: what do you want your Wiki name to be? Usually people do FirstnameLastname
[00:14] <h00k> http://wiki.ubuntu.com/ShawnMcGuire
[00:14] <h00k> bigbash: looks like you already got the hang of it
[00:33] <Cheesehead> h00k: rgr
[00:37] <h00k> Cheesehead: Looks like they lost a few, we'll see what they say. Feel free to idle in #ubuntu-locoteams for more info
[02:59] <lostson> ok then
[03:05] <h00k> okay.
[03:05] <h00k> I purchased a guitar today.
[03:05] <lostson> do you know how to play or is this a new thing ?
[03:06] <h00k> I know a G cord, and a C cord
[03:06] <h00k> as of tonight
[03:06] <lostson> lol
[03:06] <h00k> totally new
[03:06] <lostson> i played for years but havent in a long time
[03:06] <lostson> unless you count guitar hero
[03:51] <h00k> lostson: I don't think that quite counts
[03:51] <lostson> oh
[03:53] <h00k> anyway, my fingers are numbing
[03:53] <h00k> probably time to stop
[03:53] <lostson> heh
[03:54] <Cheesehead> Bach on guitar sounds a lot like Metallica
[03:54] <Cheesehead> If both are done right
[03:54] <h00k> :D
[03:56] <Cheesehead> No joke. Both are wild baroque variations, and hard to tell apart without the cultural context. And both require somewhat unruly long hair...
[03:56] <Cheesehead> Just one was meant for churches
[03:58] <Cheesehead> The other for taverns
[03:58] <Cheesehead> Ooh. That takes it into philosophy
[03:59] <Cheesehead> Too late for that, though. G'night
[03:59] <lostson> ugh running games on 11.04 is a fleeting chore all dirty hacks to make things work
[03:59] <Cheesehead> What kind of games?
[03:59] <Cheesehead> What kind of hacks?
[03:59] <lostson> pick one
[04:00] <h00k> lostson: let me know if you get Lugaru running ;)
[04:00] <lostson> damn unity!!
[04:00] <lostson> damn Unity!! again!
[04:01] <h00k> lostson: are you on Oneric?
[04:01] <h00k> lostson: let me know if you get Lugaru running ;)
[04:01] <h00k> 22:53 <         lostson > heh
[04:01] <lostson> no
[04:01] <h00k> er
[04:01] <lostson> never heard of Lugaru ?
[04:01] <h00k> $ ./.lugaru/lugaru
[04:01] <h00k> SDL_GL_LoadLibrary() failed: Failed loading libGL.so.1
[04:01] <h00k> Segmentation fault (core dumped)
[04:01] <lostson> ouch
[04:01] <h00k> It was in the first Humble Indie Bundle
[04:02] <lostson> libGL errors are always fun to track down
[04:03] <h00k> yeah, I'm not going to try
[04:03] <lostson> usually 2 things either a certain library isnt installed or a coding error
[04:07] <lostson> well lets see apt-get install xubuntu-desktop will solve this problem
[04:07] <lostson> oh crap i have to go take my pills
[04:08] <h00k> good luck
[04:09] <lostson> thanks I kinda think i am gonna need it cant see to get better no matter what the doctors do to me
[04:10] <h00k> lostson: still the ... pneumonia or... what did you have going on? Some infection deal?
[04:11] <lostson> yeah pneumonia with a infection in my blood that is what got me in the hospital for 5 days
[04:16] <lostson> ahh good ol clementine
[04:19] <h00k> okay, I need sleep
[04:19] <h00k> I'm passing out here
[04:19] <lostson> ok good night
[04:19] <h00k> Peace
[15:12] <Cheesehead> h00k: Thanks for creating a new Aug 17 meeting announcement: http://loco.ubuntu.com/meetings/ubuntu-us-wisconsin/178/detail/
[15:13] <Cheesehead> Added three items to that agenda
[21:54] <Cheesehead> A great deal of fun to watch the #ubuntu-locoteams data loss bug slowly gather momentum.
[21:55] <Cheesehead> I really like being the snowflake that triggers the avalanche


[08:08] <nalgene> Hello. Will Ubuntu 17.10 bring the option to encrypt the home directory with ext4's native file-based encryption?
[09:07] <ikonia> nalgene: don't see it on the feature list / roadmap
[09:07] <ikonia> have you tried manually deploying ext4 encypted home yet out of interest
[10:31] <lotuspsychje> can anyone test this if can reproduce this bug? bug 1715604
[10:34] <brunch> on my way
[10:35] <brunch> whoops, I'm already up to date
[10:36] <lotuspsychje> :p
[10:40] <ducasse> lotuspsychje: bug confirmed
[10:43] <lotuspsychje> ducasse: oh thanks for testing mate
[10:43] <lotuspsychje> brunch: can you reproduce aswell? bug 1715604 ?
[10:44] <brunch> lotuspsychje: unfortunaetly there's nothing to update for me
[10:44] <lotuspsychje> brunch: ok tnx anyway mate
[11:03] <flocculant> lotuspsychje: can't reproduce that - if you'd asked last cycle it was like that - also Xubuntu here, not that it should matter in this instance I suspect
[11:08] <pwuertz> Hi, I can't log into my desktop session anymore, presumably after an apt upgrade today. After singing in from the gdm screen, the screen goes black and returns to gdm after a few seconds.
[11:09] <pwuertz> When I switch to a text console and "startx" I seem to get a normal gnome session (not ubuntu-style gnome), working just fine.
[11:11] <lotuspsychje> flocculant: im on gnome, perhaps only gnome related, tnx for trying anyway ;)
[11:11] <flocculant> lotuspsychje: np
[11:12] <lotuspsychje> ducasse: wich DE did you test it on?
[11:12] <ducasse> no de, i3
[11:12] <ducasse> i normally don't use update-manager, so no idea how recently this happened here...
[11:12] <lotuspsychje> kk
[11:13] <pwuertz> Is there a bug in the ubuntu session start up script? How can I track this down and fix it?
[11:13] <lotuspsychje> pwuertz: can you still login via another (previous) kernel?
[11:15] <ducasse> pwuertz: you can also check ~/.xsession-errors
[11:15] <pwuertz> lotuspsychje: no, I only got one 4.12 and one 4.10 (zesty?) kernel. doesn't change the outcome
[11:15] <lotuspsychje> pwuertz: did you update from another version?
[11:16] <pwuertz> ducasse: I looked into .xsession-errors, I cant see any "error"  in there, just a lot of lines like "dbus-update-activation-environment: setting XYZ=VAL"
[11:18] <pwuertz> lotuspsychje: upgraded from 17.04, but 17.10 was already running for a few days, including some reboots, so this seems to be new
[11:18] <pwuertz> lotuspsychje: I guess my home folder (configurations, etc.) is pretty old though
[11:18] <lotuspsychje> pwuertz: thats not recommended to do yet, if you wanna help bugs, install 17.10 clean
[11:25] <pwuertz> lotuspsychje, ducasse: A newly created user is able to log in from gdm, so the system itself appears to be somewhat ok. Its just seems to crash due to some configuration specific to my user. Any idea how to track this down? .xsession-errors doesn't show anything of interest:/
[11:47] <pwuertz> Couldn't find the reason. Made it work again by deleting random desktop related dot-files in home and ~/.config.
[15:08] <graingert> how do I get the transparent bar?
[15:08] <graingert> it seems to stay black forever
[15:08] <graingert> do I need to reset my gnome settings?
[15:08] <lotuspsychje> graingert: you mean the dock?
[15:08] <graingert> lotuspsychje: that's translucent
[15:08] <lotuspsychje> graingert: top bar is already transparant
[15:08] <graingert> already
[15:09] <graingert> lotuspsychje: nope it's opache for me
[15:09] <lotuspsychje> graingert: oh, you want it fully transparant?
[15:09] <graingert> https://usercontent.irccloud-cdn.com/file/yxNb3Bpf/nope.png
[15:10] <lotuspsychje> graingert: this is mine: http://imgur.com/a/nWNk4
[15:10] <lotuspsychje> graingert: wich ubuntu iso did you install?
[15:11] <graingert> lotuspsychje: uhh
[15:11] <graingert> lotuspsychje: quite an old one
[15:11] <graingert> but I'm fully up to date
[15:11] <lotuspsychje> uname -a plz?
[15:11] <lotuspsychje> !info linux-image-generic artful
[15:12] <oerheks> :-)
[15:12] <graingert> lotuspsychje: Linux fester 4.12.0-12-generic #13-Ubuntu SMP Thu Aug 17 16:13:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[15:12] <lotuspsychje> graingert: looks good
[15:13] <graingert> lotuspsychje: yeah I know
[15:13] <graingert> I'm fully up to date remember
[15:13] <graingert> gsettings list-schemas | xargs -n 1 gsettings reset-recursively
[15:13] <lotuspsychje> graingert: seen mine is transparant?
[15:13] <graingert> lotuspsychje: yeah I did
[15:13] <graingert> I might run that &
[15:13] <graingert> ^^
[15:13] <lotuspsychje> graingert: should be good by default right, did you try other themes change?
[15:14] <lotuspsychje> graingert: try gnome-tweak-tool perhaps and change themes
[15:15] <graingert> lotuspsychje: I did a recursive reset just now
[15:15] <graingert> and logged in and out
[15:15] <graingert> and it's still broken
[15:15] <graingert> lotuspsychje: you mean gnome Tweaks?
[15:17] <lotuspsychje> graingert: yeah
[15:17] <graingert> lotuspsychje: I don't have the shell user theme extension installed
[15:18] <graingert> so it's probably not do with that
[15:18] <lotuspsychje> graingert: all vanilla here
[15:18] <graingert> rage
[15:18] <graingert> same
[15:18] <lotuspsychje> graingert: themes:ambiance here
[15:19] <graingert> same
[15:19] <graingert> ubuntu-bug gnome-shell
[15:19] <m0j0dj0dj0> hey, does anyone get difficulties to enable some extension on 17.10 ?
[15:20] <lotuspsychje> m0j0dj0dj0: im not gonna test until final release
[15:20] <graingert> lotuspsychje: oh I thought you were on the new gnome-shell?
[15:20] <lotuspsychje> m0j0dj0dj0: so i know what comes by default and whatnot
[15:20] <lotuspsychje> graingert: your in 17.10 support right
[15:20] <graingert> yeah I'm on the new 17.01
[15:20] <graingert> 10*
[15:20] <graingert> beta
[15:20] <graingert> early hot new saftware
[15:26] <lotuspsychje> graingert: ive tested dash to bottom also via dconf-editor
[15:26] <lotuspsychje> graingert: so perhaps you find some usefull wteaks there for transparant also?
[16:43] <graingert> lotuspsychje: ?
[19:06] <brunch> hello! I want to not use nvidia-prime and just use the discrete card
[19:06] <brunch> is it fine to just uninstall the package? Can I disable it somehow?
[19:34] <ParkerR> Trying out 17.10. Installed Discord via the Snap package (from the Software Center) and get this when trying to run Discord http://ix.io/zFu Any ideas?
[19:38] <ducasse> ParkerR: snaps are supported by their developers
[19:38] <ParkerR> ducasse, Ok thanks. Was just making sure it wasn't just a general error with snaps on artful
[19:40] <ducasse> ParkerR: you could try #snappy, but i imagine they will tell you the same...


[07:55]  * zxmpi looks for a decent tetris clone for dumb nokia...
[09:27]  * zxmpi ponders downloading the entire site i got one from in case i need any other software i found there at a later point :-P
[21:06] <diddledani> ooh, Dave was involved in the sony drm thing back in the day: https://www.youtube.com/watch?v=PqWjq2SdzpI
[21:09] <zxmpi> when people hacked sony it was fair game afterwards :-P
[21:51] <davef> I still remember waking up one morning to 30K e-mails from Sony Japan
[21:52] <davef> They configured one of their services to use a domain I still have to this very day
[21:52] <davef> And it was a catch all for email
[21:53] <diddledani> sounds like they configured an invalid domain name
[21:53] <diddledani> ;-p
[21:53] <davef> Next year will be 20 years with that domain
[21:53] <davef> Creation Date: 2002-10-28T22:30:52Z
[21:54] <daftykins> :D
[21:54] <daftykins> did you manage to contact someone?
[21:54] <diddledani> reply all. STOP!
[21:54] <davef> https://www.whois.com/whois/invaliddomain.com
[21:55] <davef> Yeah, I found their NOC email address and sent a couple of screenshots. Within about an hour, it stopped.
[21:55] <daftykins> \o/
[21:55] <davef> Didn't get a thank you or a message to say "pls delete"
[21:55] <davef> Following that, I think both IBM and Boeing have used the domain in their networks.
[21:55] <davef> I got into a disagreement with a NOC guy at Boeing claiming it was backskatter
[21:56] <davef> But then I replied, no it's not.. I used to work at Boeing, check with so-and-so.. within a few hours I got an apology.
[21:57] <daftykins> :D
[21:57] <davef> These days I don't monitor it
[22:55] <davef> sweet.. my new winter boots just arrived, just in time for tomorrows snowstorm
[22:56] <daftykins> you can wear them all day at home to break 'em in \o/
[22:56] <davef> maybe later
[22:56] <davef> i'm living in my crocs
[22:57] <daftykins> ooh yeah i had forgotten about that admission
[22:57] <davef> crocs > any other shoe
[22:58] <davef> they may look ugly, but holy hell are they comfortable, especially the fabric lined ones
[23:02] <daftykins> for now i think i'm still on the right side of 40 ;)
[23:02]  * daftykins ducks
[23:02] <davef> i got mine before i hit 40
[23:03] <davef> why do companies still ship laptops with such terrible screen resolutions like 1366 x 768?
[23:03] <daftykins> it's horrible indeed, that res needs to be banned
[23:04] <davef> this is in a 11th gen i3, 8gb ram and 512gb ssd
[23:04] <daftykins> unacceptable!
[23:04] <davef> and it's an HP
[23:04] <davef> there's an Acer, only 250G ssd, but has a 15" 1080p display
[23:04] <daftykins> what gets me is why full HD ones always default to scaling to 150% or so on clean installs
[23:05] <zxmpi> super high res is wasted on people over 40?
[23:08] <daftykins> don't think the screen res angle is tied into the >40 topic :D
[23:09] <davef> the thinkpad i was given from work defaulted to 150% ..
[23:13] <daftykins> yeah pretty much default now, i tend to relax to 125% for others and then ship 'em out
[23:35] <davef> ok, breaking in the boots
[23:46] <diddledani> "You're one of 113,990,759 people pwned in the Gravatar data breach" \o/
[23:47] <davef> you too, huh?\
[23:52] <diddledani> I guess I'm gonna receive this to all my email accounts, 'cos I put em all on the same gravatar listing
[23:53] <davef> k, so they didn't get passwords
[23:53] <davef> i couldn't care less if people have my e-mail address
[23:54] <davef> Do I want this? I want this.. https://www.shop.wirelessnetware.ca/ethernet-routers/441-rb5009ugsin.html
[23:55] <diddledani> email addresses aren't private info IMO. I keep on telling people that ask for redaction in WordPress land that emails aren't sensitive in any way whatsoever
[23:55] <diddledani> same with web addresses
[23:56] <davef> right, e-mail addresses are public info.
[23:56] <davef> if somebody asks for my e-mail address, i'll give it to them


[13:21] <Odd_Bloke> uebera||: Can I confirm your issue from a few days ago: changing `500` to `"500"` in your config is what fixed your UID issue?  Or did you end up finding something else going on?
[13:21] <Odd_Bloke> meena: I've been lying on the floor with back pain all of this week so far, which has probably contributed to the silence. :p
[13:41] <uebera||> Odd_Bloke: Yes, just using a string "500" instead of an integer 500 solved my problem with respect to UIDs.
[13:49] <uebera||> If only there was a way to specify GIDs (as far as I understand, a certain patch was not applied). I used runcmd (along with sed) to change the GID of a created account (requires a reboot), but that's really, really dirty.
[14:28] <Odd_Bloke> uebera||: Would you be interested in contributing a gid change?
[14:32] <uebera||> Odd_Bloke: If this --> https://bugs.launchpad.net/cloud-init/+bug/1396362/comments/5 does not apply cleanly anymore, I'd be interested in a modification (have not tested this yet).
[14:33] <uebera||> Given that the VM in question is now up and running, I should have time to look at the above during the weekend.
[16:44] <Odd_Bloke> uebera||: Given that we do now support `uid`, I don't think that patch will cleanly apply (because it includes changes to support `uid`).  If you do end up having time, we'd love the contribution; the getting started guide is here: https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#submitting-your-first-pull-request
[16:46] <Odd_Bloke> (If you hit any hurdles, we're happy to help in here, but note that most of the committers only monitor this channel in ~North American weekday timezones so assistance over the weekend may be sparse. :)
[17:18] <meena> Odd_Bloke: obviiously, the solution to that then is that you should complain about your back pain, whenever that happens. a lot.
[20:17] <uebera||> Odd_Bloke: Thanks for the link, bookmarked. ;)
[20:27] <meena> i cannot believe i was just removed from the Canonical github organisation!
[20:28] <meena> why was i on it again??
[20:33] <powersj> meena, yeah I couldn't recall and all I saw was read-only
[20:33] <powersj> so read-only on a public project didn't make sense
[20:35] <meena> it's just jokey fake outrage
[20:36] <meena> Odd_Bloke: added me like that, so y'all could request me as reviewer
[20:37] <meena> but of course, that probably wasn't documented, and anyway, most authorization UIs don't really have a space for "why", or?


[00:45] <mtaylor> bzr rebase still occasionally spits this out at me: NoSuchRevision: CHKInventoryRepository('file:///home/mordred/src/drizzle/.bzr/repository/') has no revision ('mordred@inaugust.com-20100420210116-ldo67yidt8wbrs0l',)
[00:45] <mtaylor> you know, for what it's worth
[00:59] <lifeless> mtaylor: is there a bug open ?
[01:01] <mtaylor> lifeless: I feel like I filed one like a year ago
[01:03] <mtaylor> oh! I suppose I haven't
[01:03] <mtaylor> there it is
[01:03] <mtaylor> bug#446075
[01:04] <lifeless> bug 446075
[01:04] <lifeless> heh
[01:06] <lifeless> spiv: if you could review my stuff branch that would be great. Its all simple stuff. You'll need to merge locally as lp is still swamped :P
[01:06] <a212901390231901> mtaylor, in case you missed it from this morning:
 lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
[01:06] <a212901390231901> and some of the rest of the log may be of interest to you.
[01:06] <lifeless> a212901390231901: that nick really breaks my mind :)
[01:07] <lifeless> can I call you ed209 ?
[01:07] <a212901390231901> I'm happy with any random string of alphanumerics
[01:09] <spiv> lifeless: Stuff branch?  Heh.  I'll take a look.
[01:09] <lifeless> yeah its just stuff
[01:09] <lifeless> anytime I need to read the bzr code to answer a question, I'm fixing docs up
[01:14] <mtaylor> a212901390231901: neat
[02:09] <lifeless> spiv: how did that review go?
[02:12] <lifeless> oh, i see, gary got to it
[02:12] <lifeless> spiv: however I've pushed more to it this morning already ;)
[02:16] <spiv> lifeless: I just hit "Save comment" as it happens!
[02:16] <lifeless> spiv: thanks!
[02:16] <spiv> lifeless: also, check this out:
[02:17] <spiv> http://paste.ubuntu.com/428000/
[02:18] <lifeless> busy busy
[04:48] <lifeless> spiv: teddy bear time ? [irc]
[04:49] <spiv> lifeless: shoot
[04:49] <lifeless> did you see my chat with james_w earlier?
[04:49] <lifeless> it provides context
[04:49] <spiv> lifeless: I skimmed it
[04:49] <lifeless> ok
[04:50] <lifeless> so, seems to me merge-upstream is /the/ place to put in detection for 'time to do something special'
[04:50] <lifeless> for joining previously unassociated upstreams
[04:50] <spiv> Sounds plausible to me :)
[04:51] <lifeless> secondly, I'm proposing to jsut discard the old file ids
[04:51] <lifeless> and not rewrite history
[04:51] <lifeless> as a first-stage 'get things connected' tool
[04:51] <lifeless> with some logic to handle variations on the theme of 'the distro content is different'
[04:52] <spiv> Fair enough.
[04:53] <lifeless> lastly
[04:53] <lifeless> as a user
[04:54] <lifeless> would you want a 'go run XXX' or a 'about to do XXX [y/n]', or a 'just did XXX' interaction with bzr
[04:55] <spiv> It depends a bit on how easy it is to undo.
[04:55] <mtaylor> lifeless:  'about to do XXX [y/n]'
[04:55] <spiv> Although if the cost of making a mistake is low, then to some extent the choice doesn't matter.
[04:55] <lifeless> spiv: uncommit; revert
[04:55] <lifeless> spiv: as usual ;)
[05:01] <spiv> In that case, 'about to do XXX [y/n]' sounds good because mtaylor likes it ;)
[05:01] <spiv> I think that's definitely nicer than 'go run XXX'
[05:02] <spiv> And probably the 'hey this is a bit unusual, you should know about this' is good.
[05:18] <lifeless> spiv: btw my branch of hydrazine uses the same message format as pqm when its doing the generation
[05:19] <lifeless> spiv: so I was confused when you said they were different the other day
[05:19] <spiv> Hmm, I didn't know that.  I'm pretty sure it's been different at some point.
[05:20] <spiv> Certainly if your branch is different to trunk, and some devs are using trunk, then that's a problem.
[05:20] <spiv> (different in how it uses the commit message field, that is)
[05:21] <lifeless> spiv: poolie was going to merge it, I thought
[05:26] <spiv> Last I looked he hadn't, but I don't know why there's a delay.
[05:29] <lifeless> spiv: ETIME probably
[06:24] <parthm> hello, I sent two proposals (lp:~jbowtie/bzr/fix-555439 and lp:~doxxx/bzr/572092-ignore-dupes ) to queue using feed-pqm.
[06:24] <parthm> is there supposed to be some time lag before they show up on http://pqm.bazaar-vcs.org/ ?
[06:25] <spiv> There isn't supposed to be, but there is ;)
[06:25] <lifeless> yes, 60 seconds
[06:25] <parthm> spiv: :) i am just try to ensure my setup is fine. ... maybe i will wait for some more time.
[06:25] <lifeless> plus mail processing time
[06:26] <spiv> It's usually only a minute or so for emails to be noticed by PQM.
[06:26] <lifeless> total time should be < 3 minutes worst case, unless your mail setup is terrible.
[06:26] <parthm> lifeless: 60 sec. hmm ... maybe something is still wrong with setup.
[06:29] <spiv> lifeless: as an example, notice the commit messages parthm has been setting -- they explicitly include the lp username of the proposer, so they aren't appropriate to use with your hydrazine branch.
[06:30] <spiv> lifeless: basically, I'd like a time machine so we can skip over these awkward transitional phases ;)
[06:32] <parthm> lifeless, spiv: i wasn't sure if i should be including lp username or if the queue adds it during commit. should i be doing that?
[06:32] <parthm> i noticed that the patch i landed yesterday didn't have it so i explicitly put it in today.
[06:34] <spiv> parthm: with current hydrazine trunk, I think you need to add that name manually.
[06:34] <parthm> spiv: will do. thanks.
[06:34] <spiv> parthm: lifeless has a branch that does it automatically
[06:35] <lifeless> parthm: if you're using my branch, you don't need to add it.
[06:35] <lifeless> but you use 'e' rather than 's' to send (e for email)
[06:35] <spiv> It will be nice when that branch is merged into trunk and everyone is using that.
[06:36] <parthm> lifeless: i am using trunk right now. yes, its sounds like a useful change to merge :)
[07:16] <parthm> so for https://code.launchpad.net/~doxxx/bzr/572092-ignore-dupes/+merge/24543 i got a mail from pqm that merge failed, conflict in NEWS.
[07:17] <parthm> its executing "star-merge". what exactly is that? any action on me from this?
[07:17] <spiv> parthm: "star-merge" just PQM-speak for "bzr merge this branch, please"
[07:18] <dash> now there's a term i haven't heard in a while
[07:18] <parthm> spiv: to the right thing to do is to merge locally and push to branch? would i have write access to ~doxxx/bzr/572...?
[07:19] <spiv> parthm: someone needs to resolve the NEWS conflict for PQM to be able to land it.
[07:19] <spiv> You can either ask the original submitter to fix the conflict, or you can just do it yourself.
[07:20] <spiv> You don't have write access to ~doxxx/..., but you can just make your own branch of that and send that to PQM.
[07:20] <parthm> spiv: thanks for clarifying. i will do it myself. shouldn't be too much work.
[07:20] <spiv> Unfortunately that's not particularly convenient using LP and hydrazine.  If I were doing it I'd resort to using 'bzr pqm-submit' from the bzr-pqm plugin.
[07:21] <spiv> You could also do it by creating a new merge proposal on LP for it, I guess.
[07:22] <parthm> spiv: yes. thats what i just though. a new lp proposal sounds like an overkill. i will try bzr pqm-submit. will the set message be retained?
[07:23] <vila> hi all
[07:23] <spiv> Hmm, I guess it would be nice if LP allowed someone from a project's review team to partially take over a merge proposal, i.e. to provide a tweaked version of the branch owned by someone else, but still considered a continuation the same proposal, with the same proposer etc.
[07:24] <spiv> parthm: no, pqm-submit unfortunately can't get any details from LP.  You have to tell it the commit message and the target branch yourself.
[07:24] <spiv> (the latter can have a default set in your config files, though)
[07:24] <parthm> spiv: that would be idea.
[07:24] <parthm> spiv: ok. thanks.
[07:25] <spiv> If you use pqm-submit, be sure to use the --dry-run option first to check the result.
[07:25] <lifeless> so the issue here is that 'review' and 'merge' are conflated.
[07:26] <lifeless> I've opened a bug in launchpad-code about separating this; adding info to that or to john's existing one about other branch landings would be good
[07:26] <parthm> spiv: will do.
[07:29] <parthm> so for 'bzr pqm-submit --dry-run [LOCATION]' should the location be lp:bzr?
[07:29] <parthm> for trunk
[07:30] <MvG> vila: good morning to you!
[07:30] <vila> MvG: _0/
[07:34] <parthm> spiv: hmm. i am getting an error saying lp:bzr isn't local. am i doing something wrong? http://pastebin.com/DDvz2Pc6
[07:35] <vila> parthm: your error error is that you don't know that the plugin doesn't allow lp: urls here, you have to use the resolved form (IIRC)
[07:35] <spiv> parthm: LOCATION is the branch to submit (defaults to the branch in the current working directory)
[07:35] <vila> s/error error/only error/
[07:35] <MvG> vila: thanks for the approval!
[07:35] <vila> MvG: thanks your work :)
[07:35] <spiv> parthm: I think there's somewhere in the bzr HACKING doc that summarises this
[07:36] <spiv> parthm: you probably want to set public_branch for your local dirs in your locations.conf.
[07:37] <spiv> (you can override that as a one-off by passing --public-location to pqm-submit)
[07:38] <spiv> parthm: e.g. when I run "bzr pqm-submit" in a directory called ~/code/bzr/foo, because of my locations.conf it will automatically know to tell PQM to merge lp:~spiv/bzr/foo, rather than file:///home/andrew/code/bzr/foo
[07:39] <spiv> (this is the same setting that the builtin "bzr send" command uses)
[07:39] <parthm> spiv: thanks. i will configure locations.conf.
[07:40] <vila> MvG: lp:~gagern/bzr/bug560030-drop-completions is superseded by https://code.edge.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 right ?
[07:40] <MvG> vila: right.
[07:40] <parthm> spiv: so the public branch with be the trunk i.e. bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ?
[07:41] <vila> MvG: ok, so can you mark the first rejected and fix the NEWS conflict in the second ? The later will allow anybody to land it (instead of fixing it locally)
[07:43] <MvG> vila: Done.
[07:43] <vila> MvG: Yeah ! Thanks !
[07:46]  * parthm reading releasing.html for configuring pqm-submit
[07:50] <parthm> vila: sorry to trouble you with so many questions. does this locations.conf seem right for this merge? http://pastebin.com/0Fg2FJPi
[07:51] <vila> parthm: no trouble, thanks to you for landing stuff !
[07:52]  * vila checks his own setup for trailing '/'
[07:53] <vila> parthm: s/parent_branch/parent_location/
[07:53] <vila> parthm: use http: not bzr+ssh for submit_branch (don't ask)
[07:53] <parthm> vila: will do. thanks. the dry run seems to have gone through ok.  http://pastebin.com/fB3BkEeF
[07:54] <vila> parthm: submit_to ? Did you mean post_commit_to ? Anyway it's irrelevant for pqm-submit I think
[07:55] <parthm> vila: looks like it requires public_branch and not public_location. "bzr: ERROR: There is no public branch set for "/storage/parth/src/bzr.dev/572092-ignore-dupes/"
[07:55] <parthm> vila: i took the config from http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#starting-a-cycle step 10
[07:56] <vila> parthm: I said parent_location, public_branch is correct
[07:56] <vila> parthm: this needs fixing then
[07:56] <spiv> poolie: how's the other side of the world?
[07:56] <poolie> lovely
[07:57] <poolie> crisp and moderately clear
[07:57] <vila> poolie: hey ! Welcome to my continent :)
[07:58] <parthm> vila: this looks fine. time to do without the --dry-run.
[07:58] <vila> winter is making its last attempt, there was snow in the south of France, not seen for... decades
[07:58] <spiv> Ooh!  Hope it stays that way :)
[07:58] <vila> spiv: taling to poolie or me ? :-P
[07:58] <poolie> it was 3C when we landed
[07:58] <vila> s/taling/talking/
[08:00] <parthm> vila: nice. it showed up on http://pqm.bazaar-vcs.org/ ... thanks.
[08:00] <vila> parthm: significant step !
[08:00] <parthm> vila: :)
[08:00] <vila> parthm: and compiling already ! Even better !
[08:01] <MvG> vila: Do you have anyone to suggest as likely second approver of the bash completion plugin merge?
[08:01] <vila> MvG: lifeless commented on the related one, but his pile is already huge... poolie maybe ? :->
[08:02] <poolie> i might but i'm not going to be only online briefly/intermittently this wek
[08:04] <vila> lifeless: can you give a shot at your review queue if only to abstain or nominate some other reviewer ?
[08:04] <MvG> Because the bzr-bash-completion branch is already 3 revisions ahead of the merge request. Among them a generic ExecutableFeature class taking path into account, which I'd like to submit in a separate merge request once the first one has been landed.
[08:06] <vila> MvG: You can use the pre-requisite branch attribute on the mp for that (there is a slight risk of divergence if you need to fix some issues on the pre-requisite itself though)
[08:07] <MvG> vila: I know, but I fear that having too many interdependent merge requests open at the same time might cause confusion and result in all of them getting merged later than if I serialize them.
[08:07] <vila> MvG: But generally starting new feature branches for stuff like that works better as you can then merge them into your other branches
[08:08] <vila> MvG: yeah, YMMV :)
[08:08] <MvG> YMMV?
[08:11] <vila> MvG: Your Mileage May Vary
[08:14] <lifeless> vila: my queue?
[08:14] <lifeless> vila: I think there is only one waiting on me; more-colo
[08:15] <vila> lifeless: far more
[08:15] <lifeless> vila: what ?!
[08:15]  * vila searches the simplest way to find the relevant mps
[08:17] <GaryvdM> lifeless, vila: https://code.edge.launchpad.net/~lifeless/+activereviews
[08:18] <lifeless> no, thats bogus
[08:18]  * vila scratches head.... where are they gone...
[08:19] <lifeless> I mean, I can abstain.
[08:19] <lifeless> but in general I'll say if I want things to block, the default should be not to
[08:20] <GaryvdM> lifeless: https://code.edge.launchpad.net/~amanica/bzr-notification/with_commit_hook/+merge/8166
[08:21] <lifeless> GaryvdM: yes ?
[08:21] <vila> lifeless: https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 you voted needs_fixing, I think it's good now
[08:21] <lifeless> GaryvdM: I did a review on a project I'm tangetially interested in, to help out.
[08:21] <lifeless> GaryvdM: I can't land stuff there
[08:22] <lifeless> vila: then land it; if you agreed with my review *and* think the points are addressed.
[08:22] <lifeless> i wish we still had tweak
[08:22] <vila> https://code.edge.launchpad.net/~jelmer/bzr/split-subsegment/+merge/23611
[08:22] <GaryvdM> lifeless: oh sorry. Thats the wrong one. I ment this one: https://code.edge.launchpad.net/~amanica/bzr/rm_dir_with_changed_emigrated_file-129880/+merge/23528
[08:23] <GaryvdM> lifeless: I think that is ready, but someone has requested your review.
[08:24] <lifeless> GaryvdM: no they haven't
[08:24] <lifeless> GaryvdM: I *did* a review, and its been addressed.
[08:25] <lifeless> vila: I need to look at jelmers updated one; or someone else could look at it.
[08:26] <lifeless> vila: if you're patch pilot, do feel free to do reviews in such cases ;)
[08:26] <vila> lifeless: that's the point, I've been piloting for the last two weeks and I'm not doing it this week
[08:26] <lifeless> vila: ok
[08:26] <lifeless> vila: anyhow, I don't think saying 'this needs fixing' makes you required to sign off on the final patch
[08:27] <GaryvdM> lifeless: The reason I though that, is that there is still a date in the Date Requested col, but I now see that the date is before your last review. Sorry.
[08:27] <GaryvdM> I'll land it :-)
[08:27] <lifeless> GaryvdM: perhaps file a bug on launchpad-code, clearly that is confusing.
[08:27] <vila> lifeless: well, voting Needs_fixing means you've invested time to do some analysis, no need to duplicate that effort
[08:27] <lifeless> vila: but also no need to block
[08:28] <lifeless> vila: and more eyeballs are good
[08:28] <vila> lifeless: more eyeballs are good but upcasting a needs_fixing to approve is... subject to too many interpretations and possible abuses, that's why I'm very uncomfortable doing it
[08:29] <jelmer> lifeless: SRU should probably be possible somewhere before the weekend
[08:29] <lifeless> jelmer: oh, if you can that would rock; I did move the info around to be more accessible
[08:29] <jelmer> lifeless: thanks
[08:30] <vila> lifeless: anyhow, it looks like many reviews I thought were on your queue are not anymore, so I suspect they have been landed and I didn't realize it
[08:30] <jelmer> in other news, roundtripping support in bzr-git is around the corner
[08:30] <spiv> I've taken to saying explicitly "this is Needs Fixing, but once you address these issues consider my vote upgraded to Approved."
[08:31] <vila> lifeless: I had ~8/10 in mind which was obviously wrong
[08:31] <vila> spiv: yup, I've noticed that and do the same now
[08:31] <vila> spiv: but it seems that people are still expecting an explicit approve :)
[08:32] <vila> lifeless: which in turns shows that explicit is better than implicit for reviews too ;)
[08:33] <lifeless> vila: thus why I want tweak.
[08:34] <spiv> lifeless: "me too"
[08:34] <lifeless> spiv: 'affects me' on the bug ?
[08:34] <vila> lifeless, spiv: metoo, bug # ?
[08:35] <lifeless> NFI
[08:35] <lifeless> pretty sure there was one
[08:36] <vila> MFI ?
[08:36] <vila> NFI ?
[08:36] <lifeless> no f* idea ;)
[08:36] <vila> LOL, I found National Forest Inventory (Australia)
[08:36] <spiv> vila: https://bugs.edge.launchpad.net/launchpad-code/+bug/373078
[08:38] <lifeless> vila: from that bug, quoting abentley: 'I'll give you one guess what *I* suggested we call "needs fixing" :-)'
[08:39] <vila> lifeless: I was *just* reading that :)
[08:39] <chx> hi. i would like to remove the changes introduced by revisions 15476-15479 inclusive both ends
[08:41] <GaryvdM> chx: bzr merge . -r 15479..15476
[08:43] <lifeless> GaryvdM: not quite - thats half-open
[08:45] <GaryvdM> lifeless: ? The reverse merge?
[08:45] <chx> 15475 isnt it
[08:45] <chx> this does not seem to roll back 15476
[08:45] <chx> (i will fire someone tomorrow for that commit but for now let's just roll it back)
[08:45] <GaryvdM> chx: oh - right - sorry
[08:45] <GaryvdM> lifeless: got it.
[08:47] <lifeless> -> dinner
[08:53] <GaryvdM> vila: Active review count = 16 :-)
[08:54] <vila> GaryvdM: thanks !
[08:55] <GaryvdM> vila: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669 has allready been reviewed, and just needs approval for 2.1. I'd rather abstain. Can you make a call.
[08:59] <vila> GaryvdM: done
[09:00] <GaryvdM> vila: Cool. There are some unlanded approved branches. I'm going to tackel that.
[09:01] <vila> GaryvdM: excellent ! Stay in touch with parthm, I think he's doing the same
[09:02] <bialix> heya
[09:02] <GaryvdM> Hi
[09:02] <parthm> GaryvdM: I have already landed the ones I was involved with. http://pqm.bazaar-vcs.org/ For https://code.launchpad.net/~parthm/bzr/563646-commit-unicode-message/+merge/23752
[09:03] <parthm> i am waiting to hear for poolie as he has requested a review.
[09:03] <GaryvdM> pathm: Ok, cool. I can also see on http://pqm.bazaar-vcs.org/ which ones have allready been submitted.
[09:04] <spiv> parthm, GaryvdM: thanks!
[09:04] <parthm> GaryvdM: i don't plan to submit anything today so i think we are good :)
[09:05] <parthm> spiv: np :) its nice to see the queue become shorter ... thanks for your help getting pqm setup here.
[09:06] <bialix> hi GaryvdM
[09:11] <vila> bialix: \o_
[09:11] <bialix> vila: \o/
[09:12]  * spiv imagines TCP-over-semaphore-over-IRC
[09:12] <bialix> what's "all stars party"?
[09:13] <vila> spiv: :-P
[09:13] <vila> bialix: at the end of the party, you see all stars
[09:13] <vila> or something like that :)
[09:13] <bialix> stars?
[09:14] <vila> bialix: kidding, music event where all UDS members can play some instrument or another, or just watch, optionally dring some beer
[09:14] <GaryvdM> bialix: http://daniel.holba.ch/blog/?p=633
[09:14] <vila> well, drink first, then dring after a few ones
[09:15] <GaryvdM> bialix: as in rock stars.
[09:20] <bialix> will abentley rocks?
[09:21] <jelmer> abentley already rocks
[09:27] <bialix> сщщд
[09:27] <bialix> cool
[09:36] <chx> gnight, thanks
[09:51] <GaryvdM> bialix: Would you like me to submit your clean-tree  branches ?
[09:52] <bialix> GaryvdM: many thanks!
[09:52] <GaryvdM> Ok
[10:06] <GaryvdM> Dose anyone have a script that deletes merged branches in a share repo?
[10:07] <a212901390231901> I just do it manually ;)
[10:08] <a212901390231901> I guess as you've been on a landing spree you might have a few more than me
[10:09] <GaryvdM> Yip. Might try write a plugin later.
[10:10] <bialix> bzr-colo ftw!
[10:13] <parthm> GaryvdM: I just noticed that ~jbowtie/bzr/fix-555439 is in the queue twice. I am assuming the changes would already be merged after the first time so that 2nd time would be a no op. right?
[10:13] <a212901390231901> yeah, might get a complaining email though
[10:14]  * GaryvdM looks
[10:14] <jelmer> lifeless: btw, I pushed a newer version of my segment url patch a couple of days ago
[10:15] <GaryvdM> parthm: Thanks for catching that
[10:15] <GaryvdM> I've got some time to try figure out how to cancel it.
[10:17] <parthm> GaryvdM: is it required to be cancelled or its just a no op. i would guess bzr should say 'nothing to merge' the second time. but maybe someone who has used the queue more than me can comment.
[10:17] <sproaty> is there a way to insert revision ID/last modified details etc to a file like svn rev ids?
[10:17] <parthm> sproaty: bzr help version-info
[10:18] <GaryvdM> parthm: I would prefer to try cancel it.
[10:18] <sproaty> cheers, wasn't sure what term to be searching for
[10:19] <parthm> GaryvdM: yup. even for a no op ... the tests might take time to run ;) ... unless there is a check for that.
[10:19]  * parthm is interested in how to cancel too ... hasn't done that before.
[10:24] <GaryvdM> vila: Is it possible to cancel a pqm submission?
[10:25] <sproaty> parthm, but is there a way to insert the version-info into a file on commit?
[10:29] <parthm> sproaty: maybe the keywords plugin will be helpful, though i haven't used it myself http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
[10:31] <sproaty> thanks :)
[10:32] <parthm> sproaty: alternatively, 'bzr help hooks'
[10:32] <parthm> sproaty: http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html
[10:37] <bialix> sproaty: no
[10:46] <parthm> sproaty: just wondering. what are you trying to do. keywords is generally not considered to be a good idea.
[10:51] <vila> GaryvdM: no you can't, the dirty trick, if you're fast enough is to push some garbage
[10:51] <GaryvdM> vila: or delete the branch :-)
[10:51] <vila> GaryvdM: right :)
[10:52] <GaryvdM> Oh
[10:52] <GaryvdM> Not my branch, so I can't :-(
[10:53] <parthm> vila: what will happen if we just let the second request be? will it be a no-op .. because the changes are already in?
[10:54] <vila> http://pqm.bazaar-vcs.org/ says Request for non-PQM managed branch.
[10:54] <vila> GaryvdM: is that the one ?
[10:54] <GaryvdM> vila: No Num 3
[10:54] <vila> parthm: if you  try to merge the same branch twice, pqm will say: 'Nothing to merge'
[10:54] <parthm> vila: will the tests be run?
[10:54] <vila> GaryvdM: what's the problem there ?
[10:54] <parthm> again.
[10:54] <vila> parthm: no
[10:55] <GaryvdM> vila: duplicate.
[10:55] <parthm> vila: nice.
[10:55] <vila> GaryvdM: as in 'sent twice' ?
[10:55] <GaryvdM> vila: yes
[10:55] <vila> GaryvdM: no worries then
[10:56] <GaryvdM> vila: number 6 (Request for non-PQM managed branch) was for --submit-branch=lp:bzr/2.1
[10:56] <vila> GaryvdM: you may get confusing mails about it, just update your bzr.dev branch to check
[10:56] <vila> GaryvdM: weird, may be you don't have rights there ?
[10:57] <GaryvdM> vila: Does pqm understand lp: urls?
[10:57] <vila> GaryvdM: I don't remember the exact status here, it used to understand them but there were also bugs
[10:58] <vila> I think that's why I use http: urls now
[10:58] <GaryvdM> vila: Ok, i'll see what happens, and resubmit if it fails.
[10:58] <vila> GaryvdM: ok, thanks again
[10:59] <GaryvdM> vila: sure, np.
[11:00] <GaryvdM> vila: thanks for the help
[12:02] <sproaty> just thought it'd be nice to have my files auto have their last revision date stored
[12:03] <quicksilver> I don't think bzr does RCS/CVS substs
[12:08] <maxb> sproaty: ooi, why is that useful?
[12:09] <sproaty> to other developers I guess
[12:09] <maxb> I'm curious because some people at my work seem to think the same, but they've never really come up with a convincing argument why :-)
[12:09] <quicksilver> well, it's quite nice to have last modification dates visible on documentation / on web pages
[12:09] <sproaty> seen some code under svn that does it
[12:10] <sproaty> or in the code itself :p
[12:10] <maxb> The problem is that keywords only help you there if it's meaningful to consider the individual file in isolation
[12:12] <sproaty> it's no big deal, really
[12:12] <maxb> https://launchpad.net/bzr-keywords exists, but I still maintain that it's a feature people use because CVS had it, not because it's actually useful
[12:12]  * jelmer thinks maxb has a point
[12:13] <sproaty> probably not worth the effort
[12:14] <LeoNerd> If you want to see the last mod. date on a web page, you'll be wanting some kind of web frontend to your VCS, which puts that information around it
[12:14] <maxb> And moreover, you'll want info about the tree, not about a particular file
[12:14] <sproaty> my code's only displayed in loggerhead
[12:15] <maxb> heh, then you don't need keywords at all
[12:15] <quicksilver> LeoNerd: that's not what I meant.
[12:15] <sproaty> that damn css bugs where long commit messages overflow into the file list stops me from writing long (i.e meaningful)  commit messages
[12:16] <quicksilver> LeoNerd: I meant some file or files from a tree might end up being deployed to a visible web page.
[12:16] <quicksilver> for example, you might use bzr as the versioning system for your personal website, etc.
[12:17] <Peng_> sproaty: I don't see that issue, but maybe it's just cuz I have a wide monitor.
[12:18] <LeoNerd> quicksilver: Oh, I see.. Well, again, that's an issue for the surrounding context. My website engine puts last mod date in the page template. :)
[12:18] <quicksilver> LeoNerd: sure, that's a valid solution but it doesn't mean it's the only solution.
[12:18] <quicksilver> LeoNerd: there is no law again a plain static HTML websit eyou know
[12:19] <LeoNerd> No, indeed.. but now you're heading down into really special-cased scenarios
[12:19] <LeoNerd> It's already handled by a plugin in those corner-cases you need it
[12:19] <Peng_> sproaty: I know I've read something about that bug, but I don't know if it's been fixed. And I'm officially AFK, so I don't want to check now. :P
[12:19] <Peng_> sproaty: If you're not running Loggerhead's trunk (lp:loggerhead), it may have been fixed.
[12:19]  * Peng_ shrugs
[12:20] <sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/revision/253
[12:21] <Peng_> Ooh, on the revision page.
[12:21] <sproaty> sorry
[12:21] <Peng_> Pah, I'm AFK, I'm AFK! I refuse to get drawn into work. Especially web design, yuck!  I don't think this is working out how I intended. :P
[13:20] <sproaty> so much for AFK :)
[15:02] <GaryvdM> Hi amanica.
[15:02] <amanica> Hi GaryvdM
[15:03] <GaryvdM> amanica: I've finished that fix that I started at the release party.
[15:03] <amanica> sweet
[15:03] <GaryvdM> where if you run bzr qcommit . nothing is selected.
[15:07] <amanica> GaryvdM: I pulled it now, and it seems to work perfectly now. Thanks!
[15:07] <GaryvdM> amanica: Tell me again about that checkbox that you wanted to add to qcommit. What command line option should it add?
[15:07] <amanica> its an option I add with my plugin
[15:08] <amanica> but I've been wondering if commit can support a pre-commit registry
[15:08] <amanica> then we can have a single --force
[15:08] <amanica> which will work for all of these types of pre-commit checks
[15:09] <GaryvdM> amanica:  Does the plugin raise an error if the option is maybe needed?
[15:09] <amanica> yes if my validations fail, I raise an error
[15:09] <amanica> thats how you can stop the commit from going through
[15:10] <GaryvdM> amanica: Ok - I have an idea. Is it a public plugin?
[15:10] <amanica> So I was thinking we can add a --force which will ignore errs thrown by the pre-commit-hook
[15:10] <amanica> yes
[15:11] <GaryvdM> Url?
[15:11] <amanica> bzr+ssh://bazaar.launchpad.net/%7Eamanica/bzr-text-checker/trunk/
[15:11] <GaryvdM> amanica: Cool - I'll take a look.
[15:12] <GaryvdM> amanica: Bye - I'm off to coach at the rink.
[15:12] <amanica> cool thanks, don't worry too much
[15:13] <amanica> I think if the core can support it better, we can know better what I need in qbzr
[15:13] <amanica> bye GaryvdM
[15:13] <amanica> better url: https://edge.launchpad.net/bzr-text-checker
[15:45] <Guest36545> i want to remove a subdir from bzr version control.  'bzr rm (.../subdir)' actually deletes the target.  not what i wanted :-/  how do i do it without deleting it?
[15:46] <dash> bzr rm --keep
[15:47] <Guest36545> same cmd, bur DELETE is the default?  dangerous ...
[15:49] <amanica> Guest36545: it only deletes it if it can be done safely, i.e. it can be recoverd from the revision history
[15:51] <Zathras> hi. what is best (and why): on a shared hosting server with ssh, python, no gcc: virtual python or the system's python? I want bazaar+webfrontend and preferably trac if possible
[15:51] <Zathras> (hoster is awardspace.com (paid))
[15:55] <Peng_> Zathras: Best is if you can convince your host to install all that stuff for you -- and keep it up-to-date.
[15:56] <Peng_> Zathras: Bazaar and Loggerhead (not that it's easy to run in a shared hosting situation, but...) may be a moving target, but at the least they can install all the dependencies, Paste and simplejson and whatnot.
[16:00] <Zathras> like 0 change a hoster will do that and take responsibility....
[16:01] <Zathras> I looked at Git and Mercurial before. Although perl and python based I ran into trouble by not having a C compiler available
[16:01] <Peng_> Git is mostly C,
[16:01] <Peng_> Neither Bazaar and Mercurial require a C compiler; there are Python versions of all of the C bits.
[16:02] <Zathras> Mercurial installer insisted on having a C compiler
[16:03] <Zathras> I was a bit surprised
[16:03] <Peng_> Zathras: You can pass an option so it doesn't.
[16:03] <Peng_> Anyway this ain't #mercurial.
[16:04] <Zathras> yup. Because it did not work for me I started looking at Bazaar. That's why I am asking
[16:08] <Peng_> Heh, well, it should work in Mercurial. make local --pure or somesuch.
[16:08] <Peng_> Although that requires make... Hm. setup.py can do it too.
[16:12] <Zathras> ty
[16:13] <Peng_> Note that Mercurial hasn't supported this forever, but it's been at least a few releases.
[16:59] <NET||abuse> arrrg,,, can't remember how to push a new project up to my webserver
[17:00] <NET||abuse> bzr push bzr+ssh://me@mydomain.com:/var/www/website/src/bzrdir/       does that not do it?
[17:02] <bialix> where is pqm web-front page?
[17:02] <bialix> NET||abuse: ater my.domain should be /
[17:03] <bialix> no :
[17:03] <Peng_> bialix: http://pqm.bazaar-vcs.org/ ?
[17:03] <bialix> Peng_: yep,
[17:03] <Peng_> NET||abuse: Bazaar uses HTTP-style URIs, not SSH or rsync or whatever.
[17:03] <NET||abuse> aoh
[17:04] <bialix> it's strange but pqm.bazaar.canonical.com does not work. yet?
[17:04] <Peng_> Oh, I forgot about the "bazaar.canonical.com" thing.
[17:04] <NET||abuse> yay, worked,, now how long will this take to push.......
[17:04] <bialix> GaryvdM: can you send merge request for my 2.1 clean tree patch?
[17:05] <Peng_> NET||abuse: Depends on your Internet connection, Bazaar version, repo format, and the size of the repo.
[17:05] <NET||abuse> indeed.
[17:05] <NET||abuse> slow enough connection. : )
[17:05] <Peng_> :D
[17:07] <NET||abuse> borrowed wifi from local cafe :)
[17:07] <NET||abuse> 2Mbit if i'm lucky
[17:08] <NET||abuse> hmm, Fetching revisions:Get stream source.... what does that mean?
[17:10] <NET||abuse> it's been sitting on the above message for a good long while.
[17:10] <NET||abuse> the .bzr directory is 58MB
[17:11] <NET||abuse> should it take that long.
[17:11] <NET||abuse> 37 MB of that is in 58 assets files, big gimp and inkscape drawings
[17:12] <NET||abuse> large png's
[17:13] <Peng_> Ah...
[17:13] <Peng_> Yeah, I think that's been fixed.
[17:15] <NET||abuse> arrg,, it just sat there for ages,,
[17:15] <NET||abuse> done nothing
[17:15] <NET||abuse> i canceld out of it, now it says it locked
[17:17] <Peng_> NET||abuse: It wasn't doing nothing. It was waiting for the server to do a bunch of stuff and then start transferring data.
[17:17] <Peng_> NET||abuse: bzr break-lock $the_url
[17:17] <Peng_> NET||abuse: IIRC this has been improved, maybe just in lp:bzr.
[17:17] <NET||abuse> yeh, that worked.
[17:18] <NET||abuse> ah, no, it was actually just doing nothing before, now the push is working
[17:18] <NET||abuse> it's actually Inserting.
[17:18] <NET||abuse> or i hope it is :P
[17:19] <NET||abuse> need a better connection :P
[17:19] <NET||abuse> held up again, probably the assets this time.. it is alphabetical isn't it
[17:20] <NET||abuse> oh shoot,, i have the cakephp docs pdf in there.. what was I doin with that.
[17:20] <NET||abuse> maybe i should ignore assets
[17:20] <Peng_> NET||abuse: How do you know it was doing nothing? Like I said, the server was doing stuff, and the client was waiting for it.
[17:20] <Peng_> That's highly distinct from nothing.
[17:21] <NET||abuse> the server wasn't likely responding as it shot past the same phase it was in last time.
[17:21] <NET||abuse> now it's stuck saying       /     81KB   157KB/s | Fetching revisions:Inserting stream
[17:21]  * Peng_ shrugs.
[17:22] <NET||abuse> i'm on bzr 2.1.1   is that version ok in terms of weirdness?
[17:22] <NET||abuse> stupid me, uploading 14MB pdf.
[17:22] <Peng_> Dunno.
[17:23] <NET||abuse> server is only on 2.0.3
[17:24] <Peng_> 2.0.3 is definitely too old.
[17:25] <NET||abuse> it's also an old ubuntu hardy server
[17:26] <NET||abuse> there we are, got 2.1.0 from update
[17:27] <NET||abuse> ahh, actually .<IP_ADDRESS>
[17:31] <NET||abuse> ok, now it's taking ages to get through   "Fetching Revisions:Get Stream Source"   but the remote repo is a bare empty standalone repo
[17:32] <NET||abuse> on the server i just ran bzr init   on a directory, did nothing else.
[17:32] <NET||abuse> now just running bzr push bzr+ssh://me@host/path/to/bzrdir
[17:38] <NET||abuse> nah this is silly, i removed the 14MB file from the assets, and checked in the local bzr repo again.
[17:39] <NET||abuse> running push and it is just sitting on   " \      2KB     0KB/s | Fetching revisions:Get stream source"   for ever, i went off and changed clothes and came back,
[17:42] <NET||abuse> ok, blew away the old bzr dir on the remote server, and re-created it, i've in the interim updated the server bzr from 2.0.3 to 2.1.1,, now when i push to the new bzr directory from my laptop's repo, it is sitting on  /     72KB   140KB/s | Fetching revisions:Inserting stream
[17:42] <NET||abuse> right, i have to go to the shop,,
[17:42] <NET||abuse> it's almost dinner time.
[17:44] <NET||abuse> ok, still no change, exact same readout.
[17:45] <Peng_> I wonder if something is horribly wrong with the server? Like, it starts swapping or something?
[17:45] <Peng_> Do htop or ~/.bzr.log say anything interesting?
[17:45] <Peng_> What about pushing over sftp (or nosmart+bzr+ssh)?
[17:47] <NET||abuse> htop on the remote server?
[17:48] <NET||abuse> hehe, no htop command on my server
[17:48] <Peng_> Install it. It rocks. :D
[17:50] <NET||abuse> Peng_,  ahhhhhhhhhhh it's started doing stuff,,
[17:50] <NET||abuse> veeeeery slowly.
[17:51] <NET||abuse> htop says memory is onlyl 430 of 2011MB
[17:52] <NET||abuse> ok, 17690KB done on the Inserting stream phase,,,,, i'm goin to the shop to get stuff for dinner :)
[17:52] <NET||abuse> Peng_, cheers for that,, htop rules
[17:52] <Peng_> :D
[17:52] <NET||abuse> CPU load is down at 0.7%
[17:52] <NET||abuse> this server has 23 sites on it though
[17:52] <NET||abuse> running quiet
[17:52] <NET||abuse> Swp is 0
[17:54] <NET||abuse> bzr only using 3.1MB
[17:54] <NET||abuse> nice,, love being able to scroll through the processes :)
[17:55] <NET||abuse> and  tree view,, nice
[17:55] <NET||abuse> ooh, f10 doesn't work to exit as it's a shortcut in gnome
[17:55] <Peng_> q exits, IIRC
[17:57] <mtaylor> you guys are generalizing lp-submit from pipelines and putting it in to core, right?
[18:05] <james_w> mtaylor: it's already in the launchpad plugin in the version I have
[18:05] <mtaylor> james_w: ooh neat
[18:05] <mtaylor> james_w: what's the command called now? is it still lp-submit or did it change?
[18:05] <james_w> that's now an alias, along with lp-propose, for lp-propose-merge
[18:06] <mtaylor> omg. that's the best thing I've ever heard
[18:06]  * mtaylor needs to upgrade to new v of bzr
[18:06] <mtaylor> when is 2.2 coming out?
[18:06] <mtaylor> :)
[18:07] <james_w> not sure actually
[18:07] <mtaylor> heh.
[18:07] <mtaylor> well, while I'm bugging you (I'm doing a thing in just a bit showing bzr/launchpad integration...)
[18:07] <mtaylor> is there any way to associate a branch with a blueprint on the cmd line?
[18:08] <Peng_> "python -c 'import launchpadlib; ...'" ? :D
[18:09] <james_w> I don't know of one
[18:12] <mtaylor> hehe
[18:12] <mtaylor> ok. just checking
[18:17] <bialix> mtaylor: august
[18:17] <mtaylor> bialix: sweet. thanks
[18:49] <thrope> is there a download tarball feature for loggerhead yet?
[18:50] <beuno> thrope, no, but there's a branch up for review that I need to get to
[18:50] <thrope> ah ok - it would be really cool!
[18:50] <beuno> it will  :)
[18:50] <beuno> probably not enabled on Launchpad
[18:50] <thrope> has the loggerhead repo moved again? I dont have any updates since nov
[18:50] <beuno> but for other people...
[18:50] <beuno> no, lp:loggerhead
[18:50] <thrope> i am using  http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/
[18:50] <beuno> that should be it
[18:50] <beuno> and there should be updates
[18:51] <thrope> oh wait pull instead of update - too used to using checkouts :|
[18:51] <kojiro> I kinda fail at using bzr+svn. So to pull new stuff from svn, I have to merge, and then commit?
[18:53] <thrope> beuno: my branch has diverged - i have a commit i pulled from michael hudson to fix relative links - is that in main now?
[18:53] <dash> kojiro: if your branch has diverged from the svn branch, yeah
[18:53] <beuno> thrope, I don't know, to be honest
[18:54] <dash> kojiro: it's the same as getting changes from a remote bzr branch. either you pull or you merge.
[18:54] <kojiro> dash: how can I say, "give my working branch the exact same layout as the remote svn repo and nuke all the differences on my side?"
[18:54] <kojiro> I'm just not used to DVCS semantics yet.
[18:55] <dash> kojiro: 'bzr pull --overwrite'
[18:55] <kojiro> aha
[18:55] <kojiro> thanks :)
[18:58] <Peng_> thrope: If Bazaar warns you that it diverged, it means you have revisions that aren't in the branch you're trying to pull.
[18:58] <Peng_> thrope: There's some ancient branch entitled relative-links rotting in the review queue, so I imagine it has not landed.
[18:58] <thrope> yeah it hasnt
[18:58] <Peng_> thrope: Um. There are other neat things, though. And you can probably merge the relative-links branch again.
[18:58] <thrope> its a shame because its quite important
[18:59] <Peng_> Might be conflicts, but..
[18:59] <thrope> im trying to run loggerhead behind ssh
[18:59] <thrope> sorry i mean https
[18:59] <thrope> without relative links everything breaks
[19:00] <Peng_> thrope: I wonder if it would be saner if you ran it through FastCGI instead of a proxy.
[19:00] <Peng_> https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 <-- Oh, look, I reviewed it.
[19:01] <Peng_> And then it sat and rotted.
[19:01] <thrope> yeah I am using proxypass in apache
[19:06] <thrope> it seemed to merge ok into a fresh branch so its working fine for now - thanks
[19:07] <thrope> ill keep an eye out for the tarball update
[19:20] <Peng_> thrope: Thanks for the prod. I'm working on relative-links right now. I think it might actually be trivial to fix the review issues, in which case it might actually get merged someday. :D
[19:21] <beuno> Peng_, you fix it and I'll merge
[19:27] <thrope> cool thanks
[19:32] <Peng_> Fixing the review was easy enough; it's the other potential issues I noticed that are the problem. :-\
[19:52] <Peng_> beuno & thrope: https://code.edge.launchpad.net/~mnordhoff/loggerhead/relative-links/+merge/24767
[19:53] <beuno> Peng_, looking
[19:53] <Peng_> thrope: Y'know, even with the relative-links branch, Loggerhead will still generate absolute links for HTTP redirects and some bits of the feed.
[19:54] <thrope> feed means rss? Im not so worried about that
[19:55] <thrope> i want to run loggerhead behind https with apache user auth... in one case I want https://bzr.domain.com/ and in another i want https://domain.com/bzr
[19:55] <thrope> if theres another way to do it relatively easily I would be happy to try
[19:55] <Peng_> thrope: I wonder if running Loggerhead over FastCGI would behave better.
[19:55] <beuno> Peng_, looks good, land!
[19:56] <thrope> i dont think that was available when I set it up but i will check it now
[19:56] <thrope> going to eat actually but be back in a bit
[19:57] <Peng_> beuno: Alright.
[19:57] <Peng_> thrope: Yeah, FastCGI (and SCGI and mod_wsgi and ...) are a recent addition.
[20:16] <cobalt_mike> is there any document/page besides http://doc.bazaar.canonical.com/bzr.2.1/downloads/pdf-developers/bzr-en-architecture-overview.pdf that describes the bzr architecture?
[20:18] <Peng_> thrope: Anyway, relative-links has landed in lp:loggerhead, so you don't need to go "bzr merge"ing anymore.
[20:28] <kkaefer> hi
[20:28] <kkaefer> is it possible to rename a tag?
[20:28] <kkaefer> To rename a tag (change the name but keep it on the same revsion), run ``bzr
[20:28] <kkaefer>   tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``.
[20:29] <GaryvdM> kkaefer: yes
[20:29] <kkaefer> ok ;)
[20:29] <kkaefer> answered my own question
[20:29] <Peng_> kkaefer: The old tag won't be deleted when you push to other branches, though.
[20:29] <GaryvdM> kkaefer: :-)
[20:36] <dutchie> is there a way to make a repo smaller? clean up old unused stuff etc
[20:37] <dutchie> ah, bzr pack
[20:52] <Peng_> dutchie: "bzr pack" doesn't "clean up old unused stuff", it just reorganizes (and, in 2a, recompresses) the existing data.
[20:52] <Peng_> dutchie: In fact, since it makes a backup first, you usually end up with twice as much disk space being used.
[20:52] <dutchie> oh
[20:52] <dutchie> how handy
[20:52] <dutchie> though it seems to have made it about 8MB smaller
[20:53] <Peng_> Bazaar doesn't have an equivalent of "git gc".
[20:53] <Peng_> Well, the removing-unused-stuff aspect.
[21:05] <mtaylor> abentley: any chance bzr sync-pipeline could eventually support pushing all of the pipeline branches to launchpad in one command?
[21:05] <abentley> mtaylor, how would that be different from what it does now?
[21:05] <mtaylor> like, bzr sync-pipeline lp:~mordred/drizzle - and it would just push to lp:~mordred/drizzle/${pipe-nick}
[21:05] <mtaylor> abentley: oh - does that work?
[21:05] <mtaylor> wow
[21:06] <mtaylor> the docs didn't make it sound like it would - lemme go try it out :)
[21:08] <abentley> mtaylor, the one difference is that you specify the push location of your current pipe, and it works out the rest.
[21:09] <mtaylor> abentley: neat!
[21:09] <Peng_> "Transferring revisions 0/3029" That can't be good...
[21:09] <mtaylor> abentley: do I still have to lp-submit them individually?
[21:09] <abentley> mtaylor, yes.
[21:10] <abentley> mtaylor, actually lp-submit is now in bzr core, renamed to lp-propose.
[21:11] <mtaylor> abentley: I've heard about that! but that's not going to be released until august I hear
[21:11] <mtaylor> so I can't talk about it in the context of core in the current presentation I'm working on
[21:13] <mtaylor> but I'm quite excited about it
[21:14] <abentley> Hmm.  I guess this is the downside of calling our monthly releases 'betas'.
[21:18] <Phoenixz> Problem: Somebody deleted some files that should not have been deleted. He pushed those changes to my repo, now I dont have those files either. I can see the files with bzr ls -r revision-before-deleting, bzr cat even shows content, but how can I recover those files directly withouth having to copy content one by one using bzr cat? svn has a cp that can do this, but bzr doesnt.. anybody?
[21:19] <Peng_> Phoenixz: "bzr revert"...?
[21:20] <dash> Phoenixz: you can do 'bzr revert -r good-revision', which will change your working copy to match that revision
[21:20] <Phoenixz> dash: ah, that sounds like what I need.. thanks!
[22:00] <lifeless> james_w: AROUND ?
[22:00] <lifeless> bah
[22:00] <lifeless> around ?
[22:00] <jelmer> 'morning lifeless
[22:01] <james_w> lifeless: YES
[22:01] <lifeless> :P
[22:02] <lifeless> how would you feel if I added a dep on testresources to bzr-builddeb?
[22:02] <james_w> it's packaged?
[22:02] <lifeless> (rmadison python-testresources for availability info)
[22:02] <lifeless> build-dep only
[22:02] <james_w> my fingers are already in the IRC window :-)
[22:03] <james_w> yep, I'm ok with that
[22:03] <lifeless> cool, thanks
[23:12] <jelmer> lifeless: if you have a chance, any review of my updated segment-url patch would be much appreciated :-)
[23:12] <lifeless> ok
[23:15] <mwhudson> Peng_: thanks for poking at the relative links thing
[23:23] <Peng_> :)
[23:23]  * Peng_ goes AFK again
[23:26] <thrope> Peng_: thanks... I think maybe it closes this bug https://bugs.launchpad.net/loggerhead/+bug/527330
[23:26] <thrope> I'd also be interested if there is any wsgi /fastcgi info
[23:26] <thrope> or documentation
[23:27] <thrope> I used mod_wsgi at some point and I think it was quite easy to set up... but I can still run 2 seperate loggerhead instances from the same apache
[23:40] <Peng_> Oh, has the mod_wsgi stuff landed yet?
[23:40] <Peng_> Anyway I'm AFK! :P
[23:42] <Guest53807> Is there anyway I can have the actual folder stored in lets say /misc/bazaar/<projectname> but have the branch look like /<projectname> so that I can do bzr push ssh+bzr://myserver.com/projectname ?
[23:45] <Peng_> TuxIce: Yes, but I'm not sure how easy it would be.
[23:45] <TuxIce> Hmm
[23:45] <Peng_> TuxIce: Umm. One of the scripts in contrib/ should help. I think.
[23:45] <Peng_> I swear I'm really AFK! :(
[23:46] <TuxIce> contrib/ in bzr's source?
[23:46] <Peng_> Yeah
[23:47] <TuxIce> Launchpad uses /~ubuntu-art-pkg/+branch/<package>/ubuntu does that mean the home directory ubuntu-art-pkg, folder +branch, folder <package>, folder ubuntu, or are they using clever rewriting or something?
[23:48] <TresEquis> TuxIce: ~ubuntu-art-pkg is the homedir of the team
[23:49] <TresEquis> +branch is a "view" identifier
[23:49] <TresEquis> so it is the "branch" view on that homedir
[23:49] <TuxIce> Yes. But I can't see ~ubuntu-art-pkg/+branch/<package>/... being a file system directory, so I'd assume launchpad somehow rewrites the url?
[23:49] <TresEquis> with '<package>/ubuntu" as the subpath passed to the view
[23:49] <TresEquis> its not on the filesystem
[23:50] <TresEquis> its in an appserver
[23:50] <Peng_> TuxIce: Launchpad uses a custom SSH server.
[23:50] <TuxIce> Oh
[23:50] <Peng_> TuxIce: (Using twisted.conch.)
[23:50]  * Peng_ really goes AFK!
[23:50] <TuxIce> Whats an appserver?
[23:51] <TresEquis> hmm, I thought we were talking about the webserver
[23:51] <TresEquis> the '+branch' bit is a Zope3-ism
[23:51] <TuxIce> Whats a Zope3-ism?
[23:51] <TuxIce> :P
[23:51] <thumper> you don't need +branch
[23:52] <thumper> in fact I'm tempted to remove   the redirect that we have in the code
[23:52] <thumper> it should be issuing permanent redirects
[23:52] <TuxIce> How about +source?
[23:53] <TuxIce> Such as https://launchpad.net/ubuntu/lucid/+source/bzr/ ?
[23:53] <TresEquis> I knew we were talking about a webserver here
[23:53] <TuxIce> Does the bzr command just make an http request?
[23:54] <thumper> TuxIce: that url points to the source package, not a branch
[23:54] <TuxIce> Mmhmm
[23:54] <TuxIce> So launchpad serves up URL's of their own scheme by using a custom ssh server?
[23:55] <TresEquis> bzr+ssh:// URLs would use the twisted.conch things
[23:55] <thumper> TuxIce: yes
[23:55] <thumper> TuxIce: the layout on disk is completely different
[23:55] <TuxIce> Of course
[23:55] <TresEquis> but http:// or https:// are going through an HTTP server, not an SSH server, right?
[23:55] <TuxIce> Thats what I'm attempting to do.
[23:55] <thumper> TresEquis: we have a complex rewrite map program
[23:56] <thumper> TuxIce: jml started to extract the core custom ssh server stuff into a new project
[23:56] <thumper> TuxIce: but I think it stalled
[23:56] <TuxIce> So, If I'm correct, you can branch using an http:// or https:// url, which would pull from a webserver?
[23:56] <TuxIce> I see.
[23:57] <thumper> I think for bazaar.launchpad.net https issues a redirect to http
[23:57] <TresEquis> TuxIce: yes, you can serve branches as static pages via apache
[23:57] <TuxIce> And then to commit+push, you have to communicate with an ssh (sftp to be more correct) server?
[23:57] <thumper> but yes, served by apache with a rewrite
[23:57] <thumper> TuxIce: well, we use bzr+ssh
[23:57] <TuxIce> I see.
[23:57] <TresEquis> TuxIce: it is possible to push over HTTP, if auth is set up
[23:57] <TresEquis> I don't think LP does that, though
[23:58] <thumper> no
[23:58] <thumper> we don't
[23:58] <TresEquis> but loggerhead can be configured to allow it
[23:58] <thumper> configured to allow what?
[23:58] <TuxIce> ANd bzr+ssh is an alternative to sftp, correct?
[23:58] <thumper> pushes?
[23:58] <TresEquis> push over HTTP
[23:58] <thumper> TuxIce: sftp is a dumb file level transport, whereas bzr is the smart server protocol
[23:59]  * TuxIce nods
[23:59] <thumper> TuxIce: bzr can operate directly or over ssh
[23:59] <TuxIce> What do you mean directly?
[23:59] <thumper> TuxIce: as in listening on a particular port (not sure which one)
[23:59] <TresEquis> thumper: bzr:// URLs require running the BZR server process, or putting it in inetd
[23:59] <thumper> TresEquis: yes


[06:32] <alkisg> Hi all. Could someone be so kind and sync ltsp from unstable to focal? I uploaded a one-bug/security fix release to unstable, but I don't yet have rights to upload it to focal...
[06:35] <Unit193> Ah, aka: https://github.com/ltsp/ltsp/commit/ecca725849f4653db06d625b4d9d903b7afb943b
[06:35] <alkisg> Righto :)
[06:36] <Unit193> alkisg is your LP username?
[06:36] <alkisg> Yes
[06:36] <Unit193> Done.
[06:36] <alkisg> Thank you Unit193, have a great day!
[06:36] <Unit193> You as well.
[08:34] <tarzeau> what are the chances to get in hpx if it gets an ACCEPT from ftp-master into debian? https://repology.org/project/hpx/versions (it's important for HPC users)
[10:04] <doko> tarzeau: file a FFe
[10:27] <ginggs> FFe not needed for new packages https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages
[10:27] <ginggs> tarzeau: i think you'll just need to file a sync request (or run requestsync)
[10:29] <tarzeau> great infos, thanks.
[11:15] <rbalint> doko, i've filed LP: #186854 , could you please take a look? i can add more of the template if needed
[11:16] <rbalint> LP: #1868542
[14:09] <ddstreet> Laney unfortunately, i am able to reproduce the systemd failure using the main autopkgtest server, but when i test with my own autopkgtest setup, the tests pass :(
[14:11] <ddstreet> rbalint do you have any idea what might be causing the systemd-upstream autopkgtest failures?  they all seem to hang right after/during installing the newly-built systemd packages
[14:15] <rbalint> ddstreet, no, sorry, seems like an infra issue :-(
[14:17] <ddstreet> yeah, unfortunately it does, it may need Laney or someone with access to the autopkgtest instances to debug :(
[14:18] <ddstreet> for reference, here is the log from a run using my upstream ppa build on the main autopkgtest servers, that fails<EMAIL_ADDRESS>[14:19] <ddstreet> and a log with the same upstream ppa build, but on my own autopkgtest deployment, that passes<EMAIL_ADDRESS>[14:25] <gpiccoli> o/ bdmurray - I received an email about increase in libvirt crash reports after a release with a patch from me reached -updates, hence stopping phasing
[14:26] <gpiccoli> It points a link with a chart, etc..but I cannot see any of those crash. I'd like to have access to data to try correlate those crashes with my (small and non-intrusive) patch, or discard the correlation
[14:26] <gpiccoli> This is the link: https://errors.ubuntu.com/?release=Ubuntu%2018.04&package=libvirt&version=4.0.0-1ubuntu8.15&period=week
[14:26] <ahasenack> cpaelzer: some assistance please? I'm failing to understand why dpkg-gensymbols wants me to add the 0ubuntu1 suffix to the symbols file: https://paste.ubuntu.com/p/GRrg7jvdcP/
[14:26] <gpiccoli> I cannot open the crash reports though, it says I don't have permission. If you or anybody here can help me on this, I appreciate
[14:26] <ahasenack> cpaelzer: and lintian says the binary deb has them, and complains about that:
[14:26] <ahasenack> $ lintian -I --pedantic
[14:26] <ahasenack> E: libcbor0.6: symbols-file-contains-current-version-with-debian-revision on symbol _cbor_alloc_multiple@Base and 230 others
[14:27] <ahasenack> cpaelzer: d/libcbor0.6.symbols: https://paste.ubuntu.com/p/kvgprG3qQj/
[14:27] <gpiccoli> [please ping my nick whenever talking back to me, I'll detach the channel! =) ]
[14:27] <ahasenack> maybe it's related to old debhelper? The package is using 9, I intend to update it
[14:28] <ddstreet> gpiccoli i have access to the error reports, i'll take a look
[14:29] <Laney> ddstreet: feel free to file an RT to get access temporarily in order to let you look at it interactively there
[14:30] <gpiccoli> Thanks a lot ddstreet =)
[14:30] <Laney> 'infra issue' could mean a lot of things couldn't it
[14:32] <gpiccoli> I'm not sure if cpaelzer highlights on libvirt, but I guess worth highlight him for awareness
[14:32] <cpaelzer> ahasenack: reading ..
[14:32] <cpaelzer> gpiccoli: I'm highlighting on it :-)
[14:33] <cpaelzer> ahasenack: you are right not to add the ubuntu1 suffix
[14:34] <cpaelzer> ahasenack: your file has "libcbor.so.0.6.0 libcbor0.6 #MINVER#"
[14:34] <ahasenack> oh
[14:34] <gpiccoli> hehe cool cpaelzer =)
[14:34] <cpaelzer> but needs "libcbor.so.0.6 libcbor0.6 #MINVER#"
[14:34] <ahasenack> it's soname, and package
[14:34] <cpaelzer> ahasenack: the rest you can keep as-is
[14:34] <ahasenack> got it
[14:34] <ahasenack> thanks
[14:34] <cpaelzer> ahasenack: did this have a symbols file before?
[14:35] <ahasenack> yes
[14:35] <cpaelzer> ahasenack: if yes could you keep all symbols that existed before at the version they were before?
[14:35] <ahasenack> they were kept
[14:35] <ahasenack> oh
[14:35] <ahasenack> at 0.5.0 you mean
[14:35] <cpaelzer> yes
[14:35] <ahasenack> ok
[14:35] <cpaelzer> that will give you a list of only a few that are added on 0.6.0
[14:35] <cpaelzer> that helps dh_shlibs and such tools to make better dependencies
[14:36] <cpaelzer> e.g. >= 0.5.0 if it only uses symbols out of that
[14:36] <cpaelzer> now with you gpiccoli
[14:36] <cpaelzer> gpiccoli: you have to wait for the data to load
[14:36] <cpaelzer> (usually)
[14:37] <ddstreet> gpiccoli in that error report i'm only seeing a small number of captured errors, and none of them are new; they've all been seen on previous versions of libvirt
[14:37] <gpiccoli> exactly ddstreet, that was my impression too
[14:37] <gpiccoli> Not related with the new versions
[14:38] <gpiccoli> cpaelzer, it seems there are files I could get...but I don't have permissions
[14:38] <ddstreet> i'll let bdmurray decide if they can be ignored when he gets in, but it seems like they probably can
[14:38] <gpiccoli> nifty ddstreet, I hope so
[14:38] <cpaelzer> this happens quite often on packages that are installed a lot and have services
[14:38] <ddstreet> yeah, do ask him if you can have access to the error tracker, it's useful
[14:38] <cpaelzer> service gets restarted and due to local config breakage an old error is crashing it (again)
[14:39] <gpiccoli> oh, so it explains what happens cpaelzer, ty!
[14:39] <cpaelzer> and I agree to ddstreet none of these look "new" like "added with your patch"
[14:40] <gpiccoli> outstanding, thank you both for that! let's then discuss with bdmurray when he gets in =)
[14:40] <cpaelzer> gpiccoli: I usually reply to the mail send it to bdmurray and explain why it can be ignored
[14:41] <cpaelzer> with some more words than what we had here, but still similar in content
[14:41] <cpaelzer> e.g. comparing the signatures seen with what the patch changed
[14:41] <gpiccoli> cpaelzer, but I didn't feel comfortable in ignoring that without looking those reports
[14:41] <cpaelzer> yep gpiccoli and reaching out was the right choice
[14:41] <cpaelzer> thank you
[14:42] <gpiccoli> thank you for the information Christian!
[14:50] <ahasenack> cpaelzer: did you ping someone about the builders being sluggish?
[14:50] <ahasenack> you mentioned dep8 before I think, but I'm noticing something wrong with the builders too
[14:52] <ahasenack> I just pinged ops
[15:16] <cpaelzer> ahasenack: I had no issue with builders yet
[15:16] <cpaelzer> ahasenack: just a long test queue
[15:16] <cpaelzer> and it wasn't slow, just a long queue
[15:16] <cpaelzer> something big must have appeared in focal
[17:53] <ahasenack> I'm always confused by this statement in the debian policy: "The package build should be as verbose as reasonably possible,"
[17:53] <ahasenack> does that mean d/rules should always have DH_VERBOSE=1?
[17:54] <ahasenack> rbasak: any opinion on that? ^
[18:03] <cjwatson> I don't think that's the usual interpretation
[18:03] <cjwatson> It generally means showing compiler commands and such
[18:04] <cjwatson> It's not necessarily an unreasonable interpretation, but it's not the usual one
[18:04] <ahasenack> ok, thanks
[19:00] <rbasak> ahasenack: if someone said to me that policy means that DH_VERBOSE=1 be set in all debian/rules files, I'd argue that debhelper should have its default changed.
[19:00] <rbasak> (if that were true)
[19:00] <rbasak> So to me it doesn't follow that we should set that in the usual case.
[19:00] <rbasak> !dmb-ping
[21:44] <GunnarHj> Hi bdmurray, There are a few verified SRU proposals at bug #1844853. There are also some minor autopkgtest failures, but our suggestion is to disregard those. My question is if the autopkgtest failures cause those items to not show up as 'ready to be considered' to the SRU team.
[21:46] <bdmurray> GunnarHj: On the pending SRU report you can see the regressions are called out there, so yes we consider them not ready. https://people.canonical.com/~ubuntu-archive/pending-sru.html
[21:48] <bdmurray> Any suggestion about disregarding tests should be made in one of the SRU bugs
[22:33] <GunnarHj> bdmurray: But we have already done that. In comment #30 and #31 at bug #1844853 (where the verification was documented) I referred to L_aney's suggestions to disregard them. So now I'm trying to call the SRU team's attention to it. :)
[22:43] <LocutusOfBorg> GunnarHj, did you ask me about unicode-data?
[22:44] <LocutusOfBorg> I remember somebody asking, but forgot who
[22:44] <LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3989/+packages
[22:44] <LocutusOfBorg> in case, please upload there ^^
[22:44] <GunnarHj> LocutusOfBorg: Nope. I just made a note on the bug that I think it's a good idea.
[22:45] <bdmurray> GunnarHj: got it
[22:46] <GunnarHj> bdmurray: Do you possibly have time to look at it?
[22:49] <bdmurray> GunnarHj: everything but Eoan based on L_aney's comment right?
[22:51] <GunnarHj> bdmurray: eoan also, see https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1850932/comments/12 (but let's drop disco...)
[22:51] <LocutusOfBorg> mmm strange, I can't find anymore the log here
[22:52] <LocutusOfBorg> GunnarHj, I meant, ibus merge, that was depending on unicode-data
[22:53] <bdmurray> GunnarHj: Yes, I can have a look shortly
[22:54] <GunnarHj> LocutusOfBorg: That's correct. I have a proposed upload at https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus, and if you can take that into account it would be great.
[22:55] <GunnarHj> bdmurray: Great, TIA!
[22:57] <LocutusOfBorg> uploaded thanks
[22:57] <LocutusOfBorg> will go in as soon and if release team acks the unicode transition
[22:59] <GunnarHj> LocutusOfBorg: Nice!