[00:46] <studio-user178> help
[00:47] <studio-user178> bye then
[00:47] <studio-user178> no one is here
[03:48] <idosedthekoolaid> howdae
[08:47] <studio-user054> hello
[11:57] <strk> hi there, I'm about to try installing ubuntustudio on an old laptop - first question: will I be guided toward partitioning of disk to keep the current OS as a boot option ?
[11:58] <strk> as I'm not the laptop owner, and the owner asked me not to wipe out her OS...
[11:58] <cfhowlett> strk, "install ubuntu next to windows" should appear.  if it doesn't, consider your options.
[12:09] <strk> thanks, we'll see :)
[12:10] <strk> what do you suggest to use for multi-track live recording ?
[12:10] <strk> music recording, that is
[12:11] <cfhowlett> strk, ardour seems to the best bet but not my area of speciality.  !opensourcemusicans would know better
[12:22] <strk> what's that !prefix ? a gnusocial group ? :)
[12:23] <cfhowlett> strk, irc channel.  sorry.  should be #opensourcemusicians
[14:42] <OvenWerks> strk: Ardour is a full DAW, it is great for recording audio and midi inputs inputs. Qtractor is a tracker if you are used to that kind of thing. LMMS tries to be fruity loops like, but is midi in only.
[14:54] <strk> thanks OvenWerks, Ardour seem to be what we're looking for then
[14:56] <OvenWerks> strk: in case you care ardour hs packages for linux, OSx and windows these days. There are now enough included plugins that it is possible to use the same session file from one to the next. So a session directory created on windows should work on linux and vise versa.
[14:56] <strk> thank, that might help, in case my friend refuses to run a linux :)
[14:57] <strk> now I wonder if I should try it out on my minipc (fanless, which would be great for music :)
[14:57] <strk> Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz
[14:57] <strk> Audio device: Intel Corporation Broadwell-U Audio Controller (rev 08)
[14:58] <strk> packaged ardour on my system (debian 8) would be Version: 1:2.8.16+git20131003+dfsg1-1~deb8u1
[14:59] <OvenWerks> There are some people who record on their desktop and then mixdown on a laptop while on a train etc. or just the oposite using a laptop to record live and mix at home.
[14:59] <OvenWerks> that sounds really old
[14:59] <strk> ardour or the audio card ?
[15:00] <OvenWerks> ardour
[15:00] <strk> debian stable...
[15:00] <OvenWerks> ardour is at 5.5
[15:00] <strk> would Ardour be used for both live recording and mixing ?
[15:00] <OvenWerks> yes
[15:01] <OvenWerks> the latest package for ubuntu 16.04 is ardour 5.0
[15:02] <OvenWerks> ardour 2.8 is before midi.
[15:02] <strk> I dont' have a midi card anyway
[15:02] <strk> was thinking about buying one, as I have an electric piano with a midi port
[15:02] <strk> an 88 keys gem
[15:03] <OvenWerks> if it has a USB port it may well show up as midi ports anyway.
[15:03] <strk>  no USB port
[15:03] <strk> (on the piano)
[15:04] <OvenWerks> I use an old AudioPCI card for midi (joy stick port)
[15:05] <strk> the piano has midi in/out, audio in/out and an headphone
[15:05] <strk> I had an old audio pci card somewhere but I guess I would not have any compatible slot by now (sooo old)
[15:05] <OvenWerks> My DX7 is the same.
[15:06] <strk> in 2009 I first attempted to put a computer near the piano
[15:06] <strk> but the fan noise convinced me it was not worth it
[15:06] <OvenWerks> :)
[15:06] <strk> now that I have this fanless pc I might try again
[15:06] <strk> only it's the home theater pc, hooked on the back of the monitor in the family room
[15:07] <strk> I'm not sure if a low-latency / realtime kernel would be stable enough for Kodi too
[15:07] <strk> I've read there could be freezes ?
[15:07] <OvenWerks> low latency wouldn't hurt
[15:08] <OvenWerks> the low latency kernel is the generic kernel with one parameter change
[15:08] <strk> so I could just configure grub to have a menu entry for that, eventually ?
[15:08] <OvenWerks> It allows preempt to work
[15:08] <OvenWerks> ubuntustudio should come that way.
[15:09] <strk> yep, but that one I'm not going to install here, uhm... unless I keep the boot time choice between the two (debian8-with-kodi / ubuntustudio)
[15:09] <strk> you mean ubuntustudio should come with the boot-time choice between realtime and not ?
[15:10] <OvenWerks> ubuntu studio comes with lowlatency, but if you install generic as well you can choose at boot time.
[15:11] <OvenWerks> The latest lowlatency is always default though.
[15:14] <strk> do you know if the debian package linux-image-rt-amd64 would also do the grub option ?
[15:15] <strk> oh well, bigger problems anyway: "Some packages could not be installed."...
[15:15] <strk> unmet dependencies: linux-image-rt-amd64 : Depends: linux-image-4.8.0-0.bpo.2-rt-amd64
[15:17] <strk> does ardour have it's own apt repository, btw ? to get a more recent version more easily ?
[15:24] <strk> sorry, I just realized what channel this was


[00:03] <tsimonq2> slangasek: Just cron.daily or cron.daily-live too?
[00:04] <slangasek> don't know yet
[00:04] <slangasek> :)
[00:04] <slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/artful/lubuntu/
[00:04] <tsimonq2> ack
[00:18] <tsimonq2> slangasek: So why does it show as successful then? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-20180105.log
[00:18] <tsimonq2> This is on Nusakan itself, not an LP builder, correct?
[00:24] <wxl> if i read slangasek's email correctly, we will be re-releasing 17.10 to fix the SPI bug, but the Meltdown/Spectre fixes will come in kernel updates, right?
[00:24] <tsimonq2> Correct.
[00:25] <slangasek> tsimonq2: it's successful because I manually hit enter at the prompt.  But it should not prompt interactively just because I ran the command with a controlling tty
[00:25] <tsimonq2> slangasek: ohhh, ic now...
[00:26] <slangasek> and yes, it also affects lubuntu live ;)
[00:26] <nacc> wxl: yeah
[00:27] <wxl> thx release team for your hard work on this! (and to the kernel team as well)
[00:27] <tsimonq2> ^^^^
[00:31] <valorie> amen to that
[00:31] <valorie> thank you thank you thank you
[00:31] <valorie> my emails asking for testing have gone out
[00:31] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Dot One] (20180105) has been added
[00:31] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Dot One] (20180105) has been added
[00:51] <tsimonq2> slangasek: So I've figured out what needs to happen. Would something like this be acceptable? https://paste.ubuntu.com/26329048/
[00:51] <tsimonq2> slangasek: As long as that env var is set, it won't prompt for anything, but I'm unsure if setting an env var in that way will ensure it gets passed to git from germinate...
[00:55] <tsimonq2> slangasek: (er, I can test this locally, my point is, what way would you prefer I set the env var?)
[00:56] <slangasek> tsimonq2: rather, you should pass an env argument to proxy_check_call (which is a wrapper around subprocess.check_call).
[00:56] <slangasek> tsimonq2: cheatsheet: https://stackoverflow.com/questions/2231227/python-subprocess-popen-with-a-modified-environment
[00:57] <tsimonq2> slangasek: thanks
[01:01] -queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Dot One] (20180106) has been added
[01:02] -queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Dot One] (20180106) has been added
[01:03] <tsimonq2> slangasek: incoming: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/make-git-noninteractive/+merge/335789
[01:03] <tsimonq2> slangasek: Also, Lubuntu Next shouldn't get 17.10.1 builds ;)
[01:06] <slangasek> tsimonq2: ack, I forgot that directory was empty; how about I delete the directory
[01:06] <tsimonq2> slangasek: sure np
[01:11] <slangasek> tsimonq2: did you run 'run-tests'?
[01:13] <tsimonq2> slangasek: er, good point... let me fix these...
[01:17] <tsimonq2> slangasek: (nothing's broken except the tests fwiw)
[01:36] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Dot One] (20180106) has been added
[01:36] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Dot One] (20180106) has been added
[01:52] <smoser> hey. just want to make sure this is expected..
[01:53] <smoser> ah. never mind.
[01:53] <smoser> no builds yet. was wondering why a package let in yesterday wasnt in archive.
[01:53] <smoser> thanks for listening :)
[01:58] <slangasek> :)
[02:01] <tsimonq2> slangasek: I'm probably really overthinking this but I keep getting an error code of 256 and I'm having trouble figuring out how to fix it
[02:01] <tsimonq2> I'll keep trying things but any pointers would really be appreciated
[02:02] <slangasek> tsimonq2: after modifying the germinate_command() function to include the same env logic?
[02:03] <tsimonq2> slangasek: Yes.
[02:04] <tsimonq2> slangasek: I tried this:
[02:04] <tsimonq2> -                    ], cwd=os.path.join(germinate_output, arch))
[02:04] <tsimonq2> +                    ], cwd=os.path.join(germinate_output, arch),
[02:04] <tsimonq2> +                       env=dict(os.environ, GIT_TERMINAL_PROMPT="false"))
[02:04] <tsimonq2> Because that's the same logic, no?
[02:05] <slangasek> yes
[02:05] <tsimonq2> Specifically: AssertionError: Calls not found. -- that's the error
[02:06] <slangasek> when I apply that and run it here, I see the same failure; if I compare the calls, I see the 'actual' list includes an additional lockfile call?
[02:08] <tsimonq2> Hmm.
[02:08] <slangasek> don't know anything beyond that and am afk for now, sorry
[02:08] <tsimonq2> Alright, thanks anyways
[02:09] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Dot One] (20180106) has been added
[02:09] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Dot One] (20180106) has been added
[02:30] <tsimonq2> slangasek: So it ended up being a *one* *line* *fix* - but what you said did help. But I did learn something about Python unit testing in the progress...
[05:04] <nacc_> tsimonq2: fyi, the documented value is 0
[05:05] <nacc_> tsimonq2: not "false" (see `man git`)
[05:05] <nacc_> tsimonq2: I mentioned that value (0) earlier
[05:06] <tsimonq2> nacc_: Oh, thanks
[05:06] <tsimonq2> Gah, where'd he go? :)
[05:07] <nacc> tsimonq2: np :) (and now i'm afk for real too :)
[05:07] <tsimonq2> o/
[09:46] <flocculant> slangasek: I don't appear to be able to get iso's from Artful Dot One ... both 32 and 64 bit give me a 404
[09:47] <flocculant> checked a couple of other flavours and ubuntu - all 404
[09:52] <flocculant> they 'can' be grabbed ok from cdimage.ubuntu.com/xubuntu/artful/daily-live/current/  at least - but I suspect everyone else points their testers to the tracker, I know I did ;)
[09:58] <acheronuk> flocculant: same for kubuntu. the qa tracker url points to /kubuntu/daily-live/20180105.2/ folder, whereas the actua images are in /kubuntu/artful/daily-live/20180105.2/
[09:58] <acheronuk> *actual
[09:58] <flocculant> acheronuk: yea - you were one of the other flavours I looked at :p
[10:01] <acheronuk> not done any announcing yet, so good catch
[10:04] <acheronuk> tsimonq2: lubuntu is also 404, so guess they all are (which is logical)
[10:04] <flocculant> acheronuk: that was the other flavour :D
[17:24] <wxl> flocculant: can't we just go on the tracker and change the URLs?
[17:31] <flocculant> wxl - no idea, never seen that anywhere
[17:32] <flocculant> wxl - just point people at the cd.image url for the time being
[17:32] <wxl> well it looks like it should just work http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/497/downloads
[17:33] <flocculant> never seen that
[17:33] <wxl> with great power comes great curiousity XD
[17:36] <flocculant> :)
[17:46] <wxl> well anyways i can't figure it out if it is possible so oh well
[17:52] <flocculant> probably is - on the other hand it could go horribly wrong
[17:52] <flocculant> for you - cos I would wait ;)
[18:18] <wxl> hm are bionic dailies halted?
[18:19] <wxl> everyone's stuck at 20180103 it seems.. except for Lubuntu alternates which are ahead and the rest of the Lubuntu images which are behind but rebuilding
[18:47] <jbicha> wxl: I assume that's because LP isn't building anything now (see the /topic )
[18:48] <wxl> yeah i guess that's true, jbicha, except for the fact that it's clear that's not true XD
[18:49] <wxl> again, lubuntu has a fresh release
[18:49] <wxl> not to mention artful dot one
[18:51] <jbicha> bionic hasn't changed in a few days anyway
[18:53] <wxl> it has for lubuntu
[18:53] <jbicha> I'm guessing it's all related to Meltdown/Spectre; there's no need for bionic dailies right now, but we do need a 17.10 release since 17.04 is nearly EOL
[19:39] <slangasek> flocculant: sorry, fixes for the code on the tracker are welcome, but in the meantime people will just have to find the correct URLs manually
[19:41] <flocculant> slangasek: no problem - have a good weekend :)
[19:41] <wxl> ouch that sucks


[07:45] <ricotz> sforshee, hi, is there a chance to get this cherry-picked to the current 4.11/artful branch ? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d557d1b58b3546bab2c5bc2d624c5709840e6b10
[07:45] <ricotz> tseliot, hi, ^
[07:55] <tseliot> ricotz: hi, I'm not on the kernel team. Maybe apw could have a look at it ^
[07:56] <ricotz> tseliot, more a fyi, since its suppose to fix the nvidia module build
[07:57] <apw> that _GPL stuff is just such utter make-work to not solve the underlying issue
[07:57] <tseliot> ricotz: err... is nvidia broken in artful?
[07:57] <apw> ricotz, and it seems reasonable to have, and i'll let sforshee pick it up
[07:58] <ricotz> tseliot, if 4.11.0-2.7 lands then yes
[07:58] <tseliot> ricotz: not looking forward to that, then...
[07:58] <ricotz> apw, I am hoping so, since it will be in 4.12 anyway
[07:59] <ricotz> tseliot, 375.66 and 381.22 building fine except for this (fatal) GPL issue
[08:43] <tseliot> ricotz: yes, that's really annoying
[12:02] <sforshee> ricotz: applied
[12:04] <ricotz> sforshee, thanks
[16:19] <gpiccoli> xnox, ping
[16:20] <xnox> gpiccoli, hi
[16:26] <gpiccoli> Hi xnox, how are you doing?
[16:26] <gpiccoli> I'm sorry to bother you
[16:26] <gpiccoli> (and sorry for my delay in replying)
[16:26] <gpiccoli> I have a question about netcfg package
[16:27] <gpiccoli> I tried to take a look in debian files and even git of the package, following a guidance from leitao..but I wasn't able to find the info I need
[16:27] <gpiccoli> "Also use short stable systemd-udev names to discover descriptions for the network interfaces"  <- I wanna know what is this modification ?
[16:28] <gpiccoli> We are investigating an "issue" on network interfaces naming on installer...seems on Xenial 16.04.1 it's getting ethX, and on Zesty, predictable namings (as expected)
[16:28] <gpiccoli> We might have narrowed this to netcfg fix (generically, debian-installer fix)
[16:36] <xnox> gpiccoli, in ubuntu interface names are created by udev. if you are getting ethX in one release but not the other, it is most likely that the patch for udev is missing.
[16:37] <xnox> gpiccoli, is this about s390x CCW bus on Qemu (gets ethX names in xenial) or the ppc64el VIO bus (which only recently was upstreamed)?
[16:37] <xnox> (including inside the installer)
[16:38] <xnox> netcfg only does things like: which ip you want, what netmask, which gateway, what's your hostname, etc. but doesn't assign or change the interface names as generated by udevd.
[16:38] <xnox> gpiccoli, https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L21
[16:39] <xnox> note that c<bus_id> and v<slot> names are not available in xenial at the moment. but with some care we can backport that.
[16:39] <xnox> also note that on upgrades to zesty, we try to preserve existing names, and one may need to remove the udev rules that use non-persistent names.
[16:40] <xnox> check udevadm info -p /sys/class/name/<interface> to figure out _why_ udev named something the way it did.
[16:40] <xnox> gpiccoli, i need to run, if you have further questions do open a bug report or email<EMAIL_ADDRESS>[16:43] <gpiccoli> thanks very much xnox !
[16:43] <gpiccoli> Really clear explanation. I'll use the udevadm trick if I ever see this behavior again
[21:01] <sforshee> dmj_s76: have you had a chance to test that linux-firmware package yet?
[21:19] <nacc> sforshee: does LP: #1637059 imply that another package needs backporting to 16.04 for the hwe stack?
[21:26] <sforshee> nacc: that user isn't running the hwe stack, they're running one of the mainline builds which is unsupported. However if it fails to build with that kernel it seems likely it will also fail to build with the hwe kernels too.
[21:26] <nacc> sforshee: there's a user in #ubuntu using 16.04.2 with the same failure :)
[21:26] <nacc> sforshee: same underlying bug, i guess
[21:26] <sforshee> nacc: I'd guess so
[21:27] <nacc> sforshee: i've fixed a few others like this, but shouldn't they be getting automatically caught?
[21:30] <sforshee> nacc: in theory yes, in practice it seems that has been marked as "known to fail" for whatever reason. If it's fixed the status in our test matrix should flip back to good, at which point a build failure for rtl8812au should actually get someone's attention.
[21:31] <nacc> sforshee: ok, at a minimum, the package in 16.04 should have gotten a patch to not build on newer releases if we aren't going to support it there
[21:32] <sforshee> nacc: if you're fixing it you probably also ought to check against linux-hwe-edge
[21:33] <nacc> sforshee: sure, i just think there's something missing in the process :)
[21:38] <sforshee> nacc: so we on the kernel team have filed bugs about the test failure, e.g. bug #1679670
[21:38] <nacc> yeah i saw that
[21:38] <nacc> but that log was weird
[21:39] <nacc> it wasn't a build failure
[21:39] <nacc> it was a "i can't remove dkms" failure?
[21:39] <sforshee> it is a build failure, it's just a bit hidden
[21:39] <sforshee><EMAIL_ADDRESS>[21:40] <sforshee> nacc: if you download ^ the dkms logs will be in there
[21:40] <sforshee> if you had questions you should have asked ;-)
[21:40] <nacc> sforshee: honestly, i was just trying to help a user, who is now leaving ubuntu because of this issue :)
[21:40] <nacc> sforshee: as arch does it right
[21:41] <nacc> sforshee: tbh, this is also in universe and i'd only be fixing it out of my own generosity :)
[21:41] <sforshee> nacc: I see
[21:43] <nacc> sforshee: i stand by my earlier point, though, that if a package is known to not build with a newer kernel (via hwe) and we are defaulting the isos to install hwe for desktop, then there should be a patch for the package in the release to not try to build on newer kernels
[21:43] <nacc> sforshee: otherwise, every kernel update for users results in a failed dkms build
[21:43] <nacc> which seems .. bad for users
[21:46] <sforshee> nacc: I agree. I'm not sure what the answer is though ... we try to make sure that some of the dkms packages we know are widely used are working, but we're unable to do that for every single dkms package.
[21:47] <nacc> sforshee: why not? it's about 30-40 packages that r-b-d on dkms right now
[21:47] <nacc> sforshee: it seems like every hwe bump should be gated that none of those all of a sudden start to fail
[21:48] <nacc> sforshee: not that i'm signing up to help gate them and change the package :)
[22:03] <sforshee> nacc: there is a process that can gate them, we just haven't had enough spare cycles to fix everything. Personally I hadn't thought about updating the packages to not attempt building against the newer kernels, so there may be something to doing at least that.
[22:04] <nacc> sforshee: e.g., smb and I did that to some iscsi package that got mainlined between the 16.04.1 and 16.04.2 kernels
[22:04] <sforshee> nacc: not saying it hadn't occurred to anyone else on the team, just not to me ;-)
[22:05] <nacc> sforshee: if we did a good job of marking the reason (via bug) in the changelog, i think users will at least be less perturbed by the failed dkms builds
[22:08] <nacc> sforshee: to be clear, i wasn't blaming you personally :)
[22:10] <sforshee> nacc: yeah, no offense taken. I've taken note of your discussion so we can discuss it as a team. Thanks for the feedback.
[22:10] <sforshee> s/discussion/suggestion/
[22:11] <nacc> sforshee: and i'm happy to help, to be clear, just let me know
[22:12] <sforshee> nacc: cool, thanks!


[15:05] <adom> marcoceppi ChinnoDog: yeah, "a few"? I think someone's building a bot-net!
[15:05] <adom> actually I read a nice article recent
[15:05] <adom> ...recently about using bot-nets for good purposes, not illegal ones.
[15:06] <adom> it was about this guy that did work for a car dealership that bought cars from auction, and apparently the dealership that always won the online auctions were the ones that had the best PC systems and connections because they would snipe it in last 5sec like on eBay.
[15:07] <adom> the problem was that in last 5sec, the site got so overloaded that normal systems wouldnt even load the page
[15:07] <adom> so the guy created this botnet that would send like 40-50 http requests to the server from different sources/networks in the last 5sec with the bid amount
[15:07] <adom> and it works i guess
[15:08] <adom> think i read it in Wired while on the can last month or something
[15:30] <marcoceppi> adom: I want to test them with Juju ;)
[15:42]  * ChinnoDog scratches head at juju
[15:43] <ChinnoDog> marcoceppi: I see you authored the wordpress charm which uses nginx and php-fpm. That is how I have my blog set up. Can I use juju on my private server? (I have no idea how juju works yet, just looking.)
[15:56] <ChinnoDog> Ok, I see I can use on my private server but I still don't understand relations.
[15:57] <ChinnoDog> And I see things like meta configuration values in the charms that control other settings. I am running mysql without InnoDB using a minimal memory footprint. I can't tell if I can still manually tune these things in juju.
[16:45] <marcoceppi> ChinnoDog: we can talk later, im currently at a sprint
[16:46] <ChinnoDog> k.


[02:06] <cjwatson> Joeboy: sorry about the grub bug; I fixed it yesterday
[02:06] <cjwatson> Joeboy: (it was due to a change in binutils that I didn't notice)
[08:02] <AlanBell> morning
[08:02] <AlanBell> I am trying to get Karmic to boot on an OLPC XO
[08:03] <AlanBell> I think I may need to compile the DCON screen driver into the kernel
[08:03] <AlanBell> and possibly ditch upstart for sysvinit
[08:03] <AlanBell> at the moment it just hangs on the open firmware screen
[08:04] <AlanBell> can someone point me in the direction of some documentation on how to recompile the kernel with the stuff needed, or any other advice on what I am doing wrong?
[08:33] <Joeboy> cjwatson: no worries, it's spurred me to upgrade to grub2 which I probably ought to have done anyway.


[00:53] <freeflying> wodering how can I know which package I have right to upload, anybody has any clues?
[00:55] <micahg> freeflying: you can use the edit_acl.py scripts in lp:ubuntu-archive-tools
[00:56] <freeflying> micahg: thanks, what about I want the right to upload some specific package, whats the process to apply for it?
[00:57] <micahg> freeflying: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders
[01:22] <freeflying> micahg: thanks
[01:42] <nathanbelomy> Hey guys, anyone want to decode some 64 binary, new string line execution for run level 7? It's C++ 3/4. GNU License, I'll add more later.
[01:42] <nathanbelomy> http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7
[01:44] <nathanbelomy> anyone here?
[02:02] <poolie> nathanbelomy: wtf is that?
[06:08] <micahg> ScottK: not that ubuntu-dev has PPU, should we revisit the newpackage wiki that says sign off by 2 Ubuntu developers, for some reason I thought it was 2 MOTUs, was that incorrect?
[06:08] <micahg> s/not/now
[06:08] <ScottK> At the time it was written those two were synonymous.
[06:09] <ScottK> I think MOTU is correct in the current context.
[06:09] <micahg> right, but is my understanding correct, 2 MOTU ACKs required (core-dev is considered a MOTU)
[06:10] <ScottK> For packages by non-MOTU.
[06:11] <ScottK> It's actually a bit trickier.
[06:11] <ScottK> For example I think a kubuntu-dev ack on a package should certainly count.
[06:11] <ScottK> (I would trust any kubuntu-dev to not comment on things outside their expertise)
[06:12] <ScottK> OTOH, the difference between PPU and kubuntu-dev is just scale.
[06:13] <ScottK> Meh.
[06:13] <micahg> ScottK: well, ok, but still, 2 ACKs are required, right?
[06:13] <ScottK> I think motu is right rule.
[06:13] <ScottK> For packages by non-motu, yes.
[06:13] <ScottK> For MOTU the 2nd ack is suggested, but not required.
[06:28] <micahg> ScottK: wiki fixed
[06:31] <ScottK> Thanks.
[07:59] <bludude> how should i create a debian/watch for a project that's hosted on launchpad but doesn't produce tarballs?
[08:04] <geser> then you can't. do you use checkouts for the .orig.tar.gz?
[08:10] <mase_wk> i find the whole orig.tar.gz thing quite annoying and redundant
[08:10] <mase_wk> not that my opinion counts for anything
[08:12] <bludude> all we have is a bazaar repo on launchpad
[08:22] <geser> bludude: then you can ignore the debian/watch file (as there is nothing to watch).
[08:22] <bludude> alright, thanks.
[08:54] <dholbach> good morning
[08:55] <xdatap1> dholbach, morning!
[08:56] <dholbach> hey xdatap1
[08:56] <BlackZ> morning dholbach :)
[08:57] <dholbach> hey BlackZ
[09:46]  * Rhonda sighs at the screenshot in Mohamad's Xlog post …
[10:36] <Laney> warp10: thanks for your package, I based the debian package on it: http://ftp-master.debian.org/new/sparkleshare_0.2.2-1.html
[10:36] <Laney> kept your changelog entries and copyright :-)
[10:55] <Daviey> Laney: kinda confusing changelog :).. Suggests it is currently in oneiric archive. :)
[10:56] <Laney> hah
[10:56] <Laney> I hope the 'ppa' in the version helps there
[12:11] <warp10> Laney: great! After it is accepted and synced I will keep my PPA just for backports to stable Ubuntu release
[12:13] <warp10> Laney: and I'm sure our friend ftp-assistant Dktrkranz  will be happy to give love to sparkleshare accpeting it ASAP from the Debian NEW queue... /me looks DktrKranz
[13:58] <Laney> meh, no rush
[14:19] <RogueTech> #ubuntu
[14:54] <DorianJaminais> hi everyone
[14:54] <DorianJaminais> I think I have misunderstood something in the version number scheme
[14:55] <DorianJaminais> i created a package witch depends on libois (>= 1.2)
[14:55] <DorianJaminais> and in the repos, there is a package libois version 1.2.0-1
[14:56] <DorianJaminais> my problem is that my package is broken because it requires a too high version on libois
[14:56] <DorianJaminais> is this normal ?
[14:59] <directhex> DorianJaminais, 1.2. is greater than 1.2
[14:59] <DorianJaminais> yes so my package requires a lower version of libois
[14:59] <DorianJaminais> I think i find out what is the actual problem
[14:59] <DorianJaminais> libois package is named libois-1.2.0
[15:02] <directhex> ...
[15:02] <directhex> then you need to depend on libois-1.2.0
[15:02] <DorianJaminais> yes that was it
[15:02] <DorianJaminais> sorry for disturbing :/
[19:21] <bdrung> bludude: packtools has the same purpose as packaging-dev
[19:28] <persia> bdrung: Did packaging-dev land?  I don't see it (but maybe I'm not looking with the right tools)
[19:28] <maco> persia: we're poking at it right now
[19:29] <persia> Oh, excellent.
[19:29] <maco> where "we" = i'm saying stuff and he's typing
[19:29] <bdrung> persia: not yet. i am currently trying to get a proper long description with maco
[19:29] <persia> packtools also suffers from a number of other issues (some of which I've passed to bludude), so it will be nice to have the proper replacement.
[19:29] <bdrung> persia, maco: http://paste.debian.net/120094/
[19:30] <bdrung> persia: besides that, packaging-dev was discussed on debian-devel
[19:30] <bdrung> persia, maco: is the description ok? can you improve it?
[19:30] <persia> bdrung: Sure, but I don't think it's fair to expect everyone to read that (especially not developers for Ubuntu remixes)
[19:30] <persia> "mangements" -> "mangement"
[19:31] <persia> "and packaging macros" -> "packaging macros"
[19:31] <maco> was about to say that one
[19:31] <persia> Err, "mangement" -> "management" if you've been accepting corrections verbatim :(
[19:32] <bdrung> persia: i enabled word correction :)
[19:32] <persia> "is just for packaging, not for developing" -> "provides tools for packaging, rather than the development of software"
[19:32] <bdrung> improvements for the last paragraph is welcome
[19:32] <persia> "This package should be installed by packagers. " -> ""
[19:33] <bdrung> current status: http://paste.debian.net/120095/
[19:34] <persia> "meta-package" -> "package"
[19:34] <bdrung> two other questions: should ubuntu-dev-tools in Depends or Recommends?
[19:34] <tumbleweed> do we have a lintian patch for complaining about it?
[19:34] <persia> "for development" = "for the development"
[19:34] <persia> I think u-d-t should be recommends.
[19:34] <tumbleweed> +1 for recommends
[19:35] <bdrung> the same for bzr-builddeb?
[19:35] <tumbleweed> I'd say so
[19:35] <persia> Is that interesting to packaging developers?  How?
[19:35] <bdrung> persia: "meta-package" -> "package" in short or long description?
[19:35] <maco> i think bzr-builddeb should move from regular recommemds to ubuntu-only recommends
[19:35] <persia> bdrung: I'm only looking at long for now.
[19:36] <persia> Oh, my: the short description is very awkward.
[19:36]  * maco tends to think the hardest part of making a new package is writing the stupid descriptions
[19:36] <maco> it's a package that does a thing! stop asking me hard questions! gimme easy ones like "what are the build-deps?"
[19:37] <tumbleweed> heh, true that
[19:38] <bdrung> maco: but we have svn-buildpackage and git-buildpackage in there too
[19:38] <broder> haha, agreed
[19:38] <broder> "it's a package that does a thing!" - i might use that for one of my internal packages now
[19:38] <bdrung> http://paste.debian.net/120096/
[19:39] <bdrung> broder: that's better than a description "TODO"
[19:39] <maco> "did a thing" is a phrase ive used a lot lately. my elbow did a thing. my knee did a thing. my hip did a thing.
[19:39] <persia> bdrung: maco: http://paste.debian.net/120097/
[19:40] <tumbleweed> persia: if you remove meta-package from the short description, you should add something about that to the long one
[19:41] <bdrung> persia: great, i will use that (there should be somewhere meta-package in there.
[19:41] <bdrung> )
[19:41] <bdrung> -> This meta-package depends on common packages [...]
[19:42] <persia> tumbleweed: Why?  It wasn't in either the short or long description of several metapackages I looked at before composing it.
[19:42] <tumbleweed> or at the end: This meta-package doesn't contain anything but depends on useful packages. No other package...
[19:42] <maco> i guess Section:meta-packages tells you that...
[19:42] <persia> Look at gnome-office, ubuntu-desktop, etc.
[19:42] <tumbleweed> persia: I find it useful when deciding what package to install, I assume other people do too
[19:43] <bdrung> W: packaging-dev: empty-binary-package
[19:43] <tumbleweed> yeah section:meta-packages does that too, I guess
[19:43] <persia> tumbleweed: As pointed out by maco, the information is already available.
[19:43] <tumbleweed> right
[19:43] <persia> bdrung: Did you remember to install copyright, changelog, etc.?
[19:44] <bdrung> persia: from lintian: If the package is deliberately empty, please mention in the package long description one of the phrases "metapackage," "dummy," "dependency package," "empty package," or "virtual package."
[19:44] <persia> Now that's a justification I can support.  Thanks!
[19:45] <persia> Yeah, "This package" -> "This metapackage" in both lines then.
[19:45] <bdrung> and section meta-packages is not allowed
[19:47] <bdrung> final check please: http://paste.debian.net/120099/
[19:47] <persia> Where can I look at the rest of control?
[19:48] <maco> huh. wonder where i found that section, cuz looking at the policy guide again its not there
[19:48] <persia> maco: It's an ubuntuism?
[19:49] <maco> maybe it was just because vim stopped going all red-text on the section when i got from meta-package to meta-packages, so it looked like it accepted that spelling?
[19:49] <maco> hm maybe
[19:49] <maco> ah yeah, metapackages is in cjwatson's ubuntu policy manual
[19:50] <persia> Heh: vim syntax highlighting requires distro-patching for debian/control files :)  The deep implications of some of the policy variations are amusing.
[19:51] <broder> huh? i thought debian added a metapackages section...
[19:51] <broder> (or something like that)
[19:52] <broder> huh. maybe not
[19:53] <persia> Policy 2.4 doesn't appear to include anything like that.
[19:55] <persia> bdrung: Sorry: failed to get back to you: 120099 looks fine to me.
[19:56] <persia> I'd still like to see control :)
[19:56] <maco> persia: he's got it in collab-maint. im guessing he's waiting to link it til he's got the desc updated
[20:01] <persia> Why is apt-file Recommends?  I use it sometimes, but can't see how it might be considered essential.
[20:01] <persia> Or even normally present.
[20:02] <micahg> persia: well, it's good for researching where other files are especially in fixing DSO linking issues
[20:03] <persia> micahg: Yes, but if one is packaging for a perfect upstream, once doesn't encoutner those.  Nor if one is packaging python, java, ruby, shell, C#, D, etc.
[20:04] <persia> I think it ought suggest gnome-pkg-tools (and in Ubuntu only, kubuntu-dev-tools, by ${vendor-specific:Suggests}
[20:04] <micahg> persia: I could make the same argument against both of those, they're specific to certain domains in UBuntu
[20:05] <micahg> persia: and kubuntu-dev-tools pulls in ruby, I don't think we want to do that by default
[20:05] <persia> micahg: How is pkg-gnome-tools specific to Ubuntu?
[20:05] <micahg> ah, suggests, nevermind..
[20:05] <persia> Err, gnome-pkg-tools
[20:05] <micahg> persia: you only use it if you package certain parts of the archive
[20:05] <micahg> but suggests is fine for both
[20:06] <persia> And there's still enough software in the archive that uses dpatch it's probably worth suggesting that as well (if not recommending it)
[20:06] <maco> oh dpatch is that one i couldnt remember
[20:06] <persia> micahg: specific to domain, yes.  Specific to Ubuntu, no: gnome-pkg-tools is also used in Debian for the same purposes.
[20:06] <maco> (it's either "quilt" or its "easy" :P)
[20:06]  * micahg thinks we should add a postinst to dpatch outputting something along the lines of (if you're installing this, consider porting the package to source format 3)
[20:07] <persia> No.
[20:07] <persia> I can do stuff with dpatch that simply isn't possible with any of the other systems.
[20:07] <Laney> why do we need more cudgels?
[20:07] <persia> Go look at the implementation some time :)
[20:07] <micahg> persia: the comment was more tongue-in-cheek :)
[20:07] <Laney> :-)
[20:08] <micahg> persia: sorry, didn't mean to emphasize the UBuntu part about being domain specific
[20:08] <persia> Heh, OK.
[20:09] <persia> Also, if we're recommeding all the VCS tools, seems like it's worth mentioning mr and pristine-tar
[20:09] <bludude> I just got a look at the packtools and packaging-dev stuff.  i'm going to move packtools to the same format as packaging-dev (no germinate).
[20:09] <persia> micahg: Anyway, my issue with apt-file is that I never need it, although it may be helpful in some contexts.  In the case of gnome-pkg-tools or kubuntu-dev-tools, there are *lots* of pacakges that simply cannot be built without them.
[20:10] <persia> bludude: Why?  Just join in the debate about what packaging-dev ends up being.  Let's have one perfect tool, rather than two.
[20:10] <micahg> persia: I never need genisoimage, should we drop that too?
[20:11] <bludude> true.  I made packtools to learn about packaging, so for me it's just for learning
[20:11] <persia> micahg: I don't see it in the recommends or depends of packaging-dev.  Am I missing something?
[20:11] <micahg> persia: I thought we were talking about ubuntu-dev-tools...
[20:11] <persia> (admittedly I have an old version of the file)
[20:11] <persia> No.
[20:11]  * micahg is confused...
[20:12] <bludude> if y'all desire, packaging-dev can have the name packtools
[20:12] <persia> It already got debated on debian-devel@ as "packaging-dev", which means confusing lots of folk if the name changes now.
[20:13] <bludude> ok
[20:13] <Laney> pristine-tar is certainly a good one
[20:14] <tumbleweed> pristine-tar should already be depended on by everything that uses it, no?
[20:14] <bludude> pristine-tar is pulled in by bzr-builddeb
[20:14] <persia> OK, then we don't need it.
[20:15] <bludude> bzr-builddeb pulls in a lot of good stuff
[20:15] <persia> tumbleweed: I don't think packages using pristine-tar need to build-dep on it, and I don't believe it's required as part of the workflow for any of the VCS packaging tools (although recommended for the majority of them)
[20:15] <tumbleweed> Depends: ... python2.6 | python2.7 | python2.4 ... ???
[20:15] <persia> Isn't there a "python-all" for just that purpose?
[20:16] <tumbleweed> persia: I mean git-buildpackage, bzr-builddeb etc depend on it
[20:16] <tumbleweed> persia: that's different
[20:16] <tumbleweed> and I'm ??ing at the 2.4
[20:16] <persia> They oughtn't.  They ought recommend it.
[20:16] <tumbleweed> git does, bzr depends on it
[20:16] <persia> That's just wrong.
[20:16] <tumbleweed> and as we can see it's no tthe only thing that's wrong :)
[20:17] <persia> All the more so given the example of the Ubuntu Desktop team who uses bzr for packaging and doesn't use pristine-tar as they use external tarballs.
[20:17] <micahg> rdepends for pristine-tar http://paste.ubuntu.com/628131/
[20:17] <micahg> +1 for recommending
[20:18] <persia> Oooh.  mercurial-buildpackage.  That ought be at least a suggests of packaging-dev
[20:19]  * tumbleweed waits for someone to mention cvs-buildpackage
[20:19] <persia> If there are packages still maintained in cvs, then I agree with tumbleweed that it ought be suggests.
[20:20] <tumbleweed> persia: I hope there aren't but there probably are
[20:20]  * tumbleweed hasn't ever come across any
[20:20] <persia> I have, but not in at least a few years.
[20:35] <nathanbelomy> anyone take a look at this http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7
[20:39] <cjwatson> nobody here is interested in that
[20:40] <nathanbelomy> I guess fedora might be?
[20:40] <nathanbelomy> It similar to the way intel's hypervisor technology works, only this is a virtual process that optimizes process executions concurrently
[20:41] <nathanbelomy> Maybe vmware wants it
[20:50] <jtaylor> sladen: openbve does not build in oneiric with mono 2.10, can you have a look?
[20:51] <bdrung> persia: http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary
[20:54] <micahg> bdrung: is piuparts useful for regular packagers?
[20:56] <persia> micahg, It's worth recommending.  Run on it's own (rather than as a service), it's a really handy way to test install/upgrade/remove/purge of the package.
[20:57] <micahg> persia: ah, I've never used it before, maybe I should :)
[20:58] <persia> heh.  Probably.
[20:58] <cjwatson> (nathanbelomy's URL is a weird troll of some kind, to save anyone else the trouble of looking.)
[21:05] <persia> bdrung: Sorry: yeah, that's what I was looking at before.  I don't see the latest changes we were discussing, but I'm sure you've a good local copy of the useful parts of the discussion.
[21:09] <bdrung> micahg: we should recommend testing :)
[21:10] <bdrung> persia: i am currently busy. will commit it soon.
[21:10] <persia> No rush.  I doubt I'd have anything more useful to comment about than I've already commented.
[21:21] <bdrung> persia: pushed
[21:23] <Laney> sladen: pretty please will you maintain openbve in debian?
[21:23] <Laney> i'll sponsor you!
[21:25] <highvoltage> sladen isn't a dd!?
[21:27] <tumbleweed> that's entirely fixable
[21:28] <directhex> i thought sladen was a DD.
[21:28] <directhex> maybe i'm confusing him with someone else
[21:29] <Laney> can't find any evidence of this fact
[21:29]  * Laney ldaps
[21:39] <bdrung> pushed http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary
[21:40] <bdrung> now is the last chance to get some changes into it before my first upload
[21:40] <bdrung> maco, persia, tumbleweed, micahg: ^
[21:42] <persia> So, I'd like bundles of changes to Recommends and Suggests (as outlined above).
[21:43] <persia> But I'd prefer discussion of my suggestions, rather than just submitting a patch and having it applied, as while I think I'm right, I'm rarely the best judge of that.
[21:44] <persia> Also, since I'm not a target user for the package (I actively don't want it installed, as I tend to like to not have e.g. autotools-dev by default so that when `make clean` breaks, I know I'm unhappy with the implementation, etc.)
[21:45] <persia> I'm probably not the right person to be made happy: the package should ideally match the documentation which is recommending it's installation.
[21:46] <tumbleweed> there was a sub-discussion about that on debian-devel, whether the package was recommended tools for new packages, or useful tools for packaging
[21:46] <bdrung> it targets new users.
[21:46] <tumbleweed> I think "things you're probably going to need" won out
[21:47] <maco> my original goal was to avoid 3 rounds of "oh wait, install this too" when mentoring newbies
[21:47] <bdrung> persia: adding suggestions doesn't hurt and they all seemed reasonable. therefore i added them
[21:47] <bludude> fyi, my goal for packtools was to automate installing everything listed in the Ubuntu packaging guide
[21:47] <maco> the stuff in the packaging guide should all be in packaging-dev. i checked that
[21:47] <bdrung> bludude: packaging-dev has the same goal
[21:47] <persia> bludude: I think that's the right goal, although I'm of the opinion that it makes sense to fix *both* the documentation and the package to do the right thing, rather than accepting either as authoritative.
[21:51] <tumbleweed> I'm pretty happy with the current contents
[21:53] <bludude> yes, they seem to fulfill the goal
[21:53] <persia> I really don't like dh-make, but that's from having repeated myself hundreds of times suggesting people clean up from it's common mistakes (e.g. Priority: extra)
[21:54] <bdrung> persia: that's the reason why it is in suggest and not in recommends
[22:00] <bdrung> packaging-dev  0.1 uploaded!
[22:31] <sladen> Laney: yeah, if you sponsor it
[22:32] <sladen> directhex: 10 years of me mistaking me for a DD now :-)
[22:32] <sladen> directhex: will get around to it at some point.  The previous one five years ago got put on hold because I refused to upload more crap into the archive just for the sake of completing NM
[22:37] <directhex> sladen: means i wasn't mistaking you for someone else, you're one of the "he's not a DD? huh?" folks as gets occasionally mentioned in #debian-uk circles
[22:37] <Laney> :-)
[22:37] <Laney> basically want to be able to drive a train at work
[22:38] <Laney> not that I can even do forward right yet
[22:48] <jtaylor> sladen: I propsed a branch for merging with openbve
[23:03] <directhex> Laney: have you booked a b&b for the night at the debian bbq yet? you're a dd now, it's your duty to attend


[05:21] <Guest10143> hey I'm having some difficulty in 16.04.1. I switched to proprietary nvidia drivers but now the system wont reboot, just hangs on a blank screen after selecting ubuntu option in grub. I assume its a problem with switching driver and xorg.conf file that I created. After searching online I have seen people suggest removing the file and it fixing the problem. However I cant figure how to access a terminal to delete? probably simple
[05:21] <Guest10143> but i cant figure it out. Thanks for any help.
[12:27] <user11> hi
[12:28] <user11> I am new to GNU/Linux, can someone help me?
[12:29] <user11> I have installed Ubuntu/Gnome on my macbook 2015 pro
[12:29] <user11> someone still alive?
[12:31] <user11> the problem is that my mac is not shutting down


[01:10] -queuebot:#ubuntu-release- Unapproved: hollywood (cosmic-proposed/universe) [1.14-0ubuntu1 => 1.15-0ubuntu1] (no packageset)
[08:59] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1035.40] (kernel)
[09:06] <seb128> could someone review/ack bug #1820259?
[09:07] <seb128> it's basically a no-op for disco since livepatch isn't working on that serie and such the indicator is not showing
[09:07] <seb128> but that's needed to do the SRU
[09:48] <seb128> no-one? I already asked yesterday, that should be a trivial one to review :-/
[09:49] <bluesabre> Release team, also looking for an ack on https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1820388 please :)
[09:55] <seb128> bluesabre, did you email the documentation/translation teams as described on https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions ?
[09:57] <bluesabre> seb128, it doesn't require a change to the strings or the layout, it's just the wallpaper
[09:57] <bluesabre> we have no documentation that features the wallpaper
[09:59] <seb128> bluesabre, no screenshot of an xubuntu desktop on any documentation/website/etc?
[10:00] <seb128> bluesabre, also the process described doesn't specify that those notifications are optionals
[10:19] <sil2100> I can take a look at FFe's today
[10:19] <sil2100> seb128: looking o/
[10:20] <seb128> sil2100, thx!
[10:26] <juliank> rbalint: I think even if the other branches are incomplete, it would be nice to import them and bring them up-to-date?
[10:26] <juliank> (re software-properties)
[10:27] <juliank> that said, are there any?
[10:27] <juliank> I can't find them
[10:29] <rbalint> juliank, there are trusty branches here: https://code.launchpad.net/ubuntu/+source/software-properties/+branches
[10:29]  * juliank is more interested in xenial and bionic
[10:30] <rbalint> juliank, those seem to be maintained only in uploads
[10:30] <juliank> ack
[10:30] <juliank> I'll probably go back in time and create git branches by importing the uploads then, so we have a basic working repo
[10:30] <juliank> * basic working repo for SRUing
[10:31] <rbalint> juliank, if the status quo is just using uploads then the usd imports provide a fine git base for it
[10:31] <juliank> It's the status quo, but it's not what it should be
[10:31] <juliank> :)
[10:32] <rbalint> juliank, if we would like to do reviews, then a proper history would be better, but the imports can be done after the switch with master
[10:32] <rbalint> juliank, i agree, but i don't find lp's git support comfortable enough to enforce people to do code reviews
[10:33] <juliank> rbalint: it's not only for reviews, but also for personal wip tracking
[10:33] <bluesabre> seb128, "Every change of the user interface (either a string or the layout)" would make it optional in this case. And yeah, no screenshots anywhere... since we're always late, we got rid of the offending screenshots years ago to make the process less painful for everybody
[10:35] <rbalint> juliank, i usually just use short time branches on top of usd branches, but i prefer what you suggest
[10:35] <bluesabre> sil2100, based on your comment on the previous release, https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1794978/comments/2, can we get an ack on https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1820388 ?
[10:35] -queuebot:#ubuntu-release- New source: python-octavia-lib (disco-proposed/primary) [1.1.1-0ubuntu1]
[10:35] <bluesabre> :)
[10:36] <rbalint> juliank, the problem is that if most people just upload the branches become outdated
[10:37] <bluesabre> (sorry for the nagging, the whole team is stretched thin and most of the team has become inactive or busy with life)
[10:39] <jamespage> ^^ octavia-lib above is a new dep for networking-ovn for this release - apologies for the late-ish new upload
[10:41] <sil2100> bluesabre: let me take a look in a minute o/
[10:50] <rbalint> juliank, i'm adding the old branches and upload a converted git snapshot shortly
[10:51] <rbalint> juliank, we can recreate the few missing uploads in ubuntu/{bionic}
[10:51] <rbalint> {bionic}
[10:51] <rbalint> {bionic|xenial|disco}
[10:51] <rbalint> (other keyboard :-\)
[10:56] <doko> Laney: why is openjdk-8 triggering the fdroidserver test?
[10:57] <Laney> dunno, I can't look because I'm at a sprint, sorry
[10:57] <Laney> depends or build-depends and build-needed or testsuite-triggers
[10:57] <doko> ahh
[10:59] <Laney> there's one thing where if there's an alternate dependency I don't think we ensure that the right one is installed
[11:00] <Laney> like a | b, triggered by b, we don't make sure that b gets put on the system and you could end up with a
[11:00] <doko> ohh crap, I see ...
[11:01] <Laney> might be that bug you filed yesterday?
[11:03] <doko> yep
[11:03] <doko> or maybe I should file that upstream as well ...
[11:04] <Laney> not aware of any direct support for that
[11:04] <Laney> dunno if debian does anything there, probably not
[11:04] <juliank> rbalint: yes, that's not a problem
[11:08] -queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [4.4.1-5~18.04 => 4.4.1-5~18.04.1] (no packageset) (sync)
[11:09] -queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [4.4.1-5~18.10 => 4.4.1-5~18.10.1] (no packageset) (sync)
[11:10] -queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [4.4.1-5~18.04.1]
[11:17] -queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (cosmic-proposed) [4.4.1-5~18.10.1]
[11:18] <jibel> kenvandine, seeding core18 broke desktop image builds cf bug 1820840
[11:25] -queuebot:#ubuntu-release- Unapproved: icedtea-web (bionic-proposed/universe) [1.6.2-3.1ubuntu3 => 1.8-0ubuntu8~18.04] (ubuntukylin) (sync)
[11:28] -queuebot:#ubuntu-release- Unapproved: icedtea-web (cosmic-proposed/universe) [1.6.2-3.1ubuntu3 => 1.8-0ubuntu8~18.10] (ubuntukylin) (sync)
[11:30] -queuebot:#ubuntu-release- Unapproved: accepted icedtea-web [sync] (bionic-proposed) [1.8-0ubuntu8~18.04]
[11:33] -queuebot:#ubuntu-release- Unapproved: accepted icedtea-web [sync] (cosmic-proposed) [1.8-0ubuntu8~18.10]
[12:41] <seb128> One other FFe we would like to see reviewed sooner than later if possible
[12:42] <seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1820850
[13:21] -queuebot:#ubuntu-release- New source: wslu (bionic-proposed/primary) [2.0.0-0ubuntu2~18.04.0]
[13:21] -queuebot:#ubuntu-release- New source: wslu (xenial-proposed/primary) [2.0.0-0ubuntu2~16.04.0]
[13:21] -queuebot:#ubuntu-release- New source: wslu (cosmic-proposed/primary) [2.0.0-0ubuntu2~18.10.0]
[15:09] <cpaelzer> there is an FFe without ack/nack for a while https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450588 - I think the case is quite simple, and was wondering if someone on the release Team could take a look at it
[15:09] <cpaelzer> vorlon: how does FFe assignment usually work in the release team?
[15:11] <cpaelzer> anything I can do better on FFEs to help the release team?
[15:37] <vorlon> cpaelzer: I basically don't have the bandwidth to chase up FFe bugs that get filed, so I only look at ones I get pinged about here
[15:37] <vorlon> cpaelzer: "nine releases ago"?
[15:37] <vorlon> we really care about this? :)
[15:40] <vorlon> cpaelzer: but also, your "better safe than sorry" position causes unnecessary drag for you
[15:45] <vorlon> so does anyone know why the daily Ubuntu image build is failing trying to find a stalbe/ubuntu-19.04 channel for the core snap? that seems wrong
[15:47] <jibel> vorlon, because the track stable/ubutnu-19.04 is not available for core18 which has been seeded yesterday. kenvandine and mvo are on it
[15:47] <vorlon> ah
[15:48] <Eickmeyer> vorlon, infinity, anyone else: still waiting for an archive admin to review carla. Sorry to be such a pest, but I was told to be persistent.
[15:54] <Eickmeyer> apw: ^?
[16:02] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1041.45] (kernel)
[16:02] <kenvandine> vorlon, jibel: mvo has created the stable/ubuntu-19.04 track
[16:04] <vorlon> Eickmeyer: it's on my list, but the copyright/license information is complex enough to be annoying and I was going to look at tooling as part of the review
[16:05] <vorlon> kenvandine, jibel: so you don't think it's an error to require a separate track for the core snap?  I would've thought we should treat the base snap specially
[16:05] <Eickmeyer> vorlon: Understood. Is this in danger of missing beta freeze, or would this be an exception?
[16:05] <kenvandine> vorlon: perhaps... but this will at least unblock it
[16:05] <vorlon> Eickmeyer: I don't think it's at risk
[16:07] <vorlon> kenvandine: ... fixing livecd-rootfs would also do that.  or reverting the seeding, because why are we directly seeding a base snap?
[16:07] <Eickmeyer> vorlon: Okay, cool. I'm asking because I'd like to get it into the archives and patched to the 2.0.0 final release that happened on Sunday. [more]
[16:07] <kenvandine> i assume core was treated differently in the past
[16:07] <vorlon> kenvandine: core was never seeded, snapd handled that internally
[16:07] <Eickmeyer> I have the patches ready to go, but I don't want to push anything until it's in the archives so I can just update it myself.
[16:07] <vorlon> but now core18 is seeded, so livecd-rootfs doesn't know it's special
[16:07] <kenvandine> vorlon: yeah, it doesn't for core18
[16:07] <vorlon> and looks for the channel
[16:08] <kenvandine> core is still required
[16:08] <kenvandine> since core18 doesn't provide snapd
[16:08] <kenvandine> so core18 requires core
[16:08] <vorlon> uh
[16:08] <kenvandine> eventually there will be a snapd snap
[16:08] <kenvandine> so core18 + snapd snap will mean we don't need core
[16:08] <vorlon> there already is a snapd snap
[16:08] <kenvandine> i don't think it's ready for us to use that way
[16:14] -queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu2 => 2:14.0.1-0ubuntu3] (openstack, ubuntu-server)
[16:21] <coreycb> hi all, can we have a look at accepting masakari-monitors from the disco NEW queue? this is a new openstack package in support of VM HA.
[16:23] <didrocks> sil2100: hey again, did you see yesterday jibel's ping about desktop-canary image? Could it be copied in people.canonical.com so that we have access to it?
[16:31] <sil2100> didrocks: ah, probably missed it, you mean the one that got built through cdimage but not published anywhere?
[16:32] <didrocks> sil2100: exactly! We wanted to have it accessible somewhere, like maybe on people.canonical.com or so
[16:32] <sil2100> Let me look into that quickly after teh meeting
[16:32] <didrocks> thx!
[16:36] <vorlon> mvo, kenvandine: hey, so currently livecd-rootfs blindly seeds the core snap in snap_prepare() - I wonder if we should be adjusting that to know about core vs. core18+snapd
[16:37] <sil2100> didrocks: hmmm, so I guess for that I'd need a current build to be succeeding
[16:37] <sil2100> didrocks: I see the latest ubuntu-canary livefs build failed, do you know why by any chance?
[16:37] <sil2100> didrocks: should I kick a new build with the EXTRA_PPAS?
[16:38] <didrocks> sil2100:the one before worked though? The current one will fail as the normal desktop image due to the core18 thingy above ^
[16:40] <vorlon> mvo, kenvandine: I definitely think it's wrong for us to need an /ubuntu-19.04 track for the core18 snap, and for us to be seeding based on this track in the desktop images
[16:41] <sil2100> didrocks: ah, hmmmmmm
[16:41] <vorlon> kenvandine: and mvo has suggested that it might be possible now to use the snapd snap instead of the core snap
[16:41] <sil2100> Ok
[16:41] <kenvandine> vorlon: it would be great
[19:03] -queuebot:#ubuntu-release- Unapproved: rejected hollywood [source] (cosmic-proposed) [1.15-0ubuntu1]
[21:08] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (cosmic-proposed) [2:14.0.1-0ubuntu3]
[21:24] -queuebot:#ubuntu-release- Unapproved: accepted openconnect [source] (cosmic-proposed) [7.08-3ubuntu<IP_ADDRESS>]
[21:28] -queuebot:#ubuntu-release- Unapproved: accepted openconnect [source] (bionic-proposed) [7.08-3ubuntu<IP_ADDRESS>]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted grilo-plugins [source] (cosmic-proposed) [0.3.8-2ubuntu1.1]
[22:05] <rharper> bdmurray: hi, we've completed sru verification on our cloud-init SRU here, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1819067  ; would appreciate a look when you can
[22:10] <bdmurray> cyphermox: Could you add a test case for receiving the prompt to bug 564843?
[22:11] <bdmurray> er bug 564853
[22:13] <bdmurray> rharper: if its done why is the disco task still open?
[22:14] <rharper> lemme check; it should be released; but I need to check the disco  bits
[22:16] <rharper> bdmurray: it's in disco;  we didn't mark the task done
[22:17] <bdmurray> rharper: okay
[22:17] <rharper> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1819038/comments/4
[22:17] <rharper> bdmurray: for context
[22:19] <bdmurray> rharper: shouldn't that one be fix released too?
[22:19] <rharper> yes, yes it should
[22:42] -queuebot:#ubuntu-release- Unapproved: rejected gtk+3.0 [source] (cosmic-proposed) [3.24.4-0ubuntu1.1]
[22:58] -queuebot:#ubuntu-release- Unapproved: accepted parted [source] (bionic-proposed) [3.2-20ubuntu0.2]
[22:59] -queuebot:#ubuntu-release- Unapproved: rejected ggcov [source] (bionic-proposed) [0.9+20190314-0ubuntu0.1]
[23:27] -queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (bionic-proposed) [2:12.0.1-0ubuntu1]
[23:29] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.5-0ubuntu1]