Bug#976703: ITP: vendorcheck -- Check that all your Go dependencies are properly vendored
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: vendorcheck Version : 0.0~git20160511.d6d54d1-1 Upstream Author : Filippo Valsorda * URL : https://github.com/FiloSottile/vendorcheck * License : MIT Programming Lang: Go Description : Check that all your Go dependencies are properly vendored vendorcheck Check that all your Go dependencies are properly vendored . . $ vendorcheck ./... [!] dependency not vendored: golang.org/x/tools/go/buildutil [!] dependency not vendored: github.com/kisielk/gotool [!] dependency not vendored: golang.org/x/tools/go/loader [!] dependency not vendored: golang.org/x/tools/go/ast/astutil . . Run vendorcheck -u to list unused vendored packages instead.
Bug#976705: ITP: netopeer2 -- server for implementing network configuration management
Package: wnpp Severity: wishlist Owner: Ondřej Surý -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: netopeer2 Version : 1.1.39 Upstream Author : CESNET, z.s.p.o. * URL : https://github.com/CESNET/Netopeer2 * License : BSD-3-clause Programming Lang: C Description : server for implementing network configuration management Netopeer2 is a server for implementing network configuration management based on the NETCONF Protocol. This is the second generation, originally available as the Netopeer project. Netopeer2 is based on the new generation of the NETCONF and YANG libraries - libyang and libnetconf2. The Netopeer2 server uses sysrepo as a NETCONF datastore implementation. -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl/N7JBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcJ7ERAAiQAaOGr/pp0TRKzYTt7friTa/zqls48tdayn2C91m91DgaOQaA4I/rj5 Dtu3BZUkunz5jN8Nd33jOkXBqqArkLkPJzmCNoJRNbX6HHKktGJKjaHuWUeUju6W 9bnKw02HklgyYhTFs5PjcrhB4CtfeijbE0eQcC9RHSYG5ddqDmrNbeCB+kIOw69v jJtGlVPvSWfC3WCtx7zANY7LDAgt293gjechG/Q/EfrO8yeOwdOxdwgySGP+r/kp wYC8lsIT/0dA2+CH761r/5WsL6KqGad4D6gY1RMJtlcrQ2q49CL4M3n2M5XOTB8B i9tcJRYI5FRcpiIc1ECQM4Ti8NBRBmQkzVy6hSuY73e+M3/Dp6ALgspUY/5Oeymm XuUr5RqecaerrfZRZvAAIZQD3V2qohAAf4hH74FYPRiFiRWjmqurhM6jMstsleIq RpuKtz0qs0LhIyWcpDobVHMVTCHYz0ebxZLiAm1iyqWPVyDUxLhj8WCZnNSB5WdB VuqhtoNfYwQaLacud4jws3vP9BDZiqBMMxwhU/GJ2bKfVZk+YMP1c9pXEAsbsIDS uVZTrY96V0J4YdRWKlxIE5M8LN0NhViplJdmAlaVRLdjTPlkj2QktBktXv74EZur azphX8U6hGn9Ogbj7+lwifNgjdh9++CNBCecpYr+18+1VH2zEiU= =48kQ -END PGP SIGNATURE-
Re: dpkg-source reproducibility
On Mon, 07 Dec 2020 at 08:41:40 +0100, Christoph Biedl wrote: > over all the years I had assumed the -x and -b operations of dpkg-source > are inverse, and the other way around as well. In other words, I > expected to rely on the following: > > Running "dpkg-source -x" on a .dsc, and then "dpkg-source -b" on > the unpacked tree re-creates the initial .dsc file. That would be impossible to guarantee, because it's affected by the options you pass to dpkg-source -b (most likely via dpkg-buildpackage or debuild, for example DEBUILD_DPKG_BUILDPACKAGE_OPTS in ~/.devscripts). > Now I came across a (native) package that fails that rule - after > running "dpkg-source -b", the top-level .gitignore file was missing. Are you using `debuild -i` or similar? That ignores .gitignore, .gitattributes and so on, not just .git/, which is not always desired. smcv
Bug#976714: ITP: age -- A simple, modern and secure encryption tool
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: age Version : 1.0.0~beta5 Upstream Author : Filippo Valsorda * URL : https://age-encryption.org/ * License : BSD-3 Programming Lang: Go Description : A simple, modern and secure encryption tool age is a simple, modern and secure file encryption tool, format, and library. It features small explicit keys, no config options, and UNIX-style composability. The format specification is at age-encryption.org/v1. An alternative interoperable Rust implementation is available at github.com/str4d/rage. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl/N/3cRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MtIDg//WkxoFSfKmtdt/puMwc9FOWaUL32GLJ7G ILTfT43/i/OxUZCXsTarY1DH4qmO+EdVAD1yFcjfLOnux0w8vbxWj18jbBoMpCIQ wRX5woI7afs4zswK5IlyKxw+xUlPJSfDWPy/PMjPQKJD2MsDRjgptKs9zO+YumYZ 1k2iGUrXzsMeE7s1Oq6+WzdlV4rUyigCOvNM8DnW5rmqTKd0tBB9pLk6XAqsckbS 4Vq6lSUE07HvHnscTJyhb/zFVB++1XKa0U0I/1lnJK46ZFPDtPzMA5gQAZ4zg+WH 8rWe54w0KJQmG5jE7ViFWfYoziADzXlbbbkypWSXe04b2fkIf8ylVJaktrM1uF5+ 5U7B5eKfkq/sPDzb9WB90O1jEwkmzaItR2RbxyLKrqW3W1F4rC0aeMsbRxcbKKyB GotPNyFaUy1YyHM0Cc/573s2qNu627qWKXLuVekf/BjZQdTwVNxwSFRqkmMtTBxY lgwtQgJJqJL2pLlJ+iRVXnbLbgt7x9MZ22bBp7p1cVSXcIIy5j0CG18DVvNBPU1W /rznmkdwf5qIbCKlempHgjR6gDbEICtqleqcE/EaCMPdmvsEZGQD0WkKeWpUY7Ak 5VbMPh0UkV4+AOW4a/lsMPFICODiNxyDfa7RAkm6hR+7CFw0SIW2F1fRWu4bFrne H643Jkpi6IA= =3Cif -END PGP SIGNATURE-
Re: Porter roll call for Debian Bullseye
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote: > On 12/1/20 5:02 AM, YunQiang Su wrote: > > I am sorry for the later response. > >Hi, > > > > I am an active porter for the following architectures and I intend > > to continue this for the lifetime of the Bullseye release (est. end > > of 2024): > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in > testing ... The main blocker for that seems to be a bug that was fixed in gcc-10 10.2.0-20, a new source upload with the gcc-10-source build dependency bumped to (>= 10.2.0-20~) should fix that. binNMU won't work due to binary-all. > > - triage arch-specific bugs > > - fix arch-related bugs > > any help with #972269 ? I looked into it back then, at least for me there was nothing obvious why dbus-python failed and not other packages. A few months earlier one other package had a similar problem, but it seems rare enough that it shouldn't be a high priority for anyone. cu Adrian
Re: pcre2 10.35 (now 10.36) uploaded to experimental
Matthew Vernon writes: > I've uploaded 10.35-1 of pcre2 to experimental; I'll upload -2 to > unstable next weekend if there aren't any show-stoppers in the mean > time. > > We may yet see 10.36 out in time for it to get into bullseye (upstream > have an RC), but I wanted 10.35 in in case that doesn't work out. ...and now 10.36-1 is in experimental. Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Intel SOF audio firmware packaging
Hi Debian, I'd like to solve the lack of Intel SOF audio firmware & topology files being available on Debian - I know it's impacting a lot of users on some of the newer Thinkpads. I figured I should have a stab at this exercise myself and see what happens. I did a bit of reading this weekend, and started the process. Having created appropriate files under a debian sub-dir, and messed around a bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of the sof-bin git repo I end up with a .deb file that I can install and makes audio work. Feels like progress :) There are plenty of warnings along the way, and it's my first time doing this so I'm sure I'm doing all sorts of things wrong (there seems like a lot of different options on how to do this); but I figured I have a good starting point. I wasn't sure where to go with this next. Is there anybody in the Debian community with the expertise to spend a bit of time guiding me through the next steps? I think I need someone who can review what I have done and point out where it needs fixing/improving. Once it's good enough then I think I need someone to help me actually get it uploaded and into Debian. There is a bug already available (https://bugs.debian.org/960788) if that helps. Obviously happy to share all the work I've done in an appropriate format if that helps too. Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or a DD - so someone with patience for dumbass questions would be a bonus. Thanks in advance Mark
Re: Intel SOF audio firmware packaging
❦ 7 décembre 2020 08:57 -05, Mark Pearson: > I'd like to solve the lack of Intel SOF audio firmware & topology > files being available on Debian - I know it's impacting a lot of users > on some of the newer Thinkpads. I figured I should have a stab at this > exercise myself and see what happens. > > I did a bit of reading this weekend, and started the process. Having > created appropriate files under a debian sub-dir, and messed around a > bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of > the sof-bin git repo I end up with a .deb file that I can install and > makes audio work. Feels like progress :) > > There are plenty of warnings along the way, and it's my first time > doing this so I'm sure I'm doing all sorts of things wrong (there > seems like a lot of different options on how to do this); but I > figured I have a good starting point. I wasn't sure where to go with > this next. > > Is there anybody in the Debian community with the expertise to spend a > bit of time guiding me through the next steps? I think I need someone > who can review what I have done and point out where it needs > fixing/improving. Once it's good enough then I think I need someone to > help me actually get it uploaded and into Debian. There is a bug > already available (https://bugs.debian.org/960788) if that helps. > Obviously happy to share all the work I've done in an appropriate > format if that helps too. > > Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or > a DD - so someone with patience for dumbass questions would be a > bonus. Hello Mark, I can help you, using the easy way: shipping binary firmwares as non-free. I don't think this is worth the effort trying to compile from source while it is not possible to use the compiled firmwares. You can either use salsa.debian.org or mentors.debian.net to expose your current work. Tell me if it means something for you or if I need to explain. -- Avoid temporary variables. - The Elements of Programming Style (Kernighan & Plauger)
Re: Intel SOF audio firmware packaging
Hi Mark On 2020/12/07 15:57, Mark Pearson wrote: > I did a bit of reading this weekend, and started the process. Having > created appropriate files under a debian sub-dir, and messed around a > bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of > the sof-bin git repo I end up with a .deb file that I can install and > makes audio work. Feels like progress :) That sounds like great progress! > There are plenty of warnings along the way, and it's my first time doing > this so I'm sure I'm doing all sorts of things wrong (there seems like a > lot of different options on how to do this); but I figured I have a good > starting point. I wasn't sure where to go with this next. Push it to a git repository and/or mentors.debian.net and send a link, I'd be happy to also take a look and give some pointers. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Jonathan, On 07/12/2020 10:15, Jonathan Carter wrote: Hi Mark On 2020/12/07 15:57, Mark Pearson wrote: I did a bit of reading this weekend, and started the process. Having created appropriate files under a debian sub-dir, and messed around a bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of the sof-bin git repo I end up with a .deb file that I can install and makes audio work. Feels like progress :) That sounds like great progress! There are plenty of warnings along the way, and it's my first time doing this so I'm sure I'm doing all sorts of things wrong (there seems like a lot of different options on how to do this); but I figured I have a good starting point. I wasn't sure where to go with this next. Push it to a git repository and/or mentors.debian.net and send a link, I'd be happy to also take a look and give some pointers. -Jonathan I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging It's pretty basic :) Thanks Mark
Re: [External] Re: Intel SOF audio firmware packaging
On 2020/12/07 18:07, Mark Pearson wrote: > I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging > > It's pretty basic :) Seems like you haven't committed go.sh? (and hopefully more files?) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Intel SOF audio firmware packaging
On 07/12/2020 11:13, Jonathan Carter wrote: On 2020/12/07 18:07, Mark Pearson wrote: I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging It's pretty basic :) Seems like you haven't committed go.sh? (and hopefully more files?) -Jonathan They're all in the upstream sof-bin repository In theory (ha!) if you try the steps in the Readme it should give you a .deb Should I be making a copy of the upstream sof-bin repository? The file I've uploaded go on top of that. Mark
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Vincent, On 07/12/2020 09:03, Vincent Bernat wrote: ❦ 7 décembre 2020 08:57 -05, Mark Pearson: I'd like to solve the lack of Intel SOF audio firmware & topology files being available on Debian - I know it's impacting a lot of users on some of the newer Thinkpads. I figured I should have a stab at this exercise myself and see what happens. I did a bit of reading this weekend, and started the process. Having created appropriate files under a debian sub-dir, and messed around a bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of the sof-bin git repo I end up with a .deb file that I can install and makes audio work. Feels like progress :) There are plenty of warnings along the way, and it's my first time doing this so I'm sure I'm doing all sorts of things wrong (there seems like a lot of different options on how to do this); but I figured I have a good starting point. I wasn't sure where to go with this next. Is there anybody in the Debian community with the expertise to spend a bit of time guiding me through the next steps? I think I need someone who can review what I have done and point out where it needs fixing/improving. Once it's good enough then I think I need someone to help me actually get it uploaded and into Debian. There is a bug already available (https://bugs.debian.org/960788) if that helps. Obviously happy to share all the work I've done in an appropriate format if that helps too. Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or a DD - so someone with patience for dumbass questions would be a bonus. Hello Mark, I can help you, using the easy way: shipping binary firmwares as non-free. I don't think this is worth the effort trying to compile from source while it is not possible to use the compiled firmwares. I agree - I went the non-free route as my understanding is from a practical point of view, that's what makes sense to use the firmware on most PCs. At least it does on Lenovo's. I figure for people who need/want to use non intel signed firmware they probably have their own hardware and know more about SOF firmware than me. I'm not really sure what other vendors do but I know in Lenovo's case the signed firmware is a requirement that I can't change. You can either use salsa.debian.org or mentors.debian.net to expose your current work. Tell me if it means something for you or if I need to explain. I replied to Jonathan's email, so at the risk of having two threads, I did just upload what I have here: https://salsa.debian.org/mpearson/sof-bin-packaging Let me know if that doesn't work as a starting point, very happy to change it for whatever works best for Debian folk. Thanks Mark
Bug#976727: ITP: libpdb-redo -- Library containing shared code for the various programs in project PDB-REDO
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libpdb-redo Version : 1.0.0 Upstream Author : Maarten L. Hekkelman * URL : https://github.com/PDB-REDO/libpdb-redo * License : BSD-2-Clause Programming Lang: C++ Description : Library containing shared code for the various programs in project PDB-REDO For the PDB-REDO project, a lot of programs have been created over time. Many of these application share common routines and these are combined in this particular library. The PDB-REDO tools that are of general interest will follow as separate Debian packages. About PDB-REDO: PDB-REDO is a procedure to optimise crystallographic structure models, providing algorithms that make a fully automated decision making system for refinement, rebuilding and validation. It combines popular crystallographic software from CCP4, e.g. REFMAC and COOT, with with our specially developed rebuilding tools Centrifuge, Pepflip & SideAide and structure analysis tools like WHAT IF and PDB-care. PDB-REDO optimises refinement settings (e.g. geometric and B-factor restraint weights, B-factor model, TLS groups, NCS and homology restraints), refines with REFMAC, partially rebuilds the structure (rejects waters, refines side chains, checks peptide planes), refines some more, and then validates the results. With PDB-REDO you can obtain updated and optimised versions of existing entries of the PDB from our DataBank, or you can optimise your own structure model using our Server. If you want to know more or install PDB-REDO on your own computers, please check below.
Re: Intel SOF audio firmware packaging
On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > I'd like to solve the lack of Intel SOF audio firmware IIRC the Debian kernel team were planning on adding those to the linux-firmware.git packaging. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Paul, On 07/12/2020 21:19, Paul Wise wrote: > On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > >> I'd like to solve the lack of Intel SOF audio firmware > > IIRC the Debian kernel team were planning on adding those to the > linux-firmware.git packaging. > If that is happening that sounds good to me and quite sensible. Can you point me at who is working on that so I can find out the details? I did do a search before starting on this but didn't find anything - but it would be an easy thing to miss :) Happy to help out, even if just as a test guinea-pig. Mark
Bug#976804: ITP: golang-sslmate-go-pkcs12 -- Go library for encoding and decoding PKCS#12 files
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-sslmate-go-pkcs12 Version : 0.0~git20201103.57fc603 Upstream Author : SSLMate * URL : https://software.sslmate.com/src/go-pkcs12/ * License : BSD-3-Clause Programming Lang: Go Description : Go library for encoding and decoding PKCS#12 files Package pkcs12 implements some of PKCS#12 (also known as P12 or PFX). It is intended for decoding DER-encoded P12/PFX files for use with the crypto/tls package, and for encoding P12/PFX files for use by legacy applications which do not support newer formats. Since PKCS#12 uses weak encryption primitives, it SHOULD NOT be used for new applications. There is a package named golang-github-azure-go-pkcs12-dev in the repository, but the upstream of this package was merged into the Go x/crypto repository. And in https://pkg.go.dev/golang.org/x/crypto/pkcs12, it says this package is frozen. If it's missing functionality you need, consider an alternative like software.sslmate.com/src/go-pkcs12
Bug#976805: ITP: imhex -- Hex Editor for Reverse Engineers
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: imhex Version : 1.5.0 * URL : https://github.com/WerWolv/ImHex * License : GPL-2.0 Programming Lang: C++ Description : Hex Editor for Reverse Engineers This will be maintained under security-tools team. (applying salsa access shortly)
