=== maclin1 is now known as maclin [06:16] Morning seb128 [06:39] good morning [06:40] Hi didrocks [06:43] hey duflu [06:45] hey duflu didrocks (and bbiab, dropping kid for the day) [06:45] Good morning [06:46] salut jibel [06:49] Morning jibel [06:55] duflu, about bug 1775743, ubuntu is the only OS on the machine ? [06:55] bug 1775743 in ubuntu-meta (Ubuntu) "[regression] Cosmic daily images 20180606-11 install but then never boot (stuck in grub)." [Critical,New] https://launchpad.net/bugs/1775743 [06:55] jibel, yes I've tried 3 different laptops. All completely wiped each time [06:56] could you attach the logs from /var/log/installer? [06:56] jibel, next time :) [06:56] It's a very time consuming bug [06:56] I know :) [06:57] jibel, if you have older images handy I can probably bisect it down to an exact image by tomorrow [06:59] duflu: hey! As mentioned on the bug, last week we did release a new grub2 package which potentially might have regressed something [06:59] Since there were some architectural changes there [06:59] duflu: but what worries me is that I cannot reproduce it on a VM [06:59] jibel: when you tested this on a VM, did you install -desktop as well? [07:00] That doesn't worry me. I wouldn't be able to do most of my job if I was confined to VMs. So many hardware issues [07:00] It worries me since I don't have an easy way to reproduce it, and the fact that it works on my VM makes it even harder to explain [07:01] Since the changes we did should either work for a setup or not [07:01] sil2100, I've no problem with cosmic on VMs [07:01] and yes I tried desktop, it's the only image I use [07:04] hm, I suppose it might be a bit difficult to create a one-off image with all the grub2 bits reverted, especially since there's the signed bits [07:07] Since most of the logic changes were in shim-signed and grub2-signed [07:07] duflu, is secure boot enabled? [07:08] sil2100, which version of grub introduced these changes? [07:08] jibel, usually no. Because these machines I only use for Ubuntu. But sometimes yet [07:08] yes [07:11] hey again desktopers :) [07:11] hey again seb128 [07:11] lut jibel, how are you? [07:12] seb128, I'm fine, thanks. [07:12] and you? [07:12] I'm good thanks [07:12] jibel: grub2-signed 1.96 and shim-signed 1.36 [07:13] sil2100, 1.96 only affects efi systems? [07:14] Potentially these changes should only affect UEFI installations, yes [07:16] okay, let me try in a vm with uefi then [07:21] I only tried server on both BIOS and UEFI on a VM and they worked, so maybe you'll have more luck with desktop [07:22] hmmm [07:26] sil2100, I confirm it's reproducible in a uefi vm [07:26] Might not be grub indeed as per what duflu mentioned, looks like it got broken a bit earlier [07:26] sil2100, with latest cosmic desktop image [07:26] jibel: thanks [07:26] Strange I didn't have the issues with the subiquity server image, but maybe I need to re-test [07:27] * sil2100 will do that now [07:27] sil2100, for you or foundations? [07:28] sil2100, subiquity uses a different method of installation afaik [07:28] jibel: yeah, I'll try both subiquity and regular debian-installer based server now, maybe it's not related to grub but something touching the installer? [07:29] I would really not want my first ever grub2 landing to cause big issues as such [07:29] ;) [07:30] sil2100, I bet you can reproduce with d-i [07:37] * didrocks realizes we didn't talk about git at the team meeting and documentation [07:37] I'll handle it I guess, finding one exemple like gnome-session, and writing docs on it, like how to update, how to apply a patch, udpate a patch… [07:38] basing on debian's doc and how to convert for us in launchpad [07:38] didrocks, right, I remembered after the meeting yesterday, we were already busy discussing some other aob with the theme and the gnome-shell update [07:38] thanks didrocks! [07:38] yw seb128 ;) [07:39] Laney, ^ if you want to help him a bit [07:42] morning [07:43] hey Nafallo [07:51] duflu, just as a fyi I'm still dealing with post-holidays catching up and performance reviews&co and don't have anything for the bluetooth meeting so I'm going to skip that one [07:51] I have a question on bluetooth! but unrelated to your meeting :) [07:51] haha [07:51] ask! [07:51] seb128, yes I was about to say that. I have been away 4 days, and koza is an "unknown" on the invite [07:51] duflu, let's skip [07:51] is there a way to create a rule or so so that you rfcomm bind automatically when a particular device is connected? [07:52] like, avoiding "sudo rfcomm bind …" [07:52] which requires root [07:52] seb128, on that note though I do have bluez 5.50 awaiting sponsorship some time [07:52] (and then, there is the bug duflu triaged that /dev/rfcomm* doesn't have correct permissions) [07:53] didrocks, I don't know that command myself. What bug do you mean? [07:54] duflu: bug #1014992 [07:54] bug 1014992 in bluez (Ubuntu) "Cannot use rfcomm as regular user. Permission denied." [Medium,Confirmed] https://launchpad.net/bugs/1014992 [07:54] and I would like to avoid "sudo" in rfcomm connect 1 [07:55] their fix is to disable modemmanager, but doesn't cover the create a /dev/rfcomm part as non root [07:57] jibel, it sounds like we are skipping the meeting [07:58] Morning willcooke. We ere about to skip the meeting unless you want it? [07:58] +w [07:58] morning, +1 [07:58] * willcooke isnt really with it yet anyway [07:59] hey willcooke, how are you? [07:59] able to speak today? ;) [07:59] :) [07:59] Bit better today, still a bit achey, but fine [08:00] hey willcooke [08:00] but I slept funny and now my neck /.shoulder is playing uop [08:00] up [08:00] it's an old injury and flares up every now and then [08:00] Don't get old kids, it sucks [08:02] hi [08:02] morning Laney [08:02] hey Laney, how are you? [08:02] hi willcooke seb128 [08:03] hey Laney [08:03] alright thanks, been potting some new houseplants [08:03] hey didrocks [08:03] what's up homies? [08:03] nothing special, yourself? [08:05] not a lot! [08:06] jibel: as expected, I was able to install and boot with subiquity on UEFI no problem - but of course I could reproduce it with the d-i installer for server [08:06] jibel: so yeah [08:06] At least I know what was wrong with my testing [08:20] didrocks, I can't add any expertise to that bug other than if it needs progressing then upstream reports go in https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=Bluetooth [08:20] duflu: ok, thanks for looking! [08:20] weird that we can't pair RFCOMM bluetooth device via g-c-c [08:22] didrocks: https://wiki.ubuntu.com/DesktopTeam/git I just added some basic thing about converting a repo for the first time [08:23] morning willcooke :-) [08:23] o/ [08:23] morning Laney [08:23] hey Nafallo [08:23] duflu, oh, I just saw your mention of bluez waiting for sponsoring, I can have a look to that today [08:23] ok, I'll edit those as needed [08:24] sil2100, good, I'll let this bug with you then since you broke the image ;) [08:24] didrocks, talk to Bastien? :p [08:24] seb128, yeah it was in the status report I didn't send due to leave yesterday. No hurry so I didn't push the point [08:24] seb128: yeah ;) [08:24] * jibel notes the testing gap and to add uefi to automated installer tests [08:25] didrocks, and no bluez is not a kernel component. It only shares the kernel tracker [08:25] jibel: I did not! As per duflu's comment it was broken before my upload! ;p [08:25] * duflu shrugs [08:25] * duflu shrugs at didrocks at least [08:25] argh :p [08:27] sil2100, over the coarse of my long weekend that actually wasn't the most annoying installation bug I found. There is also bug 1776578 :) [08:27] bug 1776578 in linux (Ubuntu) "Ubuntu installation stuck at "Installing the 'grub2' package..." every time. Kernel crash every time." [High,Incomplete] https://launchpad.net/bugs/1776578 [08:27] -coarse +course [08:34] k, changing location, bbiab [09:08] didrocks, hey! I just noticed that on my x270 I can enabled over-amplification, but the slider doesnt allow me to go > 100%. If I plug headphones in, then I can. Is that expected? [09:09] Likely something funny in the drivers here, since dock audio is a bit funny anyway [09:15] willcooke: it's only if the output allows to have over amplifications, some don't [09:16] didrocks, so would you expect it to be greyed out if not supported (the on/off button that is) - or - it would be there, but do nothing? [09:16] willcooke: the thing is that the option is global [09:16] so, if you have multiple output devices, it will impact them all [09:16] got it, thanks didrocks [09:16] in the proposed set of patches, I tried to ahve it per device [09:17] that was nacked by upstream [09:17] (it complexifies the logic a lot ofc, you ahve to track devices…) [09:17] kk, nw [09:17] yeah, not the best UI :/ [09:44] Laney: is there any reason why we push upstream/latest to launchpad? Do you know if this is used to rebuild the tarball which is in pristine-tar or should we just keep it locally? [09:45] well the upstream tags are made with reference to commits on this branch [09:45] so the next person to do work needs to be working from the same place [09:47] ah right, for further cherry-picking [09:47] so, it's more to get everything in one place [09:47] it'll go onto the upstream branch, merge the git tag and then the delta from the tarball, and make an upstream/x.y.z tag out of that [09:48] so you need it around to make that work [09:48] yeah, that's what I meant by "help reconstructing the tarball" [09:48] righto [09:49] but I think that it probably actually uses the tags for that [09:49] not that I've looked :-) [09:49] yeah [09:49] ok, sounds good [09:53] we should try to pull and push from different locations automatically for that branches [09:54] * didrocks looks if we can set that in config [09:54] you can do that somehow [09:54] so that git push works [09:54] yeah, I saw a global config [09:54] trying to find a local one or one we can add to the repository [10:05] ahah! branch..pushRemote sounds promising [10:06] it's local config though I think [10:06] I think it's in .git [10:06] let me try [10:06] I'm sort of OK with that - if you `git push -u' then it'll set it up for you [10:06] as long as we don't have to manually git push for upstream/latest, I'm fine [10:07] or we will never have it updated [10:07] why not? [10:07] because people will pull from matest to update upstream/latest [10:07] and will never think about updating the launchpad upstream/latest branch [10:07] git push lp ubuntu/master upstream/latest pristine-tar ubuntu/ upstream/ [10:07] that's my muscle memory [10:08] maybe yours, I doubt everyone will :) git push should just DTR I think [10:08] +1 [10:08] those syntaxs are chinese to me at least :p [10:08] ffs [10:09] well if there is no other way and that people have to learn long/complex commands that's the way it is [10:09] but if we can do simple things to just work that's better [10:09] imho [10:10] please [10:10] PLEASE [10:10] move away from asserting this is some insanely complex system [10:10] didrocks: look into push.default in git-config [10:10] probably you want "matching"? [10:10] Laney: nope, doesn't work as it's different remote [10:10] not different branch [10:10] but pushremote works [10:11] how does that make a no argument "git push" work? [10:11] Laney, I'm not saying that, just that a 2 arguments command is easier to remember than a 8 arguments one [10:11] git push origin -> push every tracking branch to origin repo [10:11] so, you end up with: [10:11] [branch "upstream/latest"] [10:11] remote = upstream [10:11] merge = refs/heads/master [10:11] pushremote = origin [10:12] for instance [10:12] ok, not no argument, I thought that's what you wanted [10:12] well, you have to define the origin you push to [10:13] but at least, we'll have the upstream/latest and pristine-tar branches push with your changes [10:13] without being out of sync and so on [10:13] When the command line does not specify where to push with the argument, branch.*.remote [10:13] (and as it's a local config, people can opt-in or not) [10:13] configuration for the current branch is consulted to determine where to push. If the configuration is [10:13] missing, it defaults to origin. [10:13] maybe this works already [10:14] it does [10:14] just tried :) [10:14] so, maybe we should add that as well [10:14] let's see, anyway, I think people will try/review and we'll iterate on the workflow [10:14] k [10:17] however: [10:17] $ git branch -vv [10:17] * upstream/latest 0bd90ca34 [upstream/master] region: Show scrollbars if needed [10:17] doesn't show the push remote, can be a first patch to git! :p [10:20] :> [10:21] what is "git push" pushing with your configuration if there are changes on multiple branches? [10:21] all of them or just the current one? [10:22] all of them [10:22] Trevinho: I just uploaded your gdm, do you want to handle the merge? (for practice) [10:22] well, all of them which is tracking the default remote [10:23] Laney: yeah, ok [10:23] Thanks [10:23] Laney: have you seen the nux thing too? [10:23] I'll try with additional new untracked branches and so on to confirm [10:25] good morning Trevinho! [10:26] Trevinho: the bug? [10:27] seb128: hi [10:27] yes, it doesn't add any untracked branch [10:27] Laney: https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1768610 [10:27] Ubuntu bug 1768610 in nux (Ubuntu) "leftover conffile forces GNOME is software rendering" [High,In progress] [10:28] Trevinho: yeah, that, is Andrea going to review or? [10:28] Laney: I've also prepared sru branches and bileto tickets, but I will update them [10:29] Laney: well, since it's 99% debian change I would go with you [10:30] I wanted to ask him yesterday, but I thought it was more for you [10:30] /o\ [10:30] you always add some random extra thing in :P [10:32] Laney: of course... I don't like partial solutions [10:33] like renaming the conffile [10:33] Laney: removing and the renaming it [10:34] That's optional of course, but since it's not a conf file there's no point of treating it like that [10:34] right, is that correct? [10:34] why not a mv_conffile? [10:34] oh a symlink? [10:34] wtf [10:34] I don't think you can hack the policy in that way really [10:34] Laney: that's that guidelines say... Not me [10:37] my laptop just froze long enough to type 1198 "i"s [10:38] Mh, I get freezes too, but I wasn't able to get anything from gdb [10:39] and there's loads of Jun 13 11:35:21 nightingale org.gnome.Shell.desktop[3732]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! [10:40] Trevinho: ok, where's this policy reference? :-) [10:41] 10.7.2 [10:41] Debian maintainer guide 5.3 [10:41] I mentioned in the commit msg I thought, no? [10:42] dunno, I'm looking at the diff [10:43] If the program you're packaging requires every user to modify the configuration files in the /etc directory [10:43] hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm [10:55] ok that time it crashed completelyy [10:56] Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough! [10:56] Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE) [10:56] Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: Fatal server error: [10:56] Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE) Error sending request: Resource temporarily unavailable [10:56] Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE) [11:09] Laney: well it talks about editing that, but that's the way to make sure that an /etc file is not a conffile, as in this case should not be at all [11:11] why not? [11:12] I mean I don't see why this one is different to any of the others in there [11:12] Laney: in fact I think they're all wrong [11:12] Laney: it's a distro-provided file not to be broken or changed by the user [11:13] this isn't really a policy to fix randomly in one SRU [11:13] those are scripts which are sourced, and while in some cases they might change settings, in this specific case it's not [11:15] Laney: not "randomly", anyway if you prefer I can not SRU that bit, but it's a matter of principle to me [11:15] for not being a conffile [11:16] well fine, but I think you should take this up with the X maintainers then [11:17] mh, well, I see the point for having Xsession.d in etc, and both for historic reason this can't be changed, but... Also because it could be used for user configurations, so it's fine to be in /etc to me, what's is wrong is the distro to threating it wrongly [11:20] maybe you want to ask for a way to put files in /usr [11:20] nope, since otherwise the order is compromised [11:21] I mean, that's an option too.. but [11:22] not necessarily, the order could be sorted by filename for example [11:22] anyway this is not a debate for me to have [11:23] sorry :( [11:24] I know it's nothing crucial, but I don't like the status quo and this is a clean way to fix it imho [11:24] considering we can't really change the wold, but we can change a package [11:24] world* (x11) [11:25] It's a hack, it's against policy and it's changing just one package when the alleged issue applies to more [11:25] soryr Marco [11:25] If you want to try to get someone else to approve it instead of me, you can feel free [11:27] Laney: it's not against the policy... it is based on the policy. An hack is what they propose too (as no other tools are provided to do things in a cleaner way). And while they mention a different scenario is, it has to be interpreted and can totally applied to this scope. [11:28] I don't really want to argue about this any more [11:28] but as I said, doing a bzr uncommit won't be a problem, but I wanted to point out this to underline where the issue is, and that we can have it fixed also don't worry about this later (if might happen) [11:32] hey :), it's just talking eh, but while I was aware and pretty expecting you didn't like :-D, I wanted to propose it anyway for some discussion, in a productive way. As to me this would be the way to go for all those files, and just starting from one (that is coincidentally causing troubles) [11:37] * Laney thinks that was supposed to be a PM :P [11:37] * Laney hugs Trevinho [11:38] Laney: ahah, no, just to underline there's no drama :-D [11:38] or maybe to make it for the interested audience [11:38] ohohoh [11:39] we could actually start fighting for "real", as any reality tv show, just in order to get people watching it :-D [11:40] jelly wrestling at the sun sprint [11:40] that's already on my list [11:47] ahaha [11:47] Laney: in the mean time I've updated https://code.launchpad.net/~3v1n0/ubuntu/+source/gdm3/+git/gdm3/+merge/347812 [11:48] 😘 [11:50] looks nice, thanks, /me test builds [11:50] don't spoil me now, eh... i still believe that my crusade against the conffile was right :-D [11:50] * Trevinho that's for the audience [11:51] :( trolled [11:55] * Nafallo muches popcorn [12:23] Laney: I also reverted the nux commit... [12:24] the SRU test case would be complicated though... [12:24] I don't know how people can test this upgrade at all [12:24] removing the file was quite easier to check :) [12:43] Trevinho, the SRU test case is easy [12:43] - install xenial [12:43] - upgrade to bionic [12:43] - sudo apt-get remove nux-tools [12:43] - log into your session [12:43] - check glxinfo (or other equivalent) [12:44] seb128: eh, no... that's too generic [12:44] ? [12:44] that's how the people who reported the bug got the issue [12:44] ah, wait... ok. [12:44] and a valid wait to test it [12:44] the test case doesn't need to be the most minimalistic way to test [12:44] just one way to confirm the problem is fixed [12:44] yeah, that's fine... I was thinking to the case of unity+gnome installed [12:44] but, that's just a consequence of the fix [12:45] ? [12:45] the bug report is "GNOME session uses software rendering" [12:45] the fix purpose is to make sure that doesn't happen when not necessary [12:45] yes. That could happen also in the case that unity has not been removed, but that tool fails [12:45] for any reason, thus leading to the same situation [12:46] right [12:46] well you can add another testcase if you wish [12:46] like rm the binary :p [12:46] so, I've also covered that case [12:46] or edit it in vim to corrupt it [12:46] or whatever [12:46] but that's not needed by the SRU process [12:46] what I described is good enough for the SRU [12:46] ok, fine [12:46] all bileto tickets are running [12:48] BI LE TOOOOOOOOOOOOO [12:48] * Trevinho is missing was missing it [12:48] * Trevinho was missing to hit ctrl+backspace too [12:51] SRU team hates reviewing bileto SRUs btw [12:51] ;-) [12:52] Trevinho: do you have an idea for handling people that already removed it without purging? [12:53] Laney: eh, as they don't have the tools, but I think fixed a bit [12:53] Laney: the only thing I was thinking is doing a purge from another package that is going to be installed instead, but not that I like the solution... [12:54] I mean the symlink thing was gold compared to this :) [12:54] I don't think there is a good solution :( [12:54] actually asked in #debian-devel about that earlier and nobody had a good idea [12:54] rm_conffile from like mesa or something would be OK as long as the file is put back if they reinstall nux-tools later on [12:55] Laney: that's why I also wanted to get rid of the conffile at all [12:55] Laney: in this way there won't be such problem either [12:56] stop engaging me in this argument please [12:58] ahaha, that's just I'm saying the rationale behind it (https://wiki.debian.org/ConfigPackages this also mentions something)... And don't keep it hard. It's just we're in a land of cases where clean solutions aren't always feasible, thus... [12:59] Laney: anyway doing a purge from postinst of ubuntu-desktop (or any other choice) for example would work, but really I don't like it [13:00] I don't think there *is* a good solution [13:00] I only say mesa because that's the pkg that is going to have (most) problems with this [13:00] i.e. you have a problem because you have this installed [13:09] Laney: true, I was thinking higher level like ubuntu-desktop since it's something that as a desktop we want it to be fixed when ubuntu-desktop is there, while we don't care if the user has other broken config. [13:09] Laney: anyway... thanks for approvals [13:09] but, I moved the a, b branches to another one since they don't include the m4 change [13:09] I just did the ones that were linked from the bug [13:10] Laney: yeah, you did wel.... I didn't update it yet as I was waiting for bileto results [13:10] Laney: I can self-approve btw as they're just the same - the m4 change [13:10] https://code.launchpad.net/~3v1n0/nux/x11-conffile-on-unity-only-ab/+merge/347867 [13:11] sure if you link to the one where I approved for reference [13:11] yep [13:11] that was the plan [13:19] Laney: when you've a sec, feel free to publish https://bileto.ubuntu.com/#/active?search=1768610 [13:24] Laney, Trevinho, that's what they did for upstart but they had an easier job that the package has been removed from the archive [13:25] seb128: that being? [13:25] http://launchpadlibrarian.net/358113353/xorg_1%3A7.7+19ubuntu4_1%3A7.7+19ubuntu5.diff.gz [13:25] DOH, sorry :) [13:26] thx! [13:26] np! [13:26] yeah I think you have to like check if the thing is removed [13:26] because it's still around [13:26] bit more complex as you say [13:26] morning all [13:26] same idea though [13:26] hey andyrock, how's it going? [13:27] hey andyrock [13:27] Laney: I'm good thanks you? [13:27] top [13:27] top QUALITY! [13:28] * Laney checks Trevinho's diffs carefully ;-) [13:30] ah, it wasn't me adding it as a conffiles [13:30] * didrocks started to become crazy [13:30] I added it for lightdm to check (but as a non file in /etc) [13:31] then, it's all Lukasz's fault adding it to Xsession.d :p [13:31] (but TBH, not real other alternatives) [13:32] and yeah, +1 on the issue for non real conffiles, but not something to change in a SRU ;) [13:32] /end-arg ;) [13:33] all published === pstolowski is now known as pstolowski|lunch [14:28] pristine-tars is going to be interesting vs merging vs debian [14:28] I wonder how much they will match the same hash, how we are going to document merging from debian (reimporting current debian pristine-tar branch) [14:29] git will probably merge it ok [14:31] yeah, needs experimenting [14:38] didrocks: happy you agree on that, right not to SRU it, I was fine to do it for cosmic, since it was thee though, but not really relevant. :) === pstolowski|lunch is now known as pstolowski [15:50] Laney: something is probably fishy in my config [15:51] Laney: gpb import-orig ../tarball created a commit in upstream/latest as well [15:51] with a tag upstream/3.28.2 [15:51] which it then imported in the ubuntu/master branch [15:51] so, up to latest commit [15:52] it's like it couldn't match the upstream tag and import only what was required [15:53] ah, tag format for upstream is tag: GNOME_CONTROL_CENTER_3_28_1 [15:53]