| cpaelzer | doko: I think I found an issue in glibc 2.30 vs python triggering further issues in samba https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1842618 | 07:53 |
|---|---|---|
| ubottu | Launchpad bug 1842618 in python3.7 (Ubuntu) "python3.7 might need a rebuild against the new glibc 2.30 - fails with stropts define" [Undecided,New] | 07:53 |
| cpaelzer | doko: once you are around it would be great if you could let me know if you agree and schedule a python3 rebuild or if it is more complex than that | 07:54 |
| cpaelzer | because in case of the latter we might (for now) add some silly but working emergency patch to get samba updated | 07:54 |
| cpaelzer | sbeattie: ^^ FYI | 07:54 |
| doko | cpaelzer: uploaded | 08:09 |
| cpaelzer | uh, ok that seems like a "yes I agree" :-) | 08:09 |
| cpaelzer | thanks doko | 08:09 |
| RikMills | LP: #1842382 any clue why /proc/self/maps in a live session now shows nothing much? | 08:11 |
| ubottu | Launchpad bug 1842382 in vlc (Ubuntu) "vlc won't start; eoan 19.10 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate daily" [Undecided,Invalid] https://launchpad.net/bugs/1842382 | 08:11 |
| RikMills | cjwatson: | 08:11 |
| RikMills | um cyphermox I mean | 08:11 |
| RikMills | any clue why /proc/self/maps in a live session now shows nothing much? | 08:11 |
| Laney | doko: will look at mhash | 08:28 |
| Laney | first I've heard of it though | 08:28 |
| Laney | quite an easy one, lucky :-) | 08:33 |
| fredldotme | hello, fine folks! | 08:51 |
| fredldotme | I'm here on behalf of UBports. We run into an ugly ICE with gcc-5 from xenial and would need some help to get this fixed. | 08:52 |
| doko | unlikely | 09:05 |
| Laney | doko: there you go | 09:05 |
| Laney | nmued it too for good measure | 09:05 |
| doko | ta | 09:07 |
| fredldotme | the issue we encounter is here: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419 | 09:53 |
| ubottu | Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New] | 09:53 |
| fredldotme | as I see it doko already fixed the issue on the Debian side with gcc-6. | 09:54 |
| === M_hc[m] is now known as _hc | ||
| rafaeldtinoco | good morning o/ | 10:36 |
| rbalint | sil2100, what should i press to make bileto trigger autopkgtests? https://bileto.ubuntu.com/#/ticket/3798 | 10:50 |
| Laney | lander signoff I think | 10:51 |
| choon | https://answers.launchpad.net/ubuntu/+source/systemd/+question/683624 | 10:51 |
| rbasak | xnox: incoming regression-update report: bug 1842651 | 11:42 |
| ubottu | bug 1842651 in systemd (Ubuntu) "Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules" [Undecided,New] https://launchpad.net/bugs/1842651 | 11:42 |
| rbasak | Though it looks like the reported version isn't the current one in -updates? | 11:42 |
| xnox | rbasak: yes. | 11:42 |
| xnox | hm | 11:42 |
| rbasak | I would ask for verification about .28 but I thought maybe better to leave it with you then add another cook. | 11:43 |
| rbasak | than | 11:43 |
| xnox | rbasak: that's a valid question, and i did ask that now. I fear this might be regression due to removal of the "retry renaming persistent interfaces" patch that was recently SRUed. Highlight ddstreet RAOF chrisccoulson | 11:46 |
| xnox | rbasak: but also i'm not sure if security update trumped the inflight proposed update or not | 11:46 |
| xnox | chrisccoulson: did https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.28 trump anything? | 11:46 |
| chrisccoulson | xnox, it didn't - it's based on the version in -updates | 11:47 |
| RAOF | xnox: we worked to get the security update based on that SRU | 11:47 |
| xnox | ack | 11:47 |
| chrisccoulson | well, it's in updates now - I based it on what was in the proposed pocket to avoid trumping it | 11:47 |
| xnox | chrisccoulson: tah =) so it was a chrisccoulson setup by having a regression in -proposed ;-) | 11:47 |
| ddstreet | xnox rbasak i don't think i had anything to do with that, looks like FourDollars drove that change | 11:48 |
| xnox | ddstreet: ack | 11:49 |
| chrisccoulson | xnox, RAOF, is this regression important enough for us to need to do a revert? We'd need to do that through the security pocket | 11:57 |
| chrisccoulson | I can prepare uploads now if you think it's necessary | 11:57 |
| FourDollars | ddstreet: In fact, that commit has been accepted in the git repository before I start to do another bug's SRU. | 12:02 |
| ddstreet | FourDollars ok so the commit came from vicamo? https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=832a06123f7b060b67394fe270123d80c8d7e37b | 12:11 |
| FourDollars | ddstreet: Yes | 12:12 |
| ddstreet | ok, sounds like we need that removed patch back then (i.e. Revert-udev-network-device-renaming-immediately-give.patch) | 12:12 |
| xnox | ddstreet: but that will then regress the "takes to long to connect to network upon duplicate macs" | 12:13 |
| FourDollars | Yes. XD | 12:14 |
| xnox | ddstreet: somehow we need both, or like ignore/filter out duplciate mac nics.... | 12:14 |
| xnox | ddstreet: FourDollars: vicamo: the duplicate MAC nics.... am I crazy, or should we simply take those two NICs and automatically create a bond out of them? | 12:15 |
| xnox | as that is the intention, no?! | 12:15 |
| FourDollars | xnox: Sorry. I don't know much about it. What I SRUed is majorly for https://bugs.launchpad.net/bugs/1740894. | 12:17 |
| ubottu | Launchpad bug 1740894 in OEM Priority Project bionic "KEY_RFKILL is not passed to userspace" [Critical,Fix released] | 12:17 |
| ahasenack | cpaelzer: so tl;dr for samba wrt opts header? Was a new upload of python done? | 12:39 |
| === ricab is now known as ricab|lunch | ||
| cpaelzer | ahasenack: yes it was done | 13:00 |
| cpaelzer | ahasenack: it reached proposed https://launchpad.net/ubuntu/+source/python3.7/3.7.4-4 | 13:00 |
| cpaelzer | so we can now hit rebuils on samba which I'll do now | 13:00 |
| cpaelzer | if all fits as expected it will now build just fine | 13:00 |
| cpaelzer | ubt I'll check the header on the new python first | 13:00 |
| cpaelzer | oh someone started it already | 13:01 |
| cpaelzer | and it builds fine | 13:01 |
| cpaelzer | so things are good again | 13:01 |
| ahasenack | ok, thx | 13:02 |
| cpaelzer | ahasenack: here are the greens https://launchpad.net/ubuntu/+source/samba/2:4.10.7+dfsg-0ubuntu2 | 13:02 |
| cpaelzer | with the usual slow arm taking a while | 13:02 |
| ahasenack | rafaeldtinoco: there is a history of test hints for ocfs2-tools | 13:03 |
| ahasenack | rafaeldtinoco: what we could do there is use that skippable check, if arch == s390x | 13:03 |
| rafaeldtinoco | ahasenack: yep. im giving a last look at 3 functions dealing with bit shifts | 13:04 |
| rafaeldtinoco | and then right after will suggest that | 13:04 |
| rafaeldtinoco | if nothing is conclusive | 13:04 |
| ahasenack | ok, didn't want you getting into a rabbit hole | 13:04 |
| ahasenack | can also do both: skippable, and then work on the bug without a hurry | 13:04 |
| rafaeldtinoco | ahasenack: no no, good stuff you got in public bug also | 13:04 |
| rafaeldtinoco | true. i was mostly worried if all ocfs2 was broken for s390 .. | 13:05 |
| rafaeldtinoco | (because this comes from libocfs2) | 13:05 |
| rafaeldtinoco | and if it is, more than skip, we would have to remove the arch | 13:05 |
| rafaeldtinoco | thats why I havent decided yet for skip the test | 13:05 |
| rafaeldtinoco | lets see :\ | 13:05 |
| ahasenack | rbasak: hi, I have a versioned build-dep question | 13:22 |
| ahasenack | rbasak: libpmemobj(src) has build-dep libpmemobj-dev(>=1.6~), libdaxctl-dev, libndctl-dev | 13:22 |
| ahasenack | sorry, let me rephrase | 13:22 |
| ahasenack | packages have similar names | 13:22 |
| ahasenack | rbasak: libpmemobj-cpp(src) has build-dep libpmemobj-dev(>=1.6~), libdaxctl-dev, libndctl-dev | 13:23 |
| ahasenack | the 3 build-deps I listed come from the same source: pmdk | 13:23 |
| ahasenack | libpmemobj-cpp is another src | 13:23 |
| ahasenack | so | 13:23 |
| ahasenack | with libpmemobj-dev 1.6.1 and later, the libdaxctl-dev and libndctl-dev build-deps can be dropped from libpmemobj-cpp | 13:23 |
| ahasenack | so we would have only Build-depends: libpmemobj-devel(>= 1.6~) | 13:23 |
| ahasenack | the question I got in review is if I shouldn't then update that version, since it's only with 1.6.1 and later that I can drop the libdaxctl-dev and libndctl-dev build-depends | 13:24 |
| ahasenack | i.e., isn't this more correct for libpmemobj-cpp(src): Build-depends: libpmemobj-devel (>= 1.6.1~) | 13:24 |
| ahasenack | I remember vaguely we talking about something similar in the past, that versioned build-depends shouldn't be that strict in general | 13:25 |
| * rbasak reads | 13:26 | |
| fredldotme | do you think there's a possibility someone at Canonical will take a look at our issue and backport the patch (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=261588) to gcc-5? | 13:29 |
| rbasak | ahasenack: the usual thing I go for is to not use depends (or build depends) for bugfixes, since 1) then things get awkward when bugfixes are backported; and 2) if fixing a bug we update the archive, everything updates and so no dependency is actually required | 13:30 |
| rbasak | ahasenack: for build-depends I think it's entirely up to ease of maintenance - if it holds a build back as needed, or will inform a backporter of a problem early, then it's useful | 13:31 |
| ahasenack | rbasak: this package in particular (libpmemobj-cpp) only exists in eoan, but the mentioned build-deps go back | 13:31 |
| rbasak | Otherwise there's no need. | 13:31 |
| rbasak | So I think it's up to you. | 13:31 |
| rbasak | (>= 1.6.1~) is correct if you want to express that in the build dependency | 13:31 |
| rafaeldtinoco | fredldotme: you mean for Xenial ? why dont u open a launchpad bug and suggest that ? | 13:31 |
| rafaeldtinoco | explain why you need that backport and what situation it would solve. | 13:32 |
| ahasenack | rbasak: the reason to build-dep on 1.6~, is code-wise. To build-dep on 1.6.1~, is well, the build will just fail without the (now) missing build-deps | 13:32 |
| rbasak | ahasenack: right. What I'm saying is: do you wish to express that in the build dependency? | 13:33 |
| ahasenack | rbasak: for eoan that would be correct. For < eoan, it would be introducing a bug, because 1.6.1 is not there, and with 1.6, the build-dep is not needed | 13:33 |
| ahasenack | not seeing me doing a backport, though | 13:33 |
| rbasak | Because almost every unversioned build dependency probably could correctly be versioned with a >=, but we don't do that for everything. There's no requirement to do so, except when it's convenient for us. | 13:34 |
| fredldotme | rafaeldtinoco already did: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419 | 13:34 |
| ubottu | Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New] | 13:34 |
| ahasenack | rbasak: right | 13:34 |
| rbasak | fredldotme: do you mean Canonical, or Ubuntu? | 13:35 |
| rbasak | fredldotme: Canonical will generally only do things for customers or if there's a big impact to Ubuntu users, since everything else falls off the priority list. | 13:35 |
| rbasak | fredldotme: however anybody can contribute to Ubuntu and all are welcome and encouraged to do so. | 13:35 |
| rbasak | fredldotme: if you have a patch and would like to drive landing the fix in Ubuntu yourself, see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1838419 | 13:36 |
| ubottu | Launchpad bug 1838419 in gcc-5 (Ubuntu) "ICE in emit_block_move_hints, at expr.c:1144" [Undecided,New] | 13:36 |
| rbasak | Uh | 13:36 |
| rbasak | https://wiki.ubuntu.com/StableReleaseUpdates | 13:36 |
| fredldotme | rbasak I see, if someone from Ubuntu would like to help us that would be great. All the information required to get the backport in is in the launchpad bugreport | 13:37 |
| rbasak | fredldotme: you'd be expected to work on as much as you can yourself, according to our documented policy and processes. | 13:37 |
| fredldotme | rbasak ofc | 13:38 |
| rbasak | fredldotme: if you have specific questions about our processes, you're welcome to ask here. | 13:38 |
| rbasak | fredldotme: I would start by checking the page I linked to ensure that your proposed patch is acceptable to land according to our policies (which exist to protect Ubuntu users) | 13:38 |
| rbasak | fredldotme: your goal would be to get the bug fully documented according to our requirements, and to present us with a debdiff ready for sponsorship. | 13:39 |
| rbasak | (and then you'd be expected to help with QA afterwards) | 13:39 |
| rafaeldtinoco | AND, for this case, in particular, you said gcc-6 in debian has a fix for the same issue | 13:41 |
| rafaeldtinoco | you could even use that patch for the Ubuntu SRU (stable release update) | 13:41 |
| fredldotme | that would be my first thing to try, backport the fix to gcc-5 with a PPA up and running, then we can discuss how to proceed with merging the patch. | 13:43 |
| ahasenack | rafaeldtinoco: the bug you just filed on crmsh, about parallax | 13:43 |
| ahasenack | rafaeldtinoco: I've seen that backtrace before | 13:43 |
| ahasenack | https://bugs.launchpad.net/ubuntu/+source/crmsh/+bug/1687095 | 13:43 |
| ubottu | Launchpad bug 1687095 in crmsh (Ubuntu Xenial) "crm cluster health does not work: python3-parallax and cluster-glue (hb_report) dependencies" [Undecided,Confirmed] | 13:43 |
| rafaeldtinoco | ahasenack:i used your previous bug | 13:44 |
| ahasenack | oh, wait | 13:44 |
| rafaeldtinoco | changed its title to add eoan | 13:44 |
| ahasenack | ok, sorry :) | 13:44 |
| rafaeldtinoco | so its 2 issues | 13:44 |
| rafaeldtinoco | =o) | 13:44 |
| ahasenack | you did me a confuse | 13:44 |
| rafaeldtinoco | ahasenack:im glad you still remember | 13:44 |
| rafaeldtinoco | lol | 13:44 |
| ahasenack | (dog speak) | 13:44 |
| rafaeldtinoco | fredldotme: to be honest, after checking both build logs | 13:44 |
| rafaeldtinoco | how are you sure that the backport would solve your issue ? | 13:44 |
| rafaeldtinoco | make sure to test it before, cause its in the same internal (to gcc) function but different issues/failures | 13:45 |
| rafaeldtinoco | make sure you explain that also (in the SRU).. having a working PPA would be +1 for the SRU acceptance also | 13:45 |
| fredldotme | rafaeldtinoco I was just following the lead from the Debian bug to the upstream gcc patch. it's certainly possible the patch doesn't fix our specific issue, there's only one way to find out: testing it :) | 13:49 |
| rafaeldtinoco | fredldotme: yep, I'd bet there are more fixes related to arm64<->armhf cross compiling | 13:50 |
| rafaeldtinoco | fredldotme: "tip" you can always use the upstream gcc-5 version, with "debian/" directory from Xenial (without applying the patches from debian/patches/*) and bisect generating pkgs.. | 13:51 |
| rafaeldtinoco | so lets say from gcc5 to gcc7 this is fixed, you might be able to bisect the upstream source, by generating debian packages and testing, lets say.. just to give an example on what can be done | 13:51 |
| rafaeldtinoco | after finding what fixed the issue, you can propose the SRU | 13:51 |
| rcj | rbasak and the SRU team: Can I get a review of the test SRU test plan @ https://wiki.ubuntu.com/ec2-hibinit-agent-Updates ? | 13:57 |
| rcj | sorry rbasak, that was meant for rbalint ^ | 13:58 |
| rcj | (happy to have the review, but I flubbed the autocomplete) | 13:58 |
| === ricab|lunch is now known as ricab | ||
| rafaeldtinoco | cpaelzer: alright. so ill drop ocfs2-tools s390 builds and explain in the LP and do a merge request. | 14:22 |
| cpaelzer | yeah, I mean all the years it was accepted that it doesn't work there but "kept" | 14:23 |
| cpaelzer | yet I'd agree that if it isn't working (and not meant to be working) there then the right thing would be to remove it | 14:23 |
| cpaelzer | maybe xnox or jfh have faced that (discussion) before | 14:23 |
| rafaeldtinoco | cpaelzer: im putting into a comment, but.. they are basically doing shifts in a (char *) that points to a (void *) and checking addr mask | 14:24 |
| xnox | cpaelzer: que que?! more context =) | 14:24 |
| rafaeldtinoco | xnox: ocfs2-tools s390 | 14:24 |
| rafaeldtinoco | you are aware of that already | 14:24 |
| cpaelzer | it doesn't work on s390x, and AFAIK it never did | 14:25 |
| rafaeldtinoco | anything against removing from s390 ? as libocfs2 is broken | 14:25 |
| cpaelzer | it was force-badtest all the time | 14:25 |
| cpaelzer | but I'd agree that if it doesn work then there should be no s390x biary for it | 14:25 |
| rafaeldtinoco | ocfs2_set_bit does little endian operations only (for masking addresses of the inode bitmaps) | 14:25 |
| ahasenack | some tests pass, I guess there was hope it would soon fully work | 14:26 |
| xnox | cpaelzer: rafaeldtinoco: ideally it would have a unittest and the package is attempted to build, but ftbfs | 14:26 |
| ahasenack | or maybe some portions of it work | 14:26 |
| cpaelzer | xnox: wouldn't that prevent the other architectures from entering proposed? | 14:26 |
| rafaeldtinoco | xnox: bitwise passes.. test fails because asserts() fail (since bitwise are little endian aware only) | 14:26 |
| rafaeldtinoco | building is ok, logic is broken | 14:27 |
| xnox | such that it doesn't produce binaries, but like attempts to do that, and like all the time. | 14:27 |
| xnox | cpaelzer: it will be fine. | 14:27 |
| xnox | cpaelzer: we will need AA to remove debs from release pocket, and everything will be fine from then on. | 14:28 |
| xnox | cpaelzer: as it wouldn't be a regression in arches support from then on. | 14:28 |
| cpaelzer | yeah if that works I'm ok with that approach | 14:29 |
| cpaelzer | rafaeldtinoco: do you think such a unit test would be easy to add? | 14:29 |
| xnox | rafaeldtinoco: that's what i'm saying, add a build time unit test which shows this broken logic and fails. | 14:29 |
| rafaeldtinoco | https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/4 | 14:30 |
| ubottu | Launchpad bug 1745155 in ocfs2-tools (Ubuntu) "o2image fails on s390x" [Medium,Confirmed] | 14:30 |
| rafaeldtinoco | definitely | 14:31 |
| rafaeldtinoco | i could check if arch is big endian by checking 0xfff0 to 0x0fff | 14:31 |
| rafaeldtinoco | DEB_BUILD_ARCH_ENDIAN or just check that | 14:31 |
| rafaeldtinoco | or DEB_HOST_ARCH_ENDIAN or DEB_TARGET_ARCH_ENDIAN | 14:31 |
| cpaelzer | rafaeldtinoco: could we test this ocfs2_set_bit ? | 14:32 |
| rafaeldtinoco | but if all big endians are broken | 14:32 |
| rafaeldtinoco | cpaelzer: yep | 14:32 |
| rafaeldtinoco | I can create this | 14:32 |
| rafaeldtinoco | do a ocfs2_set_bit like test | 14:32 |
| cpaelzer | not like "if big endian then die", but really call ocfs2_set_bit adn check against a expected value or so? | 14:32 |
| rafaeldtinoco | sure | 14:32 |
| cpaelzer | yep | 14:32 |
| rafaeldtinoco | ill add a DEP8 about this then | 14:32 |
| rafaeldtinoco | should I fail build ? | 14:32 |
| rafaeldtinoco | or just the test ? | 14:32 |
| rafaeldtinoco | (are we removing it from s390x still ?) | 14:32 |
| cpaelzer | rafaeldtinoco: it must be a build time test, not a dep8 | 14:32 |
| rafaeldtinoco | perfect | 14:33 |
| cpaelzer | otherwise it won't work out the way xnox and I discussed | 14:33 |
| cpaelzer | xnox: btw while I always trust your advice, could you outline in a few words why this is better than Architceture: !s390x in d/control ? | 14:33 |
| cpaelzer | for spotting when it ever starts to work? | 14:34 |
| xnox | cpaelzer: there is no way to declare !s390x, only explicit list of arches..... which is pain to maintain as whitelist especially when we are going to add more arches | 14:35 |
| cpaelzer | ok, that is a reason | 14:36 |
| cpaelzer | thanks | 14:36 |
| === bryce__ is now known as bryyce | ||
| marcoceppi | fginther`: 👋 I've spent a bit of time with livecd-rootfs - grabed the latest from git, built and installed it. I set what I assume are the correct parameters and did a `lb config` and `lb build`. I'm just not sure what the result of that is, as none of files resemble that which is foud at cdimages for rpi3 images | 14:38 |
| smoser | rafaeldtinoco: around ? | 15:00 |
| smoser | https://bugs.launchpad.net/cloud-utils/+bug/1842682 :-( | 15:00 |
| ubottu | Launchpad bug 1842682 in cloud-utils "regression in test-growpart results in test fail device or resource busy" [High,Confirmed] | 15:00 |
| rafaeldtinoco | yep, next in my queue | 15:01 |
| smoser | sorry | 15:01 |
| rafaeldtinoco | nah, i saw it yesterday | 15:01 |
| smoser | humans (at least smoser) are so incompetant | 15:01 |
| rafaeldtinoco | tks for the headsup! | 15:01 |
| rafaeldtinoco | today is the ocfs2-tools s390 fun :\ | 15:01 |
| fginther` | marcoceppi, I wasn't aware you were going to try to build images from scratch with livecd-rootfs, just modify an existing image. We actually use a helper utility to build with livecd-rootfs: https://github.com/chrisglass/ubuntu-old-fashioned | 15:09 |
| marcoceppi | fginther`: Oh, then I'm not sure how to modify an existing image | 15:09 |
| fginther` | marcoceppi, that project is essentially a single bash script which does the setup and execution of a build | 15:09 |
| marcoceppi | I'm happy to build from scratch or modify | 15:09 |
| smoser | rafaeldtinoco: i'm just going to do an upload to eoan with that in it | 15:09 |
| smoser | thanks to rharper for quick review | 15:10 |
| * tribaal notices the highlight. | 15:10 | |
| tribaal | hi all :) | 15:10 |
| marcoceppi | whichever you think would be the most sane fginther` | 15:10 |
| fginther` | hey tribaal :) | 15:10 |
| rafaeldtinoco | smoser: awesome, I can include the fix in the SRU | 15:10 |
| rafaeldtinoco | if you are ok | 15:10 |
| smoser | yeah. | 15:10 |
| smoser | i'd let it get through an autopkg test though ;) | 15:10 |
| rafaeldtinoco | +1 | 15:10 |
| fginther` | marcoceppi, since you're already down the build from scratch path. I suggest to continue. The ubuntu-old-fashioned has some assumptions about which livecd-rootfs project to build (it defaults to the cloud builds). The rpi3 builds will be under a different project | 15:11 |
| marcoceppi | I'll take a look! thanks | 15:12 |
| bdmurray | rbasak: Are you familiar with sphinxsearch at all? | 18:05 |
| bdmurray | rbasak: I've discovered the answer to my question | 18:21 |
| ahasenack | bdmurray: is he familiar or not? :) | 18:30 |
| bdmurray | ahasenack: okay, I've discovered the answer to my original question! ;-) | 18:35 |
| ahasenack | :) | 18:36 |
| tarzeau | if a gui app creates a window, that window should be movable independant of the main other window. i wonder who came up with the idea to let the main window move with the sub window. braindead! QT5! | 18:36 |
| tarzeau | can i turn that crap off somehow? | 18:36 |
| marcoceppi | fginther`: hey - thanks for your help. I'll be authoring up a blog post about what it took, but in short I was using the wrong IMAGEFORMAT parameter. Needed `ubuntu-image` instead of `ext4` | 20:22 |
| fginther` | ah, glad to hear! :) | 20:23 |
| === fginther` is now known as fginther | ||
| fginther | marcoceppi, I'd be interested in reading that post if you're willing to share :) | 20:24 |
| marcoceppi | fginther: hopefully next week, depends on how far I get in baking in my changes needed for deployments | 20:27 |
| CarlFK | marcustomlinson: long shot based on "deployments" - https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_quick_start.html | 20:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!