Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Sun, Jul 07, 2019 at 08:29:08AM +0200, Sebastiaan Couwenberg wrote: > Please upload a new revision to unstable with source-only changes to I did just now (5.26.0).
Re: Bits from the Release Team: ride like the wind, Bullseye!
❦ 7 juillet 2019 02:47 +01, Jonathan Wiltshire : > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. > > > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. I didn't follow carefully the past discussion, but why aren't we just throwing the uploaded binaries away? -- Use free-form input when possible. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Bits from the Release Team: ride like the wind, Bullseye!
Vincent Bernat: > ❦ 7 juillet 2019 02:47 +01, Jonathan Wiltshire : > >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. >> From now on, we will no longer allow binaries uploaded by maintainers to >> migrate to testing. This means that you will need to do source-only uploads >> if >> you want them to reach bullseye. >> >> >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). >> >> Q: I needed to do a binary upload because my upload went to the NEW queue, >> do I need to do a new (source-only) upload for it to reach bullseye? >> A: Yes. We also suggest going through NEW in experimental instead of >> unstable >> where possible, to avoid disruption in unstable. > > I didn't follow carefully the past discussion, but why aren't we just > throwing the uploaded binaries away? > Hi Vincent, I supported this method because it: * reliably catches all maintainer-built packages in main. Some maintainers will still need to bootstrapping in unstable using maintainer-built binaries due to the complexity of their packages. This method will simply stop them in sid until they have been rebuilt on the buildds. Compare with throw-away binaries, where exceptions are not easily tracked out of the box (plus you would need to implement an exception workflow too). * was simple and fast to deploy. It required a trivial policy in Britney plus some code to fetch data and it just works. Compare here with throw-away binaries, where the ftp-masters would have to implement changes to dak to support this and accommodate for the complexity of binary-bootstrapping. * can be combined with throw-away binaries at a later point. If/when we implement a good solution to throw-away, we can deploy that next to this change. As mentioned in past points, there are cases where we would still need maintainer-built binaries temporarily, so we would still need a solution like this to ensure full coverage. I hope this answered your question to satisfaction. Thanks, ~Niels
Re: Bits from the Release Team: ride like the wind, Bullseye!
❦ 7 juillet 2019 09:49 +00, Niels Thykier : > I hope this answered your question to satisfaction. Yes. Thanks! -- A kind of Batman of contemporary letters. -- Philip Larkin on Anthony Burgess signature.asc Description: PGP signature
Re: Bits from the Release Team: ride like the wind, Bullseye!
Am Sonntag, den 07.07.2019, 02:47 +0100 schrieb Jonathan Wiltshire: > Shortly before the end of the 6th July, we released Debian 10, > "buster". Is it intentional, that the "Version" value in InRelease files at [1] has been removed? In non-security repositories this value is still present in InRelease files. [1] http://security-cdn.debian.org/dists/ Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi, On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: > Shortly before the end of the 6th July, we released Debian 10, "buster". *yay* *yay* & *yay*! > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. > > > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. whh, that's *totally* awesome news! loving it. > All autopkgtest failures considered RC for bullseye also very yay! exciting times ahead! -- tschau, 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: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. I support this move in principle, but: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. I think that the requirement to upload binary packages for binary-NEW (but not source-NEW) needs to go. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi! [snip with a huge yay!] > All autopkgtest failures considered RC for bullseye > === > > From now on, all autopkgtest failures will be considered release-critical for > bullseye. So if your package has failing autopkgtests, now is a good time to > start looking for a fix Now this raises some questions for me. Now I maintain a (huge) library (hello Qt!). I do an unstable upload and package A starts failing it's autopkgtests. In this case: - How does this failure affects the uploaded library (imagine we have a transition, as it will always be Qt's case due to private headers). - What's expected from the maintainers of the library? Thanks, Lisandro.
Re: Bits from the Release Team: ride like the wind, Bullseye!
> "Ben" == Ben Hutchings writes: Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: Ben> [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is >> about to begin. From now on, we will no longer allow binaries >> uploaded by maintainers to migrate to testing. This means that >> you will need to do source-only uploads if you want them to reach >> bullseye. Ben> I support this move in principle, but: Ben> This is not going to fly for src:linux. We can't stage ABI Ben> bumps in experimental as we typically have a different upstream Ben> versions in unstable and experimental. We even need to do ABI Ben> bumps in stable from time to time. Ben> I think that the requirement to upload binary packages for Ben> binary-NEW (but not source-NEW) needs to go. I agree with Ben. There are a lot of good reasons to stage (possibly even most) binary new packages through experimental. Ben has talked about cases where experimental can't work. I'd like to talk about cases where it is the wrong answer. However, we've gotten a lot of feedback from our maintainers over the years that anything that adds an extra round trip to their workflow is significantly demotivating. If I need to wait for something to go through new, and then after it goes through new do an extra thing to accomplish my goal, that increases the cost of what I'm doing significantly. If it's a simple soname bump because of a new symbol, that doesn't always require experimental. Thinking back to my own experience with krb5, I have a good handle on when ABI bumps need to go through experimental and when things are going to be fine through unstable. I haven't made a lot of mistakes in that front--uploading things to unstable that ended up being broken enough we wished they had gone through experimental. I know I'm not alone. I think that for this to fly, binaries for binary new need to go. I understand that balancing the trade offs here requires a bit of a mind meld between the ftp team and the release team, and I understand that cross team decision making is more complex here. I'd be happy to facilitate any discussion around the trade offs if that would be useful. --Sam
Bug#931551: transition: llvm-defaults to 8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello Now that we release buster, I would like to move llvm-defaults to llvm-toolchain-8. Thanks, Sylvestre Ben file: title = "llvm-defaults"; Affected: .depends ~ /(clang|llvm)1?-?[345678]/ Good: .depends ~ /(clang|llvm)1?-?[8]/ Bad: .depends ~ /(clang|llvm)1?-?[34567]/
Re: Applying Dovecot for a large / deep folder-hierarchy archive - BUG REPORTS!
Dovecot Team, I'd like to report a number of bugs, that are to my view all critical. System: Replicated on multiple Debian 10 (Buster) systemsDovecot Version(s): 2.3.4.1 doveadm-sync -1/general 1) If DIRNAMEs are not different between command line and mail_location doveadm sync will fail, saying that the source and destination directories are the same 2) The -n / -N flags do not work, and a sync will fail strangely if location is specified in the namespace definition 3) Adds mbox to path name under mailbox directory (where syncing from an mbox source) 4) Not having the mailboxes at source named the same as those at destination causes errors and partial sync 5) Not having the target mailboxes formatted to receive the sync (//DIRNAME/) will cause sync errors. doveadm-sync 1) With large synchronizations UIDs are corrupted where multiple syncs are executed and the program can no longer synchronize dovecot 1) Panics and fails to expand ~ to user home: observed cases are where multiple namespaces are being used Please let me know if you need me to elaborate or to provide any further information that you may need to replicate the bugs, or if I can help in any other way. With regards to the last error that I requested help on i.e. \Noselect. This has been resolved more-or-less by the workarounds that I have implemented for the bugs reported above. I have seen a number of threads whilst researching the \Noselect issue where people have been very confused. My finding was that \Noselect is a function of the IMAP specification server-side implementation RFC3501 (https://tools.ietf.org/html/rfc3501#section-6.3.6). And for me the server was returning directories with \Noselect because the mailboxes were malformed on account of dovadm-sync errors. In order to fix this I formed a bash command to transverse the mailbox hierarchy and create the missing folders critical to the sdbox format, namely DIRNAME. Kind regards, Arnold Opio Oree -Original Message-From: Arnold Opio Oree via dovecot < dove...@dovecot.org>Reply-To: arnoldo...@parallaxict.com, Arnold Opio Oree To: dovecot@dovecot.orgCc: r...@sys4.de , aki.tuomi@open-xchange.comSubject: Re: Applying Dovecot for a large / deep folder-hierarchy archive.Date: Thu, 04 Jul 2019 14:52:28 +0100 Hi all, The guidance provided so far has been really helpful, and has helped a great deal to bringing down wasted energy on finding and executing a viable path. I am now at the final due action to complete our Dovecot application to our use-case, but am stuck on an issue that I cannot find any easily accessible documentation on. Generally this is what has been done: 1. Uploaded the enterprise data PST to the target groupware server.2. Prepared the server by changing the mailbox format to sdbox and the the Dovecot mail location to mail_location=/var/vmail/domain/user/mail/3. Converted the pst (on-server) to a recursive mbox hierarchy using readpst4. Executed doveadm-sync to convert mbox hierarchy data into sdbox and to copy it into the enterprise archive user's mailboxes4.i. The biggest issue I faced at this point was doveadm-sync saying that the source and destination pointed to the same location, whereas they clearly did not. 4.i.a. I resolved this by removing the location= setting from the target namespace, and allowing it to default to mail_location = setting, and then using a completely different DIRNAME for the import doveadm-sync execution (which was the desired final DIRNAME); I then once the sync had been successful, changed the mail_location DIRNAME so that it pointed to the imported mail DIRNAME; and hence the imported email data was in the live mailboxes4.i.b. doveadm-import failed several times, and was throwing quite inexplicable errors, so I moved onto doveadm-sync4.i.c. I also had to make sure that the source and destination folder names matched, otherwise doveadm-syc threw very many errors and only partially imported the data4.i.d. An issue which I decided just to live with is that an mbox DIRNAME was added to each mailbox as well as the DIRNAME specified so the path to mail is mbox/dbox-Mails. My thought is that with the data live on an IMAP server it will be possible to do a dysync through TCP to correct this problem. The final issue that I am facing now, is that when readpst finds empty folders in the source pst hierarchy, it does not create an mbox file in the mbox hierarchy folder space. This causes doveadm-sync to not create the target data required for its mailbox structure i.e. DIRNAME sub- folder and index file (with our configuration). At this point either doveadm-sync or the dovecot process makes these empty folders not selectable. The question now is how would I go about making all of these folders selectable, e.g. with an internal or external command line tool to change flags / create necessary sdbox mailbox constituent data? Many thanks, Arnold Opio Oree Chief Executive Officer Parallax Digital Technologies arnoldo...@parallaxdt.com http://www.
NEW changes in oldstable-new
Processing changes file: debian-archive-keyring_2017.5+deb9u1_amd64.changes ACCEPT
Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)
On 7/7/19 3:16 PM, Holger Levsen wrote: > Hi, > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > *yay* *yay* & *yay*! > >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. >> From now on, we will no longer allow binaries uploaded by maintainers to >> migrate to testing. This means that you will need to do source-only uploads >> if >> you want them to reach bullseye. >> >> >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). >> >> Q: I needed to do a binary upload because my upload went to the NEW queue, >> do I need to do a new (source-only) upload for it to reach bullseye? >> A: Yes. We also suggest going through NEW in experimental instead of >> unstable >> where possible, to avoid disruption in unstable. > > whh, that's *totally* awesome news! loving it. I don't. I don't fee happy of this at all, and here's why. I have 150 OpenStack packages waiting in Experimental, built for the OpenStack Stein release. OF COURSE, they all are inter-dependent, and to build a given package, you probably need the latest version of another one. So, instead of preparing them all (build them all for Unstable and upload at once, using sbuild and --extra-package when needed), it means that I'll have to build them one by one, upload, wait for the next dak run to have a new package in, then go to the next. With the amount of package, this probably can take 3 weeks to a month instead of a single week like I planned. Also, the result, it's *less nice* for Sid/Bullseye users, because the transition will be super long if I do this way. The other alternative is to build all like I planned, upload all to Unstable, then rebuild all again, and do a 2nd upload (source only this time). There, I'm also loosing a lot of time for no valid technical reason, which isn't nice at all either. I feel like I'm going to be doing all of this during all of debcamp / debconf, which isn't fun at all, I had planned for other stuffs to do there. Advice on what's the best way would be welcome. I also very much would prefer if this wasn't announced just like this, without giving any amount of time to prepare for the thing and discuss it. That's not the first time the release team does this way, and that's really not the best way to do things. (If I missed the discussion, then IMO it wasn't advertised enough, which has the same effect.) I very much salute the source-only enforcement, but I really don't think this was thought through completely. Cheers, Thomas Goirand (zigo)
Bug#931596: stretch-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi all,
libjavascript-beautifier-perl don't understand Javascript ES6 "=>"
operator (#931379). This very simple patch fixes the problem (just
adding "=>" in operators list).
Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index d53fc65..531e69b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libjavascript-beautifier-perl (0.25-1+deb10u1) unstable; urgency=medium
+
+ * Add missing "=>" operator (ES6) (Closes: #931379)
+
+ -- Xavier Guimard Wed, 03 Jul 2019 18:40:37 +0200
+
libjavascript-beautifier-perl (0.25-1) unstable; urgency=medium
* Import upstream version 0.25.
diff --git a/debian/patches/missing-operator.patch
b/debian/patches/missing-operator.patch
new file mode 100644
index 000..54f0167
--- /dev/null
+++ b/debian/patches/missing-operator.patch
@@ -0,0 +1,18 @@
+Description: Add missing ES6 "=>" operator
+Author: Xavier Guimard
+Bug: https://rt.cpan.org/Ticket/Display.html?id=129976
+Bug-Debian: https://bugs.debian.org/931379
+Forwarded: https://rt.cpan.org/Ticket/Display.html?id=129976
+Last-Update: 2019-07-03
+
+--- a/lib/JavaScript/Beautifier.pm
b/lib/JavaScript/Beautifier.pm
+@@ -18,7 +18,7 @@
+ my @wordchar = split('',
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_$');
+ my @digits = split('', '0123456789');
+ #
Processed: retitle 931596 to buster-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1
Processing commands for cont...@bugs.debian.org: > retitle 931596 buster-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1 Bug #931596 [release.debian.org] stretch-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1 Changed Bug title to 'buster-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1' from 'stretch-pu: package libjavascript-beautifier-perl/0.25-1+deb10u1'. > thanks Stopping processing here. Please contact me if you need assistance. -- 931596: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931596 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#904418: transition: json-c
Hello all, > > So yeah 0.12.1-2 should be alright for sid/buster, and 0.13 will have to > > wait > > for bullseye after the freeze. > > Thank you very much Boyuan <3 > > I will have a look in a moment. > Hello, I fixed all the failing reverse-dependencies in Ubuntu, and completed the transition successfully there (and posted patches on BTS). The only remaining issue is syslog-ng on i386 and s390x, but the maintainer is already working on (and we fixed with a patch in Ubuntu) I would like to do this one before gcc changes default or something else entangles, it should be a trivial one, I plan to NMU as needed. thanks G.
