[00:19] <nacc> smoser: ping
[00:23] <nacc> rharper: you may be able to hel guide, if you're around, as well
[00:23] <rharper> here
[00:23] <nacc> rharper: hey, so i'm looking at LP: #1645515
[00:23] <nacc> i think i finally understand the code enough to know where the changes need to go
[00:24] <nacc> but in reading smoser's suggestion in c1, it feels like maybe the format suggested in the bug is not exactly what would be used -- minimally because rfc4173 includes 'iscsi:...'. Did you and smoser have a plan of how to specify a iscsi disk in the yaml?
[00:25] <rharper> the format is a suggestion; not a spec
[00:25] <rharper> my suggestion would be to run with changes to that that make sense
[00:26] <rharper> we will get to define what's required and the format
[00:26] <rharper> maas will the learn to specify the format as needed
[00:26] <nacc> ok, so my initial thought was to overload 'path', as the rfc2173 format is a network path (fully specified) to a disk
[00:26] <nacc> rather than adding a nested iscsi config section
[00:28] <rharper> hrm
[00:28] <rharper> so, conceptually I would like to treat an iscsi disk as a disk generically
[00:28] <nacc> agreed, rather than a special case
[00:29] <rharper> basically, once we've established connection, it will show up as a block device;  would we not be able to construct whatever dictionary of config needed under the disk.iscsi namespace ?
[00:29] <rharper> I imagined the iscsi.* space to include details w.r.t what is needed for establishing the connection
[00:29] <nacc> right, but the rfc2173 specification is all of that in one line
[00:30] <nacc> *4173
[00:30] <rharper> the path would be an expected dev/disk/by-id path
[00:30] <rharper> s/would/coud
[00:30] <rharper> could
[00:30] <rharper> ok
[00:30] <nacc> and given that, it feels weird (to me) to say
[00:30] <nacc> iscsi:
[00:31] <nacc>   uri: iscsi:<servername>:<protocol>:...
[00:31] <nacc> as it seems sort of redundant :)
[00:32] <rharper> yeah;  if we can get it in a single line, that seems reasonable;  in our disk_handler, we can check on path.startswith("iscsi:" ) and spin off an iscsi_handler
[00:32] <nacc> yep, that's what i was thinking
[00:32] <nacc> just wanted to verify it made some sense first :)
[00:33] <nacc> rharper: to be clear, that would be off in get_path_to_storage_volume? or would it be a special case in disk_handler itself? I see the former is called in multiple places
[00:34] <rharper> I'm thinking we may need to spin those up first
[00:34] <rharper> it could be triggered off the get_path_to_storage; but I don't like that as a side-effect of looking up a path
[00:34] <nacc> ah good point
[00:35] <rharper> we could introduce an iscsi_handler that's fed disk objects which have a path with 'iscsi':  at the start
[00:35] <rharper> and the iscsi_handler would call disk_handler after the setup is complete
[00:36] <rharper> the contract being that after iscsi_handler is done, the get_path_to_storage_volume would return the local scsi device path that can be used by disk_handler
[00:36] <nacc> right
[00:36] <nacc> that makes some sense to me, we pay the cost one-time, up front to setup the connection, at init time, and then from then on use the normal /dev/disk path and treat it like it's a local disk
[00:37] <nacc> or whatever local /dev path makes sense, i mean
[00:37] <rharper> y
[00:37] <nacc> rharper: great, thanks!
[00:37] <rharper> sure
[09:33] <fossfreedom_> cjwatson:  thanks for the feedback with regards to using our seeds to resolve lightdm-gtk-greeter vs unity-greeter.
[09:34] <fossfreedom_> I have updated our desktop seed.  I could not get germinate to run locally (kept saying 'unknown package' for various stuff) - but I noticed today that http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.zesty/_germinate_output no longer contains unity-greeter.
[09:34] <fossfreedom_> So I presume I should now run ./update in our meta package and ask for an upload of our meta package with the changes?
[10:10] <fossfreedom_> damn - unity-settings-daemon is still being installed - something else is pulling that in.
[10:19] <caribou> Hi, what's the systemd service that is responsible for removing the /run & /var/run tmpfs ?
[10:31] <cjwatson> fossfreedom_: Yep.
[10:31] <ogra_> caribou, removing ? its a tmpfs ... so it is gone on reboot
[10:31] <ogra_> you dont need a service for that
[10:32] <caribou> ogra_:  hmm, yes true.
[10:32] <caribou> ok, I go back to sleep
[12:34]  * rbasak discovers that bug tasks have tooltips on Launchpad.
[12:34] <rbasak> Handy!
[14:27] <smoser> nacc, reading back above... see in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804162
[14:27] <smoser> "Note that RFC does not cover username and password, so that would have to be done outside the spec if needed."
[14:28] <smoser> it may be sufficient to use what is supported in dracut and in that debian fix
[15:45] <zerous> Hi, I would like to get involved with ubuntu packaging and as I am really new I have decided to go with fixing packages which have unmet dependencies. However, I am not able to retrieve the list using debcheck.py as it throws an error "No such file or directory: debcheck.tmpl. I am running ubuntu yakkety with python 2.7.12
[16:42] <zerous> Ubuntu packaging bug #1214608
[16:51] <zerous> Bug #1370599
[17:05] <nacc> smoser: ack
[17:14] <nacc> doko: would you be ok with me merging ldb? Updated samba depends on a newer version of libldb-dev than what is in zesty currently?
[17:25] <zerous> nacc: I am really new to bug fixing and packaging, will you be able to walk me through the entire process of it ?
[17:32] <nacc> zerous: what are you trying to do?
[17:42] <zerous> nacc: Well I would like to fix bugs related to packaging.
[17:43] <zerous> Hence, I wanted to know how it is done. For instance bug 1370599
[17:48] <nacc> zerous: i don't see that source package any longer in ubuntu, do you?
[17:49] <nacc> zerous: bah, nm, typo on my part
[17:50] <nacc> zerous: afaict, in zesty, it already depends on wxgtk3.0
[17:52] <bdmurray> barry, slangasek: will one of you be able to have a look at my apport changes?
[17:58] <zerous> nacc: yeah, it is. So I guess I have to hunt for another one
[18:39] <dupondje> mm firefox broke?
[18:44] <dupondje> chrisccoulson: nobody reported issues on firefox or so? Since the update to 51.0.1 my pages are all blank .. :)
[19:04] <dupondje> anyone else with broken firefox since 51.0.1 update on yakkety?
[19:08] <jgrimm> dupondje, working for me,
[19:08] <dupondje> strange... my whole page is just blank
[19:08] <dupondje> downgraded, and it works fine again
[19:14] <chrisccoulson> dupondje, what addons do you have installed?
[19:21] <chrisccoulson> dupondje, do you see the browser chrome? Is it just the content that's blank?
[20:02] <dupondje> chrisccoulson: even in safe mode its broken
[20:02] <dupondje> and I see the bars etc indeed, just the content is white
[20:02] <dupondje> but for example if I open a new tab, the 'history' pages are shown correctly
[20:03] <dupondje> also if I browse to some site, I can click on the links etc
[20:03] <dupondje> but its just all white
[20:03] <chrisccoulson> dupondje, does it work if you run with MOZ_FORCE_DISABLE_E10S=1 in the environment?
[20:04] <dupondje> let me test
[20:04] <tjaalton> jbicha: you still have pkg-gnome packages on subversion?-)
[20:05] <jbicha> tjaalton: we're moving to git soon, but that's been the case for several years, maybe in 2017?
[20:05] <dupondje> chrisccoulson: yep! then it works fine again ..
[20:06] <jbicha> tjaalton: I believe the main blocker all along was just making sure that svn history was preserved along with author mapping
[20:07] <chrisccoulson> dupondje, awesome, thanks!
[20:07] <dupondje> :)
[20:08] <chrisccoulson> dupondje, can you please open a bug on bugzilla.mozilla.org?
[20:08] <chrisccoulson> (it would be worth including the info from about:support too)
[20:09] <tyhicks> chrisccoulson: isn't it odd that it is even broken in safe mode? when I start firefox in safe mode, e10s gets disabled
[20:09] <tjaalton> jbicha: alright, was just looking at backporting libpwquality from jessie to wheezy..
[20:10] <tjaalton> for sssd
[20:13] <chrisccoulson> dupondje, once you've got a bug number, please let me have it :)
[20:13] <chrisccoulson> and I'll make sure the right people are cc'd
[20:17] <jbicha> I feel like pkg-gnome is one of the largest remaining users of svn in Debian packaging
[20:30] <tsimonq2> SVN? O__o
[20:30] <tsimonq2> ...why?
[20:30] <sarnold> because it really was a vast improvement over CVS :)
[20:31] <tsimonq2> Well I guess my question is, why are we *still* using it?
[20:51] <dupondje> chrisccoulson: i'll fix later this evening or tomorrow :)
[20:51] <dupondje> trying to migrate my laptop to an SSD now :)
[20:51] <dupondje> and that **** livecd isn't starting correctly :(
[21:54] <infinity> slangasek: "now redundant with iproute2" ... Is it though?
[21:54] <infinity> slangasek: arp, rarp, and netstat are tools I use near-daily.   net-tools isn't just ifconfig and route.
[21:56] <slangasek> infinity: iproute2 contains ss as a replacement for netstat; arp and rarp don't seem particularly "minimal" to me; see both the debian-devel and ubuntu-devel discussions
[21:56] <infinity> slangasek: Yeah, I found the ubuntu-devel discussion.
[21:57] <infinity> slangasek: Despite it never having been Essential, I suspect there are a ton of user-local scripts that depend on ifconfig existing (I know I have a few), so that'll be fun fallout.
[21:58] <acheronuk> slangasek: so something like?
[21:58] <acheronuk> dpkg-architecture -e s390x
[21:58] <acheronuk> if [ $? -eq 0 ]
[21:58] <acheronuk> then
[21:58] <acheronuk>   exit 0
[21:58] <acheronuk> fi
[21:58] <infinity> acheronuk: "if dpkg-architecture -e s390x; then" is the compact way to write that.
[21:59] <infinity> (Totally not sure of context)
[22:00] <acheronuk> infinity: just wanting to put a conditional to exit a testuite with a pass exit code status, on an architecture that is borked for the test
[22:01] <infinity> Understanding why it's broken would help.
[22:03] <slangasek> sure. but inop'ing the test, on an architecture where the software is not actually supported, is better than making the release team repeatedly hint it
[22:04] <infinity> Yeah.  Just curious if the failure has to do with s390x or with the infrastructure.
[22:04] <infinity> ie: People blame s390x for gnupg-fails-on-long-paths-in-containers, for instance.
[22:04] <infinity> And the solution shouldn't be "ignore s390x", but "ignore in containers", or "try to sort out how to make it less dumb".
[22:04] <slangasek> if so, that should show up on both s390x and armhf
[22:05] <infinity> Was just an example.
[22:05] <acheronuk> asked upstream and could could maybe summarise the response as "why the *something are you building on that architecture?"
[22:06]  * infinity tries to teach himself 'ss' ...
[22:07] <acheronuk> anyway, I just wanted to confirm that a testuite would exit then with a 'no-op' pass with that code.
[22:07] <infinity> acheronuk: Anyhow, quibbling about "why" aside, yes, that should work.
[22:07] <acheronuk> infinity: thanks. still learning on these tests
[22:08] <acheronuk> slangasek: and thank you too
[22:08] <infinity> Or, much more compact: "dpkg-architecture -e s390x && exit 0"
[22:08] <tsimonq2> infinity: Best way to check if package tests work locally? Docs are outdated.
[22:08] <infinity> tsimonq2: Run them locally.
[22:09] <tsimonq2> infinity: ...how?
[22:09] <tsimonq2> infinity: (in a Debian-packageish way)
[22:09] <infinity> tsimonq2: For anything that doesn't reboot the testbed, you can just install the deps and run the tests listed in debian/tests/control
[22:09] <tsimonq2> infinity: hm k
[22:09] <tsimonq2> Thanks
[22:10] <infinity> For things that break the testbed, you can run them "properly" via... Stuff that is indeed documented.  But I always forget the URL.
[22:10]  * tsimonq2 naps, hurt my knee and I'm tired...
[22:10] <tsimonq2> Ok thanks o/
[22:11] <infinity> http://packaging.ubuntu.com/html/auto-pkg-test.html looks like the place.
[22:15] <acheronuk> infinity: yep running the tests locally works here. though some architectures don't seem possible to emulate here
[22:17] <acheronuk> there are newer 'autopkgtest' commands to run that that wiki link as well. pitti had a blog post explaining I think?
[22:18] <acheronuk> https://www.piware.de/tag/autopkgtest/
[23:02] <jgrimm> nacc, did you delete any git repos for packages in usd-import-team?  asking as i'm certain their used to be an iproute2 there
[23:03] <nacc> https://code.launchpad.net/~usd-import-team/ubuntu/+source/iproute2/+git/iproute2 ?
[23:03] <nacc> jgrimm: --^
[23:03] <jgrimm> doh
[23:03] <nacc> jgrimm:  there are about 300 packages imported now, it seems like
[23:03] <jgrimm> i saw! that's wild
[23:04] <nacc> jgrimm: do you need me to update iproute2? it might be out of date
[23:04] <jgrimm> nacc, yes it is, that's why i went looking for it
[23:04] <jgrimm> thanks!
[23:04] <nacc> jgrimm: np, running now
[23:06] <nacc> jgrimm: it ony imported two new publishes (4.9.0-1) to debian (sid/stretch), is that what you expected? (it's also done now if you want to fetch and check)
[23:07] <jgrimm> yep, 4.9 was what i wanted
[23:07] <jgrimm> nacc, thanks