Bug#514123: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#393646: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#807120: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#663530: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Tue, Jun 18, 2019 at 10:39:06AM +0800, Paul Wise wrote: You might want to sign these tarballs: https://wiki.debian.org/Creating%20signed%20GitHub%20releases You may also want to sign all git tags and commits: https://mikegerwitz.com/papers/git-horror-story All my git tags and releases are already signed: they show as "Verified" on github: https://github.com/ndilieto/uacme/tags The tarball is also signed with the same key in the dsc file https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.16-1.dsc Personally I would delete these from upstream git. I would also delete generated autotools files (configure, Makefile.in, aclocal.m4 etc). I would also delete any files that are copied into the source tree by autotools (build-aux, INSTALL etc). I will definitely not delete configure, Makefile.in and their friends from the upstream releases because other systems than debian also use uacme and I want to preserve, as is customary, the ability to do './configure && make install'. In addition build-aux/git-version-gen and build-aux/m4/* are not generated. If I deleted them autotools would not be able to regenerate the configure script anymore. As an example, uacme is now being packaged for OpenWRT: https://github.com/openwrt/packages/pull/9150 and there they don't want to regenerate configure and the manuals. All they care is that it gets built. We might disagree with their approach but then again they could disagree with debian's. So I am being pragmatic and trying to support both. I think in the end what matters for debian is that everything is regenerated from source cleanly, which is the case. I think what you are doing now is fine but not optimal (need deletions). Ok. Note I did a new release yesterday to satisfy a request by OpenWRT devs to check for libcurl HTTPS support and I also took the chance to eliminate AC_REVISION from configure.ac, which is redundant and produced some warnings at build time when building outside of the git tree: https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.16-1.dsc Is anyone willing to sponsor it then?
Bug#839227: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#745605: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#876636: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#873115: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#607755: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930668: lxc-usernsexec: "Failed to find subuid or subgid allocation"
Package: lxc
Version: 1:3.1.0+really3.0.3-8
I believe that the patch in the PR below fixes the issue.
https://github.com/lxc/lxc/pull/2740
From c14ea11dccbfa80021a9b169b94bd86e8b359611 Mon Sep 17 00:00:00 2001
From: Cameron Nemo
Date: Wed, 28 Nov 2018 19:42:29 -0800
Subject: [PATCH] lxc-usernsexec: fix default map functionality
* Place NULL bytes at the end of strings so that
lxc_safe_ulong() can parse them correctly
* Only free the newly created id_map on error,
to avoid passing garbage to lxc_map_ids()
Signed-off-by: Cameron Nemo
---
src/lxc/cmd/lxc_usernsexec.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/src/lxc/cmd/lxc_usernsexec.c b/src/lxc/cmd/lxc_usernsexec.c
index 10557dd519..ab0dffcffc 100644
--- a/src/lxc/cmd/lxc_usernsexec.c
+++ b/src/lxc/cmd/lxc_usernsexec.c
@@ -200,6 +200,7 @@ static int read_default_map(char *fnam, int which, char *user)
{
size_t len;
char *p1, *p2;
+ unsigned long ul1, ul2;
FILE *fin;
int ret = -1;
size_t sz = 0;
@@ -224,37 +225,42 @@ static int read_default_map(char *fnam, int which, char *user)
if (!p2)
continue;
- newmap = malloc(sizeof(*newmap));
- if (!newmap)
- goto on_error;
+ line[strlen(line) - 1] = '\0';
+ *p2 = '\0';
- ret = lxc_safe_ulong(p1 + 1, >hostid);
+ ret = lxc_safe_ulong(p1 + 1, );
if (ret < 0)
- goto on_error;
+ break;
- ret = lxc_safe_ulong(p2 + 1, >range);
+ ret = lxc_safe_ulong(p2 + 1, );
if (ret < 0)
- goto on_error;
+ break;
+
+ ret = -1;
+ newmap = malloc(sizeof(*newmap));
+ if (!newmap)
+ break;
newmap->nsid = 0;
newmap->idtype = which;
+ newmap->hostid = ul1;
+ newmap->range = ul2;
- ret = -1;
tmp = malloc(sizeof(*tmp));
- if (!tmp)
- goto on_error;
+ if (!tmp) {
+ free(newmap);
+ break;
+ }
tmp->elem = newmap;
lxc_list_add_tail(_map, tmp);
+
+ ret = 0;
break;
}
- ret = 0;
-
-on_error:
fclose(fin);
free(line);
- free(newmap);
return ret;
}
Bug#852776: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#703617: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#797653: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#666926: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#880421: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#741082: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930667: Download is performed unsandboxed as root as file '/var/lib/apt/lists/partial/...' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Package: apt Version: 1.8.2 Severity: minor # apt update W: Download is performed unsandboxed as root as file '/var/lib/apt/lists/partial/opensource.nchc.org.tw_debian_dists_experimental_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) # ls /var/lib/apt/lists/partial/ -ld drwx-- 2 _apt root 4096 06-18 10:47 /var/lib/apt/lists/partial/
Bug#668858: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Mon, 2019-06-17 at 20:10 +0200, Nicola Di Lieto wrote: > I generate the original tarball by tagging master with 'vX.Y.Z', then > './configure' and 'make dist' (note master does NOT include a /debian > directory). You might want to sign these tarballs: https://wiki.debian.org/Creating%20signed%20GitHub%20releases You may also want to sign all git tags and commits: https://mikegerwitz.com/papers/git-horror-story > Regarding the manual pages (uacme.1 and uacme.1.html), they are rebuilt > from their source (uacme.1.txt) by default unless configure is run with > --disable-docs. Personally I would delete these from upstream git. I would also delete generated autotools files (configure, Makefile.in, aclocal.m4 etc). I would also delete any files that are copied into the source tree by autotools (build-aux, INSTALL etc). > To conclude, is there anything else I need to change to make it worthy > of inclusion in debian? I think what you are doing now is fine but not optimal (need deletions). -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#298994: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#715470: RFP: cr3 -- Cool Reader 3, an e-book reader
noowner -1 retitle -1 RFP: cr3 -- Cool Reader 3, an e-book reader thanks I didn't make any progress on this package, so I'm removing myself from it and setting it back to RFP. Sorry... :( If someone wants to work on the packaging, I can definitely help, just let me know. :)
Bug#635333: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#784804: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#876179: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#799105: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#769322: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#325547: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#880871: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#868656: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#533231: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#303228: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930487: lintian: speed up test suite CI
On Mon, Jun 17, 2019 at 4:03 PM Chris Lamb wrote: > > Chris Lamb wrote: > > The naïve solution here might be to save & restore debian/test-out > between runs. I do not think that will work for very long, although there is a better chance if we separate the expected tags from the artifact directory. (The expected tags change relatively often a new checks are implemented or old ones are tweaked.) > > There's currently no magical command in the > fancy test runner of yours that will rebuild any missing or otherwise > changed test packages is there…? We used filesystem timestamps for a while, but the standard resolution (1 sec) was not granular enough. AFAIR, we now generate everything every time. We instead split the generation of test packages from the test runs, although they currently just run consecutively. We could probably skip the generation of test packages if they are already present and nothing in t/ has changed. > In other > words, are we barking up the wrong tree here and what we need to do is > use different GitLab CI stage altogether and pass "artifacts" around > instead? > > https://docs.gitlab.com/ee/ci/caching/index.html#cache-vs-artifacts Artifacts may work, but uploading them separately without a dependency scheme seems to invite other problems. Also, your local build architecture and environment—which may figure into the artifacts you upload—may not match what the the runner needs. (I am thinking about stable or ubuntu-devel.)
Bug#823618: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#780123: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#763866: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#679522: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930666: Please document consensus on use of dh sequencer
package: debian-policy Dear policy team: I just published a consensus call on a discussion we had to canvas the project on the use of Debhelper's dh sequencer. https://lists.debian.org/msgid-search/tslmuif7pwy@suchdamage.org I'd like to ask the policy editors to facilitate using the normal process to document this consensus in policy. My understanding is that the editors already have some ideas about how that might work. Obviously I'm available to help as desired. In the interest of setting expectations, if this issue is still open in December, I plan to check in and see whether I think the approach of going through the normal policy process still makes sense. signature.asc Description: PGP signature
Bug#787584: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#842676: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930665: gpg won't import valid self-signatures if no user ids are present in imported transferable public key
Package: gpg Version: 2.2.13-2 Severity: normal Dear Maintainer, in the current version of GnuPG, signatures will be imported from public key blocks only if they are accompanied by a UserID packet plus valid signature. However, self-signatures on the key itself and on subkeys can be cryptographically verified, independently of user ids. This opens a use case of transferring revocations and updates on subkeys, without revealing the key's user ids. For instance, consider a case where I have the following key in my keyring: > -BEGIN PGP PUBLIC KEY BLOCK- > > mDMEXECaehYJKwYBBAHaRw8BAQdAAiJ1/GyBM4kgpY/nx+sXytMi8I+x8MW0/NBq > 3jepKpG0E0RhbmllbCBLYWhuIEdpbGxtb3KImQQTFggAQQIbAQUJA8JnAAULCQgH > AgYVCgkICwIEFgIDAQIeAQIXgBYhBHI+NDrAAzHwNHPmg3vloR+jfochBQJcQJsl > AhkBAAoJEHvloR+jfoch7q0A/3AMFfxPJGJ5rljN8qMctaFWAzAGc5rElBFQ433t > vuFYAQDagLYOFgcv9A5axQR4O0oYXJKfMBuImqaWyhDRg/MbAA== > =dSe7 > -END PGP PUBLIC KEY BLOCK- The following PGP block contains the same primary key, as well as a valid revocation signature: > -BEGIN PGP PUBLIC KEY BLOCK- > > mDMEXECaehYJKwYBBAHaRw8BAQdAAiJ1/GyBM4kgpY/nx+sXytMi8I+x8MW0/NBq > 3jepKpGIeAQgFggAIBYhBHI+NDrAAzHwNHPmg3vloR+jfochBQJcQJp6Ah0AAAoJ > EHvloR+jfochA+QA/jzjDXDZxwNd39ZfEkngWkR3Xebc96hCkTu9+jlbQnL/AP0b > HrIUG62g5BGzePFhXB+XtSpRL1g4H1Ywsd+GdWymBQ== > =KuHa > -END PGP PUBLIC KEY BLOCK- Importing this via `gpg --import` will yield an error: > gpg: key 0x7BE5A11FA37E8721: no user ID The key in my keyring will remain valid and unrevoked, even though a keyblock that contained a cryptographically valid revocation signature was encountered by GnuPG during an import operation. User IDs typically contain data that is of a more personal nature than the cryptographic information stored in other packets. It is arguably a quite important use case to distribute updates to cryptographic data in an OpenPGP certificate independently of personal information. This applies in particular to revoked keys, where usually the only important thing to distribute is the revocation itself. In countries where GDPR applies, it can also be interpreted as a legal obligation to distribute User IDs only with consent of its owner. A related effort is a new keyserver implementation [Hagrid], which went live last week at https://keys.openpgp.org/ (disclaimer: I'm the maintainer of said project). This keyserver publishes identity information only after verification via e-mail, but distributes non-identity information freely. This was received very well by the community so far. However, since GnuPG won't import keys without identity information, a `gpg --refresh-keys` will not update any keys which don't have at least one verified identity. I contributed a patch series to GnuPG (see [patch mail] on gnupg-devel) that implements the desired behavior, which is currently under review. Since GnuPG already supports a similar (but different) mechanism via the import-option "import-drop-uids" on its current master (see [related announcement]), the required changes are relatively unintrusive. Given the increasing reliability issues of the sks keyserver pool to distribute OpenPGP certificate updates (in particular, key revocations), and the freshly changing landscape of keyservers, I would welcome a speedy distribution and, ideally, backport of this patch in the debian packaging of GnuPG. Thanks - V [section 11.1]: https://tools.ietf.org/html/rfc4880#section-11.1 [Hagrid]: https://gitlab.com/hagrid-keyserver/hagrid/ [related announcement]: https://lists.gnupg.org/pipermail/gnupg-devel/2018-October/033969.html [patch mail]: mid:20190613192743.12991-1-look@my.amazin.horse
Bug#930487: lintian: speed up test suite CI
Chris Lamb wrote: > > Gitlab has a support for saving various parts of a successful build > > for the next one. I believe the idea is that we would build the test > > packages and then push them to this cache re-using them on any subsequent > > test runs. [..] The naïve solution here might be to save & restore debian/test-out between runs. However, I'm not sure whether this would result in changes to the testsuite itself resulting in the changed versions being tested, resulting in all manner of false positive and false negatives. Felix, any insight here? There's currently no magical command in the fancy test runner of yours that will rebuild any missing or otherwise changed test packages is there…? Or, before we implement that, am I asking an XY question? In other words, are we barking up the wrong tree here and what we need to do is use different GitLab CI stage altogether and pass "artifacts" around instead? https://docs.gitlab.com/ee/ci/caching/index.html#cache-vs-artifacts I'm not entirely sure, alas. (Although that magical command might be useful locally...) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#927184: Looks like RedHat/CentOS has a possible solution
https://bugs.centos.org/view.php?id=15723
Bug#695587: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#929557: Some Thoughts
On Thu, 06 Jun 2019 12:19:03 -0400 Sam Hartman wrote: > > The linux Kernel introduced an upstream commit designed to remove an > interface that was being misused. No, it was removed as part of code cleanup. There was no “misuse”. It was added for KVM and existed for 7 years. KVM hasn’t needed it for a while, so patch was submitted to remove the exported function *only* leaving the GPL exported version. GKH went ahead and violated the kernel procedures and removed the symbols from LTS kernels as well. LTS is not where code cleanup should be done and symbols removed. > That does not meet the kind of requirements for changes that we (Debian) > make in stable releases. > If I filed an unblock for krb5 to remove an interface at this point in > the release process it would be outright refused. Except this is to *not* remove an interface from LTS kernels. See above. > We are more permissive in what changes we accept from the kernel team. And yet you are trying to stick to the rules unlike the kernel team… > That is, if we had the resources to review the changes adequately and do > adequate testing, I actually suspect we would hold the kernel to the > same standards we hold other packages to. The symbol was exported without issue for 7 years. It’s been tested. > I do not think this particular change would meet those standards for > buster. I thought LTS was supposed to be stable and not have symbols removed? > I'm not saying the kernel team should revert the commit. > I'm saying that the issue is far more complex than has been outlined in > this bug so far. > > I think that the kernel team and the ZOL maintainers should work with > the stable release team for buster to figure out which changes are > permissible. > Ultimately I'd expect that the stable release team will get to decide > which changes they want in buster and I hope that the kernel team and > the ZOL maintainers will work with that. Unfortunately GKH has put his foot down with this change and insists the symbols be exported GPL only for 5.x and above. He doesn’t care much about other open source projects: "My tolerance for ZFS is pretty non-existant. “ https://marc.info/?l=linux-kernel=154714516832389 except he is doing extra work to cause problems with ZFS by removing exported symbols from LTS kernels against policy. See the pattern? No ZFS on linux user is happy about the 5.x change, but there is no valid reason to remove it from 4.x. Also. there is no copyright violation reversing a commit, as it’s still released GPL code. GPL code is still GPL code even if it’s not in a current release. That would be interesting if code lost it’s copyright once it wasn’t being shipped. -chris zubrzycki - -- PGP ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 "Twice blessed is help unlooked for." --Tolkien
Bug#930664: ITP: libcamera/0~190601-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libcamera" * Package name: libcamera Version : 0~190601-1 Upstream Author : Libcamera * URL : http://libcamera.org/ * License : LGPL-2.1+ Section : libs It builds those binary packages: libcamera - Open-source-friendly camera stack (development file) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libcamera Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libc/libcamera/libcamera_0~190601-1.dsc More information about libcamera can be obtained from http://libcamera.org/. Changes since the last upload: * Initial Release Regards, Emmanuel Arias -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#930650: khronos-api FTBFS
Hi Jens, and thanks for your quick answer. But the same fails if I add the letter "Ă" to d/changelog. I assume you have some unicode/non-ascii letter entry there!? Well see, that was it. For completeness sake, I had those characters: à é ê in my d/changelog. Moving those to non-accentuated characters, and the build passes. Thank you very much. Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a053625 Mastodon : https://mastodon.xyz/@LibraZiK
Bug#340946: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#920546: dolfin: flaky autopkgtest as it times out sometimes
Source: dolfin Followup-For: Bug #920546 Took a while, but we eventually got the timeout error again in a debci test for 2019.1.0. One fail after 32 successful tests. That's evidently much less frequent than the timeout errors for 2018.1.0, indicating the new version has fixed some of the race conditions but not all. debci provides only 2 CPUs, but the dolfin MPI test uses 3 processes, so the test is oversubscribed. However upstream says that oversubscribed MPI tests are in fact useful, and can help iron out bugs. They say that the MPI tests are not expected to time out the way we've been experiencing, so I'll draw their attention to the ongoing problem in 2019.1. This first C++ test fail in 2019.1 occured during demo_gmg-poisson_mpi.
Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config
Hi Stefan, On Mon, 17 Jun 2019 22:20:11 +0200, Stefan Weil wrote: > I am not sure whether reassigning the bug to mingw-w64-tools is the best > way to get a quick (intermediate) solution. If it helps, I have no > objection, although I thought that patching the pkg-config package would > be easier to fix that special issue. Oh well, I suppose mingw-w64-tools *is* the right place to deal with this, if pkg-config is only intended to handle Debian architectures. If you do reassign the bug, please upgrade it to serious and I’ll try to get a fix ready in time for Buster. > I agree that a Debian architecture *-w64-mingw32 would be the preferred > solution, but that will take much more time. Nevertheless I am willing > to try that (with your help) and see how how far we can come with > reasonable efforts. That would be useful, thanks. That was my plan a while ago; see http://sk2.org/talks/crossporting-to-windows.pdf for the slides of a talk I gave at the Paris mini-DebConf in 2014. Unfortunately the triplet used by MinGW-w64 isn’t acceptable to Guillem so it hasn’t been added to dpkg, which is a requirement for multiarch support of course. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825 is the relevant bug. Regards, Stephen pgpM5wy8s1EMp.pgp Description: OpenPGP digital signature
Bug#631230: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#405762: Înștiințare
-- Atenție: Abonatul, Aveți (2) e-mailurile primite respinse. Ați depășit limita de stocare a cutiei poștale, pentru a preveni oprirea e-mailului dvs., Verificați mai jos. VERIFICAți-vă contul utcluj.ro ACUM ... https://upgrade-youremails-org.weebly.com Cu sinceritate, Setările administratorului Webmail. Echipa de administrare a contului © 2001 - 2019 Administrator. Toate drepturile rezervate. Acest e-mail nu poate primi răspunsuri. Pentru mai multe informații, accesați Centrul de ajutor pentru cont. Ați primit acest anunț prin e-mail obligatoriu pentru a vă informa despre modificări importante ale contului și serviciilor dvs. utcluj.ro.
Bug#815477: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930648: exim4-daemon-heavy: Weird leakage of unrelated data like /etc/aliases into /var/spool/exim4/input/*-H
Am Mon, 17 Jun 2019 schrieb Andreas Metzler: > On 2019-06-17 Bjoern Buerger wrote: > > Package: exim4-daemon-heavy > > Version: 4.92-7 > > Severity: important > > [...] > > We did update to 4.92-7 from bpo before we saw the problem for > > the first time. > > what version did you upgrade from, the previous bpo-version (4.92-2) or > the original stretch release? exim4-base:i386 (4.89-2+deb9u4, 4.92-7~bpo9+1) exim4-daemon-heavy:i386 (4.89-2+deb9u4, 4.92-7~bpo9+1) exim4:i386 (4.89-2+deb9u4, 4.92-7~bpo9+1) > > 2019-06-13 17:55:22 1hbS4P-0004q8-LL <= linux-usb-ow...@vger.kernel.org \ > > H=vger.kernel.org [209.132.180.67] P=esmtp K S=9996 DKIM=linaro.org [...] > > > The first error message is logged with the same timestamp: > > > 2019-06-13 17:55:22 1hbS4P-0004q8-LL Format error in spool file > > 1hbS4P-0004q8-LL-H: size=9934 > > Are you running sa-exim or something else that directly modifies the > spoolfiles outside exim? sa-exim
Bug#803190: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930663: apt-move: Port to apt 1.9
Package: apt-move
Version: 4.2.27-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* Port to apt 1.9
Thanks for considering the patch.
-- System Information:
Debian Release: buster/sid
APT prefers eoan
APT policy: (991, 'eoan'), (500, 'eoan'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-15-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
diff -Nru apt-move-4.2.27/debian/patches/apt-1.9.patch
apt-move-4.2.27/debian/patches/apt-1.9.patch
--- apt-move-4.2.27/debian/patches/apt-1.9.patch1970-01-01
01:00:00.0 +0100
+++ apt-move-4.2.27/debian/patches/apt-1.9.patch2019-06-17
23:06:45.0 +0200
@@ -0,0 +1,34 @@
+Description: Port to apt 1.9
+ Minor changes
+Author: Julian Andres Klode
+--- apt-move-4.2.27.orig/fetch.cc
apt-move-4.2.27/fetch.cc
+@@ -1,9 +1,11 @@
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -13,6 +15,7 @@
+ using std::cerr;
+ using std::cout;
+ using std::endl;
++using std::string;
+
+ typedef pkgCache::VerIterator VerIterator;
+ typedef pkgCache::VerFileIterator VerFileIterator;
+@@ -43,7 +46,7 @@ VerIterator getHighestVersion(pkgCache &
+ bool downloadPackages(int test, int argc, char **argv) {
+ pkgCacheFile cache;
+ OpTextProgress prog(*_config);
+- if (!cache.Open(prog, false))
++ if (!cache.Open(, false))
+ return false;
+
+ pkgRecords rec(cache);
diff -Nru apt-move-4.2.27/debian/patches/series
apt-move-4.2.27/debian/patches/series
--- apt-move-4.2.27/debian/patches/series 2016-11-02 05:34:17.0
+0100
+++ apt-move-4.2.27/debian/patches/series 2019-06-17 23:06:16.0
+0200
@@ -4,3 +4,4 @@
fix_perl_implicit_split_deprecation.patch
fix-makefile.patch
drop-contents-header.patch
+apt-1.9.patch
Bug#930662: libauth-googleauth-perl: poor source of entropy for secret generation
Package: libauth-googleauth-perl Version: 1.02-1 Severity: important Tags: security Hi, Auth::GoogleAuth uses the rand function to generate a 16-bytes secret key for TOTP authentication. Sadly, rand is a poor source of randomness and unsuitable for crypto-related uses. Following RFC6238's SHOULDs, Auth::GoogleAuth should use a CSPRNG like urandom as a source to generate the key, and possibly generate a 20-bytes key to follow a second SHOULD. Cheers, -- Raphael Geissert - Debian Developer www.debian.org
Bug#884068: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hello, Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > >> "لاحقاً" > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > That avoids the issue here indeed. I however see it used in various > > > > Hmm. > > There has been no changing in the ar.po of partman-auto > > for 3 years now (JFTR), thus the real problem seems to be > > sitting somewhere else ... > > How should we proceed here? > Since we are late in the freeze, and it's most probably not that > easy to find out what happened and what the real issue is: > should we go with the "work-around" proposed by > Butterflyoffire and confirmed to fix the issue by Samuel? Personally, I don't think I'll have the time to debug what is actually happening inside gtk until the release, so even if it's ugly, I guess the browntape fix is the least worst I can come up with. Samuel
Bug#930661: unblock: rustc/1.34.2+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock The next Firefox ESR 68 (about to obsolete ESR60 in October) will need rustc 1.34, while buster currently has 1.32. This is against all freeze policies, but OTOH only bumping to 1.34 in the first buster point release doesn't seem to buy us anything? unblock rustc/1.34.2+dfsg1-1 Cheers, Moritz
Bug#930660: libapache-sessionx-perl: poor source of entropy for session id generation
Package: libapache-sessionx-perl Version: 2.01-5 Severity: important Tags: security Hi, As discussed in oss-security[1], libapache-sessionx-perl uses a poor source of entropy in Apache::Session::Generate::MD5. The critical part is moving away from rand (e.g. to using urandom), but it would also be a good time to update the way the id is generated. The details are in the oss-sec thread. [1] https://www.openwall.com/lists/oss-security/2019/06/15/1 Cheers, -- Raphael Geissert - Debian Developer www.debian.org
Bug#930659: libapache-session-perl: poor source of entropy for session id generation
Package: libapache-session-perl Version: 1.93-3 Severity: important Tags: security Hi, As discussed in oss-security[1], libapache-session-perl uses a poor source of entropy in Apache::Session::Generate::MD5. The critical part is moving away from rand (e.g. to using urandom), but it would also be a good time to update the way the id is generated. The details are in the oss-sec thread. [1] https://www.openwall.com/lists/oss-security/2019/06/15/1 Cheers, -- Raphael Geissert - Debian Developer www.debian.org
Bug#930417: freeorion: Crash on save/load button
Hello, unfortunately the problem remains the same. I installed with dpkg. It worked fine in the stretch-backports version. I have another problem with this package. The starlanes between producing stars are weirdly cut at the ends but this problem occurred only after I changed gpu and happened in the backports version as well so we can probably rule that out. ii freeorion 0.4.8-2 ii freeorion-data 0.4.8-2
Bug#869729: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930658: unblock: debian-edu-doc/2.10.18
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-edu-doc, it's a documentation and translation update only: debian-edu-doc (2.10.18) unstable; urgency=medium * Update Debian Edu Buster manual from the wiki. * Update Audacity manual from the wiki. * Update Rosegarden manual from the wiki. * Update debian/copyright from the wikis. [ Translation updates ] * Buster manual: - Chinese (Simplified): Ma Yong - Japanese: hoxp18 - Dutch: Frans Spiesschaert * Stretch manual: - Chinese (Simplified): Ma Yong - Japanese: hoxp18 * Audacity manual: - new Japanese translation by hoxp18. - Dutch: Frans Spiesschaert * Rosegarden manual: - French: Quentin Lejard [ hoxp18 ] * documentation/common/edu-css.xml: increase font size for headings in the HTML variants. -- Holger Levsen Mon, 17 Jun 2019 22:17:41 +0200 $ debdiff debian-edu-doc_2.10.17.dsc debian-edu-doc_2.10.18.dsc debian/changelog| 27 debian/copyright| 10 documentation/audacity/audacity-manual.cs.po| 10 documentation/audacity/audacity-manual.fr.po| 18 documentation/audacity/audacity-manual.ja.po| 1107 + documentation/audacity/audacity-manual.nb.po| 18 documentation/audacity/audacity-manual.nl.po| 24 documentation/audacity/audacity-manual.pl.po| 10 documentation/audacity/audacity-manual.pot | 10 documentation/audacity/audacity-manual.pt_BR.po | 10 documentation/audacity/audacity-manual.sv.po| 10 documentation/audacity/audacity-manual.uk.po| 13 documentation/audacity/audacity-manual.xml |4 documentation/audacity/audacity-manual.zh.po| 10 documentation/audacity/audacity-manual.zh_Hant.po | 10 documentation/common/edu.css.xml|7 documentation/debian-edu-buster/debian-edu-buster-manual.da.po | 276 - documentation/debian-edu-buster/debian-edu-buster-manual.de.po | 23 documentation/debian-edu-buster/debian-edu-buster-manual.es.po | 16 documentation/debian-edu-buster/debian-edu-buster-manual.fr.po | 32 documentation/debian-edu-buster/debian-edu-buster-manual.it.po | 191 documentation/debian-edu-buster/debian-edu-buster-manual.ja.po | 1944 +- documentation/debian-edu-buster/debian-edu-buster-manual.nb.po | 18 documentation/debian-edu-buster/debian-edu-buster-manual.nl.po | 40 documentation/debian-edu-buster/debian-edu-buster-manual.pl.po | 16 documentation/debian-edu-buster/debian-edu-buster-manual.pot| 11 documentation/debian-edu-buster/debian-edu-buster-manual.xml|6 documentation/debian-edu-buster/debian-edu-buster-manual.zh.po | 88 documentation/debian-edu-buster/debian-edu-buster-manual.zh_Hant.po | 16 documentation/debian-edu-stretch/debian-edu-stretch-manual.ja.po| 108 documentation/debian-edu-stretch/debian-edu-stretch-manual.zh.po|4 documentation/rosegarden/rosegarden-manual.es.po|8 documentation/rosegarden/rosegarden-manual.fr.po| 308 - documentation/rosegarden/rosegarden-manual.nb.po| 14 documentation/rosegarden/rosegarden-manual.nl.po| 17 documentation/rosegarden/rosegarden-manual.pl.po|8 documentation/rosegarden/rosegarden-manual.pot |8 documentation/rosegarden/rosegarden-manual.xml |4 documentation/rosegarden/rosegarden-manual.zh.po|8 documentation/rosegarden/rosegarden-manual.zh_Hant.po |8 40 files changed, 2761 insertions(+), 1709 deletions(-) The full debdiff is attached. unblock debian-edu-doc/2.10.18 Hooray for Buster! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C debian-edu-doc_2.10.18.diff.xz Description: application/xz signature.asc Description: PGP signature
Bug#719265: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config
Hello Helmut, I am not sure whether reassigning the bug to mingw-w64-tools is the best way to get a quick (intermediate) solution. If it helps, I have no objection, although I thought that patching the pkg-config package would be easier to fix that special issue. I agree that a Debian architecture *-w64-mingw32 would be the preferred solution, but that will take much more time. Nevertheless I am willing to try that (with your help) and see how how far we can come with reasonable efforts. Stefan CC'ing Steven
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
On 2019-06-17, Salvatore Bonaccorso wrote: > On Sun, Jun 16, 2019 at 01:49:24PM -0400, Daniel Kahn Gillmor wrote: >> On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote: >> > As "--changes-option=-S" creates an upload that is broken from the point of >> > view of the archive, it might make sense not to recommend (or even allow) >> > this >> > for now. Just building with "-S" instead should create a buildinfo file >> > with >> > _source, which won't trigger this issue. >> >> For the rest of the regular archive, --changes-option=-S is definitely >> *not* broken. I use that regularly, and strongly prefer it. It allows >> me to document what i managed to build, while still ensuring that the >> distributed binaries are created by debian's buildd network, and not my >> own machinery. >> >> I would be pretty sad if --changes-option=-S was explicitly deprecated >> in any part of the debian archive. > > This behaviour is really causing issues for the security-archive so in > one way or the other there needs to be a solution. Regularly we need > to fetch the buildd changes and build binary packages, resign them and > reupload them due to this bug. What's unclear to me is why the workaround in DAK for the main archive, which adds .buildinfo.N for duplicate .buildinfo filenames, can't be or hasn't been applied for the security archive. Is there something fundamentally different with the security archive? It seems quite late in the freeze cycle to get this fixed in dpkg even for buster, so it seems worth considering fixing in the archive, unless I'm missing something? > Prefered for us would defintively to find a solution though which does > not mean the need to disable source only uploads for security-master, > that IMHO would be a read drawback. > > That said, sorry it looks I'm repeating myself, but I wanted to > express again that this causes real issues for the work on releasing > security-updates via the security archive. Really hard to see that this has dragged on for almost two years now without resolution! live well, vagrant signature.asc Description: PGP signature
Bug#928111: [pre-approval] unblock: icu/63.2-1
Control: tags -1 -moreinfo On Mon, Jun 17, 2019 at 9:50 PM Paul Gevers wrote: > On 16-06-2019 11:20, László Böszörményi (GCS) wrote: [The ICU 63.2 upstream release] > > Last but not least fixed the startup slowness issue, changing a > > function signature as well. While this is a public function, I guess > > not meant to be used externally. It's an ABI break nevertheless > > without a soname bump. The good thing is that it's only used by the V8 > > JavaScript engine (being in Chromium). Just for the record, this mean > > chromium, nodejs and qtwebengine-opensource-src will need binNMUs once > > I can upload this change to Sid. > > Do I understand correctly that what we are now getting with this version is: > > - Reiwa support > - fix for the speed regression? > > Can you confirm that all the changes that I am seeing in your last diff > (which were missing the debian/* changes by the way) are for those two > issues? You asked for the patched sources difference as I understood - not to include noise with the patch changes under the debian directory. Let me try to explain the current situation again. Current ICU version in Sid is 63.2-2 which adds Reiwa support over the current version in Buster. The startup speed regression fix is _not_ present in this package version. It would break the mentioned three source packages due to the ABI change. The affected packages are binNMU-able, but the current Chromium package is not ready to migrate to Buster and you can't binNMU its Buster version. That's why it is only _planned_ for 63.2-3 which is _not_ yet uploaded. Hope I could describe the current situation better. Regards, Laszlo/GCS
Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems
Hi Daniel, On Sun, Jun 16, 2019 at 01:49:24PM -0400, Daniel Kahn Gillmor wrote: > On Sun 2019-06-16 15:50:55 +0200, Ivo De Decker wrote: > > As "--changes-option=-S" creates an upload that is broken from the point of > > view of the archive, it might make sense not to recommend (or even allow) > > this > > for now. Just building with "-S" instead should create a buildinfo file with > > _source, which won't trigger this issue. > > For the rest of the regular archive, --changes-option=-S is definitely > *not* broken. I use that regularly, and strongly prefer it. It allows > me to document what i managed to build, while still ensuring that the > distributed binaries are created by debian's buildd network, and not my > own machinery. > > I would be pretty sad if --changes-option=-S was explicitly deprecated > in any part of the debian archive. This behaviour is really causing issues for the security-archive so in one way or the other there needs to be a solution. Regularly we need to fetch the buildd changes and build binary packages, resign them and reupload them due to this bug. Prefered for us would defintively to find a solution though which does not mean the need to disable source only uploads for security-master, that IMHO would be a read drawback. That said, sorry it looks I'm repeating myself, but I wanted to express again that this causes real issues for the work on releasing security-updates via the security archive. Regards, Salvatore
Bug#928111: [pre-approval] unblock: icu/63.2-1
Control: tags -1 moreinfo Control: retitle -1 unblock: icu/63.2-2 Hi László, On 16-06-2019 11:20, László Böszörményi (GCS) wrote: >> Unfortunately, the state of chromium at this moment doesn't allow us to >> rebuild and have the package migrate to buster as chromium FTBFS on >> arm64 and the package is newer in unstable. You'll have to wait until >> that situation improves. > It improved but still not good. As it's irrelevant for now, let me > summarize the current status of ICU. > Unfortunately ICU 63.1 (which is in Buster already) have a startup > speed regression compared to previous versions. Chromium and > GraphicsMagick hit by this issue as I know, meaning these applications > start slower. > Then upstream released ICU 63.2 with three type of changes. First > security fixes that I've already backported to 63.1/Buster a while > ago. Then there's the Japanese new era "Reiwa" changes. This would be > nice to have for Buster. > Last but not least fixed the startup slowness issue, changing a > function signature as well. While this is a public function, I guess > not meant to be used externally. It's an ABI break nevertheless > without a soname bump. The good thing is that it's only used by the V8 > JavaScript engine (being in Chromium). Just for the record, this mean > chromium, nodejs and qtwebengine-opensource-src will need binNMUs once > I can upload this change to Sid. Do I understand correctly that what we are now getting with this version is: - Reiwa support - fix for the speed regression? Can you confirm that all the changes that I am seeing in your last diff (which were missing the debian/* changes by the way) are for those two issues? Paul signature.asc Description: OpenPGP digital signature
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Mon, Jun 17, 2019 at 09:20:18PM +0200, Paul Gevers wrote: > > This debdiff looks good. Can you please upload it as > > 1:5.25.3-1+really5.25.2-1 (with the source tar ball of 1:5.25.2) to > > unstable as requested in bug 930313. tpu isn't covered well by QA, so we > > don't want packages going though it that don't need to. > > Should have been 1:5.25.3+really5.25.2-1. Could you kindly explain what's wrong with the current version? I don't understand why I should set an invalid upstream version.
Bug#880656: lastbind module and missing forwarding updates
Control: tag -1 fixed-upstream This lastbind enhancement has been added to the 2.4 branch for the upcoming 2.4.48 release. That makes it too late for buster, but it will be available in bullseye and buster-backports. http://www.openldap.org/lists/openldap-commit/201906/msg00025.html
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Control: tags -1 confirmed Dear Ilias, Please go ahead with uploading the reviewed ghc to unstable and remove the moreinfo tag when it is available so we can schedule the binNMU's. Paul signature.asc Description: OpenPGP digital signature
Bug#880122: hw-detect: Drop reference to floppy disks; it's almost 2018
retitle 880122 hw-detect: Drop reference to floppy disks; it's almost 2020 thanks :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
Arg. On 17-06-2019 21:19, Paul Gevers wrote: > Control: tags -1 moreinfo confirmed > > Hi Sergey, > > On 17-06-2019 11:01, Sergey B Kirpichev wrote: >> Please unblock package monit in t-p-u. The version >> 1:5.25.2-3+deb10u1 has only targeted fixes for security >> issue #927775 (two CVE's). See attached diff. > > This debdiff looks good. Can you please upload it as > 1:5.25.3-1+really5.25.2-1 (with the source tar ball of 1:5.25.2) to > unstable as requested in bug 930313. tpu isn't covered well by QA, so we > don't want packages going though it that don't need to. Should have been 1:5.25.3+really5.25.2-1. Paul signature.asc Description: OpenPGP digital signature
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
Control: tags -1 moreinfo confirmed Hi Sergey, On 17-06-2019 11:01, Sergey B Kirpichev wrote: > Please unblock package monit in t-p-u. The version > 1:5.25.2-3+deb10u1 has only targeted fixes for security > issue #927775 (two CVE's). See attached diff. This debdiff looks good. Can you please upload it as 1:5.25.3-1+really5.25.2-1 (with the source tar ball of 1:5.25.2) to unstable as requested in bug 930313. tpu isn't covered well by QA, so we don't want packages going though it that don't need to. Paul signature.asc Description: OpenPGP digital signature
Bug#930650: khronos-api FTBFS
control: reassign -1 libpython3.5-minimal 3.5.3-1+deb9u1 @doko: reassigning, only affects stretch, but might be rc. See below. Hi Olivier thanks for your feedback! > trying to rebuild khronos-api (version from backport) with pbuilder on a > Debian Stretch, it fails with: I just successfully rebuilt khronos-api_4.6+git20180514-1~bpo9+1 with gbp in a clean stretch (+backports) environment. But the same fails if I add the letter "Ă" to d/changelog. I assume you have some unicode/non-ascii letter entry there!? Similar to you I get: [...] File "/usr/lib/python3/dist-packages/debian/changelog.py", line 308, in parse_changelog for line in file: File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 75: ordinal not in range(128) [...] I get "0xc4" while you got "0xc3" - I probably copy the wrong character from my websearch. Anyway, there's some issue with decoding unicode characters - I assume /usr/lib/python3.5/encodings/ascii.py in package libpython3.5-minimal needs to be fixed. Reassigning to this package. I'm not sure about the severity, might be rc if other packages are affected. Luckily, the same build succeeds in a clean sid environment with libpython3.7-minimal 3.7.3-2. Greets jre
Bug#929505: upgrade-reports: No sound card found in gnome-control-center after upgrade stretch ->buster - No sound can be played
The bug was already created! As i updated the system without apt-listbugs, I could not think in a bug of timidity bogues de gravité critical sur timidity (→ ) b1 - #901148 - timidity: upgrading to 2.14.0-2 broke sound via pulseaudio Fusionné avec : 902330 904652 918522 Résumé : timidity(1 bogue) Le lundi 17 juin 2019 à 20:44 +0200, cron.apt.upd...@gmail.com a écrit : > Hi, > The problem was fixed uninstallind timidity-daemon as said on that > page > https://www.linux.org/threads/dummy-sound.21092/ > > Le samedi 08 juin 2019 à 11:14 +0200, Paul Gevers a écrit : > > Control: tags -1 moreinfo > > > > Hi Olivier, > > > > Thanks for your report. > > > > On Sat, 25 May 2019 08:03:06 +0200 Olivier < > > cron.apt.upd...@gmail.com > > wrote: > > > The result is a system that can't play any sound under gnome > > > The problem only affects the user, (sound is ok for root) > > > When using the command "alsamixer", pressing F6 key shows that > > > the > > > default > > > sound card used by gnome for my user is not the expected one > > > > Your problem is not totally clear to me. Is it now that you had to > > configure the system again after the upgrade, or can't you even > > select > > the right sound card at all? > > > > Paul > >
Bug#929505: upgrade-reports: No sound card found in gnome-control-center after upgrade stretch ->buster - No sound can be played
Control: reassign -1 timidity Control: force-merge 901148 -1 Hi Olivier, On 17-06-2019 20:44, cron.apt.upd...@gmail.com wrote: > The problem was fixed uninstallind timidity-daemon as said on that page > https://www.linux.org/threads/dummy-sound.21092/ Thanks for reporting back. I have found the bug report against the timidity-daemon package that is a duplicate of your bug report. I have reassigned your bug to that package. Paul signature.asc Description: OpenPGP digital signature
Bug#929505: upgrade-reports: No sound card found in gnome-control-center after upgrade stretch ->buster - No sound can be played
Hi, The problem was fixed uninstallind timidity-daemon as said on that page https://www.linux.org/threads/dummy-sound.21092/ Le samedi 08 juin 2019 à 11:14 +0200, Paul Gevers a écrit : > Control: tags -1 moreinfo > > Hi Olivier, > > Thanks for your report. > > On Sat, 25 May 2019 08:03:06 +0200 Olivier > > wrote: > > The result is a system that can't play any sound under gnome > > The problem only affects the user, (sound is ok for root) > > When using the command "alsamixer", pressing F6 key shows that the > > default > > sound card used by gnome for my user is not the expected one > > Your problem is not totally clear to me. Is it now that you had to > configure the system again after the upgrade, or can't you even > select > the right sound card at all? > > Paul >
Bug#930657: Possible shutdown problems
Package: waagent Version: 2.2.34-4 From https://lintian.debian.org/tags/systemd-service-file-shutdown-problems.html: The specified systemd .service file contains both DefaultDependencies=no and Conflicts=shutdown.target directives without Before=shutdown.target. This can lead to problems during shutdown because the service may linger until the very end of shutdown sequence as nothing requests to stop it before (due to DefaultDependencies=no). There is race condition between stopping units and systemd getting a request to exit the main loop, so it may proceed with shutdown before all pending stop jobs have been processed. Please add Before=shutdown.target. Refer to https://github.com/systemd/systemd/issues/11821 for details. Suggested fix awaits in Salsa as MR!2 https://salsa.debian.org/waldi/waagent/merge_requests/2 -Topi
Bug#785729: Quotation Inquiry #RFQ170619E - New Supplier
Hello, Our partners referred your company to us. Regarding your great products. Please see required products, quantity and specifications as attached. Kindly give us your lowest possible prices for FCL shipment. Best Regards, Wanda Rodriguez Purchase Assistant Hidroconta Trading Ltd. Av. de Sta. Catalina, 60, 30012 Murcia, Spain Phone: +34 968 26 77 66 Fax: +34 968 26 77 06
Bug#930655: release-notes: broken link on using encrypted boot
Control: tags -1 confirmed Hi John, Thanks. On 17-06-2019 19:57, John Scott wrote: > On the What's New page for Buster, it says > Please note that the GNU GRUB bootloader doesn't support the > LUKS2 format yet. See the corresponding documentation for further > information on how to install Debian 10 with encrypted boot. > > with 'documentation' linking to > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html > which 404s, and I can't seem to find the intended page. I pinged the submitter of the text on IRC. He will (try to) fix it tomorrow. Paul signature.asc Description: OpenPGP digital signature
Bug#930656: unblock: gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gokey
The current version of gokey suffers the RC bug #930426 which makes the
RSA key generation non-deterministic. The main purpose of gokey is to
generate deterministic keys. The second upload to Debian unstable fixes
the build failure by increasing the timeout for the tests, because the
tests take very long on mips/mipsel. The gokey tests takes 11408.183 s
(= 190 min) on minkus.debian.org (mips porter box).
By the way, gokey
0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-2 is more or less
the same version as 0.0~git20190103.40eba7e-1, because there are only
two upstream commits between 20181023.b4e2780 and 20190103.40eba7e.
The debdiff is attached. My email address changes and this is not
mentioned in the changelog.
unblock gokey/0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss
Member of United Internet
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
2019-06-04 20:53:29.0 +0200
+++
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/changelog
2019-06-17 20:04:04.0 +0200
@@ -1,3 +1,18 @@
+gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-3) unstable;
urgency=medium
+
+ * Increase test timeout to six hours, because the tests need 190 minutes
+on mips (Closes: #919759)
+ * Run tests for RSA2048 and RSA4096 again
+
+ -- Benjamin Drung Mon, 17 Jun 2019 20:04:04
+0200
+
+gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-2) unstable;
urgency=medium
+
+ * Cherry-pick patch from upstream to import deterministic RSA key generation
+code from Go 1.10 crypto/rsa package (Closes: #930426)
+
+ -- Benjamin Drung Thu, 13 Jun 2019 15:51:37
+0200
+
gokey (0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780-1) unstable;
urgency=medium
* Team upload.
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
--- gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
2019-06-04 20:52:40.0 +0200
+++ gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/control
2019-06-13 15:53:37.0 +0200
@@ -1,6 +1,6 @@
Source: gokey
Maintainer: Debian Go Packaging Team
-Uploaders: Benjamin Drung ,
+Uploaders: Benjamin Drung ,
Anthony Fok
Section: utils
Testsuite: autopkgtest-pkg-go
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
2019-06-04 20:52:40.0 +0200
+++
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/0002-disable-TestGetKey-for-RSA.patch
1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-Description: Disable tests for RSA2048 and RSA4096 in TestGetKey
- rsa.GenerateKey has been intentionally made non-deterministic since Go 1.11.
- This patch fixes the "gokey_test.go:161: keys with same invocation options
- do not match" error in TestGetKey with Go >= 1.11.
-Author: Anthony Fok
-Origin: vendor
-Bug: https://github.com/cloudflare/gokey/issues/17
-Last-Update: 2018-12-31
-This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
a/gokey_test.go
-+++ b/gokey_test.go
-@@ -165,8 +165,9 @@
- func TestGetKey(t *testing.T) {
- testGetKeyType(EC256, t)
- testGetKeyType(EC521, t)
-- testGetKeyType(RSA2048, t)
-- testGetKeyType(RSA4096, t)
-+ // rsa.GenerateKey is no longer deterministic in Go >= 1.11
-+ //testGetKeyType(RSA2048, t)
-+ //testGetKeyType(RSA4096, t)
- testGetKeyType(X25519, t)
- testGetKeyType(ED25519, t)
- }
diff -Nru
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go.patch
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go.patch
---
gokey-0.0~git20190103.40eba7e+really0.0~git20181023.b4e2780/debian/patches/Import-deterministic-RSA-key-generation-code-from-Go.patch
1970-01-01
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Mon, Jun 17, 2019 at 05:59:17PM +0800, Paul Wise wrote: One should always build everything from source as often as possible. Also remove build products from upstream VCSen and tarballs (except autotools cruft). I generate the original tarball by tagging master with 'vX.Y.Z', then './configure' and 'make dist' (note master does NOT include a /debian directory). Then I feed the tarball to gbp import-orig, which automatically updates the upstream/latest, pristine-tar and debian/master branches. The end result is that the contents of any pristine tarball uacme_X.Y.Z.orig.tar.gz are archived as upstream/X.Y.Z and the tarball can be regenerated at any time from the repository by pristine-tar. I always build with 'gbp buildpackage' from the debian/master branch which does a full build from source every time. When I want to make a debian release I update and commit debian/changelog on the debian/master branch, then use gbp buildpackage --git-tag which builds the package and additionally makes a tag of the form 'debian/X.Y.Z-N' Regarding the manual pages (uacme.1 and uacme.1.html), they are rebuilt from their source (uacme.1.txt) by default unless configure is run with --disable-docs. You may want to read through our upstream guide: https://wiki.debian.org/UpstreamGuide Yes, I've gone through this, thanks. To conclude, is there anything else I need to change to make it worthy of inclusion in debian?
Bug#930655: release-notes: broken link on using encrypted boot
Package: release-notes Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On the What's New page for Buster, it says Please note that the GNU GRUB bootloader doesn't support the LUKS2 format yet. See the corresponding documentation for further information on how to install Debian 10 with encrypted boot. with 'documentation' linking to https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html which 404s, and I can't seem to find the intended page. - -- System Information: Debian Release: 10.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXQfUkQAKCRDYKFckL7gu M1kjAQDlP6N2QG7mQ0ZvFuOeFbLmtU1qZB3i9mY1s4EExKX0SQEA+r5fn63oOCz4 I8IFTFwu/VMZ+/s7STvFZW8Q9Y5Vb9w= =+Q8S -END PGP SIGNATURE-
Bug#929907: implications for libgnutls-openssl27?
On 2019-06-16 Ross Boylan wrote: [...] > So it sounds as if I should wait til gnutls30 3.6.7-4 appears before > doing the upgrade. Or maybe the security problem is serious enough to > warrant an upgrade now? TLS is likely to matter to me only as a > client. Hello Ross, this choice a noop, 3.6.7-4 is in testing now. cu Andreas
Bug#911702: Bug#911844: okular: Prints to the wrong printer
Thank you all!!! El lun., 17 jun. 2019 04:06, Dmitry Shachnev escribió: > On Sun, Jun 16, 2019 at 10:45:29PM +0100, Brian Potkin wrote: > > > I have uploaded a new version of qtbase to unstable today, which has > > > it backported. > > > > > > Can you please test that it really fixes the bug for you? If yes, > > > I will file an unblock request for this upload. > > > > A couple of quick tests and it seems to me that #911844 and #911702 > > have been fixed with this upload. > > Thanks for testing it! > > I am marking bug 911702 as fixed now, and will file an unblock request > soon (to make the fix accepted into Buster). > > -- > Dmitry Shachnev >
Bug#930633: i3-gaps RFS/ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi antisocrates, > Ingo will outline what needs to be done to get i3-gaps into a mergable > state, so that we can eventually bring these features to all i3 users. > > For the time being, our recommendation is to NOT add i3-gaps to Debian or > any other Linux distribution. Instead, if you have time and motivation, > please consider helping improve i3-gaps with the goal of a merge. With that in mind, please reconsider your package, antisocrates, and the invitation at hand ☺. I strongly support the view not to add i3-gaps as a separate package, now that it was made clear that there are efforts to get the gaps feature merged. Cheers, Nik -BEGIN PGP SIGNATURE- iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl0Hz6IxGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW oMTyliwpEADbI2jq1IiEhBjBi8qDSPaq3WGG8gNtC6kt57JXysUV+FerDrp9qwax Z9HXHjyHyP4oxq0bpbJQHmYTjnNz4FknN2bqdqWO5/bBodOsYmrs4leailsqzDPX aweB3HB46or6lZhCymwKZhhseL9Sv3aBbRBiusBI5umpuGlIwMm1cjXlGse6jUgp +q28k9dydqHb14yxTjA4HPuWHamcoKAwT28IzTV5T6PaKKRiUgmdH6OqDXLpNTFO 8pWvldEHn8lL4QCFiu2kaDA3AAucAZ8++ebxzfyORksWAsLRT56tu+eBHt6nJyQs hf+BeDAWUjOKmx304N38mPcHrhq+mFnNlaUtspxXhGEWOfSnce8ZDacN/ST6jepV nB4vGdiyl6leUNTq9fDENg8UU00Hkpuz5n4pAzQMLc2nx6YLkujS7NOhNff8gwei HiyYqCNK1ATw/X2r+RLl2oROgd+rBPQ5C2RZw2sm+sDd/hSZLEcO5kjDpXXyAze8 /8YhpbgsC5OSy7gK7UmKYm66pexKoto6VDeyh05gqG2z0eXTjpyM+19Rc6f9nZrv Rnt/ON0xUFldZZ2s71nz0Wzc9zeDNQL40iisUZP1i8+qhoS7cuQKC3Kl0rUHkOqt 1ViYNdBszUkBuvCyuaZuPV3Oi2gpHfWbbqv8UBNjVK6iatZMf0UBgg== =3IgO -END PGP SIGNATURE-
Bug#930652: systemd removes static ipv4 address from ethernet sporadically
If you do actually use networkd, please share your networkd configuration and provide a debug log. See https://coreos.com/os/docs/latest/network-config-with-networkd.html#debugging-networkd -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930648: exim4-daemon-heavy: Weird leakage of unrelated data like /etc/aliases into /var/spool/exim4/input/*-H
On 2019-06-17 Bjoern Buerger wrote: > Package: exim4-daemon-heavy > Version: 4.92-7 > Severity: important [...] > We did update to 4.92-7 from bpo before we saw the problem for > the first time. Hello Bjoern, what version did you upgrade from, the previous bpo-version (4.92-2) or the original stretch release? [...] > 2019-06-13 17:55:22 1hbS4P-0004q8-LL <= linux-usb-ow...@vger.kernel.org \ > H=vger.kernel.org [209.132.180.67] P=esmtp K S=9996 DKIM=linaro.org [...] > The first error message is logged with the same timestamp: > 2019-06-13 17:55:22 1hbS4P-0004q8-LL Format error in spool file > 1hbS4P-0004q8-LL-H: size=9934 Are you running sa-exim or something else that directly modifies the spoolfiles outside exim? cu Andreas
Bug#930652: systemd removes static ipv4 address from ethernet sporadically
[please always CC the bug report] Am 17.06.2019 um 18:54 schrieb Joshua Hudson: > systemd-networkd is active. NetworkManager is not. Well, the systemd-analyze dump you attached to this bug report shows systemd-networkd.service as inactive. And you also said this: >> Am 17.06.2019 um 18:35 schrieb Joshua Hudson: >>> Machine has been losing ipv4 address out of ethernet sporadically. >>> This machine does not use NetworkManager anymore as all interfaces are >>> static. >>> ifup should run at boot and nothing ever touch network configuration >>> again. ifup is provided by the ifupdown package. Please provide logs, which show that systemd-networkd is actually active and share your networkd network configuration. It's really hard to make sense out of this bug report. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930654: base-files: mesg: ttyname failed: No such device
Package: base-files Version: 10.2 Severity: normal Tags: patch Dear Maintainer, Every time I log in to a Debian LXC container I get this greeting :-): $ lxc shell sid mesg: ttyname failed: No such device root@sid:~# Please consider applying the following patch or something similar to suppress the useless error. -- --- ./share/dot.profile +++ ./share/dot.profile @@ -6,4 +6,4 @@ fi fi -mesg n || true +mesg n 2> /dev/null || true -- Thanks, Balint PS: This was a discussion already in #794727 . -- Balint Reczey Ubuntu & Debian Developer
Bug#930652: systemd removes static ipv4 address from ethernet sporadically
Control: tags -1 + moreinfo Am 17.06.2019 um 18:35 schrieb Joshua Hudson: > Package: systemd > Version: 241-5 > Severity: important > > This is in fact a corporate server; real email is jhud...@cedaron.com > but if I try to use that source for reportbug, nothing goes through. :( > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > Machine has been losing ipv4 address out of ethernet sporadically. > This machine does not use NetworkManager anymore as all interfaces are static. > ifup should run at boot and nothing ever touch network configuration > again. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Uninstalled NetworkManager, thinking that was the culpret. It wasn't. > There's not much left on the machine that monitors network interfaces. > > If you are using ifup (ifupdown) to configure your network and systemd-networkd is not active, why is this bug report filed against systemd? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930653: libapt-pkg-perl: Port to apt 1.9.0
Package: libapt-pkg-perl
Version: 0.1.34
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
Control: user de...@lists.debian.org
Control: usertag -1 apt-1.9.0
Ports libapt-pkg-perl to apt 1.9.0 (coming soon to experimental), this
removes:
- IsOk() method of a PkgFileIterator
- GetMatch() method of a Policy
- GetPriority(Package) of Policy
adds:
- GetPriority(Version) of Policy
An alternative would be to do no-ops for IsOk(),
GetMatch(), and GetPriority(Package), returning true,
no version, and 0 (or priority of candidate) respectively;
but we removed those variants in APT; so it's probably
best to follow along.
Thanks for considering the patch.
-- System Information:
Debian Release: buster/sid
APT prefers eoan
APT policy: (991, 'eoan'), (500, 'eoan'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-15-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
diff -Nru libapt-pkg-perl-0.1.34build2/AptPkg.xs
libapt-pkg-perl-0.1.34ubuntu1/AptPkg.xs
--- libapt-pkg-perl-0.1.34build2/AptPkg.xs 2017-08-18 14:35:27.0
+0200
+++ libapt-pkg-perl-0.1.34ubuntu1/AptPkg.xs 2019-06-17 18:42:06.0
+0200
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,9 @@
#include "utils.h"
+using std::string;
+using std::vector;
+
/* XS has grief with colons */
#define Configuration_Item Configuration::Item
#define pkgSrcRecords_Parser pkgSrcRecords::Parser
@@ -1142,13 +1146,6 @@
OUTPUT:
RETVAL
-bool
-pkgCache_PkgFileIterator_p::IsOk()
- CODE:
-RETVAL = (char *) THIS->obj->IsOk();
-
- OUTPUT:
-RETVAL
MODULE = AptPkg PACKAGE = AptPkg::Cache::_ver_file
@@ -1282,20 +1279,20 @@
SV *arg
CODE:
pkgCache_PkgFileIterator_p *f = 0;
-pkgCache_PkgIterator_p *p = 0;
+pkgCache_VerIterator_p *v = 0;
if (SvROK(arg))
{
if (sv_derived_from(arg, "AptPkg::Cache::_pkg_file"))
f = (pkgCache_PkgFileIterator_p *) SvIV((SV *) SvRV(arg));
- else if (sv_derived_from(arg, "AptPkg::Cache::_package"))
- p = (pkgCache_PkgIterator_p *) SvIV((SV *) SvRV(arg));
+ else if (sv_derived_from(arg, "AptPkg::Cache::_version"))
+ v = (pkgCache_VerIterator_p *) SvIV((SV *) SvRV(arg));
}
if (f)
RETVAL = THIS->obj->GetPriority(*f->obj);
-else if (p)
- RETVAL = THIS->obj->GetPriority(*p->obj);
+else if (v)
+ RETVAL = THIS->obj->GetPriority(*v->obj);
else
croak("arg is not of type AptPkg::Cache::_pkg_file"
" or AptPkg::Cache::_package");
@@ -1304,18 +1301,6 @@
RETVAL
pkgCache_VerIterator_p *
-pkgPolicy_p::GetMatch(pkgCache_PkgIterator_p *p)
- CODE:
-pkgCache::VerIterator v = THIS->obj->GetMatch(*p->obj);
-if (v.end())
- XSRETURN_UNDEF;
-
-RETVAL = new pkgCache_VerIterator_p(THAT_sv, v);
-
- OUTPUT:
-RETVAL
-
-pkgCache_VerIterator_p *
pkgPolicy_p::GetCandidateVer(pkgCache_PkgIterator_p *p)
CODE:
pkgCache::VerIterator v = THIS->obj->GetCandidateVer(*p->obj);
@@ -1460,11 +1445,11 @@
PUSHs(s);
}
-vector files;
-if (parser->Files2(files))
+vector files;
+if (parser->Files(files))
{
AV *av = newAV();
- for (vector::const_iterator f = files.begin();
+ for (vector::const_iterator f = files.begin();
f != files.end(); ++f)
{
HV *hv = newHV();
diff -Nru libapt-pkg-perl-0.1.34build2/debian/control
libapt-pkg-perl-0.1.34ubuntu1/debian/control
--- libapt-pkg-perl-0.1.34build2/debian/control 2019-06-17 13:09:25.0
+0200
+++ libapt-pkg-perl-0.1.34ubuntu1/debian/control2019-06-17
18:42:22.0 +0200
@@ -1,8 +1,7 @@
Source: libapt-pkg-perl
Section: perl
Priority: optional
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Brendan O'Dea
+Maintainer: Brendan O'Dea
Build-Depends: perl (>= 5.8.0-6), debhelper (>= 10), libapt-pkg-dev (>=
0.6.40.1)
Standards-Version: 4.1.4
Vcs-Browser: https://salsa.debian.org/bod/libapt-pkg-perl
Bug#930294: Nautilus slow to respond and consumes 100% CPU resource
On Mon, Jun 17, 2019 at 02:22:57PM +0530, Vikram Vincent wrote: > I've uploaded the entire folder contents so you can try to replicate the bug I think you've misunderstand what the Templates folder is for. It's for nautilus's, or possibly another file manager's, "New Documents" menu. Right-click in a nautilus window and it will show options to create documents based on what is in the Templates folder. For example, you could have a file in there named "Text Document.txt" and nautilus will see this and offer you the option to create a new text document in its right-click menu. Instead, you've placed a git repository of LibreOffice Impress templates in that folder. These are not the kind of template files that nautilus is expecting, they are themes for creating slideshow presentations in the Impress application. They contain a lot of images and xml, so nautilus spends a lot of time scanning the 2678 files in that directory to build its New Documents menu. Even if nautilus were faster or more efficient, you would be left with a very confusing New Document menu in nautilus. It's not clear to me what should be done to address this. Possibly the Templates folder is confusing and the concept should be redesigned. Possibly nautilus should be made more efficient, since based on my limited testing, it appears to rebuild the New Documents menu more often than it should. Possibly nautilus should have a safeguard or limit on the number of entries that it is willing to add to the New Documents menu.
Bug#930557: i3-gaps RFS/ITP
Hey, thanks everyone for reaching out. The interest in making i3-gaps available to more people has prompted some discussion between Ingo (the maintainer of the i3-gaps fork, and an i3 core maintainer) and me. The key concern about the i3-gaps fork is code quality: the implementation cannot easily be merged into i3 as-is. One example is that you cannot enable gaps and display title bars at the same time. The intention behind publishing the fork was to make the feature available to people who can live with the lower code quality and restrictions, not to have a long-term sustainable fork. Ingo will outline what needs to be done to get i3-gaps into a mergable state, so that we can eventually bring these features to all i3 users. For the time being, our recommendation is to NOT add i3-gaps to Debian or any other Linux distribution. Instead, if you have time and motivation, please consider helping improve i3-gaps with the goal of a merge. Thank you, -- Best regards, Michael
Bug#930645: Vagrant images debian/stretch64 9.9.1: same client ID for all VM
Le 17/06/2019 à 15:03, Nicolas Quiniou-Briand a écrit : > Package: cloud.debian.org > Severity: important > > Hello, > > Since upgrade to debian/stretch64 9.9.1 image, I noticed that virtual > machines share > the same client ID in libvirtd. Consequently, libvirtd override old DHCP > lease by new one. > thanks for the detailed bug report I think the problems comes from every libvirt having the same /etc/machine-id we do delete the initial machine-id when creating the box in https://salsa.debian.org/cloud-team/vagrant-boxes/blob/master/helpers/vagrant-setup#L103 so I suppose while working on #910143 I booted the vmdk to test the change and the local machine-id generated at that moment ended up in all libvirt images IIRC this is a libvirt specific problem (again) since the virtualbox boxes use isc-dhcp instead of the built in systemd dhcp client, and isc-dhcp does not rely on the machine-id when requesting an IP. as this bug is a major regression, I will move the 9.99.2 box offline until this is fixed ( a rebuild should be enough, but I am starting my honeymoon this week ) -- You know an upstream is nice when they even accept m68k patches. - John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Bug#930651: Please remove elilo from Suggests: list
Package: bootcd Version: 5.14 Severity: minor elilo isn't in Debian any more... -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bootcd depends on: ii busybox-static [busybox] 1:1.30.1-4 ii coreutils 8.30-3 ii cpio 2.12+dfsg-9 ii dosfstools4.1-2 ii e2fsprogs 1.44.5-1 ii fdisk 2.33.1-0.1 ii fdutils 5.5-20060227-8 ii file 1:5.35-4 ii genisoimage 9:1.1.11-3+b2 ii init-system-helpers 1.56+nmu1 ii initramfs-tools 0.133 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-1 ii lsb-base 10.2019051400 ii syslinux 3:6.04~git20190206.bf6db5b4+dfsg1-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-1 ii util-linux2.33.1-0.1 Versions of packages bootcd recommends: ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-1 ii wodim 9:1.1.11-3+b2 Versions of packages bootcd suggests: pn aufs-tools ii discover2.1.2-8 pn elilo ii ssh 1:7.9p1-10
