| arraybolt3 | vorlon: w.r.t. your comments on the merge, am I understanding correctly that we do *not* care to adhere strictly to the coding style already present in the 00_header file? I noticed you disliked the backticks, which I also disliked, but used only because that was how the rest of the file was written. Same with the x$var trick. | 00:15 |
|---|---|---|
| arraybolt3 | I'm very happy to not use those, I just want to make sure that I'm understanding correctly that we really are OK with departing from those styles before I rewrite things. | 00:16 |
| vorlon | arraybolt3: please write good code, not code matching existing bad idioms ;-) | 00:16 |
| arraybolt3 | +1 | 00:16 |
| arraybolt3 | also btw I really liked your $envpath_arg refactor, that was shorter, more elegant, and will probably run a lot faster because of all the subshells that are avoided that way | 00:33 |
| === esembee_ is now known as esembee | ||
| === sem2peie- is now known as sem2peie | ||
| === JanC_ is now known as JanC | ||
| === sem2peie- is now known as sem2peie | ||
| === gurupras- is now known as guruprasad | ||
| === tribaal_ is now known as tribaal | ||
| === mfo is now known as Guest5070 | ||
| === mfo_ is now known as mfo | ||
| dbungert | what's the correct bug location for seed changes that don't require an ubuntu-meta upload? | 15:12 |
| jbicha | dbungert: I would still use ubuntu-meta | 15:13 |
| bryceh | adrien, right, unfortunately the launchpad api doesn't have a hook for setting proposed on a ppa, but that's definitely something we want - https://bugs.launchpad.net/ppa-dev-tools/+bug/1990245 | 15:34 |
| -ubottu:#ubuntu-devel- Launchpad bug 1990245 in ppa-dev-tools "[Feature] select pocket dependencies on ppa creation (and or later update them)" [Undecided, New] | 15:34 | |
| bryceh | adrien, I'm hoping I'm just missing something and there's a way I can use, but haven't uncovered any ideas so far | 15:35 |
| bryceh | adrien, please feel free to add your own thoughts/needs in the comments on that bug | 15:36 |
| dviererbe | Does someone know if you can trigger autopkgtests in a private ppa? When I tried this I got a "invalid request" response. | 15:58 |
| === arraybolt3_wc is now known as arraybolt3 | ||
| Skia | probably not, I don't see how it would authenticate on the private PPA, and I don't see any part of the code handling that. | 16:19 |
| bryceh | @dviererbe autopkgtest doesn't support private ppas. Both the authentication, as Skia mentions, and mechanisms for keeping the results private, would need implemented I suppose | 17:16 |
| bryceh | @dviererbe, it is possible though to set up an LXC container with your private PPA installed, and then run autopkgtest locally. It's not apples to apples with what would happen in the archive, but I think that's as close as you can get. | 17:17 |
| dviererbe | Skia, bryceh: thanks, I thought because security-britney has the ability that the autopkgtest cloud can do this too. I opened a bug for this LP: #2058049 | 17:18 |
| -ubottu:#ubuntu-devel- Launchpad bug 2058049 in auto-package-testing "Can not trigger autopkgtest of private PPA" [Undecided, New] https://launchpad.net/bugs/2058049 | 17:18 | |
| bryceh | ty | 17:21 |
| bryceh | @dviererbe, in perusing that tracker, I see LP: #1550280 with some meaty discussion; your bug might be a dupe to that? | 17:25 |
| dviererbe | bryceh: Oh... weird i searched for "private ppa" before reporting the bug | 17:26 |
| dviererbe | marked my bug as duplicate | 17:27 |
| arraybolt3 | juliank: Sadly I think I'm going to have to declare the C patches needed for https://code.launchpad.net/~arraybolt3/grub/+git/grub/+merge/462445 to be beyond my skill level. The patch to loadenv.c for adding support for the envpath variable was doable, but trying to check if we can write the environment path at grub runtime ended up leading far deep into the weeds. | 17:28 |
| arraybolt3 | I don't know C all that well (I can read most of it, but not all), and since this is the bootloader, I don't trust that I'll do it right even if I do come up with a solution. | 17:29 |
| adrien | bryceh: thanks! I'll try to dig further | 18:30 |
| arraybolt3 | juliank: ok I changed my mind and am going to try again :P | 19:06 |
| juliank | arraybolt3: my expectation would have been that the grub_file_open instead the loadenv open would fail on ro, and then one could look at the return code which is an error number and try grub_file_open with the other path | 19:45 |
| arraybolt3 | The thing is figuring out whether a file is RO or not is possibly hard - GRUB doesn't normally write to files, and so it doesn't have any easy read-only check. | 19:45 |
| arraybolt3 | So far my best guess from inspecting the code is that, if you try to open a file with mode GRUB_FILE_TYPE_SAVEENV, it *should* throw an error if the file is read-only, since that file type implies that you intend to write to it. | 19:46 |
| arraybolt3 | I bet I can look at the BTRFS driver in here and see if it does that. | 19:46 |
| arraybolt3 | anyway, I have one patch down so far (checking $envpath first), and one to go, then a bunch of script work. | 19:47 |
| juliank | arraybolt3: yeah that's why I said try to open the file for writing and see if it fails | 19:48 |
| arraybolt3 | right. There just isn't an easy "open for writing" command anywhere in here is the problem, or if there is I'm having a heck of a time finding it. | 19:49 |
| arraybolt3 | but I think I have it, I just need to confirm that it behaves how I think. | 19:49 |
| arraybolt3 | juliank: ...I think I might have done it. It's a bit complex, since the logic goes "If the user explicitly sets a file to open with load_env, try to open it for writing, if that fails try to open it for reading and set grubenv_readonly to 'y'. If the user doesn't explicitly set a file to open, see if the envpath variable is set. If it is, try to open that file for writing, if that fails try | 21:10 |
| arraybolt3 | to open the default file for writing, if that fails open the default file for reading and set grubenv_readonly to 'y'. If envpath isn't set, try to open the default file for writing, if that fails open the default file for reading and set grubenv_readonly to 'y'." I couldn't think of an easy way to simplify that tree :P | 21:10 |
| arraybolt3 | anyway, I guess now I see if this builds. Also I sent a grub-devel email to see if GRUB_FILE_TYPE_SAVEENV really does work as an "open for writing" flag that will fail if a file can't be written to.) | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!