[13:10] <teste1> hi
[13:10] <teste1> anybody here?
[13:13] <teste1> hello?
[14:06] <jfi> Hi, the creator of a private bug cannot see it? https://bugs.launchpad.net/psensor/+bug/1394590
[14:07] <teward> jfi: looks like that's because it's not against Ubuntu but an upstream LP project
[14:07] <teward> jfi: i.e. the psensor project on Launchpad.
[14:08] <jfi> teward, well, I have created it against psensor project by error, then I change it to the ubuntu psensor package, and then....can no more see it:(
[14:08] <teward> so only the bug supervisor for that project can see the private bugs
[14:08] <jfi> I am the supervisor of the psensor project
[14:09] <teward> jfi: well... it doesn't look like its against the Package to me...
[14:09] <teward> and as bugcontrol I'd see it...
[14:09] <teward> or at least should
[14:09] <jfi> maybe I did a mistake when changing the concerned package:(
[14:11] <teward> it's possible.  I can't tell from here.  I can confirm I can see the private bugs against psensor though in Ubuntu.
[20:44]  * eliasps is away: I'm away or busy, leave a message and I'll get back to you.
[21:13] <teward> eliasps: you need to turn that off
[21:16] <eliasps> teward turn what off? The "away" message?
[21:16] <teward> yep - the autoaway messages add noise everywhere
[21:17] <teward> point being that you don't need to announce your being away to the world
[21:19] <eliasps> I'm not sure I follow, but turned it off rather than starting a pointless argument. Sorry for the inconvenience.
[21:20] <teward> https://wiki.ubuntu.com/IRC/Guidelines
[21:20] <teward> "Don't use public away messages"
[21:20]  * teward leaves that there as he goes to tackle closing ancient bugs via the LP API


[00:25] <jjohansen> back on later
[12:30] <Kano> hi, why do i still need to hack the controls for the daily kernel?
[12:31] <Kano> module-init-tools should not be higher than the version in hardy for those kernels, otherwise it is useless. hacking with dpkg-deb takes ages on slower systems


[15:57] <attente> hi, i'm trying to sru bubblewrap to xenial: https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1649330
[15:57] <ubot5`> Ubuntu bug 1649330 in bubblewrap (Ubuntu) "[SRU] bubblewrap unavailable on xenial" [Undecided,New]
[15:58] <attente> i'm not sure what the process is for sru'ing a new package there, is there something i need to do? i don't have upload rights
[16:02] <rbasak> attente: there's not much of a defined process as it's a pretty rare thing. You'll need sponsorship, an archive admin's approval, and an SRU team member's approval.
[16:02] <rbasak> attente: and you'll need to prepare the upload.
[16:03] <rbasak> I won't know what ordering to recommend.
[16:03] <rbasak> don't know
[16:03] <rbasak> If it were me, I'd seek approval from everyone involved before getting a sponsor to upload, since that avoids tangling stuff up with Launchpad technicalities.
[16:04] <rbasak> The archive admin and SRU team member may be the same person, I don't know.
[16:04] <rbasak> Hope that helps.
[16:04] <rbasak> And I'd prepare the proposed upload in a git or bzr tree, so that every reviewer can review in one place instead of the scattergun-and-reject-from-the-queue approach.
[16:05] <attente> rbasak: ok, thanks
[16:07] <rbasak> attente: OTOH, consider using the backports pocket, but I presume you've already ruled that out for some reason?
[16:08] <attente> rbasak: i believe the integration tests don't run in an environment with backports enabled
[16:08] <attente> rbasak: (this is for a snapcraft branch)
[16:10] <rbasak> If that's the only reason, it sounds like the integration tests need fixing to work with backports, rather than putting the package in updates just because of that.
[16:11] <attente> is it ok to generally assume that backports will be enabled on a user's machine?
[16:12] <attente> if this branch gets merged, then snapcraft on xenial will require that once that's sru'd
[16:12] <rbasak> I believe backports is generally available by default but pinned from packages from it being used except when specifically requested.
[16:12] <rbasak> If snapcraft is in updates, it shouldn't have a dependency on backports.
[16:12] <rbasak> So that's a more solid reason that this needs to go into updates.
[16:12] <rbasak> (or it's a reason that snapcraft should have been in backports, depending on your perspective)
[16:13] <attente> snapcraft is generally sru'd back to xenial, right?
[16:13] <rbasak> I don't know.
[16:14] <attente> i see for example: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1614322
[16:14] <ubot5`> Ubuntu bug 1614322 in snapcraft (Ubuntu Yakkety) "[SRU] New stable micro release 2.15" [Undecided,Fix released]
[16:15] <attente> so my impression is that backports might not be enough for this case
[16:17] <rbasak> It does sound that way.
[16:22] <attente> rbasak: would it be frowned upon if i copied the packaging from yakkety's or zesty's archive?
[16:23] <rbasak> attente: no, that's absolutely fine.
[16:23] <rbasak> attente: just add a new changelog entry to the top, and get the package versioning right. Assuming it works :-)
[16:23] <attente> rbasak: sounds good, thanks! :)


[05:35] <centaur5> A preseed file that I used with Hardy doesn't point an Intrepid install the right mirror and it still stops for a user when it's not supposed to. Did something change?
[16:46] <CIA-2> finish-install: cjwatson * r825 ubuntu/ (29 files in 3 dirs): merge from Debian 2.22
[16:47] <CIA-2> finish-install: cjwatson * r826 ubuntu/finish-install.d/90console: more -8 handling
[16:49] <CIA-2> finish-install: cjwatson * r827 ubuntu/debian/changelog: releasing version 2.22ubuntu1
[16:56] <CIA-2> netcfg: cjwatson * r633 ubuntu/ (31 files in 3 dirs): merge from Debian 1.46
[17:05] <CIA-2> netcfg: cjwatson * r634 ubuntu/debian/changelog: releasing version 1.46ubuntu1
[17:43] <CIA-2> yaboot-installer: cjwatson * r264 ubuntu/ (34 files in 3 dirs): merge from Debian 1.1.14
[17:45] <CIA-2> yaboot-installer: cjwatson * r265 ubuntu/debian/changelog: releasing version 1.1.14ubuntu1
[17:54] <CIA-2> usb-creator: evand * r60 usb-creator/scripts/install.py: Add missing block size parameter to dd.
[18:25] <CIA-2> usb-creator: evand * r61 usb-creator/ (bin/usb-creator debian/changelog): Add -t option to write a trace file.
[19:15] <CIA-2> usb-creator: evand * r62 usb-creator/ (Makefile debian/changelog po/POTFILES.in setup.cfg):
[19:15] <CIA-2> usb-creator: * Don't include all .py files in the tree for translation.
[19:15] <CIA-2> usb-creator: * Don't update the pot file on every build.
[20:41] <CIA-2> usb-creator: evand * r63 usb-creator/ (debian/changelog scripts/install.py usbcreator/backend.py): Write more information to the log (subprocesses, stderr, etc).