Bug#1083225: v17 and pypdf2
I'm actively trying to sort out this situation with upstream, since v17 is, unfortunately and unexpectedly, still somewhat in limbo with regard to this pypdf/pypdf2 issue. Cheers, -- Seb
Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2
On Tue, Sep 03 2024, Colin Watson wrote: > I had a brief look at this and noticed that this package was > previously ported to pypdf, but that the port was reverted in > https://salsa.debian.org/freexian-team/packages/odoo/-/commit/d68da30bd5746f41e33c19ba5c2b8bc0f100e4d6. > > CCing Sébastien - was there a problem with the port? (Maybe > https://bugs.debian.org/1032300? But that was closed six months before > the commit above ...) Yeah, it unfortunately breaks PDF printing. odoo-17 is scheduled to enter unstable soon'ish, and eventually make it into trixie, so odoo-16 is not meant to be included in that release. Cheers, -- Seb
Bug#1064843: odoo-16: minor upgrades available
Control: severity -1 normal
Control: tag -1 + pending
Hello,
odoo-16 is the official and latest version available in Debian ("saas"
are not meant to be deployed locally) right now; 17 and 18 will be
packaged soon.
Upgrading from one major version to the next is not directly supported
in Debian: it's a commercial service provided by the Odoo company.
Addons can be installed by referencing their path in the `addons_path`
variable, see for instance:
https://github.com/odoo/odoo/blob/16.0/debian/odoo.conf
I'll add a line about this in the Debian documentation for the next
update.
Cheers,
--
Seb
Bug#1059326: Workaround
In case someone out there is stuck real bad with this bug in bookworm, here's a very nasty workaround for which I of course decline all responsibility: $ mkdir /usr/share/fonts/type1/gsfonts $ ln -sf /usr/share/fonts/X11/Type1/C059-Roman.pfb /usr/share/fonts/type1/gsfonts/n021003l.pfb Cheers, -- Seb
Bug#1059326: fixed in 4.0.8-1
Control: fixed 1059326 4.0.8-1 The earliest fixed version is most likely between 4.0.4-7 and 4.0.4-11. Cheers, -- Seb
Bug#1029736: Odoo-14 fails to start
On Thu, Mar 02 2023, Glenn wrote: > I think this bug could be more serious than wishlist, as the server > doesnt start, for me at least. > > When trying to start it with the same line from its init file, it > concludes with the error; No module named 'PyPDF2.utils' Hi Glenn, the bug you're hitting is actually #1032300. Cheers, -- Seb
Bug#1022721: New aptly upstream version 1.5.0
On Mon, Jan 30 2023, Roland Mas wrote: > golang-github-cavaliergopher-grab has been accepted into > unstable. Shall I proceed with the aptly upload or would one of you > guys prefer doing it? You can go ahead. Cheers, -- Seb
Bug#1022721: New aptly upstream version 1.5.0
On 02/01 15:04, Roland Mas wrote: > I took the liberty of packaging the cavaliergopher/grab library Thanks for uploading that to NEW and closing the associated RFP. > I also updated the packaging for aptly 1.5.0, which I committed and > pushed to salsa, but I'd rather you had a look before uploading, as > I'm not a Golang expert at all. On a very general note I would have rather preferred a MR on a separate branch, at least until cavaliergopher/grab gets accepted from NEW before the freeze. This would have ketp the CI status green, and made for easier fixes around freeze time if some problem arises in the current version. But this is git anyway, so if it comes to that we'll have to ignore debian/master and build something off of 4c7796ca instead. I don't have much time right now, but after a cursory glance at the current HEAD it looks fine to me. Thanks a lot for your work on aptly, it's much appreciated and hopefully will allow us to get 1.5 into bookworm. Cheers, -- Seb
Bug#1024641: Aptly does not support zstd compression
On 22/11 11:01, Kyle Edwards wrote: > Package: aptly > Version: 1.4.0+ds1-7 > > Aptly 1.4.0 does not support the zstd compression found in Ubuntu 22.04 > packages. Please upgrade Aptly to 1.5.0 to support the new zstd compression. This was fixed in 1.4.0+ds1-7, as per #1010465[fn:1]. Are you actually saying this version, currently in sid, doesn't properly support zstd for you? If so, how does it fail? As for packaging 1.5.x, please see #1022720[fn:2]. Cheers, -- Seb * Footnotes [fn:1] https://bugs.debian.org/1010465 [fn:2] https://bugs.debian.org/1022720
Bug#1024166: blist: dead upstream, no maintainer upload since 2015
On 15/11 14:51, Louis-Philippe Véronneau wrote: > I'm CC-ing Sebastien Delafond explicitly, as he seems to be the > maintainer of all the packages in the archive that depend or > build-depend on blist (python-raccoon, python-panwid, elastalert). > > In a perfect world, those packages should migrate away from blist in > time for the freeze. If not possible, it would be nice if it could > have an active maintainer again. I've uploaded new versions of raccoon and panwid that don't depend on blist anymore. elastalert is maintained by Freexian, I'll see what can be done on that side. Cheers, -- Seb
Bug#1012287: aptly: Please provide a bullseye-backports version
On 03/06 03:21, Bastian Germann wrote: > Source: aptly > Version: 1.4.0+ds1-7 > > Now that aptly can publish zstd packages can you please upload the > current version to bullseye-backports? That would be very helpful, > e.g., to mirror Ubuntu jammy. > > I can also upload it myself if you agree. I can take care of it late next week, but if you want to make it happen before that please feel free to do so. Cheers, -- Seb
Bug#1005290: 1005290
Hi Enrico, see the comment from upstream here: https://github.com/aptly-dev/aptly/issues/1031#issuecomment-1046299497 I'm tempted to mark this as minor+wontfix, leaving it open to serve as a reference for other users. What do you think? Cheers, -- Seb
Bug#824609: Reproducer for #824609?
Hi Sam, upstream apparently cannot reproduce the issue anymore[0]. Do you still this see on your end? Cheers, -- Seb [0] https://github.com/aptly-dev/aptly/issues/403#issuecomment-1024176943
Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content
On 06/01 06:10, Salvatore Bonaccorso wrote: > CVE-2021-46144 has been assigned for the roundcube issue. Thanks for taking care of this Salvatore. I'll review the debdiffs once Guilhem sends them, and will take care of the DSA afterwards. Cheers, -- Seb
Bug#924139: OVAL generation code migrated to python3
As far as OVAL is concerned, all the relevant MRs are merged in, and the OVAL files are now being generated on www-master[0] using python3: [...] /usr/bin/python3 generate.py -q -d .. -j DebianSecTracker.json -r bullseye >oval-definitions-bullseye.xml Cheers, -- Seb [0] https://www-master.debian.org/build-logs/webwml/wml_run.log
Bug#924139: OVAL python3
With https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/737 now merged, python3 support is in https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/740. I'll open an RT ticket to get https://salsa.debian.org/seb/debian.org/-/commit/72fbf295abfd042835ce786344a13bcf8a81148b included so python3-lxml is available on the server side.
Bug#998757: salsa MR
https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/752
Bug#998757: security.debian.org: OVAL feed issues
On 07/11 10:22, Noah Meyerhans wrote:
> [...] These two OVAL definitions list essentially identical criteria,
> yet their actual status in bullseye is quite different:
>
> CVE-2020-28200 is still present in bullseye and is a legitimate
> finding by any scanner based on these definitions:
> https://security-tracker.debian.org/tracker/CVE-2020-28200
>
> CVE-2012-0833 is not present in any bullseye and should not trigger a
> finding from a scanner:
> https://security-tracker.debian.org/tracker/CVE-2012-0833
>
> If we look at the security-tracker's JSON feed [2], we see some
> details that should be reflected in the OVAL feed but aren't, in
> particular the "status" field:
>
> "CVE-2012-0833": { ...
> "releases": { ...
> "bullseye": { "status": "resolved", "repositories": {
> "bullseye": "1.4.4.11-2" }, "fixed_version": "0", "urgency":
> "unimportant"
> }, ... } and
>
> "CVE-2020-28200": {
> "releases": { ...
> "bullseye": { "status": "open", "repositories": { "bullseye":
> "1:2.3.13+dfsg1-2" }, "urgency": "not yet assigned"
> }, ... },
>
> I'm not super familiar with the semantic expectations of OVAL, but I
> think logically we want to represent CVE-2012-0833 somewhat
> differently in OVAL using logic similar to:
>
> if status == resolved: if fixed_version == 0:
> # All versions of this package in this release's repos are fixed:
> OVAL_criterion = "package is earlier than
> min(values.repositories)"
> else OVAL_criterion = "package is earlier than fixed_version"
>
> In this case the criterion for CVE-2012-0833 would be:
>
> test_ref="oval:org.debian.oval:tst:4696"/>
>
> Which I believe is correct. If a system is running bullseye and has
> 1.4.4.11-2 or later installed, then a scanner should determine that
> this vulnerability is not present.
Thanks for the detailed report.
I agree the current "greater than 0" criterion in OVAL isn't right, and
ideally the JSON export would correctly list "min(version for version in
all_versions_ever_in(repository)" in fixed_version instead of the
current "0": the current OVAL code would then expose the correct result
automatically.
I'm not sure how feasible that is, as I'm not familiar with the JSON
export code, but what I would *most* like to avoid here, is having that
min() computation be performed on the OVAL side: it doesn't belong
there, IMO.
The other approach is for the OVAL code to simply skip a CVE entirely if
the target distribution was never affected: it would remove the current
false positives, and the only downside would be the lack of an alert is
someone was to accidentally downgrade or hang on to a vulnerable version
(from a previous stable suite for instance). I'm not sure if our OVAL
exports should really for such a scenario, so maybe that's the better
option here.
Cheers,
--
Seb
Bug#924139: OVAL generation code migrated to python3
See https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/737.
Bug#988673: centreon-connectors: diff for NMU version 19.10.0-1.1
On 08/09 16:54, Adrian Bunk wrote: > I've prepared an NMU for centreon-connectors (versioned as > 19.10.0-1.1) and uploaded it to DELAYED/14. Please feel free to tell > me if I should cancel it. Hi Adrian, thanks a lot for taking of this, it's really appreciated. Cheers, -- Seb
Bug#987084: unblock: wordpress/5.7.1+dfsg1-1
For the Security Team, unblocking 5.7.1 is the preferred option as it will make supporting WP for the entire bullseye lifecycle much easier. If the Release Team thinks it's too late at this point for such an unblock, we'd favor going with 5.6.3 instead. Cheers, -- Seb
Bug#983104: RFS: mupdf/1.14.0+ds1-4+deb10u3 [NMU, CVE-2020-16600] -- lightweight PDF viewer
On 19/02 13:53, Bastian Germann wrote: > * Package name: mupdf >Version : 1.14.0+ds1-4+deb10u3 > [...] > * Avoid a use-after-free in fz_drop_band_writer (CVE-2020-16600) Hi Bastian, thanks for your work on this. We think this update should go via stable-proposed-updates: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable Cheers, -- Seb
Bug#983090: python-django: CVE-2021-23336
On 19/02 09:25, Chris Lamb wrote: > > Django is vulnerable because it embeds parse_qsl: > > > > https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ > > Security team, let me know if you would like an update for stable. Hi Chris, we think this should rather go via s-p-u. Cheers, -- Seb
Bug#982493: openvswitch: CVE-2020-35498
On 12/02 16:07, Thomas Goirand wrote: > Please find the attached debdiff for the upload to security-master. Hi Thomas, this looks good, please upload to security-master. Cheers, -- Seb
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On 21/01 12:46, Utkarsh Gupta wrote: > I can create an issue in the original fork. However, just know that > this library is *not* being maintained at all. So there won't be much > help from anywhere. I'm not expecting upstream to fix it either, but it'd feel more comfortable to close this bug on our side while still linking to an existing upstream issue. > Either way, I'd also like to mention that we did a build for > ruby-in-parallel against ruby3.0 and everything seems to work, > including those tests as well. Ideally we'd only skip this test in 2.x, while keeping it in 3.0 to see if same race eventually pops up on debci. Cheers, -- Seb
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
On 21/01 12:31, Utkarsh Gupta wrote: > Aah, okay. So I ran sbuild + autopkgtest 10 times, all passed for me. > But when I ran these tests locally with rake, it failed for me exactly > like the report just for the first time. And then passed all 9 times > afterward. I haven't been able to reproduce it here: local rake, autopkgtest+lxc, autopkgtest+qemu. > Then I tried to trace back the origin of this problem but couldn't > find anything. I am not sure what's causing this (I haven't gone > through the source thoroughly) but I am inclined towards skipping this > test if that's OK with you? It definitely looks like a race, so I agree we can skip it if we create an upstream bug documenting the issue. Cheers, -- Seb
Bug#980585: ruby-in-parallel: FTBFS: ERROR: Test "ruby2.7" failed: Failure/Error: expect(@result_3).to_not eq(true)
Hi Utkarsh, since you took care of the last upload, do you also plan to fix this FTBFS? If not, please let me know and I'll look into it. Cheers, -- Seb
Bug#977537: odoo: Use JS libraries already packaged in Debian
Here's upstream's take on the problematic items in this list: > use libjs-jquery-form The version in Debian is too old right now, and won't work properly. > libjs-underscore The version in Debian is more recent, and needs to be validated. > libjs-cropper Different upstreams: Odoo: 1.5.5 from https://github.com/fengyuanchen/cropperjs Debian: 1.2.2 from http://www.defusion.org.uk/code/javascript-image-cropper-ui-using-prototype-scriptaculous/ The rest of the libjs warnings should be fine.
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
On 11/12 18:59, Sylvain Beucler wrote: > I did more tests during the past few hours (checking that > XERCES_DISABLE_DTD does address the memory leak and using a couple > reverse dependencies) and just uploaded the buster update to security > master. I've just rejected this upload, so you can reuse deb10u1 once the test suite is fixed on 32bit architectures. Cheers, -- Seb
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
On 09/12 17:46, Sylvain Beucler wrote: > Here's a debdiff against buster. > > The testsuite passes, provided we modify MemHandlerTest1 to take the > leak into account. Hi Sylvain, thanks for the debdiff, it looks good and the trade-off makes sense. You can upload to security-master and I'll take care of the DSA soon. Cheers, -- Seb PS: please try to cc:secur...@debian.org when asking questions to the team in the BTS, as this will help keeping them high up on our radar.
Bug#973562: wordpress: Wordpress 5.5.2 security release
On 02/11 08:01, Craig Small wrote: > Wordpress versions less than 5.5.2 have the following security > vulnerabilities: > > CVE-2020-28039: Protected meta that could lead to arbitrary file deletion. > CVE-2020-28035: XML-RPC privilege escalation. > CVE-2020-28036: XML-RPC privilege escalation. > CVE-2020-28032: Hardening deserialization requests. > CVE-2020-28037: DoS attack could lead to RCE. > CVE-2020-28038: Stored XSS in post slugs. > CVE-2020-28033: Disable spam embeds from disabled sites on a multisite > network. > CVE-2020-28034: Cross-Site Scripting (XSS) via global variables. > CVE-2020-28040: CSRF attacks that change a theme's background image. Hi Craig, are you planning on backporting the fixes for those on top of buster's 5.0.10+dfsg1-0+deb10u1? Cheers, -- Seb
Bug#971591: Please update testinfra to 5.3.0
On 27/10 16:20, Baptiste Beauplat wrote: > I've just been given out the access on salsa. Ready to welcome > testinfra :) Done: https://salsa.debian.org/python-team/packages/testinfra Cheers, -- Seb
Bug#971591: Please update testinfra to 5.3.0
On 23/10 17:11, Baptiste Beauplat wrote: > Sure. I initially suggested debian because I'm not in the python > team. I guess that will be the opportunity to join in :) All right; can you let me know once you've joined, and then we can see about transferring it there? Cheers, -- Seb
Bug#971591: Please update testinfra to 5.3.0
On 15/10 09:30, Baptiste Beauplat wrote: > From what I can see on the package tracker, testinfra hasn't been very > active packaging wise. No source upload have been done and the package > hasn't migrated to testing, since 2019. > > I do believe that having testinfra in a Debian stable release would be > quite useful and so, if you are short in time to maintain that > package, I'm offering to adopt and maintain it with your approbation. > > If you are interested, would you consider moving the repository to the > debian/ namespace on salsa and granting me the maintainer right (as > lyknode, I'm not a DD yet). I'm CC'ing my usual sponsor for info. We'll happily hand the package over to you, however python-modules is probably a better namespace than debian. Do you agree? Cheers, -- Seb
Bug#947187: Unmaintained
tag 947187 + wontfix close 947187 thanks This is now unmaintained upstream: Note: As of June 2020 I do not have time to maintain this repository anymore and I've thus made it read-only. FTR, here's where I was with the packaging (the package itself could be built, but dh_test failed): https://github.com/sdelafond/cistern/tree/debian/master Cheers, -- Seb
Bug#968497: fixed in astra-toolbox 1.8.3-2
On 02/09 09:23, Gianfranco Costamagna wrote: > source only uploads for non-free are a sad story... Ah, forgot about that again. > I'll try to upload the binary shortly! Do you want me to do that today? Cheers, -- Seb
Bug#969371: hdf5plugin
Upstream uses hdf5plugin, but it can be patched out in 2 lines once https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/1 is merged.
Bug#959180: tornado6
I plan on testing whether relaxing the constraint plus including 902ef59 is enough to get the current version of mitmproxy running with tornado6. If that doesn't work, I'll look into packaging 5.1.1. Cheers, -- Seb
Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596
On 15/06 10:49, Chris Lamb wrote: > > The full debdiffs are attached. Can you especially check the > > versioning scheme and distribution fields for me? I often get this > > wrong and end up confusing myself. Really appreciated. > > They are now attached. They look fine, please upload to security-master. Cheers, -- Seb
Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596
On 06/06 10:15, Chris Lamb wrote: > > python-django: CVE-2020-13254 CVE-2020-13596 > > Security team, would you like an update for stretch and/or buster to > address these issues? It's fixed in sid, experimental as well as > jessie LTS. Bullseye is just pending migration time AFAICT. Hi Chris, yes, that'd be fine. Is there any chance you could also piggyback the fix for CVE-2020-9402 (marked "postponed") on top of the ones for CVE-2020-13254 and CVE-2020-13596? Cheers, -- Seb
Bug#950198: ring
Hi Alexandre, I noticed opendht 2.1 is now in sid. Is there anything I can do to help with the next steps, however you see fit? Cheers, -- Seb
Bug#950198: restinio
On 04/05 10:31, Sébastien Delafond wrote: > > I add a basic d/salsa-ci.yml, that should tell us what's going on. > > All the unit tests are passing in salsa: > > https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500 Hi Alexandre, in the current state, do you think I should upload restinio to NEW? Cheers, -- Seb
Bug#950198: restinio
On 04/05 09:18, Sébastien Delafond wrote: > I re-ran the build this morning from the repository you created, and it > passes here in sbuild; TTBOMK it's only binding its test router to > 127.0.0.1, and not trying to reach anything outside, but I may be > missing something. > > I add a basic d/salsa-ci.yml, that should tell us what's going on. All the unit tests are passing in salsa: https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500 Cheers, -- Seb
Bug#950198: restinio
On 03/05 19:40, Alexandre Viau wrote: > Also, I notice that the package's Changelog already has two entries, > but was it even uploaded once? Should it say UNRELEASED instead, until > it is uploaded, or should I understand that it was uploaded? This was my mistake, it should have said UNRELEASED as I definitely did not upload the package. I just changed that. > Action item before we can upload: > - Agree where the package will be maintained (hopefully thats over - > debian/restinio) Agreed. > - If we run the tests, they should pass (or was it my machine?) I re-ran the build this morning from the repository you created, and it passes here in sbuild; TTBOMK it's only binding its test router to 127.0.0.1, and not trying to reach anything outside, but I may be missing something. I add a basic d/salsa-ci.yml, that should tell us what's going on. Cheers, -- Seb
Bug#957071: fixed-upstream
Control: tag -1 fixed-upstream Fixed by https://github.com/CCExtractor/ccextractor/pull/1226, merged on master. Cheers, -- Seb
Bug#950198: restinio
On 27/04 13:13, Felix Salfelder wrote: > I hope it is more clear now, how I prefer to use the small tarball > over running the tests, as a matter of principle It was perfectly clear the first time, and this is where we can agree to disagree. Starting on this project I had a couple of goals, and what's in my salsa repository right now achieves the three of them: - copyright-clean - runs the upstream tests - should pass NEW As I don't intend to maintain restinio in the long run, I don't feel the need to argue this any further, and will happily defer to Alexandre's opinion. Cheers, -- Seb
Bug#950198: restinio
On 27/04 11:02, Felix Salfelder wrote:
> > - salsa-ci
> >
> > - open an issue upstream to integrate my two cmake patches for the
> > scenario "build a release without shipping binaries, yet
> > insist on running the tests during our build"
>
> I will see what I can do about these.
Before you go ahead on any of this, please let's wait for Alexandre's
input.
> Something else that might need work.
>
> The freshly imported tarball (0.6.6) contains an embedded dev/asio
> directory, which does not exist in the upstream repository, nor was it
> in the 0.6.4 tarball. I understand that this copy is unnecessary. But
> some test is compiled with -I${top_srcdir}/dev/asio/include.
>
> The embedded asio does not coincide with libasio-dev in sid,
> 1:1.12.2-1. Imo (and I am certainly clueless here) this may lead to
> questionable test results. Technically, We may need to depend on a
> specific libasio-dev.
Definitely not; instead we'd patch the corresponding CMakeLists to
compile against the system-wide asio. As for the 2 above points, let's
wait on Alexandre to see if he thinks this should delay the upload to
NEW.
> The source of this is, upstream is offering multiple tarballs, one
> with third party packages included. This also explains some of
> Sébastiens additions to the copyright file.
Some of them, yes. But there wasn't really any effort put into coming up
with a proper d/copyright with 0.6.4, as my initial "git grep -i
copyright upstream/0.6.4" led me to conclude.
> As of version 0.6.4, none of the additional headers were required for
> either for building opendht or jami.
But the whole point is, they are required to run the unit tests.
> I have imported the smaller tarball and rebased Sébastiens
> commits. It's in my master branch now [1]. I'm afraid the package does
> no longer build, and I am unsure how to proceed.
I'm not sure what to tell you here, except that this operation was
indeed bound to fail.
> My gut feeling is that the small tarball is the correct one, (although
> I can see the other one listed in d/watch), and that the tests should
> be compiled against installed packages, if at all.
I am unsure where your gut feeling comes from: the smaller package is OK
to simply use as an include in a development project. OTOH when building
the Debian package, we're definitely interested in running the
upstream-provided unit tests during a regular build.
Cheers,
--
Seb
Bug#950198: restinio
I've pushed my version of restinio's packaging to https://salsa.debian.org/seb/restinio's master branch. I started from Felix's initial effort, but a lot of things were missing: - d/copyright severely lacking - missing build-deps (most notably on cmake) initially prevented building as-is in a clean chroot - reworked/removed patches to cmake: initial patch had a "CMakeLists hacks; no idea what they are trying to do" comment associated to various changes in upstream CMakeLists. I changed that hack, which was aimed at "just building the package", so that we now run the full suite of unit tests provided by upstream (needed to upgrade to upstream version to 0.6.6 to fully implement that) Let me know if you want me to upload what I've got now to NEW. So we don't forget, here are a couple of items we'll want to fix later on: - salsa-ci - open an issue upstream to integrate my two cmake patches for the scenario "build a release without shipping binaries, yet insist on running the tests during our build" Cheers, -- Seb
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
On 21/04 20:23, Thomas Koch wrote: > I just uploaded persist-el. Thank you and sorry for the delay. As I had announced in my previous email, I already did that; see msg=19 of #954050, and https://ftp-master.debian.org/new/persist-el_0.4+dfsg-1.html. I'll most definitely be out of your way for the next uploads of persist-el. Cheers, -- Seb
Bug#950198: 950198
On 07/04 14:06, Alexandre Viau wrote: > - https://bugs.debian.org/950198 Hi Alexandre, I will look into Felix's packaging of restinio soon. Cheers, -- Seb
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
On 11/04 06:31, Nicholas D Steeves wrote: > #947017 "ITP: org-drill" is blocked by this RFS (#954050) for a > required dependency (persist-el). Please sponsor at your earliest > convenience to we can resume progress on getting org-drill back into > Debian. Hello, I have very little bandwidth these days, so if Thomas has some to handle this mentoring request, that would work out best. If not, I will try to find some time next week-end to do a one-time review and upload of persist-el. Thomas, can you let us know what you think? Cheers, -- Seb
Bug#954614: 954614
block 954614 by 954572 thanks This is due to #954572: since ruby-method-source got bumped to 1.0.0, the requirements for ruby-pry-byebug are not satisfiable anymore. Since puppet-beaker depend on that, it also fails to run its tests. Ultimately the solution is to fix #955340. Cheers, -- Seb
Bug#711554: pyhst2
retitle -1 ITP: pyhst2 -- Python High Speed Tomographic reconstruction tag -1 + pending owner -1 s...@debian.org thanks
Bug#723017: xrayutilities: changing from RFP to ITP
retitle 723017 ITP: xrayutilities -- Python x-ray data reduction and analysis owner 723017 s...@debian.org tag 723017 + pending thanks
Bug#951458: no-dsa
Hi Axel, for the record, the Security Team doesn't think this warrants a DSA. Cheers, -- Seb
Bug#948491: centengine crashes regulary
On 09/01 14:24, Pascal Vibet - ADACIS wrote: > I have an seg-fault in centengine process > [...] Hi Pascal, thanks for opening this; could you report it upstream at https://github.com/centreon/centreon-engine/issues/ ? Cheers, -- Seb
Bug#947017: [ATT seb] Re: Bug#947017: RFP: org-drill -- emacs self-learning mode with spaced repetition
On 08/01 09:56, tho...@koch.ro wrote: > I intend to start using org-drill again once it is in Debian. > I've never sponsored yet, but I'm a DD now and should learn how to do it. > So I can upload. Perfect: it's a much better solution than me uploading it. Cheers, -- Seb
Bug#947017: [ATT seb] Re: Bug#947017: RFP: org-drill -- emacs self-learning mode with spaced repetition
On 07/01 15:07, Nicholas D Steeves wrote: > Since you're the elpa-org-mode maintainer Would you like to package > org-drill, which was broken out into its own project for org-mode 9.3 > (possibly earlier)? > > Failing that, could I add you as an uploader? I'm happy to do the > work to package it, but I don't want to be the only person responsible > for something that I don't use ;-) Hi Nicholas, I'm OK to be listed as an uploader, but let me state right now that I don't use org-drill either :) Cheers, -- Seb
Bug#947287: python3-certifi: ships useless cacert.pem file
On 24/12 00:19, Thorsten Glaser wrote: > While the package is patched to return the system location, > it still ships /usr/lib/python3/dist-packages/certifi/cacert.pem > which causes the .deb to be larger than it must. > > Furthermore it might lead people to believe using that bundle > is acceptable by hardcoding a path to it. That cacert.pm is 275KB, and I believe it's important that people have it readily available should they choose to run comparisons or what not with the upstream cert store. README.Debian describes this somewhat accurately I believe (although it could probably be rephrased, patches welcome) but at this point I don't think I want to remove upstream's cert store. Before tagging this wontfix, however, I'm of course open to hearing further arguments. Cheers, -- Seb
Bug#944819: docker-based tests
Hi Antonio, the solution currently implemented does indeed test the installed package: it will install it using /etc/apt/sources.list.d/autopkgtest.list, and run the entire upstream test suite against that. You are right that all of this happens in a docker container. This is because that all the dependencies and requirements for that test suite to run are a bit complex, and upstream's solution uses docker for setting all that up: our initial implementation therefore chose that as well. There is however an ongoing effort to rewrite it shell, so as to directly use the underlying host. Once that effort is complete, disk usage shouldn't be a problem anymore on the debci workers. Cheers, -- Seb
Bug#941530: jackson-databind: CVE-2019-16942 CVE-2019-16943
On 02/10 09:43, Salvatore Bonaccorso wrote: > Whilst I'm not yet sure if we should really release a futher DSA for > jackson-databind (we will come back to you on that), a possible idea > for bullseye (might be better cloned/filled as new bug, but want to > mention it here already): Let's do a DSA for this one. For future issues, we can choose to decide on DSA vs. point release on a case-by-case basis, depending on severity. Cheers, -- Seb
Bug#933929: python-rtslib-fb < 2.1.69 prevents ceph-iscsi from being uploaded to unstable
Hello, just a quick follow-up to let you know that this bug is still preventing ceph-iscsi from being uploaded to sid. As such, I'm again offering my help if you think the version bump itself is OK, but you don't have enough time to take care of it. Cheers, -- Seb
Bug#939626: Upstream
Upstream indicates that: We are working actively on that subject. So the next release of centreon-broker won't need qt4 nor qt5. Qt will be completely removed from it. We hope this change to be finish for the next release of Centreon. This is targetted for 19.10, to be released in October 2019.
Bug#934356: stretch-pu: package mitmproxy/0.18.2-6
I've tried a bunch of things, essentially reusing my older
pbuilder-based build setup (as opposed to the newer sbuild-based one),
to no avail: I keep getting those extra upper-bound versioned
dependencies in the resulting package.
At this point I see two options:
- build a +deb9u2 that uses debian/pydist-overrides to prevent the
insertion of those extra versioned dependencies (see attached
patch); with that one, the resulting dsc debdiff is minimal:
$ debdiff mitmproxy_0.18.2-6_all.deb mitmproxy_0.18.2-6+deb9u2_all.deb
[seb hulk]
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Version: [-0.18.2-6-] {+0.18.2-6+deb9u2+}
- give up on fixing #934356 in the upcoming point release
What do you think ?
Cheers,
--
Seb
diff --git a/debian/changelog b/debian/changelog
index 4fcb7218..a714bb37 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mitmproxy (0.18.2-6+deb9u2) stretch; urgency=medium
+
+ * Prevent insertion of unwanted upper-bound versioned dependencies
+
+ -- Sebastien Delafond Wed, 28 Aug 2019 13:04:01 +0200
+
mitmproxy (0.18.2-6+deb9u1) stretch; urgency=medium
* Blacklist tests that require internet access (Closes: #934033)
diff --git a/debian/pydist-overrides b/debian/pydist-overrides
index 144dfb3a..49405aa3 100644
--- a/debian/pydist-overrides
+++ b/debian/pydist-overrides
@@ -1 +1,5 @@
brotlipy python-brotli
+cryptography python-cryptography (>= 1.3)
+flask python-flask (>= 0.10.1)
+pyasn1 python-pyasn1 (>= 0.1.9)
+six python-six (>= 1.10)
Bug#934356: stretch-pu: package mitmproxy/0.18.2-6
On 26/08 17:42, Adam D. Barratt wrote:
> Our tooling has highlighted a dependency issue. I've not had chance to
> check if it already existed in the earlier package, but:
>
> unsat-dependency: python-cryptography (< 1.6)
>
> stretch has python-cryptography 1.7.1
This is a regression somewhere in the build process; 0.18.2-6 in stretch
currently has (sorted alphabetically for easier reading):
Depends:
python-backports.ssl-match-hostname,
python-blinker (<< 1.5),
python-brotli (>= 0.5.1),
python-certifi,
python-click,
python-configargparse (>= 0.10),
python-construct (>= 2.5.2),
python-cryptography (>= 1.3),
python-cssutils (<< 1.1),
python-flask (>= 0.10.1),
python-h2 (>= 2.4.1),
python-hpack,
python-html2text (>= 2016.1.8),
python-hyperframe (<< 5),
python-jsbeautifier (>= 1.6.3),
python-lxml (>= 3.5.0),
python-openssl (>= 16.0),
python-passlib (>= 1.6.5),
python-pil (>= 3.2),
python-pyasn1 (>= 0.1.9),
python-pyparsing (>= 2.1.3),
python-pyperclip,
python-requests (>= 2.9.1),
python-six (>= 1.10),
python-tornado (>= 4.3),
python-typing
python-urwid (>= 1.3.1),
python-watchdog (>= 0.8.3),
python:any (<< 2.8),
python:any (>= 2.7.5-5~),
0.18.2-6+deb9u1 has:
Depends:
python-backports.ssl-match-hostname,
python-blinker (<< 1.5),
python-brotli (>= 0.5.1),
python-certifi,
python-click,
python-configargparse (>= 0.10),
python-construct (>= 2.5.2),
python-cryptography (<< 1.6),
python-cryptography (>= 1.3),
python-cssutils (<< 1.1),
python-flask (<< 0.12),
python-flask (>= 0.10.1),
python-h2 (>= 2.4.1),
python-hpack,
python-html2text (>= 2016.1.8),
python-hyperframe (<< 5),
python-jsbeautifier (>= 1.6.3),
python-lxml (>= 3.5.0),
python-openssl (>= 16.0),
python-passlib (>= 1.6.5),
python-pil (>= 3.2),
python-pyasn1 (<< 0.2),
python-pyasn1 (>= 0.1.9),
python-pyparsing (>= 2.1.3),
python-pyperclip,
python-requests (>= 2.9.1),
python-six (<< 1.11),
python-six (>= 1.10),
python-tornado (>= 4.3),
python-typing
python-urwid (>= 1.3.1),
python-watchdog (>= 0.8.3),
python:any (<< 2.8),
python:any (>= 2.7.5-5~),
At this point I'm not sure what part of the build chain is adding back
all the "python foo (<< .n.m)" (obviously during the expansion of
${python:Depends}, and by looking at setup.py), even though python-foo
is already explicitly listed in debian/control's Depends field.
Even more confusing to me right now is that the whole point of 0.18.2-6
was indeed to *remove* all those upper-bound dependencies:
- https://bugs.debian.org/848562
-
https://salsa.debian.org/debian/mitmproxy/commit/4c238cb3549b9bf5e7b01a9c287eb2428a7134d2
And obviously at the time it worked, because 0.18.6-2 is indeed
"correct".
Cheers,
--
Seb
Bug#934026: python-django: CVE-2019-14232 CVE-2019-14233 CVE-2019-14234 CVE-2019-14235
On 08/08 11:02, Chris Lamb wrote: > +python-django (1:1.10.7-2+deb9u5) stretch-security; urgency=high > [...] > +python-django (1:1.11.23-1~deb10u1) buster-security; urgency=high Thanks, these both look good; please upload to security-master. Cheers, -- Seb
Bug#934026: python-django: CVE-2019-14232 CVE-2019-14233 CVE-2019-14234 CVE-2019-14235
On 06/08 10:20, Chris Lamb wrote: > Security team (added to CC), would you be interested in uploads for > buster (currently 1:1.11.22-1~deb10u1) and stretch (currently > 1:1.10.7-2+deb9u5)? Hi Chris, yes, thank you. Can you email us debdiffs ? I'll then take care of the review and DSAs. Cheers, -- Seb
Bug#931383: Add man page
Hello, upstream doesn't ship one, and I unfortunately do not have the time to write it myself. If someone does, and also commits to keeping it synchronized with upstream releases, I'll include it in the package. Cheers, -- Seb
Bug#927164: py3status: missing dependency
On 15/04 21:31, Alessandro -oggei- Ogier wrote: > I'd like to point out that package in fact depends on file(1) > and when that package isnt installed py3status fails with an error. > > Since on a freshly installed Debian system file package is not an > essential, this dependency should be explicitly listed. Could you be kind enough to include the error/traceback you get ? Cheers, -- Seb
Bug#907495: please ship the x11idle binary
On 27/03 09:26, Michal Politowski wrote: > Actually I think there is no need to compile x11idle. As the footnote > https://orgmode.org/manual/Resolving-idle-time.html#DOCF82 says, > Debian already provides xprintidle, which seems to work for me. > > Maybe elpa-org could just suggest that package and change the default > for org-clock-x11idle-program-name? Hi Michal, that's a good point, and sounds like an elegant way to solve this in Debian. I'm pretty busy these days, so I won't have time to work on that right now, but I'd happily accept a patch in the meantime :) Cheers, -- Seb
Bug#921725: libu2f-host: CVE-2018-20340
On Feb/09, Nicolas Braud-Santoni wrote: > Ah, I was bitten in the arse by #884428 again. > The upload to security-master should now be fine :) > > Sorry for accidentally duplicating your work, I didn't realise you had > prepared a backported fix for stable before the issue went public :) Thanks for being responsive on that issue; the DSA just went out. Cheers, -- Seb signature.asc Description: PGP signature
Bug#921725: libu2f-host: CVE-2018-20340
On Feb/08, Nicolas Braud-Santoni wrote: > I backported the fix and prepared an upload. > The debdiff is attached, and the commands used to produced it are documented > below. > > May I proceed with an upload to security-master? It looks OK to me, so if it passes testing on your end please upload to security-master (don't forget to use -sa as it will be new there). Cheers, -- Seb
Bug#921726: libu2f-host: CVE-2018-20340
Package: libu2f-host X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for libu2f-host. CVE-2018-20340[0]: Unchecked buffer in libu2f-host before 1.1.7 ... If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-20340 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20340 Please adjust the affected versions in the BTS as needed.
Bug#888903: [Pkg-javascript-devel] Bug#888903: 888903
On Jan/31, Jonas Smedegaard wrote: > The underlying issue is that the "js" in python-jsbeautifier stands > for JavaScript, and python-jsbeautifier fail to properly expose the > JavaScript part of the project as a shared library! > > The straightforward solution is for python-jsbeautifier to also build > libjs-beautify and node-beautify! I unfortunately do not have the available bandwidth to work on that, and I'm not also not particularly interested in maintaining any node-* stuff. I'm however totally fine with someone taking over python-jsbeautifier and doing just that. Cheers, -- Seb
Bug#888903: 888903
To me the straightforward solution here is not dpkg-alternative, but what Ivo recommended, since it only involves modifying *one* package. Cheers, -- Seb
Bug#917200: Fixed
https://salsa.debian.org/qt-kde-team/qt/pyside2/merge_requests/2
Bug#917001: MR
Here is the corresponding MR: https://salsa.debian.org/python-team/modules/python-twilio/merge_requests/1 Cheers, -- Seb
Bug#915765: MR
Here is the corresponding MR: https://salsa.debian.org/python-team/modules/pystaticconfiguration/merge_requests/1 Cheers, -- Seb
Bug#915765: FTBFS with pytest 3.10
Control: forwarded -1 Control: tag -1 + upstream Let's wait a bit for upstream's take on this issue, that was triggered when pytest 3.10 entered unstable last month. If need be, we could disable TestConfigurationWatcher::* when building the python2 package. Cheers, -- Seb
Bug#893723: 1.9.10 closing 4 bugs
Hi fellows, I've got a 1.9.10 nagvis package ready in salsa[0], that fixes four of the currently open bugs including this one. I've also manually included 1:1.7.10+dfsg1-3.2, which wasn't present in the salsa repository. Would you like an actual MR ? I'm also attaching a debdiff of debian/* to this report, and pasting the corresponding changelog here: , | Source: nagvis | Version: 1:1.9.10-1 | Distribution: unstable | Urgency: medium | Maintainer: Sebastien Delafond | Timestamp: 1544597179 | Date: Wed, 12 Dec 2018 07:46:19 +0100 | Closes: 858042 893723 903369 903706 | Changes: | nagvis (1:1.9.10-1) unstable; urgency=medium | . |[ Bas Couwenberg ] |* Team upload. |* Update watch file for move to GitHub. |* Bump Standards-Version to 4.2.1, no changes. | . |[ Sebastien Delafond ] |* NMU |* Imported Debian patch 1:1.7.10+dfsg1-3.2 |* Update php-gettext link |* Add Files-Excluded to debian/copyright, even though those files are | gone in 1.9.x: this will make further repacking more straightforward, | should it be needed |* Add repacksuffix to debian/watch |* New upstream version 1.9.10 (Closes: #893723, #903706) |* Use db_stop at the end of postinst (Closes: #858042) |* Add pt_BR translation (Closes: #903369) |* Update Vcs-* URLs to point to salsa ` Unless you object, I plan on uploading this to delayed/10 later this week: the RC bug is 9 months old, and the last uploads of nagvis are all quite old and were all NMUs as well. Cheers, -- Seb [0] https://salsa.debian.org/seb/pkg-nagvis diff --git a/debian/changelog b/debian/changelog index 3d2348a2..bcd3fec8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,25 @@ +nagvis (1:1.9.10-1) unstable; urgency=medium + + [ Bas Couwenberg ] + * Team upload. + * Update watch file for move to GitHub. + * Bump Standards-Version to 4.2.1, no changes. + + [ Sebastien Delafond ] + * NMU + * Imported Debian patch 1:1.7.10+dfsg1-3.2 + * Update php-gettext link + * Add Files-Excluded to debian/copyright, even though those files are +gone in 1.9.x: this will make further repacking more straightforward, +should it be needed + * Add repacksuffix to debian/watch + * New upstream version 1.9.10 (Closes: #893723, #903706) + * Use db_stop at the end of postinst (Closes: #858042) + * Add pt_BR translation (Closes: #903369) + * Update Vcs-* URLs to point to salsa + + -- Sebastien Delafond Wed, 12 Dec 2018 07:46:19 +0100 + nagvis (1:1.7.10+dfsg1-3.2) UNRELEASED; urgency=medium * Non-maintainer upload. diff --git a/debian/control b/debian/control index ea96db7a..3f07e28f 100644 --- a/debian/control +++ b/debian/control @@ -8,10 +8,10 @@ Uploaders: Markus Frosch , Build-Depends: debhelper (>= 7.0.50~), quilt, po-debconf -Standards-Version: 3.9.5 +Standards-Version: 4.2.1 Homepage: http://www.nagvis.org -Vcs-Git: git://anonscm.debian.org/pkg-nagios/pkg-nagvis.git -Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-nagios/pkg-nagvis.git;a=summary +Vcs-Git: https://salsa.debian.org/nagios-team/pkg-nagvis.git +Vcs-Browser: https://salsa.debian.org/nagios-team/pkg-nagvis Package: nagvis Architecture: all diff --git a/debian/copyright b/debian/copyright index 9a80d868..e5d43b49 100644 --- a/debian/copyright +++ b/debian/copyright @@ -1,6 +1,7 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: NagVis Source: http://sourceforge.net/projects/nagvis/files/ +Files-Excluded: uifx share/netmap/shell.html share/netmap/shell.swf share/netmap/modules/gmap Files: * Copyright: Copyright 2007-2013, Lars Michelsen diff --git a/debian/nagvis.links b/debian/nagvis.links index 2a2622e0..f00b2429 100644 --- a/debian/nagvis.links +++ b/debian/nagvis.links @@ -3,7 +3,7 @@ /usr/share/nagvis/docs /usr/share/nagvis/share/docs /etc/nagvis/usr/share/nagvis/etc /var/cache/nagvis /usr/share/nagvis/var -/usr/share/php/php-php-gettext /usr/share/nagvis/share/server/core/ext/php-gettext-1.0.9 +/usr/share/php/php-php-gettext /usr/share/nagvis/share/server/core/ext/php-gettext-1.0.12 /usr/share/nagvis/defaults/nagvis.ini.php-sample /usr/share/doc/nagvis/nagvis.ini.php-sample /usr/share/nagvis/defaults/apache2-nagvis.conf-sample /usr/share/doc/nagvis/apache2-nagvis.conf-sample etc/nagvis/apache2.conf etc/apache2/conf-available/nagvis.conf diff --git a/debian/nagvis.postinst b/debian/nagvis.postinst old mode 100644 new mode 100755 index 4220b70e..c5243614 --- a/debian/nagvis.postinst +++ b/debian/nagvis.postinst @@ -198,6 +198,8 @@ case "$1" in ;; esac +db_stop + # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. diff --git a/debian/patches/config.patch b/debian/patches/config.patch index e056f9f6..27cb63af 100644 --- a/debian/patches/config.patch +++ b/debian/patches/config.pat
Bug#893723: 893723
Control: tag -1 + upstream Control: forwarded -1 https://github.com/NagVis/nagvis/issues/79 This has apparently been closed in "recent releases", although upstream doesn't mention when that happened exactly. Scouring through git log, it appears to be in this commit: commit da8746985d21b517a66ec8795a672192e4551b49 Author: Lars Michelsen Date: Fri Apr 22 13:18:48 2016 +0200 FIX: Fixed some compatibility issues with PHP 7. NagVis should work with it. This would make 1.9b7 the first release containing the fix. Cheers, -- Seb
Bug#910228: NMU
Hi, I just uploaded ruby-gitlab 4.5.0-2 to DELAYED/10. Don't hesitate to cancel or reschedule it if you need to. Cheers, --Seb
Bug#888011: #888011
Python3 package, plus upstream bump to 0.3.7, available at: https://github.com/sdelafond/python-jenkinsapi Would you be willing to share or hand over maintenance of this package, ideally on salsa ? Cheers, -- Seb
Bug#910228: Renaming to /usr/bin/ruby-gitlab
https://salsa.debian.org/ruby-team/ruby-gitlab/merge_requests/1
Bug#912106: test_auth_aws_region
The test_auth_aws_region test tries to make an actual HTTP request, it should be disabled in debian/rules. Cheers, -- Seb
Bug#910228: /usr/bin/ruby-gitlab
I'm OK with ruby-gitlab shipping /usr/bin/ruby-gitlab and /usr/share/man/man1/ruby-gitlab.1.gz, so unless someone disagrees I will do that this week. Cheers, -- Seb
Bug#910088: python-pyperclip: please provide a backport of python-pyperclip
On Oct/02, Mattia Rizzolo wrote: > Could you please provide a stretch-backports of python-pyperclip? > > If you wish, I'm happy to build such backport myself. Yes, that will be fine: please do ! Cheers, --Seb
Bug#907495: 907495
Sure, shipping this as a separate binary package makes sense. A patch would be most welcome. Cheers, --Seb
Bug#725408: org-mode-doc_9.1.14-1_amd64.changes ACCEPTED into unstable
On Aug/23, Nicholas D Steeves wrote: > Is that wrong info page bug still valid? It just occured to me that > it should be possible to add a few lines to the elpa-org-mode that > rebinds infopath to put org-mode-doc ahead of emacs' built-in when > elpa-org-mode is loaded. > > If the non emacs bin/info is the issue, then there might be some kind > of dh hook that could be used. That bug was still valid last time I checked, yes: re-reading the bug history[0], the problem is indeed only with info(1), and emacs's own info mode seem to always do the right thing. I unfortunately don't have much time these days to try and investigate this some more... Cheers, --Seb [0] https://bugs.debian.org/725408
Bug#906976: mitmproxy: FTBFS in buster/sid
Control: retitle -1 FTBFS in buster Control: tags -1 - sid + buster thanks In sid it builds fine during the 1st run, as shown here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mitmproxy.html The 2nd reproducible run fails because of the "date in the future" thing: since the unit tests use a live example.mitmproxy.org host, there are certificate issues when simulating a 09/2019 date. However, your FTBFS in buster is not caused by that, as confirmed here: https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/mitmproxy.html Something in the dependencies must be causing this error; I'll look into it. Cheers, --Seb
Bug#906236: openssh: CVE-2018-15473: delay bailout for invalid authenticating user until after the packet
On Aug/21, Chris Lamb wrote: > a) You will take the lead on stable/DSA. > b) I'll carry on with LTS, etc. Yes. --Seb
Bug#906236: openssh: CVE-2018-15473: delay bailout for invalid authenticating user until after the packet
On Aug/19, Chris Lamb wrote: > Would the security team be interested in one for stretch? If so, I can > return with a proposed debdiff. Sorry, missed your email about this. I'm actually done with the patch on my end. Cheers, --Seb
Bug#865505: php-horde-image 2.3.6-1+deb9u1 (CVE-2017-9773, CVE-2017-9774 & CVE-2017-14650)
On Jun/23, Chris Lamb wrote: > I've prepared an upload to fix the following: > > php-horde-image (2.3.6-1+deb9u1) stretch-security; urgency=high > > * CVE-2017-9773: [...] > > * CVE-2017-9774: [...] > > * CVE-2017-14650: [...] > > The full debdiff is attached. Please let me know if it is okay to > upload. Hi Chris, it looks OK to me, please upload to security-master. Cheers, --Seb
Bug#903325: delayed/10
Hi, I have just uploaded blinker 1.4+dfsg1-0.2, fixing this FTBFS, to DELAYED/10. Don't hesitate to cancel or reschedule it if you need to. Cheers, --Seb
Bug#887332: 887332
On Jul/19, Bastien wrote: > > For reference, upstream change is: > > https://code.orgmode.org/bzg/org-mode/commit/b186d1d7236c0dc397eadeb004c9a17eaffd3aab > > I've received this email with no context -- can you tell me more about > this issue at stake? Hi Bastien, this was Debian bug #887332 : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887332 Cheers, --Seb
Bug#725408: org-mode 8 info does not show up in info index
On Jun/25, Nicholas D Steeves wrote: > I looked up this bug as soon as I remembered that I'd been neglecting > it for some time--thankfully I hadn't set myself as owner. Hi Nicholas, a quick test in unstable shows that: * with emacs25 installed but not emacs25-common-non-dfsg, both info(1) and info-mode from emacs find the org-mode-doc's version of the manual, as they should. * with emacs25-common-non-dfsg also installed, info(1) reverts back to only finding the manual for 8.2.9. > Does this bug still occur with unflavoured emacs from experimental? > https://packages.debian.org/experimental/emacs * with emacs-common-non-dfsg from experimental installed, and emacs25-common-non-dfsg not install, info(1) still unfortunately finds the manual for 8.2.9. Cheers, --Seb
Bug#894423: mlbviewer: No longer works starting in 2018
On Jun/25, Andreas Beckmann wrote: > On Fri, 30 Mar 2018 08:41:38 +0200 Sebastien Delafond > wrote: > > mlbviewer no longer works, starting in 2018[0]. A new implementation > > is in the works[1], with corresponding instructions[2]. It will be > > packaged later, but in the meantime I've filed #894422 to remove > > mlbviewer from unstable. > > Should the unusable package be removed from stable as well? Yes, it might as well be. Cheers, --Seb
Bug#902032: aptly: please provide an aptly-api service
On Jun/21, Alexandre Viau wrote: > I would like to add that I am willing to provide a patch that > implements this. That'd be most welcome ! > However, I would only start working on it after aptly is moved to > dh-golang to avoid merging issues. See bug #902038 for that. I've just merged your patch, and uploaded 1.3.0-2 with it. Thanks a lot for that :) Cheers, --Seb
Bug#901036: no rm
Actually, that won't be possible: dam rm shows libspring-java among other rdeps. We'll just stick with the EOL in debian-security-support. Cheers, --Seb
Bug#897613: RM: redmine/3.0~20140825-8~deb8u4
On May/03, Adam D. Barratt wrote: > There's a few r-deps. Walking the tree gives us: > > - redmine-plugin-pretend > - redmine-plugin-recaptcha > - redmine-recaptcha > > I assume the intent is that those also be removed. That is correct, sorry for not mentioning the r-deps initially. Cheers, --Seb
