Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
First off, thanks to Antoine not only for doing all this work for jessie, but for helping out with getting stretch in better shape. If we aim to support our users for an LTS distro, this is exactly the sort of thing we need done. If we're realistically talking about actually dropping support for enigmail on jessie on the grounds that not many people are using it for destkop systems at all, then i think we should instead consider dropping thunderbird itself from jessie. (alternately, of course, we could just drop jessie entirely and encourage an upgrade to debian stable instead, but that doesn't seem to be the consensus on this debian-lts list) On Wed 2018-12-19 11:59:46 -0500, Antoine Beaupré wrote: > On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote: >> libgcrypt is a bit more worrying, even after dropping most of the noise: >> >> $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x >> '*/tests/*' >> | diffstat | tail -1 >> 263 files changed, 51927 insertions(+), 14888 deletions(-) > > Yeah, that's my concern as well. > > Daniel, what do you think of that diff? Is that something we can > reasonably review? How much can we expect stability in that upgrade? > > I know you stated before general principles of gpg vs lib / API > stability, but I'd be curious to hear your thoughts on gcrypt, in this > specific case. I agree that an upgrade to gcrypt is the biggest risk here, and i'm not sure how to evaluate it other than running what meager rdep test suites we have in jessie. I don't know whether anyone who has been working on ci.debian.net is following this discussion, but i think it points to some really salient use cases for test infrastructure. How nice it would be if a DD could upload a prospective package and say "please run all test suites for reverse dependencies!" Andreas Metzler (cc'ed here) has been a stalwart steward of gcrypt in debian for many years, even after GnuTLS switched to nettle, and probably has the best sense of what kind of system integration dangers might lurk in the proposed upgrade for jessie. Perhaps he can comment on it? as rdeps go, systemd is the scariest of the lot (breaking systemd with a dep upgrade would be bad bad bad) but frankly, i'm not worried there. systemd does link against gcrypt, it is used primarily for cryptographic digests (hashes) in any significant way across the codebase, which i'm not worried about breaking across an upgrade. It is only used in any complex way in systemd in two places, afaict: * systemd-journald (its forward-secure pseudorandom generator, and its authenticator function), and * systemd-resolved's DNSSEC verification. These are both pretty advanced systemd features (i don't know how well either of them have ever been tested in jessie at all, fwiw) and i have a hard time imagining that anyone stuck on jessie is actually using either of them. Regards, --dkg signature.asc Description: PGP signature
Re: automating process for publishing DLAs on the website
On 2018-12-19 18:05:36, Antoine Beaupré wrote: > On 2018-12-19 11:09:10, Antoine Beaupré wrote: >> On 2018-12-19 14:58:29, Holger Levsen wrote: >>> On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: > I also note #859122 is not marked 'patch'. fixed. >>> >>> :) >>> >> I've requested access as an individual, for what that's worth. > you were given access a week ago, too. \o/ yup. I guess I could just merge my own patches now... or do you want to review them and do that instead, so we can get at least a second pair of eyes on them? >>> >>> I just briefly reviewed them (not being a debian-www expert) and they >>> a.) looked good and b.) only affect our areas, so I do think you should >>> merge them. >> >> i merged both patches, but it doesn't look like the change showed up on >> the main website yet: >> >> https://www.debian.org/security/2018/ >> >> ... doesn't list any DLA, and those are both 404s: >> >> https://www.debian.org/security/2018/dla-1580 >> https://www.debian.org/security/2018/dla-1561 > > This is actually processed every few hours, not directly after the CI > runs. > > The DLAs are visible here: > > https://www-staging.debian.org/security/2018/dla-1580 > > One thing that's unclear is how the entries get added to the main list > in: > > https://www-staging.debian.org/security/2018/ > > That still needs to be cleared up. In the meantime, I did do a mass > import here: > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 Sigh. I forgot to add that one issue that came up is duplicates: even though the security tracker enforces unique DLA identifiers fairly well, human error still creeps in and leads to duplicate DLA identifiers in the wild. This will make automation harder: the current parser croaks out on duplicate identifiers (and rightly so). I guess we can just punt that back to the humans: they just need to issue a new advisory with the correct identifier. The problem is this is first come, first serve: if DLA X is claimed by alice and bob comes in and publishes DLA X before alice has time to send the mail, DLA X is on the website and can't be reverted by the script and will need manual correction. I am worried this will be forgetten in the future... A. -- The difference between a democracy and a dictatorship is that in a democracy you vote first and take orders later; in a dictatorship you don't have to waste your time voting. - Charles Bukowski
Re: automating process for publishing DLAs on the website
On 2018-12-19 11:09:10, Antoine Beaupré wrote: > On 2018-12-19 14:58:29, Holger Levsen wrote: >> On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: >>> > I also note #859122 is not marked 'patch'. >>> fixed. >> >> :) >> >>> >> I've requested access as an individual, for what that's worth. >>> > you were given access a week ago, too. \o/ >>> yup. I guess I could just merge my own patches now... or do you want to >>> review them and do that instead, so we can get at least a second pair of >>> eyes on them? >> >> I just briefly reviewed them (not being a debian-www expert) and they >> a.) looked good and b.) only affect our areas, so I do think you should >> merge them. > > i merged both patches, but it doesn't look like the change showed up on > the main website yet: > > https://www.debian.org/security/2018/ > > ... doesn't list any DLA, and those are both 404s: > > https://www.debian.org/security/2018/dla-1580 > https://www.debian.org/security/2018/dla-1561 This is actually processed every few hours, not directly after the CI runs. The DLAs are visible here: https://www-staging.debian.org/security/2018/dla-1580 One thing that's unclear is how the entries get added to the main list in: https://www-staging.debian.org/security/2018/ That still needs to be cleared up. In the meantime, I did do a mass import here: https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 A. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre
Re: proposed removal of Enigmail from jessie/LTS
Hi Antoine, On 19/12/2018 18:25, Antoine Beaupré wrote: > On 2018-12-19 17:03:26, Holger Levsen wrote: >> On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: >> [...] >> I've now also re-read this thread (for the 2nd time today..) and first >> I'd like to notice that all the concerns were only brought up in the >> last week, so it was definitly right from you to work on this for those >> months. Second, it now reads to me as if Emilio changed his mind after >> expressing concerns on Dec 14th, he indeed replied much more favorably >> on the 18th. > > Thanks for your message, I'm relieved and happy to get support from > you. :) I'm sorry if my comments caused your frustration. I think you have done an amazing job getting all this work done. I just think we need to try and balance the goal of supporting all packages that we can, versus the risk or causing regressions in important stuff. >> I mostly worried that you didnt test all dependent packages and that we >> essentially might break those when trying to support a package no >> customer has expressed need for. But then I also suppose such breakage >> could be fixed... > > So I was mostly concerned about libgcrypt dependencies, and in > particular cryptsetup, and smoke tests seems to go through okay > there, for what that's worth... cryptsetup is definitely one of the main rdeps. Also libgcrypt20 is used by systemd, ntfs-3g. There's also libssh, which is used by e.g. qemu, php-ssh2, libcurl... That doesn't mean we can't upgrade it. It just means it's an important package and the risk is higher due to its wide use and because of the extensive changes. Just need to be extra careful. >> and now we are back to square one :/ > > Not really. We're actually at square N-1, we just need to do that one > final jump to get in the "let's actually support that newer version" > game. :p > > Should we pursue this? Are there any other packages that should be > tested? > > Would love other people's opinion as well... Maybe some of the other rdeps. libssh test suite (if it has one), systemd... However in the end it will come down to whether you feel confident to push that out or think it's better to stay put. Whatever you decide, I'll do my best to help in any way I can. Cheers, Emilio
policykit-1 CVE-2018-19788 in jessie
Dear Maintainers, (It seems my first attempt to send this mail failed. Sorry if you received it twice) As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in jessie. i.e. systemctl correctly doesn't allow me to stop services, and pkexec blocks me from executing applications that need privileges. Do you think is it safe to consider jessie as not-affected? Or is it still worth to apply the patch? Cheers, S signature.asc Description: PGP signature
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! ke 19. jouluk. 2018 klo 18.01 Holger Levsen (hol...@layer-acht.org) kirjoitti: > > Also note that mariadb 10.0 is EOL in three months[2]. > > I think this rules out mariadb 10.0 as a sensible upgrade path here. > (Also, switching from mysql to mariadb in an LTS security upload???) Do we have any stats on how large the Debian 8 installation base is? I guess we could try to push for an extended maintenance or at least security update period for it if there are compelling arguments. Note that the Ubuntu 16.04 LTS release also has MariaDB 10.0.
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-19 17:03:26, Holger Levsen wrote: > On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: > [...] > I've now also re-read this thread (for the 2nd time today..) and first > I'd like to notice that all the concerns were only brought up in the > last week, so it was definitly right from you to work on this for those > months. Second, it now reads to me as if Emilio changed his mind after > expressing concerns on Dec 14th, he indeed replied much more favorably > on the 18th. Thanks for your message, I'm relieved and happy to get support from you. :) > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... So I was mostly concerned about libgcrypt dependencies, and in particular cryptsetup, and smoke tests seems to go through okay there, for what that's worth... > and now we are back to square one :/ Not really. We're actually at square N-1, we just need to do that one final jump to get in the "let's actually support that newer version" game. :p Should we pursue this? Are there any other packages that should be tested? Would love other people's opinion as well... A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Re: proposed removal of Enigmail from jessie/LTS
On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: [...] > Both Emilio and Daniel supported the idea of pushing the GnuPG 2.1 > backport. So I did that and spent most of my LTS time for december > working on the GnuPG 2.1 upload. > > I was just about to finalize the upload, based on Emilio's review of the > patchset, when I read your message. Now I'm at a loss at what to do with > this project. > > Obviously, it would be easy to upload a new debian-security-support > package to declare Enigmail dead. But it would have been a much more > efficient use of our time if we would have decided that back in > september when I first brought up the idea. > > I find this situation rather frustrating, to say the least. I understand > people don't always have time to read all messages and respond promptly > to proposals, but I think I've given that one plenty of time, so it's a > little difficult to just drop everything now, after so much work has > been done to finalize that backport. I very much understand your frustration and I don't think you should have done this work in vain/uncompensated, however sometimes it's only possible after the work to determine that an upgrade is too risky. I've now also re-read this thread (for the 2nd time today..) and first I'd like to notice that all the concerns were only brought up in the last week, so it was definitly right from you to work on this for those months. Second, it now reads to me as if Emilio changed his mind after expressing concerns on Dec 14th, he indeed replied much more favorably on the 18th. I mostly worried that you didnt test all dependent packages and that we essentially might break those when trying to support a package no customer has expressed need for. But then I also suppose such breakage could be fixed... and now we are back to square one :/ -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote: [...] > Looking at a jessie -> jessie-new diff, I see that several -dbg packages are > gone in your backports. Yes. That's because they were switched to dbgsym in stretch, but that mecanism wasn't supported in jessie. I did a "fast" backport which meant just dropping those, but I could possibly re-create the -dbg packages for jessie-security, especially considering we might trigger bugs and regressions which could really use dbg/gdb support. > There are some mingw builds as well, which in some cases > don't seemto be installed, but e.g. libgpg-error actually adds a mingw > package. > I would remove all that stuff. Hmm... I *thought* I explicitely removed all that stuff, but i'll make sure to remove that one as well, thanks for the catch! > The npth diff is pretty trivial, basically comes down to this: > > src/npth.c | 132 Neat, I'll explicitely review that one then. > libassuan is a bit larger, but not too bad: > > $ diff libassuan-2.*/src/ | diffstat | tail -1 > 26 files changed, 1492 insertions(+), 510 deletions(-) > > (some of that is Makefile.in) Probably worth reviewing as well... > libgpg-error has some autogenerated stuff, ignoring that it's mostly this: > > estream.c| 1456 > +-- ... and same. > libgcrypt is a bit more worrying, even after dropping most of the noise: > > $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x > '*/tests/*' > | diffstat | tail -1 > 263 files changed, 51927 insertions(+), 14888 deletions(-) Yeah, that's my concern as well. Daniel, what do you think of that diff? Is that something we can reasonably review? How much can we expect stability in that upgrade? I know you stated before general principles of gpg vs lib / API stability, but I'd be curious to hear your thoughts on gcrypt, in this specific case. > FWIW I see that Ubuntu added OpenPGP.js back, and is using gnupg 2.0.x in > trusty. We ruled that out because supporting gnupg 2.0.x is unfeasible or > because we are missing some dependencies for OpenGPG.js ? Can't we just use > the > bundled code inside enigmail? Sorry if these questions have already been > answered. I have looked at the various long threads but wasn't sure. Yeah, I went down that rabbit hole... three months ago now! I documented my work in bug #787774. It's a complicated set of nesting dependencies, and many packages would first need to cross NEW in unstable (let alone stretch / jessie) before this lands in Debian. A summary of the situation is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787774#49 I made a wiki page, back then, detailing all those dependencies. I am just re-running the script again to get an accurate picture: https://wiki.debian.org/Javascript/Nodejs/Tasks/openpgp That's all stuff in unstable, mind you. All that would need to trickle down in jessie somehow, and that includes npm/nodejs, which I am not sure are in good health in jessie in the first place. A. -- During times of universal deceit, telling the truth becomes a revolutionary act. - Georges Orwell
uw-imap: unclaimed package after 3 weeks of inactivity
Hi Roberto, I just ran the weekly "./bin/review-update-needed --lts --unclaim \ 1814400 --exclude linux linux-4.9" and uw-imap unclaimed after 3 weeks without work or documenting progress. As this is the 3rd or 4th week of my running this and since you can trivially reclaim that package (and because we dont want such long phases of claimed inactivity) I went ahead and have commited that change. Feel free to reclaim, just please try to not have packages claimed for so long without notifyng dla-needed.txt about progress (or lack thereof). -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
proposed removal of Enigmail from jessie/LTS
On 2018-12-19 16:21:46, Holger Levsen wrote: > Hi Antoine, dkg, > > On Sat, Dec 15, 2018 at 01:09:39PM +0100, Moritz Mühlenhoff wrote: >> On Fri, Dec 14, 2018 at 09:08:42AM +0100, Emilio Pozuelo Monfort wrote: >> > However given the impact of these library updates, I was wondering >> > if we have considered to just mark enigmail as EOL in jessie? Obviously if >> > we >> > can keep supporting stuff we should do that, but as you say these library >> > updates affect important unrelated rdeps so we need to weigh that. >> +1 > > I've read this thread multiple times now and came to conclude that > Moritz and Emilio are probably right here, also because - afaics - noone > besides you two have tested the packages on > https://people.debian.org/~anarcat/debian/jessie-lts/ and also mostly > concerning whether they fix enigmail, not so much for subtile breakage > in other parts. (Or did I miss something?) > > Then I also looked at the packages LTS customers (=sponsors) are using > and noted neither enigmail nor libgcrypt20 are among those, so while I > agree breaking/not fixing/declaring EOL of enigmail will be sad for our > jessie users, I also think that most web users are using modern desktops > now (though of course those still on jessie are bitten) and that keeping > jessie stable should have highest priority. > > Of course, more tests could probably convince me again in the other > direction.. ;) So I appreciate finally getting feedback on this proposal, but I'll just note that I've been personnally working on this project for over three months now, and it's the first time the proposal to remove Enigmail from jessie has been explicitely supported instead of the gnupg backport. That is, as far as I can remember and find through archive searches. I've brought up the topic of how to deal with breakage on Enigmail numerous times on this forum. The first thread starts here, in September: https://lists.debian.org/871s9fps8e@curie.anarc.at I even explicitely proposed to remove enigmail from jessie here: https://lists.debian.org/87pnwzngcy@curie.anarc.at There was no explicit support for that idea and limited feedback on the other proposals I brought up. After helping dkg with the stretch package, thinking that would would eventually benefit jessie as well (or ultimately even stretch-LTS), I waited another month and brought up the proposals again: https://lists.debian.org/87pnvra144@curie.anarc.at Both Emilio and Daniel supported the idea of pushing the GnuPG 2.1 backport. So I did that and spent most of my LTS time for december working on the GnuPG 2.1 upload. I was just about to finalize the upload, based on Emilio's review of the patchset, when I read your message. Now I'm at a loss at what to do with this project. Obviously, it would be easy to upload a new debian-security-support package to declare Enigmail dead. But it would have been a much more efficient use of our time if we would have decided that back in september when I first brought up the idea. I find this situation rather frustrating, to say the least. I understand people don't always have time to read all messages and respond promptly to proposals, but I think I've given that one plenty of time, so it's a little difficult to just drop everything now, after so much work has been done to finalize that backport. A. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
Hi Antoine, dkg, On Sat, Dec 15, 2018 at 01:09:39PM +0100, Moritz Mühlenhoff wrote: > On Fri, Dec 14, 2018 at 09:08:42AM +0100, Emilio Pozuelo Monfort wrote: > > However given the impact of these library updates, I was wondering > > if we have considered to just mark enigmail as EOL in jessie? Obviously if > > we > > can keep supporting stuff we should do that, but as you say these library > > updates affect important unrelated rdeps so we need to weigh that. > +1 I've read this thread multiple times now and came to conclude that Moritz and Emilio are probably right here, also because - afaics - noone besides you two have tested the packages on https://people.debian.org/~anarcat/debian/jessie-lts/ and also mostly concerning whether they fix enigmail, not so much for subtile breakage in other parts. (Or did I miss something?) Then I also looked at the packages LTS customers (=sponsors) are using and noted neither enigmail nor libgcrypt20 are among those, so while I agree breaking/not fixing/declaring EOL of enigmail will be sad for our jessie users, I also think that most web users are using modern desktops now (though of course those still on jessie are bitten) and that keeping jessie stable should have highest priority. Of course, more tests could probably convince me again in the other direction.. ;) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: automating process for publishing DLAs on the website
On 2018-12-19 14:58:29, Holger Levsen wrote: > On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: >> > I also note #859122 is not marked 'patch'. >> fixed. > > :) > >> >> I've requested access as an individual, for what that's worth. >> > you were given access a week ago, too. \o/ >> yup. I guess I could just merge my own patches now... or do you want to >> review them and do that instead, so we can get at least a second pair of >> eyes on them? > > I just briefly reviewed them (not being a debian-www expert) and they > a.) looked good and b.) only affect our areas, so I do think you should > merge them. i merged both patches, but it doesn't look like the change showed up on the main website yet: https://www.debian.org/security/2018/ ... doesn't list any DLA, and those are both 404s: https://www.debian.org/security/2018/dla-1580 https://www.debian.org/security/2018/dla-1561 Any ideas? A. -- Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. - Mark Twain
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi Emilio, thanks for bringing up this issue on the LTS list. On Mon, Dec 17, 2018 at 10:49:57AM +0100, Emilio Pozuelo Monfort wrote: > MySQL 5.5 should be EOL this month if nothing has changed, although I don't > see > an announcement on [1] yet. Maybe it will be published next month when the > next > CPU (critical patch update) is released. Norvald, do you know if 5.5 is > effectively EOL already? Or will it receive another update next month? [Norvald replied, saying that 5.5.62 in October was the last 5.5 release.] > Also note that mariadb 10.0 is EOL in three months[2]. I think this rules out mariadb 10.0 as a sensible upgrade path here. (Also, switching from mysql to mariadb in an LTS security upload???) > I don't think it makes much sense to upload mysql-5.6, since stretch has no > mysql at all. Since users will have to migrate to MariaDB anyway (or to > externally provided MySQL packages if they so choose), they can do so now. following that logic they could also upgrade to Stretch now... :) > For mariadb 10.0, we may be able to backport important security fixes, or we > could backport 10.1 which will be supported upstream until October 2020. > > I would lean towards one of those last two options. I think I'm rather *leaning* towards mysql-5.6 or declaring mysql-5.5 unsupported/EOL in jessie, but that's really leaning, nothing more. (And then I believe mysql-5.6 in jessie isnt simple/feasable neither, so... :/ Other comments/suggestions? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Xen 4.4 updates vs. Xen Stretch backport
Hi Peter, sorry for the delay in replying... On Fri, Dec 07, 2018 at 01:32:49PM +0100, Peter Dreuw wrote: > > Assuming (*) you will continue to work on xen DLAs: please apply to become > > a project member of https://salsa.debian.org/security-tracker-team/ so > > that you can push your commits directly. Until you are accepted (which > > should be a matter of hours or very few days) I'll be glad to merge > > patches from you sent to me via email or some such. > Oh, thats nice. How do I do this? I haven't found such an option to join > on the salsa gitlab page go to https://salsa.debian.org/security-tracker-team as a logged in user and you will see a button "request access" (unless you are already a member.) > and the documentation at > https://wiki.debian.org/LTS/Development#Prepare_security_updates_for_Jessie_LTS > says, this list here is one of the three options to request this access. right. and it works :) Even more seriously, I just fixed the URL for the first option on that page. How are the Xen 4.4 fixes coming along? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: automating process for publishing DLAs on the website
On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: > > I also note #859122 is not marked 'patch'. > fixed. :) > >> I've requested access as an individual, for what that's worth. > > you were given access a week ago, too. \o/ > yup. I guess I could just merge my own patches now... or do you want to > review them and do that instead, so we can get at least a second pair of > eyes on them? I just briefly reviewed them (not being a debian-www expert) and they a.) looked good and b.) only affect our areas, so I do think you should merge them. > then if all is good I could push a batch to complete the backlog and get > us started on an ongoing workflow... yes! thanks for following up on this! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: automating process for publishing DLAs on the website
On 2018-12-19 14:44:02, Holger Levsen wrote: > Hi Antoine, > > On Tue, Dec 11, 2018 at 10:15:15AM -0500, Antoine Beaupré wrote: [...] > I also note #859122 is not marked 'patch'. fixed. [...] >> I've requested access as an individual, for what that's worth. > > you were given access a week ago, too. \o/ yup. I guess I could just merge my own patches now... or do you want to review them and do that instead, so we can get at least a second pair of eyes on them? then if all is good I could push a batch to complete the backlog and get us started on an ongoing workflow... >> I've also got feedback from larjona on IRC, saying she didn't have time >> to work on this yet, but ping'd the team to see if someone else >> will. Otherwise she might be able to review our work in January. > > that's almost like next week ;) right, time flies! >> I wonder if we could consider more automation here to remove the manual >> push/pull process, because it seems it will be a significant source of >> friction in our process in the future... > > sure, more automation = better. > >> Anyways, hopefully we'll figure out a workflow soon enough. :) > > I'm confident we will, eventually. #859122 was filed >18 months ago, so > I don't think it's suddenly urgent, though I fully agree it would be > more than nice to have this fixed before the bug is two years old. yep. i'm not in a rush... a. -- One of the strongest motives that leads men to art and science is escape from everyday life with its painful crudity and hopeless dreariness. Such men make this cosmos and its construction the pivot of their emotional life, in order to find the peace and security which they cannot find in the narrow whirlpool of personal experience. - Albert Einstein
Re: automating process for publishing DLAs on the website
Hi Antoine, On Tue, Dec 11, 2018 at 10:15:15AM -0500, Antoine Beaupré wrote: > >> How does that sound? > > sounds very good to me. thanks for your work on this so far! > Right, agreed. :) I guess the script could both parse previous emails > and future ones quite easily. yup, that would be cool. > The problem we have right now is we have no feedback from the www team > on the patches proposed in #859122 so I don't know if the formatting is > alright. I've just asked on #debian-www to comment: [15:37] < h01ger> | it would be very nice if you could comment on the patches proposed/linked in #859122 - those are https://salsa.debian.org/webmaster-team/webwml/merge_requests/41 and https://salsa.debian.org/webmaster-team/webwml/merge_requests/42 and https://salsa.debian.org/webmaster-team/webwml/merge_requests/43 I also note #859122 is not marked 'patch'. > Nor is it promising for the promptness with which the team can > respond to our constant flurry of such MRs in the future... I'm not this pessimistic: first, (after a while) those patches should be pretty clear ones and they will know that. second, I do think that in the long term we should just be able to directly push our DLAs on the website, without a (human) proxy. > > So I've just requested webwml access from the debian-www folks. > ... where did you do that? on salsa. I was also granted access 4 weeks ago it seems :) > Considering that the patches I proposed now 3 weeks ago haven't been > merged, it seems it would be imperative for all LTS people to have > access to the www repository in our workflow. Or at least a significant > numebr of people. Otherwise we'll just be clogging their review queue > forever. agreed. and as said (previously): for a start being i'm happy to act as a human proxy... > I've requested access as an individual, for what that's worth. you were given access a week ago, too. \o/ > I've also got feedback from larjona on IRC, saying she didn't have time > to work on this yet, but ping'd the team to see if someone else > will. Otherwise she might be able to review our work in January. that's almost like next week ;) > I wonder if we could consider more automation here to remove the manual > push/pull process, because it seems it will be a significant source of > friction in our process in the future... sure, more automation = better. > Anyways, hopefully we'll figure out a workflow soon enough. :) I'm confident we will, eventually. #859122 was filed >18 months ago, so I don't think it's suddenly urgent, though I fully agree it would be more than nice to have this fixed before the bug is two years old. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Accepted cargo 0.25.0-2~deb8u2 (source armel all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 18 Dec 2018 23:45:48 +0100 Source: cargo Binary: cargo cargo-doc Architecture: source armel all Version: 0.25.0-2~deb8u2 Distribution: jessie-security Urgency: medium Maintainer: Rust Maintainers Changed-By: Emilio Pozuelo Monfort Description: cargo - Rust package manager cargo-doc - Rust package manager, documentation Changes: cargo (0.25.0-2~deb8u2) jessie-security; urgency=medium . * Add armel stage0 binaries. Checksums-Sha1: 9a8732834f9fdcc3b3c6951124df2fb799ae942e 2616 cargo_0.25.0-2~deb8u2.dsc b23c0636595f86a30ea44a779e2cd53885647ab3 33275588 cargo_0.25.0-2~deb8u2.debian.tar.xz 790ea471820bde58f42755fe9c33868441370faf 1839026 cargo_0.25.0-2~deb8u2_armel.deb 2aff4420605196d409b3f94bb052a8527e3b7393 1030394 cargo-doc_0.25.0-2~deb8u2_all.deb Checksums-Sha256: b8317efbe4577d21926e4123b0098c3db475d8fa74a5e752c2f0794f2d411294 2616 cargo_0.25.0-2~deb8u2.dsc 76dae1aa69920354927c8e0622f5c3b0ecb12c65849b23a930cc47887fe697c0 33275588 cargo_0.25.0-2~deb8u2.debian.tar.xz 5354f3c48bc5bc16d01ab3cd441c2e227e326a4a7f1286d4cbc035fe02183241 1839026 cargo_0.25.0-2~deb8u2_armel.deb 76b346db3ed16618fd2bd2f12b61607afcba4e1e8119af30cbffb99063fcc65f 1030394 cargo-doc_0.25.0-2~deb8u2_all.deb Files: ab9b6208dc56607c4231b4350515e0df 2616 devel optional cargo_0.25.0-2~deb8u2.dsc f4e5591cba8259185ea6c775bae2bca6 33275588 devel optional cargo_0.25.0-2~deb8u2.debian.tar.xz f155635f109fdb7ead4de74b000e11fa 1839026 devel optional cargo_0.25.0-2~deb8u2_armel.deb c004c16629c3a45b576475c4318304dc 1030394 doc optional cargo-doc_0.25.0-2~deb8u2_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEcJymx+vmJZxd92Q+nUbEiOQ2gwIFAlwZ/gUACgkQnUbEiOQ2 gwKrLxAAh9QnKRX3XkK9XL7Vh3UZWBWEg7i6i7amhzZz0jhcKkaPgigwKoDYeK2C nIww7w/jTrUy6ezV2S/q8b7sQBm7at/DQHTj3XN05pVTWqb43Q/kKaTIGH356Rct qlxhX+racj6KpoW0Y2VQUUhdMUk1ecu0JmrPlliirLjHIQJwoj25CXNaVUa1FdkF 5d6lbtI+THF5z0bExqdqmyVEZZjD0HF+mS2NgSRQyncG7nxlyP25d6ZTLliWtQVd O/oRrZDgjc6A761GuR9lirSmRYME53R/sP3rYN7yjl+hTe4Ot/Yxg8VnCzxYTeh0 IfsrcGegaJl9nOqkd5avZ6s/4FFf0Ahvw3vCtG7HxLPLp1YxJV41ugn5ollT5d8C fBBeas1FkDGKhbF/zgG6C+isAYjrbLYZ2shsNGeoZxgJACIiTRUOqxdikDRHuB81 1W6DVUupk0pXMKxJElwQWSJU+NTdcfGyAlZNxZCzufR5BDK6w4ZejG+uuh4zKCoi R1elfS/J4kBOD8JZSTiaXcn9U2jAujJyrb0BP3DHsEn8tTuKwlgRrtHL7L3aQ+QJ 2Ec6IHej8JCvpNZjxevwN++tP/nTRjtG2lARDuHy0kL5XeXxbRVUDf9rGP/9uQ2k M0Wu/9bH9vyyiwWvGLAoTXBaVDGb53I0YozFGN2z+oSZuk9MCAU= =dxng -END PGP SIGNATURE-
