nacc | smoser: ping | 00:19 |
---|---|---|
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 |
ubottu | Launchpad bug 1645515 in curtin "Support for ISCSI block devices" [High,Confirmed] https://launchpad.net/bugs/1645515 | 00:23 |
nacc | i think i finally understand the code enough to know where the changes need to go | 00:23 |
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:24 |
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:25 |
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:26 |
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:28 |
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:29 |
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:30 |
nacc | uri: iscsi:<servername>:<protocol>:... | 00:31 |
nacc | as it seems sort of redundant :) | 00:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
nacc | or whatever local /dev path makes sense, i mean | 00:37 |
rharper | y | 00:37 |
nacc | rharper: great, thanks! | 00:37 |
rharper | sure | 00:37 |
=== salem_ is now known as _salem | ||
=== juliank is now known as Guest7672 | ||
=== pavlushka is now known as anyone | ||
=== anyone is now known as pavlushka | ||
fossfreedom_ | cjwatson: thanks for the feedback with regards to using our seeds to resolve lightdm-gtk-greeter vs unity-greeter. | 09:33 |
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? | 09:34 |
fossfreedom_ | damn - unity-settings-daemon is still being installed - something else is pulling that in. | 10:10 |
caribou | Hi, what's the systemd service that is responsible for removing the /run & /var/run tmpfs ? | 10:19 |
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:31 |
caribou | ogra_: hmm, yes true. | 10:32 |
caribou | ok, I go back to sleep | 10:32 |
=== _salem is now known as salem_ | ||
=== hikiko is now known as hikiko|ln | ||
* rbasak discovers that bug tasks have tooltips on Launchpad. | 12:34 | |
rbasak | Handy! | 12:34 |
=== hikiko|ln is now known as hikiko | ||
smoser | nacc, reading back above... see in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804162 | 14:27 |
ubottu | Debian bug 804162 in open-iscsi "open-iscsi: support iscsi root by format in RFC 4173 (root=iscsi:server:prot:...)" [Wishlist,Fixed] | 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:27 |
smoser | it may be sufficient to use what is supported in dracut and in that debian fix | 14:28 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== JanC_ is now known as JanC | ||
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 | 15:45 |
zerous | Ubuntu packaging bug #1214608 | 16:42 |
ubottu | bug 1214608 in phatch (Ubuntu) "Unnecessary thai-fonts dependency" [Low,Triaged] https://launchpad.net/bugs/1214608 | 16:42 |
zerous | Bug #1370599 | 16:51 |
ubottu | bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599 | 16:51 |
nacc | smoser: ack | 17:05 |
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:14 |
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:25 |
nacc | zerous: what are you trying to do? | 17:32 |
zerous | nacc: Well I would like to fix bugs related to packaging. | 17:42 |
zerous | Hence, I wanted to know how it is done. For instance bug 1370599 | 17:43 |
ubottu | bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599 | 17:43 |
nacc | zerous: i don't see that source package any longer in ubuntu, do you? | 17:48 |
nacc | zerous: bah, nm, typo on my part | 17:49 |
nacc | zerous: afaict, in zesty, it already depends on wxgtk3.0 | 17:50 |
bdmurray | barry, slangasek: will one of you be able to have a look at my apport changes? | 17:52 |
zerous | nacc: yeah, it is. So I guess I have to hunt for another one | 17:58 |
dupondje | mm firefox broke? | 18:39 |
dupondje | chrisccoulson: nobody reported issues on firefox or so? Since the update to 51.0.1 my pages are all blank .. :) | 18:44 |
dupondje | anyone else with broken firefox since 51.0.1 update on yakkety? | 19:04 |
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:08 |
chrisccoulson | dupondje, what addons do you have installed? | 19:14 |
chrisccoulson | dupondje, do you see the browser chrome? Is it just the content that's blank? | 19:21 |
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:02 |
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:03 |
dupondje | let me test | 20:04 |
tjaalton | jbicha: you still have pkg-gnome packages on subversion?-) | 20:04 |
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:05 |
jbicha | tjaalton: I believe the main blocker all along was just making sure that svn history was preserved along with author mapping | 20:06 |
chrisccoulson | dupondje, awesome, thanks! | 20:07 |
dupondje | :) | 20:07 |
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:08 |
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:09 |
tjaalton | for sssd | 20:10 |
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:13 |
jbicha | I feel like pkg-gnome is one of the largest remaining users of svn in Debian packaging | 20:17 |
tsimonq2 | SVN? O__o | 20:30 |
tsimonq2 | ...why? | 20:30 |
sarnold | because it really was a vast improvement over CVS :) | 20:30 |
tsimonq2 | Well I guess my question is, why are we *still* using it? | 20:31 |
=== salem_ is now known as _salem | ||
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 :( | 20:51 |
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:54 |
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:56 |
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:57 |
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:58 |
infinity | (Totally not sure of context) | 21:59 |
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:00 |
infinity | Understanding why it's broken would help. | 22:01 |
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:03 |
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:04 |
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:05 |
* infinity tries to teach himself 'ss' ... | 22:06 | |
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:07 |
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:08 |
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:09 |
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:10 |
infinity | http://packaging.ubuntu.com/html/auto-pkg-test.html looks like the place. | 22:11 |
acheronuk | infinity: yep running the tests locally works here. though some architectures don't seem possible to emulate here | 22:15 |
acheronuk | there are newer 'autopkgtest' commands to run that that wiki link as well. pitti had a blog post explaining I think? | 22:17 |
acheronuk | https://www.piware.de/tag/autopkgtest/ | 22:18 |
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:02 |
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:03 |
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:04 |
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:06 |
jgrimm | yep, 4.9 was what i wanted | 23:07 |
jgrimm | nacc, thanks | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!