[00:19] smoser: ping [00:23] rharper: you may be able to hel guide, if you're around, as well [00:23] here [00:23] rharper: hey, so i'm looking at LP: #1645515 [00:23] Launchpad bug 1645515 in curtin "Support for ISCSI block devices" [High,Confirmed] https://launchpad.net/bugs/1645515 [00:23] i think i finally understand the code enough to know where the changes need to go [00:24] 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] the format is a suggestion; not a spec [00:25] my suggestion would be to run with changes to that that make sense [00:26] we will get to define what's required and the format [00:26] maas will the learn to specify the format as needed [00:26] ok, so my initial thought was to overload 'path', as the rfc2173 format is a network path (fully specified) to a disk [00:26] rather than adding a nested iscsi config section [00:28] hrm [00:28] so, conceptually I would like to treat an iscsi disk as a disk generically [00:28] agreed, rather than a special case [00:29] 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] I imagined the iscsi.* space to include details w.r.t what is needed for establishing the connection [00:29] right, but the rfc2173 specification is all of that in one line [00:30] *4173 [00:30] the path would be an expected dev/disk/by-id path [00:30] s/would/coud [00:30] could [00:30] ok [00:30] and given that, it feels weird (to me) to say [00:30] iscsi: [00:31] uri: iscsi:::... [00:31] as it seems sort of redundant :) [00:32] 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] yep, that's what i was thinking [00:32] just wanted to verify it made some sense first :) [00:33] 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] I'm thinking we may need to spin those up first [00:34] 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] ah good point [00:35] we could introduce an iscsi_handler that's fed disk objects which have a path with 'iscsi': at the start [00:35] and the iscsi_handler would call disk_handler after the setup is complete [00:36] 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] right [00:36] 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] or whatever local /dev path makes sense, i mean [00:37] y [00:37] rharper: great, thanks! [00:37] sure === salem_ is now known as _salem === juliank is now known as Guest7672 === pavlushka is now known as anyone === anyone is now known as pavlushka [09:33] cjwatson: thanks for the feedback with regards to using our seeds to resolve lightdm-gtk-greeter vs unity-greeter. [09:34] 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] 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] damn - unity-settings-daemon is still being installed - something else is pulling that in. [10:19] Hi, what's the systemd service that is responsible for removing the /run & /var/run tmpfs ? [10:31] fossfreedom_: Yep. [10:31] caribou, removing ? its a tmpfs ... so it is gone on reboot [10:31] you dont need a service for that [10:32] ogra_: hmm, yes true. [10:32] ok, I go back to sleep === _salem is now known as salem_ === hikiko is now known as hikiko|ln [12:34] * rbasak discovers that bug tasks have tooltips on Launchpad. [12:34] Handy! === hikiko|ln is now known as hikiko [14:27] nacc, reading back above... see in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804162 [14:27] Debian bug 804162 in open-iscsi "open-iscsi: support iscsi root by format in RFC 4173 (root=iscsi:server:prot:...)" [Wishlist,Fixed] [14:27] "Note that RFC does not cover username and password, so that would have to be done outside the spec if needed." [14:28] it may be sufficient to use what is supported in dracut and in that debian fix === salem_ is now known as _salem === _salem is now known as salem_ === JanC_ is now known as JanC [15:45] 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] Ubuntu packaging bug #1214608 [16:42] bug 1214608 in phatch (Ubuntu) "Unnecessary thai-fonts dependency" [Low,Triaged] https://launchpad.net/bugs/1214608 [16:51] Bug #1370599 [16:51] bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599 [17:05] smoser: ack [17:14] 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] 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] zerous: what are you trying to do? [17:42] nacc: Well I would like to fix bugs related to packaging. [17:43] Hence, I wanted to know how it is done. For instance bug 1370599 [17:43] bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599 [17:48] zerous: i don't see that source package any longer in ubuntu, do you? [17:49] zerous: bah, nm, typo on my part [17:50] zerous: afaict, in zesty, it already depends on wxgtk3.0 [17:52] barry, slangasek: will one of you be able to have a look at my apport changes? [17:58] nacc: yeah, it is. So I guess I have to hunt for another one [18:39] mm firefox broke? [18:44] chrisccoulson: nobody reported issues on firefox or so? Since the update to 51.0.1 my pages are all blank .. :) [19:04] anyone else with broken firefox since 51.0.1 update on yakkety? [19:08] dupondje, working for me, [19:08] strange... my whole page is just blank [19:08] downgraded, and it works fine again [19:14] dupondje, what addons do you have installed? [19:21] dupondje, do you see the browser chrome? Is it just the content that's blank? [20:02] chrisccoulson: even in safe mode its broken [20:02] and I see the bars etc indeed, just the content is white [20:02] but for example if I open a new tab, the 'history' pages are shown correctly [20:03] also if I browse to some site, I can click on the links etc [20:03] but its just all white [20:03] dupondje, does it work if you run with MOZ_FORCE_DISABLE_E10S=1 in the environment? [20:04] let me test [20:04] jbicha: you still have pkg-gnome packages on subversion?-) [20:05] tjaalton: we're moving to git soon, but that's been the case for several years, maybe in 2017? [20:05] chrisccoulson: yep! then it works fine again .. [20:06] tjaalton: I believe the main blocker all along was just making sure that svn history was preserved along with author mapping [20:07] dupondje, awesome, thanks! [20:07] :) [20:08] dupondje, can you please open a bug on bugzilla.mozilla.org? [20:08] (it would be worth including the info from about:support too) [20:09] 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] jbicha: alright, was just looking at backporting libpwquality from jessie to wheezy.. [20:10] for sssd [20:13] dupondje, once you've got a bug number, please let me have it :) [20:13] and I'll make sure the right people are cc'd [20:17] I feel like pkg-gnome is one of the largest remaining users of svn in Debian packaging [20:30] SVN? O__o [20:30] ...why? [20:30] because it really was a vast improvement over CVS :) [20:31] Well I guess my question is, why are we *still* using it? === salem_ is now known as _salem [20:51] chrisccoulson: i'll fix later this evening or tomorrow :) [20:51] trying to migrate my laptop to an SSD now :) [20:51] and that **** livecd isn't starting correctly :( [21:54] slangasek: "now redundant with iproute2" ... Is it though? [21:54] slangasek: arp, rarp, and netstat are tools I use near-daily. net-tools isn't just ifconfig and route. [21:56] 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] slangasek: Yeah, I found the ubuntu-devel discussion. [21:57] 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] slangasek: so something like? [21:58] dpkg-architecture -e s390x [21:58] if [ $? -eq 0 ] [21:58] then [21:58] exit 0 [21:58] fi [21:58] acheronuk: "if dpkg-architecture -e s390x; then" is the compact way to write that. [21:59] (Totally not sure of context) [22:00] 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] Understanding why it's broken would help. [22:03] 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] Yeah. Just curious if the failure has to do with s390x or with the infrastructure. [22:04] ie: People blame s390x for gnupg-fails-on-long-paths-in-containers, for instance. [22:04] 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] if so, that should show up on both s390x and armhf [22:05] Was just an example. [22:05] 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] anyway, I just wanted to confirm that a testuite would exit then with a 'no-op' pass with that code. [22:07] acheronuk: Anyhow, quibbling about "why" aside, yes, that should work. [22:07] infinity: thanks. still learning on these tests [22:08] slangasek: and thank you too [22:08] Or, much more compact: "dpkg-architecture -e s390x && exit 0" [22:08] infinity: Best way to check if package tests work locally? Docs are outdated. [22:08] tsimonq2: Run them locally. [22:09] infinity: ...how? [22:09] infinity: (in a Debian-packageish way) [22:09] 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] infinity: hm k [22:09] Thanks [22:10] 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] Ok thanks o/ [22:11] http://packaging.ubuntu.com/html/auto-pkg-test.html looks like the place. [22:15] infinity: yep running the tests locally works here. though some architectures don't seem possible to emulate here [22:17] there are newer 'autopkgtest' commands to run that that wiki link as well. pitti had a blog post explaining I think? [22:18] https://www.piware.de/tag/autopkgtest/ [23:02] 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] https://code.launchpad.net/~usd-import-team/ubuntu/+source/iproute2/+git/iproute2 ? [23:03] jgrimm: --^ [23:03] doh [23:03] jgrimm: there are about 300 packages imported now, it seems like [23:03] i saw! that's wild [23:04] jgrimm: do you need me to update iproute2? it might be out of date [23:04] nacc, yes it is, that's why i went looking for it [23:04] thanks! [23:04] jgrimm: np, running now [23:06] 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] yep, 4.9 was what i wanted [23:07] nacc, thanks