Re: Help with a watchfile for MUT
Andrius, I am very much not a uscan expert, but the attached watch file appears to do what you want. Key changes are: 1. Adding a dversionmangle line to each entry that modifies the Debian version number to extract the information that should be used for each upstream tarball. Your case is a little interesting because one of the tarballs has a different numbering scheme. 2. Change the version entries to remove `group` and use `ignore` on the last entry. 3. Add `uupdate` as the script at the end of the file. There are probably many other ways you could accomplish this. Soren PS. I find the following as a good way to test: uscan -vv --download-current-version For best results, delete all previously downloaded tarballs prior to running the command. -vv generally provides the right about of debugging verbosity. On Thursday, May 2, 2024 2:58:39 AM MST Andrius Merkys wrote: > Hello, > > I am writing a watchfile for vst3sdk, you can find it on salsa [1]. I > cannot get 'same' components downloaded, 'uscan > --download-current-version' fails with the following: > > uscan warn: In debian/watch no matching hrefs for version in watch line >https://github.com/steinbergmedia/vst3_base/tags > (?:.*?/)?v([0-9\.]+_build_\d+)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz| tar\.zstd?| > zip|tgz|tbz|txz)) same > > It is strange that uscan does not seem to know the version to download > (notice the empty space after 'no matching hrefs for version' in the > error message). > > I would appreciate any help with this. > > [1] https://salsa.debian.org/merkys/vst3sdk/-/raw/master/debian/watch > > Best, > Andrius -- Soren Stoutner so...@debian.orgversion=4 opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%, uversionmangle=s/_build_/\./, dversionmangle=s/\+.*//" \ https://github.com/steinbergmedia/vst3sdk/tags \ (?:.*?/)?v([0-9\.]+_build_\d+)@ARCHIVE_EXT@ opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-base-$1$2%, uversionmangle=s/_build_/\./, dversionmangle=s/\+.*//, component=base" \ https://github.com/steinbergmedia/vst3_base/tags \ (?:.*?/)?v([0-9\.]+_build_\d+)@ARCHIVE_EXT@ same opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-cmake-$1$2%, uversionmangle=s/_build_/\./, dversionmangle=s/\+.*//, component=cmake" \ https://github.com/steinbergmedia/vst3_cmake/tags \ (?:.*?/)?v([0-9\.]+_build_\d+)@ARCHIVE_EXT@ same ## doc/ contains a lot of files diagnosed as source-is-missing by lintian # opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-doc-$1$2%, dversionmangle=s/\+.*//, component=doc" \ # https://github.com/steinbergmedia/vst3_doc/tags \ # (?:.*?/)?v?@ANY_VERSION@_build_\d+@ARCHIVE_EXT@ same opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-pluginterfaces-$1$2%, uversionmangle=s/_build_/\./, dversionmangle=s/\+.*//, component=pluginterfaces" \ https://github.com/steinbergmedia/vst3_pluginterfaces/tags \ (?:.*?/)?v([0-9\.]+_build_\d+)@ARCHIVE_EXT@ same opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@pack...@-public.sdk-$1$2%, uversionmangle=s/_build_/\./, dversionmangle=s/\+.*//, component=public.sdk" \ https://github.com/steinbergmedia/vst3_public_sdk/tags \ (?:.*?/)?v([0-9\.]+_build_\d+)@ARCHIVE_EXT@ same # opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-tutorials-$1$2%, dversionmangle=s/\+.*//, component=tutorials" \ # https://github.com/steinbergmedia/vst3_tutorials/tags \ # (?:.*?/)?v?@ANY_VERSION@_build_\d+@ARCHIVE_EXT@ same opts="filenamemangle=s%v@ANY_VERSION@_build_\d+(@ARCHIVE_EXT@)%@PACKAGE@-vstgui4-$1$2%, dversionmangle=s/.*~//, uversionmangle=s/_/\./g, component=vstgui4" \ https://github.com/steinbergmedia/vstgui/tags \ (?:.*?/)?vstgui(4_\d+_\d+)@ARCHIVE_EXT@ ignore uupdate signature.asc Description: This is a digitally signed message part.
Re: Contributing to Debian - How to get started?
Welcome to Debian! There are a lot of different ways someone can get started contributing to Debian. Some of them are described at: https://mentors.debian.net/intro-maintainers/[1] I would recommend reading over the resources on that page. If you have any questions as you go, this mailing list is the perfect place to ask them. Soren On Tuesday, April 30, 2024 2:08:42 PM MST Dimitrios Antoniou wrote: > Hi, > > I have a background in software engineering, albeit limited experience with > C, C++ and Python. I'm looking to join the Debian community and start > contributing to the project. I was hoping to get some guidance as to what > the starting steps would be to someone with my background. Any help is > appreciated. > > Thank you in advance. -- Soren Stoutner so...@debian.org [1] https://mentors.debian.net/intro-maintainers/ signature.asc Description: This is a digitally signed message part.
Re: Uscan no longer works with GitLab tags
On Wednesday, April 3, 2024 5:00:03 AM MST Soren Stoutner wrote: > That is indeed complex as the tarball is only available as an upload the > developer has manually added to GitLab and not as one of the standard release > tarballs generated by GitLab. > > If GitLab weren’t being a punk and would present the same HTML a browser gets > to uscan (or wget) when pulling up: > > https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/releases[1] > > it would be easy. But GitLab is presenting what amounts to a login screen to > uscan instead. I submitted a request to GitLab to correct this buggy behavior. https://gitlab.com/gitlab-org/gitlab/-/issues/454301[1] -- Soren Stoutner so...@debian.org [1] https://gitlab.com/gitlab-org/gitlab/-/issues/454301 signature.asc Description: This is a digitally signed message part.
Re: Uscan no longer works with GitLab tags
On Wednesday, April 3, 2024 1:00:28 AM MST Mike Gabriel wrote: > The appmenu-gtk-module code is a subfolder in upstream > vala-panel-appmenu (subprojects/appmenu-gtk-module) and that subfolder > was packaged as a separate src:pkg in Debian at the time when it got > introduced. > > For this the upstream maintainer provides appmenu-gtk-module as a > separate tarball for download at [1]. > > So the watch file should achieve downloading this exact tarball, i.e. > https://gitlab.com/vala-panel-project/vala-panel-appmenu/uploads/6c0332e34c41e > 99de5a1db1fc4239de2/appmenu-gtk-module-24.02.tar.xz > > Only chew on this if you really want to nut-crack it. I have burnt > quite a few brain cells on it yesterday and failed (which does not > mean you will also, but be warned, the solution does not seem trivial, > however, maybe it is). That is indeed complex as the tarball is only available as an upload the developer has manually added to GitLab and not as one of the standard release tarballs generated by GitLab. If GitLab weren’t being a punk and would present the same HTML a browser gets to uscan (or wget) when pulling up: https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/releases[1] it would be easy. But GitLab is presenting what amounts to a login screen to uscan instead. You might be able to resolve the situation by switching to using Git to download a tag and then producing a tarball locally from that, but I don’t know how to have uscan produce a tarball from just a subdirectory in Git. Perhaps one of the people who are currently advocating using git instead of pre-packaged tarballs on devian-devel would have an idea of how to do that. -- Soren Stoutner so...@debian.org [1] https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/releases signature.asc Description: This is a digitally signed message part.
Re: Uscan no longer works with GitLab tags
Mike, On Tuesday, April 2, 2024 8:22:26 AM MST Mike Gabriel wrote: > https://salsa.debian.org/debian-ayatana-team/appmenu-gtk-module/-/blob/ master/ > debian/watch > > ``` > version=3 > https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/tags/?([\d\.]+) > .*/uploads/.*/appmenu-gtk-module-?([\d\.]+)\.tar\.xz > ``` > > The above used to successfully download the appmenu-gtk-module tarball > from the vala-panel-appmenu releases page: > https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/releases Try the attached watch file. -- Soren Stoutner so...@debian.orgversion=4 opts="searchmode=plain" \ https://gitlab.com/vala-panel-project/vala-panel-appmenu/tags?sort=updated_desc -/archive/v?\d[\d.]+/vala-panel-appmenu-@any_vers...@.tar.gz signature.asc Description: This is a digitally signed message part.
Re: Uscan no longer works with GitLab tags
https://wiki.debian.org/debian/watch#Gitlab[1]
"From 2024/03 above solution do not work anymore since Gitlab changed their tag
ordering. You can use direct API access:”
version=4
opts=\
searchmode=plain,\
https://gitlab.com/api/v4/projects/PROJECTID/releases
archive/v?\d[\d.]+//-v?
([\d.]+)@ARCHIVE_EXT@
Looks like you aren’t the only one with this problem. ;)
On Tuesday, March 26, 2024 1:05:10 PM MST Sergio Durigan Junior wrote:
> On Monday, March 25 2024, Shriram Ravindranathan wrote:
> > Dear Mentors,
> >
> > I noticed from the past couple of days, uscan seems to be having trouble
> > finding files from the gitlab tags page.
> >
> > ```
> > $ uscan
> > uscan warn: In debian/watch no matching files for watch line
> >
> > https://gitlab.com/saalen/highlight/tags?sort=updated_desc
> > .*/archive/(\d\S+)/.*\.tar\.gz.*>
> > ```
> >
> > Checking the same pattern with grep shows that it does find a match
> >
> > ```
> > $ curl -L "https://gitlab.com/saalen/highlight/tags?sort=updated_desc; |
> > grep -E ".*/archive/([0-9]\S+)/.*\.tar\.gz.*">
> > % Total% Received % Xferd Average Speed TimeTime Time
> > Current
> >
> > Dload Upload Total SpentLeft
> > Speed
> >
> > 100 126 100 1260 0287 0 --:--:-- --:--:-- --:--:--
> > 287>
> > 0 00 00 0 0 0 --:--:-- 0:00:01 --:--:--
> > 0 > data-download-artifacts="[]"
> > data-download-links="[{text:zip,path:
> > /saalen/highlight/-/archive/4.11/highlight-4.11.zip},{te
> > xt:tar.gz,path:/saalen/highlight/-/arc
> > hive/4.11/highlight-4.11.tar.gz},{text:tar.bz2
> > t;,path:/saalen/highlight/-/archive/4.11/highlight-4.11.
> > tar.bz2},{text:tar,path:/s
> > aalen/highlight/-/archive/4.11/highlight-4.11.tar}]">>
> > 100 85448 100 854480 0 51822 0 0:00:01 0:00:01 --:--:--
> > 401k ```
> >
> > It seems like a few other packages are also having similar troubles with
> > uscan, for example lomiri
> >
> > Is there a way to fix this?
>
signature.asc
Description: This is a digitally signed message part.
Re: Uscan no longer works with GitLab tags
Shriram,
I am neither a uscan nor a regex expert, but when I was trying to troubleshoot
problems with uscan for the upcoming fonts-adobe-sanssource3 package I found
`uscan -vv` to be very helpful as it displays on the screen how it is
attempting to process the page it is scraping.
On Sunday, March 24, 2024 11:27:19 PM MST Shriram Ravindranathan wrote:
> Dear Mentors,
>
> I noticed from the past couple of days, uscan seems to be having trouble
> finding files from the gitlab tags page.
> ```
> $ uscan
> uscan warn: In debian/watch no matching files for watch line
>https://gitlab.com/saalen/highlight/tags?sort=updated_desc
> .*/archive/(\d\S+)/.*\.tar\.gz.*
```
>
> Checking the same pattern with grep shows that it does find a match
>
> ```
> $ curl -L "https://gitlab.com/saalen/highlight/tags?sort=updated_desc; |
grep
> -E ".*/archive/([0-9]\S+)/.*\.tar\.gz.*"
% Total% Received % Xferd
> Average Speed TimeTime Time Current Dload Upload Total Spent
> Left Speed 100 126 100 1260 0287 0 --:--:--
--:--:--
> --:--:-- 287 0 00 00 0 0 0 --:--:-- 0:00:01
> --:--:-- 0 data-download-artifacts="[]"
> data-download-
links="[{text:zip,path:
> t;/saalen/highlight/-/archive/4.11/highlight-4.11.zip},
{text
> :tar.gz,path:/saalen/highlight/-/archive/4.11/
hi
> ghlight-4.11.tar.gz},
{text:tar.bz2,path
> ot;:/saalen/highlight/-/archive/4.11/highlight-4.11.tar.bz2},
{
> t;text:tar,path:/saalen/highlight/-/
archiv
> e/4.11/highlight-4.11.tar}]"> 100 85448 100 854480 0
> 51822 0 0:00:01 0:00:01 --:--:-- 401k ```
>
> It seems like a few other packages are also having similar troubles with
> uscan, for example lomiri <https://tracker.debian.org/pkg/lomiri>
> Is there a way to fix this?
>
> Regards,
>
> --
> Shriram Ravindranathan
>
--
Soren Stoutner
so...@debian.org
signature.asc
Description: This is a digitally signed message part.
Re: Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C
On Monday, March 18, 2024 2:21:16 PM MST itd wrote: > > - d/watch / this dsc > > > > uscan download this: > > c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1 > > batsignal_1.8.0.orig.tar.gz> > > your dsc contains: > > d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b > > batsignal_1.8.0.orig.tar.xz> > > when constructing your dsc, please make sure to use the same file as > > uscan would produce. (I've verified that the content of both orig files is > > identical) > Ouch, sorry about that. If I understand diffoscope correctly it's > indeed only the timestamps that differ. d/watch's version uses the date > of the upstream repo's 1.8.0 tag. My version, created via gbp, uses the > date of my repo's upstream/1.8.0 tag. I'll try to figure out how to > solve this. Without knowing for certain, I would suspect that the problem is that gbp is repacking your orig.tar as an .xz (the upstream is .gz). That is fine if a repack is intended, but in that case the file name should be something more like batsignal_1.8.0+dfsg.orig.tar.xz or batsignal_1.8.0+ds.orig.tar.xz. If you do intend to repackage the upstream tarball you should indicate it in the package version (+dfsg for upstream tarballs that need non-free components removed and +ds for tarballs that have things removed for reasons like size). https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds. 2BIB0_in_the_version_string_mean.3F[1] If you don’t intend to repackage the upstream tarball you probably need to modify your configuration to not do so. -- Soren Stoutner so...@debian.org [1] https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F signature.asc Description: This is a digitally signed message part.
Re: Moving my packages to the debian namespace on salsa?
Sven, I would be happy to move them for you. Just grant me full access to each project. My Salsa name is soren. On Sunday, March 17, 2024 11:38:38 AM MST Sven Wick wrote: > Hi, > > I was reading the discussion [1]"Question about the debian group on Salsa" > because I wondered that myself for some time. > Actually since my package [2]ssh-tools was moved into the debian namespace a > while ago. > > I have no issue if my [3]other packages are moved there as well > if that is considered best practice. > > What do I have to do for moving my packages into the debian namespace? > > [1] https://lists.debian.org/debian-mentors/2024/03/msg00021.html > [2] https://salsa.debian.org/debian/ssh-tools > [3] https://salsa.debian.org/users/swick/projects -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation
Use the wnpp bug number in the Changelog file. The other bug will close automatically when the package is sponsored. On Monday, March 18, 2024 5:57:41 AM MST Dr. Burkard Lutz wrote: > Hi Bastian, > > thanks for your advices. As you suggested, I created a bug report > against wnpp. But now I have to Bug numbers: > #1066033 (sponsorship-requests) > #1067096 (wnpp) > Which one should I use in the Changelog file? > > Regards, > Burkard > > Am Samstag, dem 16.03.2024 um 11:06 +0100 schrieb Bastian Germann: > > On Mon, 11 Mar 2024 14:20:25 +0100 "Dr. Burkard Lutz" > > > > wrote: > > > Changes for the initial release: > > > > > > galvani (0.34-1) unstable; urgency=medium > > > . > > >* Initial release. > > > > You are not referring to any ITP. Please file one on the wnpp pseudo > > package. > > > > > My /debian/rules contains: > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > > > Nevertheless I always get the lintian error "hardening-no-fortify- > > > functions" > > > How can I fix that? > > > > By making sure that LDFLAGS, CPPFLAGS and CFLAGS set by dpkg are used > > in to your build. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, Thank you for your work on this package. It is quite impressive and I am happy to sponsor it. As this source package now contains new binary packages, I have done a source upload to the NEW queue. Soren On Thursday, March 7, 2024 12:19:47 PM MST Mateusz Łukasik wrote: > Hi Soren, > > Sorry for delay. I converted the sources into separate libraries in new > mentors upload. The soname will change every new version. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, Did you have any questions about what I was asking here? Soren On Tuesday, February 20, 2024 2:40:04 PM MST Soren Stoutner wrote: > Mateusz, > > When compiling locally on my system, the current version of lintian (2.117.0) > found the following problems. These are not displayed on mentors.debian.net, > leading me to believe they were recently added checks. > > W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/ > libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so] > N: > N: Although this package is not a "-dev" package, it installs a > N: "libsomething.so" symbolic link referencing the corresponding shared > N: library. When the link doesn't include the version number, it is used by > N: the linker when other programs are built against this shared library. > N: > N: Shared libraries are supposed to place such symbolic links in their > N: respective "-dev" packages, so it is a bug to include it with the main > N: library package. > N: > N: However, if this is a small package which includes the runtime and the > N: development libraries, this is not a bug. In the latter case, please > N: override this warning. > N: > N: Please refer to Development files (Section 8.4) in the Debian Policy > N: Manual for details. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: libraries/shared/links > N: Renamed from: non-dev-pkg-with-shlib-symlink > N: > N: > W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8 > N: > N: The package name of a library package should usually reflect the soname > of N: the included library. The package name can determined from the > library N: file name with the following code snippet: > N: > N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/ > ^[[:space:]]*SONAME[[:space:]]*//p' | \ > N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/ \L&/' > N: > N: Visibility: warning > N: Show-Always: no > N: Check: libraries/shared/soname > N: > N: > I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct- common.so. > 1.8 > N: > N: Although the package includes a shared library, the package does not have > N: a symbols control file. > N: > N: dpkg can use symbols files in order to generate more accurate library > N: dependencies for applications, based on the symbols from the library that > N: are actually used by the application. > N: > N: Please refer to the dpkg-gensymbols(1) manual page and > N: https://wiki.debian.org/UsingSymbolsFiles for details. > N: > N: Visibility: info > N: Show-Always: no > N: Check: debian/shlibs > > As noted in the text of the checks, there are scenarios where these do not > apply (like small packages that include the runtime and the development > files), which appears to be the case with qt5ct. Can you please help me to > understand why qt5ct is including this shared library, if there are any other > packages in Debian that are building against this library, and if you feel > that any of the lintian checks above apply? If you feel they don’t apply I > would recommend you add lintian overrides and I will be happy to upload your > package. > > Soren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: FWD: Copyright in LGPL projects
Wookey, On Tuesday, March 5, 2024 2:51:10 AM MST Wookey wrote: > On 2024-03-04 11:19 -0700, Soren Stoutner wrote: > > Alan, > > > > These are good questions. > > > > 1. Yes, there must be a copyright statement. Only the person, people, > > group, or organization that holds the copyright can issue a license for > > other people to use the work. So, you must have someone claiming a > > copyright or they do not have the legal ability to release the work to > > others under the LGPL. > But what requires that to be in the source tarball? Copyright is > intrinsic in the authors, it doesn't require a statement to create > it. Said authors _do_ need to specify a licence (and the LGPL requires > that licence text to be shipped in the source (I think, although I > could only actually find this requirement for a 'Combined work' and in > the FAQ just now)). > > _Debian_ requires a copyright statement (in the copyright file) so we > do need to find out from the project what to put, and a statement in > the source would be a good way to communicate that, but a notice on > the project website or even an email from a representative would also > do the job. That is correct. There must be a copyright statement or the license information is not legally valid (because only someone who claims copyright can issue a license). However, it doesn’t expressly need to be in the tarball (see below). That part is simply best practice, because it maintain the copyright information if the project is forked or upstream disappears, which otherwise can be difficult to determine if it was only on a website that is now defunct or in an email sent to a Debian developer who is no longer participating in the project. So, there is a distinction between what is the minimum legal requirement and what is best practice. > > My recommendation would be that you communicate to the upstream project that > > they need to include the copyright and licensing information in the root of > > their repository, preferably all in one file, as a minimum requirement for > > you to be willing to package their project in Debian. > > I don't think this is correct. And we should be happy to package > anything which is actually free software. We don't get to impose extra > requirements before we will package something. As pointed out above, there is a distinction between what is the minimum requirement for packaging in Debian and best practice. I carefully worded point 2 in my original email to state that, if **I** were packaging this software, I would communicate with upstream that if they wanted **me** to package their software in Debian, my minimum requirement would be that they explicitly state the copyright information in the source code. Originally I had a point 3, which I deleted before sending the email, explaining that my personal preference for when I would be willing to package software is higher than Debian’s requirement, and that a website notation or email communication of copyright has been used in some packages in the past, but with the downside described above. I took out point 3 because I felt it muddied the waters, but since the point has been brought up, it is worth discussing. > They should put a copy of the LGPL in (in a file called 'COPYING' or > 'LICENCE' by convention) (if this isn't done already). A copyright > notice for the project should _not_ go in the same file (The LGPL > already has one for the LGPL authorship itself, so this is probably > the only file in the distribution which should definitiely _not_ have > the project copyright notice). It should ideally be a header on at least > one source file, (preferably all of them), but could be any README, or > even just a notice on the project website, or an email saying ' I must disagree with you on this point. It is perfectly fine to ship the copyright and the license in two separate files, but it is also perfectly fine to ship them in the same file. I do so in my upstream project linked in a previous email, and Debian does so in debian/copyright. Using a file named LICENSE or COPYING or AUTHORS is fairly standard, but exactly how this is done doesn’t matter as long as both copyright (with years) and license are communicated. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1065078: Question about the debian group on Salsa
Peter, That’s a good point. When I granted the access I actually selected Maintainer, but for some reason I wrote Developer in the email. On Tuesday, March 5, 2024 5:44:51 AM MST Peter B wrote: > On 01/03/2024 04:12, Soren Stoutner wrote: > > I have created a repository named planner under debian and have granted you > > Developer access. :) > > F.Y.I. 'Developer' access on Salsa does not allow to Manage CI/CD > settings. > > If required, 'Maintainer' or 'Owner' is needed to do that. > https://docs.gitlab.com/ee/user/permissions.html > > BTDTGTTS, > Peter -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1065078: Question about the debian group on Salsa
On Sunday, March 3, 2024 12:08:00 PM MST Loren M. Lang wrote: > > There is certainly nothing wrong with keeping your project under your own > > namespace, but if you would like to move it to the debian namespace, grant > > me > > full access to it (my Salsa username is soren) and I can then move it to the > > debian namespace and grant you full access to the project there. > > Thanks! I've granted you full access to > > https://salsa.debian.org/penguin359/tiv > > -Loren Done. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: FWD: Copyright in LGPL projects
Alan, These are good questions. 1. Yes, there must be a copyright statement. Only the person, people, group, or organization that holds the copyright can issue a license for other people to use the work. So, you must have someone claiming a copyright or they do not have the legal ability to release the work to others under the LGPL. 2. No, it is not required that each individual file contain a copyright statement or the header of the LGPL at the top. The FSF recommends such as a best practice, and I would agree that it is desirable, but it is not required. My recommendation would be that you communicate to the upstream project that they need to include the copyright and licensing information in the root of their repository, preferably all in one file, as a minimum requirement for you to be willing to package their project in Debian. Soren On Sunday, March 3, 2024 11:06:30 PM MST Alan M Varghese wrote: > Sent message incorrectly to debian-mentors-request instead of debian- mentors. > Correcting. > > > Forwarded Message > Subject: Copyright in LGPL projects > Date: Mon, 4 Mar 2024 11:10:58 +0530 > From: Alan M Varghese > To: 1065...@bugs.debian.org > CC: Matthias Geiger , SmartList > > > Hello Mentors, > > I have been working on packaging Hyprland window manager. > hyprlang[0] (with a 'g') is a new dependency for this project. This project > (hyprlang) is licensed under LGPL. > > But, the project authors haven't included a copyright notice anywhere in the > project. It turns out that the authors are not sure if this is required for > an LGPL project[1]. > > From a Debian perspective, what is the recommendation regarding this? Do we > require projects to include the copyright information along with LGPL? > > If the copyright *has* to be included, is it enough to include it in a > COPYRIGHT file? I couldn't find an example of a project that does this. Most > projects seem to include a copyright line along with a short form of LGPL in > each file. (I think it may be more appealing to upstream authors if we don't > have to include the copyright in every file). > > For example, libplacebo[2] is a library I found installed on my system that > uses LGPL. This project does not have a common copyright file, but there are > copyright notices in some source files[3]. While some other source files in > this project do not have a copyright notice[4][5][6]. > > Note: my doubts are specifically regarding the LGPL license. For other > licenses like BSD, I see both practices of including a COPYRIGHT file as well > as a short copyright notice in each file, or a combination of the two. > > Thanks, > Alan M Varghese > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065352 > [1] https://github.com/hyprwm/hyprlang/issues/28 > [2] https://code.videolan.org/videolan/libplacebo > [3] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c? ref_ > type=heads [4] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c? ref_t > ype=heads [5] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c? ref_t > ype=heads [6] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/ colorspace.c? > ref_type=heads -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1065078: Question about the debian group on Salsa
Loren, Yes, I would say that is generally correct. If you have a package that is team maintained, it is best under the team namespace. If it is not team maintained, it is generally best under the debian namespace (which is the team of all Debian Developers). It makes it easier for others to pick up if something happens to you. However, there may be specific cases where you do want to keep it in your own namespace. I maintain one package where I am also the upstream developer. I keep the Debian packaging in my own namespace because I want to have a very high threshold for other people making changes to it. At this stage, if something were to happen to me, both the Debian package and the upstream project would need to be adopted by someone else, which would probably necessitate a renaming of the project. Down the road, I would like to get more people involved in both the upstream development and the Debian packaging. When that happens I will probably move the Salsa project to a team namespace. There is certainly nothing wrong with keeping your project under your own namespace, but if you would like to move it to the debian namespace, grant me full access to it (my Salsa username is soren) and I can then move it to the debian namespace and grant you full access to the project there. Soren On Saturday, March 2, 2024 11:34:14 PM MST Loren M. Lang wrote: > On Sat, Mar 02, 2024 at 01:11:46AM +0100, Salvo Tomaselli wrote: > > In data venerdì 1 marzo 2024 05:12:51 CET, Soren Stoutner ha scritto: > > > Generally you should create the repository under the debian namespace > > > > You need to ask a DD to do that. Non DD don't have permissions for this. > > So is having all packages (at least those not maintained by a team) > under the debian/ namespace considered a best practice for all but the > most sensitive of packages? Should I actually have my own package > transfered to this namespace? > > I just have a small, CLI package that I maintain alone and, since I > don't have DD permissions, just assumed that I should put it under my > own namespace. Is it recommended to just keep it under the neutral > debian namespace just in case I am no longer able to keep it maintained > in the future? > > My current package is https://salsa.debian.org/penguin359/tiv > > -Loren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Medical Device Interfacing
You probably just need to wait a bit. "Your account will be locked until a gitlab administrator enables it. As of July 2021 you will now receive an email confirming your account validation, please be patient. (Ping the above Support after 4 days patience)” https://wiki.debian.org/Salsa/Doc#Support[1] On Saturday, March 2, 2024 11:37:12 PM MST Nishi Shailesh wrote: > Thank you for the information. > *"create a Git repository on Salsa to host the Debian package information"* > This requires login to https://salsa.debian.org/ > I am not receiving email for confirming my email. > > On Sun, Mar 3, 2024 at 10:29 AM Soren Stoutner wrote: > > What you probably want to do is create an upstream project on your > > internet > > repository host of choice. Then, once it is published, create a Git > > repository on Salsa to host the Debian package information. > > > > On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > > > Hello mentors, > > > I forgot to add that, I have basic skill in preparing .deb file > > > > > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh < > > > > biochemistryg...@gmail.com> > > > > > wrote: > > > > Hellos mentors, > > > > I am from medical field and also know python/php > > > > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > > > > communication between medical instruments and linux box. > > > > They are generic and tested in many equipments. > > > > As no such packages are available in linux, I would like to contribute. > > > > Can any mentor guide me how I can contribute? > > > > Dr Shaileshkumar Patel > > > > MD, Biochemistry > > > > https://github.com/nishishailesh/mdi > > > > > > > > > > > > -- > > > > શૈલેશ પટેલ > > > > -- > > Soren Stoutner > > so...@debian.org -- Soren Stoutner so...@debian.org [1] https://wiki.debian.org/Salsa/Doc#Support signature.asc Description: This is a digitally signed message part.
Re: Medical Device Interfacing
What you probably want to do is create an upstream project on your internet repository host of choice. Then, once it is published, create a Git repository on Salsa to host the Debian package information. On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > Hello mentors, > I forgot to add that, I have basic skill in preparing .deb file > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh > > wrote: > > Hellos mentors, > > I am from medical field and also know python/php > > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > > communication between medical instruments and linux box. > > They are generic and tested in many equipments. > > As no such packages are available in linux, I would like to contribute. > > Can any mentor guide me how I can contribute? > > Dr Shaileshkumar Patel > > MD, Biochemistry > > https://github.com/nishishailesh/mdi > > > > > > -- > > શૈલેશ પટેલ -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1065078: Question about the debian group on Salsa
Generally you should create the repository under the debian namespace unless you really don’t want anyone else making any changes to it, even if the changes are urgent and you are AFK for some reason. I have created a repository named planner under debian and have granted you Developer access. :) On Thursday, February 29, 2024 7:28:59 AM MST Shriram Ravindranathan wrote: > Dear mentors, > > I'm curious about the guidelines for putting a package under the debian > namespace on Salsa <https://salsa.debian.org/debian>. I wasn't able to > find much discourse about this online. > > This package didn't have a salsa repository created for it, I am unsure > whether I should create a repository under my own namespace or if the > package should be placed under the debian namespace. > > Thank you, > > -- > Shriram Ravindranathan > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Maintaining a Package as a Non-Software Developer
Zach, Let me offer my encouragement as someone who has worked in IT for 25 years, taught myself programming about 8 years ago, started contributing to Debian as a Maintainer a couple of years ago, and recently became a Debian Developer. TL;DR If you can write a bash script you can maintain packages for Debian. In fact, I would say that writing bash script is a more useful skill set when packaging than having a knowledge of Java or C or whatever the upstream project is written in. And, particularly, I would say that having real world IT experience in maintaining production servers is probably more valuable than having coding experience (because you have a visceral feel for what types of changes are disruptive for people who are consuming the packages). I think it is important to realize that there is a steep, steep, steep, almost discouraging learning curve to figuring out how to package for Debian, which is exacerbated by the fact that there really isn’t good documentation written in such a way to be helpful for people who don’t already know how to do it (there is generally good documentation about packaging policy to remind those who already know how it works what the policies are). I say this not to discourage you but to help you anticipate what you are getting into. I spent about three months consuming documentation before I made my first contribution to Debian. I found that a whole bunch of it was outdated, incorrect, contradictory, or assumed I had knowledge of underlying principles that I was missing. I know that there are some people working to improve this, but it is a daunting task (partially because it is a moving target and partially because it is really hard to write documentation for people who aren’t already initiated to a subject). However, once you get over the learning curve and realize how amazing Debian’s build system is and the fact that it can consume almost any piece of source code on the internet and turn it into a standardized package it becomes a thing of beauty. My recommendation to you would be this: Find a package that you use that is currently maintained by an active maintainer or group but which needs some work. Then volunteer to pick off some easy bug reports or do an easy upgrade to a newer version under their guidance. From there you can iterate to more and more complicated tasks. In my case I did this with Electrum. The package had not be updated in so long that it no longer communicated with the Electrum network. The maintainer was no longer participating in Debian, but I was lucky enough that it was a team-maintained package and that Bastian Germann was a member of the team and also frequently contributes to mentors. He guided me through that initial packaging experience. I should note that Electrum is mostly written in Python, a language I had no experience with when I started and of which I still have only a little understanding (although you pick up things as you go). One recommendation I would make (that I don’t always see in Debian) is that you curate a relationship with the upstream maintainers. I have done this with the Electrum maintainers and it has been both a benefit to me and to them. Sometimes I reach out to them with a question about why they have done things a certain way and they have been invaluable in helping me to understand how the source code is structured. Sometimes I ask them if they could modify upstream to make my packaging easier, and they have been open to doing so when reasonable. In one instance they made my life a lot easier when coordinating a security fix by providing a custom patch for an older version shipping in stable. My experience is that most upstream projects would like to have their code shipped in Debian and are more than willing to be helpful to the process. And of course, mentors is always the place to ask questions. Ultimately, we want to make it as easy as possible for anyone to get involved because the more hands we have the lighter everyone’s load. Soren On Tuesday, February 27, 2024 10:28:15 PM MST earache_curtsy...@simplelogin.com wrote: > I was thinking that maintaining one or more packages would be a great way to > do this. I know a bit of Java and C but do not write code on a regular basis > (other than bash scripts). > > I am asking for a sanity check on whether or not this is a good idea, or if > the work of maintaining a package is only plausible for highly skilled > software engineers. > > From, > Zach -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Salsa Repository Access
Done, and thank you. On Sunday, February 25, 2024 1:58:06 AM MST Shriram Ravindranathan wrote: > Dear mentors, > My package "highlight" was uploaded to the debian archive. > I would like to have access to the salsa repository > <https://salsa.debian.org/debian/highlight> so that I may update it with > the latest changes. > > my salsa username is s20n <https://salsa.debian.org/s20n> > > Thanks, > > -- > Shriram Ravindranathan > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Help with debian/watch file
Hilmar, Try the following: opts="searchmode=plain,repack,compression=xz,repacksuffix=+ds1,dversionmangle=s/ \+ds1//, \ pgpsigurlmangle=s%$%.asc%" \ https://api.github.com/repos/silnrsi/teckit/releases \ https://github.com/silnrsi/teckit/releases/download/v\d+\.\d+\.\d+/ teckit@any_vers...@.tar.gz On Thursday, February 22, 2024 3:59:18 PM MST Hilmar Preuße wrote: > Hello, > > I could need some help with a debian/watch file [1]. The file is mostly > not written by me, I just replaced just some regexes to introduce the > correct versioning scheme. When running "uscan -vv" it downloads > correctly upstreams tar ball, the pgp is checked and the tar ball is > repackaged. Unfortunately the new upstream version is determined to be > $version.$version: teckit_2.5.12.2.5.12+ds1.orig.tar.xz the name of the > reduced tar ball is wrong and uscan (incorrectly) reports a new upstream > version. > > What do I do wrong? > > Thanks, >Hilmar > > [1] https://github.com/debian-tex/teckit/blob/master/debian/watch > -- > Testmail > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Request for salsa repo access
Done. Thank you for your contribution. On Wednesday, February 21, 2024 9:18:36 AM MST Akash Doppalapudi wrote: > Dear Mentors, > > My package just got accepted. > > "python-redmine" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971356 > > I just adopted this package and I don't have access to the salsa vcs > repository. > > I would like to update the salsa vcs and would like to request for access. > > Here is the link to the salsa repo > https://salsa.debian.org/debian/python-redmine > > My salsa username is 'akashdoppalapudi' > > > Thanks, > > Akash Doppalapudi > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1064346: Source is missing errors on HTML source files
Shriram, On Wednesday, February 21, 2024 8:30:54 AM MST Shriram Ravindranathan wrote: > Upon inspecting the embedded font, It seems to be a bespoke icon-font > generated using a tool called "Fontello" from one of the icons of the > octicons iconset from Atom <https://github.com/primer/octicons> (MIT > Licensed SVGs) > > The font has only 1 glyph, Would it suffice to add this source image to > d/missing-souces and add that copyright info to d/copyright? I would assume so. If anyone on mentors knows differently please speak up. > On 21/02/24 9:56 am, Soren Stoutner wrote: > > > > > > > Shriram, > > > > > > > > > > 1. For anything that has the unminified source in the upstream > > tarball, I would just create a lintian override with a comment listing > > the full path to the source for each file. You can see an example of > > how this can be done here: > > > > > > > > > > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/ sou > > rce/lintian-overrides?ref_type=heads > > > > > > > > > Typically you only copy the source to the debian/missing-sources > > directory when it is not included in the upstream tarball and you have > > had to acquire it from another place. > > > > > > > > > > 2. The github link below includes an embedded font in woff format. > > Typically, fonts like this would be considered compiled, so a separate > > font source would be needed. However, I’m not sure what the Debian > > guidance for dealing with an HTML embedded font like this. If someone > > else on mentors doesn’t know, I would recommend you ask on debian-legal. > > > > > > > > > > As these are mostly README files, and if it becomes difficult for you > > to acquire the source for some of them, you might consider excluding > > those you can’t get the source for, at least temporarily, using > > Files-Excluded in debian/copyright (and then running uscan, which will > > produce a modified tarball that does not include the problematic > > files). For example, see: > > > > > > > > > > https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/ copyr > > ight?ref_type=heads > > > > > > > > > Whether this is a good option depends on how helpful those README > > files are for the users of your package. If you go this route, you > > should add +dfsg to the version of your package to indicate that the > > upstream tarball has been repackaged to remove files that are not free > > (or for which the source is not available). > > > > > > > > > > Soren > > > > > > -- > Shriram Ravindranathan > ters > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1064346: Source is missing errors on HTML source files
Shriram, 1. For anything that has the unminified source in the upstream tarball, I would just create a lintian override with a comment listing the full path to the source for each file. You can see an example of how this can be done here: https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1] Typically you only copy the source to the debian/missing-sources directory when it is not included in the upstream tarball and you have had to acquire it from another place. 2. The github link below includes an embedded font in woff format. Typically, fonts like this would be considered compiled, so a separate font source would be needed. However, I’m not sure what the Debian guidance for dealing with an HTML embedded font like this. If someone else on mentors doesn’t know, I would recommend you ask on debian-legal. As these are mostly README files, and if it becomes difficult for you to acquire the source for some of them, you might consider excluding those you can’t get the source for, at least temporarily, using Files-Excluded in debian/copyright (and then running uscan, which will produce a modified tarball that does not include the problematic files). For example, see: https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright? ref_type=heads[2] Whether this is a good option depends on how helpful those README files are for the users of your package. If you go this route, you should add +dfsg to the version of your package to indicate that the upstream tarball has been repackaged to remove files that are not free (or for which the source is not available). Soren On Tuesday, February 20, 2024 8:23:41 PM MST Shriram Ravindranathan wrote: > Thanks, Soren. > > It looks like most of these files have just one or two lines that are > extremely long. > > These are mostly README files. Most of them seem to have this > github-markdown.css > <https://gist.github.com/jojoldu/9cb1b6a5110619e221dfd4603f30ddd4> > minified and pasted in them. While others have the sources that were > used to generate them listed in the same folder. > > Should I copy these sources into the d/missing-sources directory? -- Soren Stoutner so...@debian.org [1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/ lintian-overrides?ref_type=heads [2] https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright? ref_type=heads signature.asc Description: This is a digitally signed message part.
Re: Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, When compiling locally on my system, the current version of lintian (2.117.0) found the following problems. These are not displayed on mentors.debian.net, leading me to believe they were recently added checks. W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/ libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so] N: N: Although this package is not a "-dev" package, it installs a N: "libsomething.so" symbolic link referencing the corresponding shared N: library. When the link doesn't include the version number, it is used by N: the linker when other programs are built against this shared library. N: N: Shared libraries are supposed to place such symbolic links in their N: respective "-dev" packages, so it is a bug to include it with the main N: library package. N: N: However, if this is a small package which includes the runtime and the N: development libraries, this is not a bug. In the latter case, please N: override this warning. N: N: Please refer to Development files (Section 8.4) in the Debian Policy N: Manual for details. N: N: Visibility: warning N: Show-Always: no N: Check: libraries/shared/links N: Renamed from: non-dev-pkg-with-shlib-symlink N: N: W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8 N: N: The package name of a library package should usually reflect the soname of N: the included library. The package name can determined from the library N: file name with the following code snippet: N: N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/ ^[[:space:]]*SONAME[[:space:]]*//p' | \ N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/' N: N: Visibility: warning N: Show-Always: no N: Check: libraries/shared/soname N: N: I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-common.so. 1.8 N: N: Although the package includes a shared library, the package does not have N: a symbols control file. N: N: dpkg can use symbols files in order to generate more accurate library N: dependencies for applications, based on the symbols from the library that N: are actually used by the application. N: N: Please refer to the dpkg-gensymbols(1) manual page and N: https://wiki.debian.org/UsingSymbolsFiles for details. N: N: Visibility: info N: Show-Always: no N: Check: debian/shlibs As noted in the text of the checks, there are scenarios where these do not apply (like small packages that include the runtime and the development files), which appears to be the case with qt5ct. Can you please help me to understand why qt5ct is including this shared library, if there are any other packages in Debian that are building against this library, and if you feel that any of the lintian checks above apply? If you feel they don’t apply I would recommend you add lintian overrides and I will be happy to upload your package. Soren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1064346: Source is missing errors on HTML source files
The question is if the long lines in these HTML files are actually indications that the HTML files are not the original source. This usually happens in one of two cases. 1. The files have been minified. 2. The files were originally created in another format and converted to HTML. Sometimes HTML files naturally have long lines. If you look at the descriptions of the lintian warnings, they acknowledge that this is an imperfect check that will result in some false-positives. If that is the case, the HTML files are the original source, and they have not been minified, then you can override these warnings with a description as to why. On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote: > Hello mentors, > > I am getting a few lintian "source-is-missing" errors for some HTML > files. These HTML files are infact present in the source code but they > have too many lines which triggers a > "very-long-line-length-in-source-file" lintian tag and that in turn > causes the "source-is-missing" error. > > Most of the info I could find in the policy manual and in the forums > pertained to binary files that were included in the source, the strategy > these resources suggested were > 1. Repack upstream tar with the source code of these files > 2. Add the source code to the d/missing-sources directory > > I don't think either of these are viable options in my case. I was > wondering whether it would be okay to suppress these errors. Is there > any other way to solve this? > > -- > Shriram Ravindranathan > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Looking to find a sponsor
Jordan, Welcome to Debian packaging! There are a set of instructions that will be helpful as you work on your first package: https://mentors.debian.net/intro-maintainers/[1] Even though you are packaging a Python app, there are still a number of additional things needed to turn it into a proper Debian package. For example, you need a debian/copyright file, a debian/control file, and a debian/rules file among other things. One of the packages I maintain is Electrum, which is also a Python app. You can get some sense of how to do it by looking at my packaging repository on Salsa (Debian’s GitLab server): https://salsa.debian.org/cryptocoin-team/electrum/-/tree/master/debian[2] You might also want to subscribe to the Debian Python mailing list: https://lists.debian.org/debian-python/[3] Soren On Monday, November 6, 2023 5:58:57 PM MST Jordan Rahim wrote: > Hello Debian Mentors. I would like to apologize in advance if this is > not the correct protocol. I am trying to follow the instructions as best > as I can. > > > I was wondering if there was anyone willing to sponsor my first debian > package on to the apt repositories. > > > Package Info > > > The package is a Python app called CraftServerSetup that allows the user > to create and manage game servers for the popular video game Minecraft. > As a result of the app's choice in programming language, it does not > need any building or compiling at all (so I have it as a binary deb file > right from the start). > > On the "New Packager's Guide" page I saw something about requesting > sponsors with a certain skillset..? > > For that, I don't care very much. Just someone who is willing to upload > the deb files to apt. > > > Once again, I am very sorry if this is not what I am supposed to do. > > > Thank you -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Nyxt Browser package
Fionn, It is a pleasure to make the acquaintance with a fellow developer working on packaging a browser based on Qt WebEngine. I am the developer and packager of Privacy Browser: https://tracker.debian.org/pkg/privacybrowser[1] On Monday, April 24, 2023 12:58:50 PM MST Fionn Stephens wrote: > Hi, > > I'm wondering what interest there is in Debian for packaging the Nyxt > browser? I'm definitely not an expert in Lisp, but I can help packaging it. > I've already made a Debian Sid virtual machine. Am I correct in saying that > the first step would be to package version "3-pre-release-6" for the > unstable version of Debian? As testing is currently in freeze, the best course of action would probably be to do a first upload to experimental, followed by an upload to unstable once Bookworm is released. > I'm also interested in writing some documentation on the Nyxt browser. Would > appreciate any hints on how to get contributing. I imaging getting in > contact with the Common Lisp Debian team is a good start? I would imagine they would be a good reference. You might also find the following information about Qt WebEngine dictionary support in Debian interesting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387[2] Soren -- Soren Stoutner so...@stoutner.com [1] https://tracker.debian.org/pkg/privacybrowser [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387 signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
You are correct about past support. There probably hasn’t been anyone in Debian as focused on Qt WebEngine before me. That was part of the reason I decided to get involved in Debian. On Wednesday, March 15, 2023 11:05:14 PM MST Paul Wise wrote: > I don't see Debian security updates nor stable updates of Qt WebEngine > for current/previous Debian releases so far, but I am very glad to hear > that they are being worked on for the Debian bookworm release at least. > > https://lists.debian.org/debian-security-announce/ > https://lists.debian.org/debian-announce/ -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
I’m not sure I understand what point you are trying to make. On Wednesday, March 15, 2023 12:35:07 PM MST Mezgani Ali wrote: > Look Storen, > > Qt WebEgine used 15 years ago for developing a Safari from scratch. > Debian/GNU Linux is more GTK side than Qt. > > > Kind regards, > > Mezgani Ali > +212 6 44 17 94 51 > ali.mezg...@nativelabs.ma > https://wiki.debian.org/mezgani > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > On 15/03/2023, at 19:52, Soren Stoutner wrote: > > > > Paul, > > > > The point is that these security updates are added upstream, they are > > regularly packaged in Debian, and it wouldn’t be any harder to support > > them in Debian stable than security updates for any other browser. Your > > original email indicated that none of these three things were true. > > > > Beyond that, you might find the following an interesting read (fairly > > long, but the point is that, as per the Chromium maintainer, Qt WebEngine > > has better coverage in Debian stable than Chromium does): > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255 > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255> Privacy > > Browser is not going to ship in Bookworm, but it will ship in Bookworm+1. > > Part of the reason why I have become one of the Qt maintainers is so > > that it receives proper security support in stable (and oldstable as much > > as possible, although there probably isn’t any web browser that currently > > has good security coverage in oldstable). > > > > Soren > > > > On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote: > > > Hi all! > > > > > > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote: > > > > Paul, > > > > > > > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit > > > > code > > > > to the upstream Qt project. > > > > > > > > The Salsa link you included appears to be a bit misinformed about > > > > security > > > > support for Qt WebEngine in Debian. For more accurate information, I > > > > would > > > > point you to this link: > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 > > > > > > Please note that this request is for a not-yet-released Debian version. > > > > > > I am not sure the Release team will agree to have such updates in > > > stable. > > > Although, I would be happy to discuss this with them. > > > > > > -- > > > Dmitry Shachnev > > > > -- > > Soren Stoutner > > so...@stoutner.com -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Paul, The point is that these security updates /are/ added upstream, they /are /regularly packaged in Debian, and it wouldn’t be any harder to support them in Debian stable than security updates for any other browser. Your original email indicated that none of these three things were true. Beyond that, you might find the following an interesting read (fairly long, but the point is that, as per the Chromium maintainer, Qt WebEngine has better coverage in Debian stable than Chromium does): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255[1] Privacy Browser is not going to ship in Bookworm, but it will ship in Bookworm+1. Part of the reason why I have become one of the Qt maintainers is so that it receives proper security support in stable (and oldstable as much as possible, although there probably isn’t any web browser that currently has good security coverage in oldstable). Soren On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote: > Hi all! > > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote: > > Paul, > > > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code > > to the upstream Qt project. > > > > The Salsa link you included appears to be a bit misinformed about security > > support for Qt WebEngine in Debian. For more accurate information, I > > would > > point you to this link: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 > > Please note that this request is for a not-yet-released Debian version. > > I am not sure the Release team will agree to have such updates in stable. > Although, I would be happy to discuss this with them. > > -- > Dmitry Shachnev -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255 signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Paul, I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code to the upstream Qt project. The Salsa link you included appears to be a bit misinformed about security support for Qt WebEngine in Debian. For more accurate information, I would point you to this link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794[1] Bug fixes for Qt WebEngine are backported every couple of months by upstream Qt: https://www.qt.io/blog/commercial-lts-qt-5.15.13-released[2] There are a number of other browsers based on Qt WebEngine currently in Debian. A non- exhaustive list includes the following: Konqueror Falkon qutebrowser Angelfish If you are interested in more information about the subject, I have a section of Privacy Browser’s handbook dedicated to the subject which is included in the index.docbook in the .deb. Soren On Tuesday, March 14, 2023 6:19:44 PM MST you wrote: > On Sat, 2023-03-11 at 14:41 -0700, Soren Stoutner wrote: > > * URL : https://www.stoutner.com/privacy-browser-pc/ > > privacybrowser - web browser that respects your privacy > > I note that this browser depends on Qt WebEngine, all the Qt based web > engines are not security supported in Debian. I encourage you to switch > to a browser engine that is security supported, or discuss with the > Debian and upstream Qt web engine maintainers to add such support. > > https://salsa.debian.org/debian/debian-security-support/-/blob/master/securi > ty-support-limited > * qtwebengine-opensource-src: No security support upstream and >backports not feasible, only for use on trusted content > * qtwebkit: No security support upstream and backports not feasible, >only for use on trusted content > * qtwebkit-opensource-src: No security support upstream and backports >not feasible, only for use on trusted content > * kde4libs: khtml has no security support upstream, only for use on >trusted content > * khtml: khtml has no security support upstream, only for use on >trusted content, see #1004293 -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 [2] https://www.qt.io/blog/commercial-lts-qt-5.15.13-released signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "privacybrowser": * Package name : privacybrowser Version : 0.1-1 Upstream contact : Soren Stoutner * URL : https://www.stoutner.com/privacy-browser-pc/ * License : GPL-3+, GFDL-NIV-1.3+ * Vcs : https://salsa.debian.org/sorenstoutner/privacybrowser Section : web The source builds the following binary packages: privacybrowser - web browser that respects your privacy To access further information about this package, please visit the following URL: https://mentors.debian.net/package/privacybrowser/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/privacybrowser/ privacybrowser_0.1-1.dsc Changes for the initial release: privacybrowser (0.1-1) experimental; urgency=low . * Initial release (closes: #1031755). Regards, -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Help needed in setting up dev-environment
I can second that. Not that I have any personal experience with WSL, but I can tell you that dual boot is your friend. Twenty-five years ago I got started on Linux in a dual boot environment. Slowly I started booting into Linux more and DOS/Windows less. Now, very few of my machines even have a Windows installation. It’s a good way to slowly migrate while enjoying a full Linux distro instead of a hobbled one. On Friday, February 10, 2023 9:33:01 AM MST Danial Behzadi دانیال بهزادی wrote: > For your own sake please don't! > At least dual boot your machine with real Debian. WSL is too immature to be > used as a development environment. > در 10 فوریهٔ 2023 13:07:31 (UTC)، Ashutosh Pandey نوشت: > >Hello everyone, > > > >I am Ashutosh Pandey and I want to be a part of this year's GSoC program as > >a mentee. I am doing my Bachelor's in Computer Science at ABESIT Ghaziabad, > >India. > > > >I am interested in Dev-Ops and Full-Stack side of things and I have built > >many projects where I have utilized my knowledge. > > > >Now coming to the help part > > > >I'm on a Windows machine and I have WSL enabled I'm using Ubuntu since > >Debian has many packages I would like to contribute to Python and C code. > >and I would prefer to work in my WSL ubuntu distro since it's closer to > >Debian than Windows. > > > > - Should I set up the development environment on Windows or on WSL? > > - In both cases(dev environment on Windows or WSL) is there any > > step-by-step guide for building Debian on Windows or on WSL? > > > >Thanks in advance and apologies if formatting isn't right. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
`UNRELEASED` is used because it will cause a failure if you accidentally try to upload it, which prevents accidental releases before they are intended. At the point of release, you should change it to be `unstable` or `experimental` or a backports repository. On Saturday, February 4, 2023 8:18:19 AM MST min sun wrote: > > Hello Min Sun, > > > > is there a particular reason why you opt for / stick to distribution > > `UNRELEASED` for a package already monitored by the tracker?[1] It is the > > entry e.g., `dch -i` puts into file `/debian/changelog` when you start to > > work on a new version (increment) of a package. After all other other > > work on your side is done, an eventual change to the string `unstable` > > (then lower case only) is one of the keys necessary to let results of > > your work enter branch `unstable`, and later `testing`, etc. > > Thanks for your clarification, Tony, > > I did not mean to specify it as `UNRELEASE`, the ‘uscan and uupdate” tools > insert this keyword to debian/changelog. > > I am not clear about the internal mechanism from `UNRELEASED` to `testing` > and later stage. > > I need learn more about Debian policy along with your guideline. > > All the best. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: help with python3 depends < 3.11
Piuparts tests, among other things, upgrades. So, it tries installing the old version, upgrading to the current version, and checking for errors during that process. In your case, as the old version is uninstallable, you can ignore this as a known problem. On Tuesday, January 17, 2023 6:45:52 AM MST Stephen Sinclair wrote: > If that's the case, I feel like I can just ignore this and when it's > uploaded the problem will fix itself. Does this mean that it's just a > problem with how piuparts works, or how Salsa is configured for it? > If so I will try to find how to report it. > > thanks, > Steve -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: How to create multi-source tarball with different submodules for scipy
I haven’t looked closely at it myself, but qtwebengine-opensource-src accomplishes something along these lines using `get-orig-source` in their rules file. https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/rules[1] Note that, in their case, you must have the python3-debian package installed, because the script depends on Python for some of the processing. On Monday, January 16, 2023 9:27:59 AM MST Julian Gilbey wrote: > On Mon, Jan 16, 2023 at 05:05:39PM +0100, Andreas Tille wrote: > > Hi, > > > > I tried to create a multi-source tarball for scipy in its experimental > > branch[1]. Upstream includes a set of git submodules in its build > > process. I intended to merge all these submodules in a single > > scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a > > script[2] which makes sure that the exact directory structure as it is > > used by upstream is conserved. This directory layout is needed in the > > build process. Unfortunately `dpkg-source -x` extracts the content of > > the submodules tarball into a subdirectory submodules/. > > > > Is there any trick to unpack this tarball right into the root? > > Otherwise I need to do some symlinks workaround in d/rules to provide > > all files where these are needed. > > Not that I know of; this is the design of the multi-source tarball > setup: each component tarball is extracted into a directory with the > name of the component. > > Best wishes, > >Julian -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/rules signature.asc Description: This is a digitally signed message part.
Re: Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
I would recommend you install the debian-policy package and review the documentation on the format of the copyright file at /usr/share/doc/debian- policy/copyright-format-1.0.html. With that as a reference, I do not find it difficult to manually edit copyright files. On Thursday, January 12, 2023 7:40:02 PM MST Nick Hastings wrote: > * Bastian Germann [230104 02:20]: > > Control: tags -1 moreinfo > > > > Am 15.12.22 um 06:40 schrieb Nick Hastings: > > > > d/copyright > > > > === > > > > Please use more wildcards so you do not have to list so many files. > > > > > > This is where it gets tricky for me. As I understand it the last match > > > in d/copyright file is the one that applies. So for example, the block > > > starting at line 253 specifies a LGPL-2.1+ license for a bunch of files > > > under lib/libc/include/. Lines 253-270 explicitly list header files > > > under lib/libc/include/aarch64-linux-gnu/bits/. So first thought is to > > > just list them all as a glob lib/libc/include/aarch64-linux-gnu/bits/* > > > However on closer inspection I see that there is a file in that > > > directory that is not listed. Specifically > > > lib/libc/include/aarch64-linux-gnu/bits/fcntl/endianness.h > > > Inspecting this file and the others in the directory I see that > > > explicitly listed files contain the LGPL-2.1+ text, but that > > > endianness.h contains no license text. Thus endianness.h is actually > > > Expat license and is covered in the block starting on line 10 "Files: > > > lib/*". > > > > > > So if I change the explicit list of files under > > > lib/libc/include/aarch64-linux-gnu/bits/ to a glob, I'll need to and > > > anther block later to explicitly list endianness.h as Expat. > > > > Yes, you would use a glob for the LGPL files and add another block > > specifically for the Expat-licensed file after the LGPL block. > > Understood. However I do not feel confident that I can correctly make > these changes by hand. The above is just one example where I found that > using a glob would require an additional section/exception. There are > likely many more. > > This debian/copyright file was originally produced by decopy and I > adjusted it wherever I found problems. I hesitate to change things that > I do not know to be wrong, at the risk of introducing errors simply to > reduce the number of lines in the file. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1028121: RFS: d11amp/0.61-1 -- Oldskool MP3 player
Although I completely agree that spamming the list is not appropriate, I also think that Thomas has a valid complaint in that, as far as I have seen, nobody has raised any real objections to his package that have not been addressed, except that there are already a lot of MP3 players. If we generally denied the creation of a new package because there are already other packages that do similar things, a lot of innovation would be shut down. Hence, that is an argument that I find antithetical to the open source movement. During this time period many other packages have been sponsored. Therefore, I think it is appropriate for Thomas to request that someone either point out a valid reason for not sponsoring the package, or else sponsor it. On Saturday, January 7, 2023 4:17:17 AM MST David Bürgin wrote: > Hello Thomas, > > Thomas Dettbarn: > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am still looking for a sponsor for my package "d11amp": > > They are an elusive bunch, aren't they? > > So, this week, I am trying the SPAMMING approach. ;) > > I am not a sponsor, but this kind of behaviour cannot be somehow made > ‘ok’ by adding a smiley face. It is unpleasant and abusive behaviour. > > Please remember that you are asking *volunteers* to do work for you *for > free*. Patience is the key here. My recommendation is to move on for > now; you have posted your ITP, you have invited sponsors, you have done > your thing. Now in my experience, a few months can go by until someone > finds the time, and wants to spend the time to sponsor your package. > > No offence; this is only my perspective as someone who relies regularly > on sponsorship by the generous Debian mentors. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: How to request a package python-pyqt6.qsci?
Edit /etc/apt/sources.list to have the following contents: deb http://deb.debian.org/debian/ testing main contrib non-free deb-src http://deb.debian.org/debian/ testing main contrib non-free deb http://deb.debian.org/debian/ unstable main contrib non-free Then run the apt commands mentioned previously to install the packages you want from unstable. Newer packages will always be prioritized over older packages, so it is fine having both testing and unstable listed as repositories at the same time. Then edit the contents of /etc/apt/sources.list to be the following: deb http://deb.debian.org/debian/ testing main contrib non-free deb-src http://deb.debian.org/debian/ testing main contrib non-free #deb http://deb.debian.org/debian/ unstable main contrib non-free The commented out line removes the unstable repository, but makes it easy to add back in whenever you need it. Soren On Monday, January 2, 2023 2:36:59 AM MST Andrew M.A. Cater wrote: > On Mon, Jan 02, 2023 at 07:50:53AM +, Barry wrote: > > I need to install pyqt qsci to test the built code anyway so… > > > > What is the stanza to get to these debs please? > > deb http://deb.debian.org/debian/ sid main contrib non-free > deb-src http://deb.debian.org/debian/ sid main contrib non-free > > So essentially these two lines where sid replaces the distribution name > bookworm > > Hope this helps, > > Andy Cater > > > Barry -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: How to request a package python-pyqt6.qsci?
Click on the tracker (the second link). It will tell you why it is not in testing. Specifically, it tells you this is the problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027416 Which has just been fixed. You can either wait 5 days for it to migrate to testing, or you can edit your apt/sources.list file and add in entries for unstable (you can list sources for more than one repository). Run `apt update` to update the indexes for all the repositories. Don’t run ` apt upgrade` unless you want to upgrade to everything in unstable, which could have negative consequences. Do run `apt install python3-pyqt6-qsci pyqt6.qsci-dev` which will pull in all the needed packages from unstable to install these on your system but otherwise leave all the testing packages. Then edit sources.list and comment out the unstable lines. On December 31, 2022 3:39:19 PM MST, Barry wrote: > > >On 31 Dec 2022, at 22:32, Soren Stoutner wrote: > > > Is this the package you are looking for? > >https://packages.debian.org/search?keywords=python3-pyqt6.qsci > > >Yes that is what i am after. Debian testing does not have it available. > >This is where i need help understanding what i do to get that deb. > >It says thats its available for sid? But testing is bookworm. > >Does the dev need to push a build for bookwork? > > >Barry > > > >https://tracker.debian.org/pkg/qscintilla2 > > >On December 31, 2022 3:14:43 PM MST, Barry Scott >wrote: > >On 31/12/2022 17:38, Soren Stoutner wrote: > >There are already some QScintilla Qt6 packages. Is one of these the one you >are looking for? > > >https://packages.debian.org/search?keywords=qscintilla2-qt6 > >That will be the C binding for Scintilla. Its a build dep of PyQt6. > >I need the python3 version. Only the old PyQt5 version is available. > And I've ported all my code to PyQt6. > >If the maintainer is stuck I know enough about building PyQt6 to be helpful. > >I had to build it in Copr for my use on Fedora. FYI Copr is the service that >allows > users to build repos of code that not build as part of the official Fedora > releases. > >Here are my repos for example >https://copr.fedorainfracloud.org/coprs/barryascott/ > >Barry > > > >On Saturday, December 31, 2022 10:30:44 AM MST Barry Scott wrote: > >> How do I file a request to get QScintilla packaged for debian testing? > >> > >> There is the python3-pyqt5 package, but the qt6 version is missing. > >> > >> Barry > > > >-- > >Soren Stoutner > >so...@stoutner.com <mailto:so...@stoutner.com> > > >-- >Soren Stoutner >so...@stoutner.com -- Soren Stoutner so...@stoutner.com
Re: How to request a package python-pyqt6.qsci?
Is this the package you are looking for? https://packages.debian.org/search?keywords=python3-pyqt6.qsci https://tracker.debian.org/pkg/qscintilla2 On December 31, 2022 3:14:43 PM MST, Barry Scott wrote: > >On 31/12/2022 17:38, Soren Stoutner wrote: >> >> There are already some QScintilla Qt6 packages. Is one of these the one you >> are looking for? >> >> >> https://packages.debian.org/search?keywords=qscintilla2-qt6 >> >That will be the C binding for Scintilla. Its a build dep of PyQt6. > >I need the python3 version. Only the old PyQt5 version is available. >And I've ported all my code to PyQt6. > >If the maintainer is stuck I know enough about building PyQt6 to be helpful. > >I had to build it in Copr for my use on Fedora. FYI Copr is the service that >allows >users to build repos of code that not build as part of the official Fedora >releases. > >Here are my repos for example >https://copr.fedorainfracloud.org/coprs/barryascott/ > >Barry > > >> >> On Saturday, December 31, 2022 10:30:44 AM MST Barry Scott wrote: >> >> > How do I file a request to get QScintilla packaged for debian testing? >> >> > >> >> > There is the python3-pyqt5 package, but the qt6 version is missing. >> >> > >> >> > Barry >> >> >> >> -- >> >> Soren Stoutner >> >> so...@stoutner.com >> -- Soren Stoutner so...@stoutner.com
Re: How to request a package python-pyqt6.qsci?
There are already some QScintilla Qt6 packages. Is one of these the one you are looking for? https://packages.debian.org/search?keywords=qscintilla2-qt6[1] On Saturday, December 31, 2022 10:30:44 AM MST Barry Scott wrote: > How do I file a request to get QScintilla packaged for debian testing? > > There is the python3-pyqt5 package, but the qt6 version is missing. > > Barry -- Soren Stoutner so...@stoutner.com [1] https://packages.debian.org/search?keywords=qscintilla2-qt6 signature.asc Description: This is a digitally signed message part.
Re: Debian 11 missing packages I need what configure should I run?
Users new to Debian often misunderstand the various Debian repositories. Let me give you a brief description. Stable: Debian releases a new Stable version about every two years. It is designed for servers where administrators require complete *feature* stability, meaning that they don’t want anything to change, they don’t want any new features, they don’t want to have to modify any config files to make them compatible with any changes in the software. They just want it to run and receive security updates. Very few people would be looking to run Debian Stable in a desktop environment. Testing: Testing is a rolling release. It updates twice a day from packages that have been vetted in Unstable long enough to be considered generally usable. It is what most people are looking for if they want to use recent versions of software. Periodically, testing freezes and becomes the new Stable release. The next freeze of Testing is scheduled to begin on January 12. https://release.debian.org/bookworm/freeze_policy.html[1] Unstable: Unstable is where new packages are uploaded. They sit there for a cooling-off period (the default is 5 days in most situations) and move to Testing if no significant bugs are found. Sbuild defaults to building packages using an Unstable environment. Experimental: Unlike the other three repositories listed above, Experimental does not contain a full set of packages (meaning that you cannot install and run a full system solely from experimental). Rather, it is a supplement to Unstable. Packages in Experimental do not automatically propagate to other repositories. Developers can upload packages to Experimental that they want to make available for wider testing but which they know are in an unfinished state. The above is just a brief summary. There is much more nuance that can be explored, including Backports (a supplementary repository of newer software that can be added on to a stable release). The first place you would want to look for more information is: https://www.debian.org/releases/[2] From a personal perspective, I run all my servers and workstations on Debian Testing. I use sbuild to test packaging in a Debian Unstable environment. Other developers and users have different preferences. On Friday, December 30, 2022 5:15:48 AM MST Barry Scott wrote: > I have installed debian 11 (bullseye) but find that its missing packages > that I need for my software. > > For example python3-pyqt6 is a must have. debian 11 only has pyqt5. > > What do you recommend I do to be on a debian which has the newer packages? > > What is the stability expectation of your recommendation? > > Barry -- Soren Stoutner so...@stoutner.com [1] https://release.debian.org/bookworm/freeze_policy.html [2] https://www.debian.org/releases/ signature.asc Description: This is a digitally signed message part.
Re: lintian errors packaging Barry's Emacs
On Wednesday, December 28, 2022 2:49:19 PM MST Barry Scott wrote: > If you ever need to package RPMs I can return the favor. I might some day. I am the upstream developer for Privacy Browser PC, which will shortly reach an alpha release. I am planning to maintain Debian packages, but I might also want to maintain official RPMs. https://www.stoutner.com/privacy-browser-pc/[1] -- Soren Stoutner so...@stoutner.com [1] https://www.stoutner.com/privacy-browser-pc/ signature.asc Description: This is a digitally signed message part.
Re: Clean-room build of deb package?
Both pbuilder and sbuild have been suggested. Packagers use either, but, if it is of interest, sbuild is what the Debian architecture uses to build your package after you upload it. On Thursday, December 29, 2022 9:21:39 AM MST Sebastian Kuzminsky wrote: > On 12/29/22 06:02, Barry Scott wrote: > > On Fedora/RHEL I would use mock to build a RPM from source to ensure > > that I have the RPM spec file correctly written. > > > > Mock ensures that no packages in my dev machine are used to build the RPM. > > > > What is the debian version of that tool? > > I use `pbuilder` for this purpose: > <https://pbuilder-team.pages.debian.net/pbuilder/> -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: lintian errors packaging Barry's Emacs
Barry, Figuring out how to package for Debian has a stiff learning curve (speaking as someone who is going through the process myself). There are a couple of website that collect links to information that might be useful to you. https://mentors.debian.net/intro-maintainers/[1] https://wiki.debian.org/Packaging[2] The references that I personally found most helpful were there following: https://packages.debian.org/bookworm/developers-reference[3] (Install the package and then read /usr/share/developers-reference/developers- reference.pdf) https://packages.debian.org/bookworm/maint-guide[4] (Install the package and then read /usr/share/doc/maint-guide/maint-guide.en.pdf) Note that this document is considered outdated and replaced by https://www.debian.org/ doc/manuals/debmake-doc/index.en.html[5] but I found it to be a more useful read, even though they share an author. You will discover that almost all Debian documentation is outdated, because writing documentation is almost always less exciting than writing code. So, you almost always have to adjust anyway. Also, if you decide to use Git, definitely check out the git-buildpackage documentation: https://packages.debian.org/bookworm/git-buildpackage[6] (Install the package and then read /usr/share/doc/git-buildpackage/manual-html/ index.html) On Tuesday, December 27, 2022 9:24:18 AM MST Barry Scott wrote: > On 27/12/2022 11:16, Ole Streicher wrote: > > Hi Barry, > > > > Barry Scott writes: > >> I am build my first Debian package for Barry's Emacs > >> (https:://barrys-emacs.org) > > > > Aside from Santiagos technical tips: If you really want to contribute > > your package to the Debian distribution, you should also have a few > > other things in mind: > > > > * Your package should come with a proper DFGS compliant [1] license. Your > > > >Github upstream package [2] doesn't have one, and it would be useful > >(not only for Debian packaging) to add one there. > > I plan to state it is Apache-2.0 licensed. There is an issue to fix this. > > > * I would recommend to follow the usual procedures here. Specifically, > > > >you should open an "Intend To Package" (ITP) bug [3] to indicate your > >packaging efforts. > > Happy to contribute bemacs and my other packages to debian. > > The others include scm-workbench, but that needs PyQt6 Scintilla > to get packaged only PyQt5 Scintilla is packaged at the moment. signature.asc Description: This is a digitally signed message part.
Re: Bug#1026811: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player
Thomas, I would just like to say that I don’t consider the existence of any number of other MP3 players in Debian to be a good reason to prohibit the introduction of another one. I am not yet a Debian Developer, but if I were I would sponsor your package. Soren On Wednesday, December 21, 2022 6:22:07 AM MST Thomas Dettbarn wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I would like to point out that there is still a BADASS-LOOKING package > "d11amp" > waiting to be sponsored. > > > > > * Package name : d11amp > Version : 0.59-1 > Upstream contact : Thomas Dettbarn > * URL : https://www.dettus.net/d11amp/ > * License : BSD-2-Clause > * Vcs : https://github.com/dettus/d11amp/ > Section : sound > > The source builds the following binary packages: > > d11amp - Simple MP3 player > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/d11amp/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/d11amp/d11amp_0.59-1.dsc > > Changes for the initial release: > > d11amp (0.59-1) unstable; urgency=low -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: doubts about debian/copyrights
On Saturday, October 22, 2022 7:04:37 PM MST Paul Wise wrote: > Allegedly scancode is the best option for that, but it isn't in Debian. > I think decopy/licensecheck are the best ones already in Debian. I have seen this mentioned several times, but I have not seen any explanation as to why. It seems that the large number of dependencies is the reason. https://wiki.debian.org/JelmerVernooij/scancode[1] -- Soren Stoutner so...@stoutner.com [1] https://wiki.debian.org/JelmerVernooij/scancode signature.asc Description: This is a digitally signed message part.
Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
I opened up another MR. It has a detailed explanation of the changes, including an updated patch. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
I opened MRs that contain a DFSG clean update. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
On Wednesday, October 19, 2022 2:05:21 AM MST Bastian Germann wrote: > Am 19.10.22 um 00:43 schrieb Soren Stoutner: > > Because this Lintian error existed in the previous packages and because it > > does not relate the RC bug that this upload is attempting to fix I was > > planning to wait for a future release to fix it. Do you think it would > > be best to deal with it now without input from Tristan Seligmann? > > Yes. I am a team member and can make this kind of change. > I have to care about packages that I upload are conforming to the Debian > Policy and not having the source available for the JS files is violating > it. > > The replacing of the embedded copies can wait however, but I would be happy > to sponsor another version with them as well. I have submitted a request to upstream to help me understand the best way to remove these JavaScript files and depend on system copies. You can follow that conversation at the following link if you like. Once I have a working build without these files I will create a MR. https://github.com/spesmilo/electrum/issues/8023[1] -- Soren Stoutner so...@stoutner.com [1] https://github.com/spesmilo/electrum/issues/8023 signature.asc Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
On Wednesday, October 19, 2022 2:00:23 AM MST Bastian Germann wrote: > Am 19.10.22 um 00:52 schrieb Soren Stoutner: > > I very carefully looked though all the files in the source and the output > > of licensecheck to create the copyright file. If you compare it to the > > copyright file from 4.0.9-1 you will see that it is much improved and > > fixes many inaccuracies that existed in the 4.0.9-1 Debian package. I am > > fairly sure that the current copyright file is comprehensively correct, > > but feel free to point out anything I have missed. > > Missing copyright: > > 2011, ParaType Ltd. > 2014, The Monero Project Good catch. I have added these to the copyright file and will submit a MR shortly. > Missing license: > > CC0 via electrum/www/jquery-ui-themes-1.12.1/LICENSE.txt The jQuery UI themes license is covered by the following existing section in the copyright file: Files: electrum/www/jquery-ui-themes-1.12.1/* Copyright: jQuery Foundation and other contributors, https://jquery.org/ License: Expat Comment: Various authors are described in the electrum/www/jquery-ui-themes-1.12.1/ AUTHORS file. The CC0 license mentioned in the second half of electrum/www/jquery-ui- themes-1.12.1/LICENSE.txt specifically says, "Copyright and related rights for sample code are waived via CC0. Sample code is defined as all source code contained within the demos directory.” The demos directory is not shipped in the upstream tarball, so this license was left out of the copyright file as it does not apply to any files. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
For some reason, the plain text version of my previous email cut of the end (although it was included in the HTML version). I am sending just that part again in hopes it goes through in both plain text and HTML. > On Tuesday, October 18, 2022 1:41:51 PM MST Bastian Germann wrote: > The debian/copyright needs some more > changes. Search the upstream import commit for newly added copyright lines > and new license texts. I very carefully looked though all the files in the source and the output of licensecheck to create the copyright file. If you compare it to the copyright file from 4.0.9-1 you will see that it is much improved and fixes many inaccuracies that existed in the 4.0.9-1 Debian package. I am fairly sure that the current copyright file is comprehensively correct, but feel free to point out anything I have missed. On a different topic, I see that you replaced the included distutils with the Debian system one. Thank you for doing that. (I created an MR that updates debian/copyright to include your copyright on that patch.) -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
On Tuesday, October 18, 2022 1:41:51 PM MST Bastian Germann wrote: > Okay, those tests can fail. Still there is some stuff to do on the package: > Please fix the reprotest at > https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398402, which > used to passed Do you know why this is failing? The applicable line appears to be: Binary files /builds/cryptocoin-team/electrum/debian/output/reprotest/control/source-root/ python3-electrum_4.3.2+ds1-1+salsaci_all.deb and /builds/cryptocoin-team/electrum/ debian/output/reprotest/experiment-1/source-root/python3- electrum_4.3.2+ds1-1+salsaci_all.deb differ However, I can’t see any indication *why* they differ. I assume that is is building it in two ways and comparing the output, but I don’t understand what the difference between those two build environments are or why they are producing different output. > , and the lintian errors at > https://salsa.debian.org/cryptocoin-team/electrum/-/jobs/3398403: > > E: electrum source: source-is-missing [electrum/www/jquery-3.4.1.min.js] > E: electrum source: source-is-missing [electrum/www/jquery-ui.min.js] > E: electrum source: source-is-missing [electrum/www/qrcode.js] > > If the sources of these minified js files are included in the source tree, > add a lintian override with a comment where it is. Else, please add the > source to debian/missing-sources/. Extra points for replacing the files > with the versions from Debian packages (if possible). These same Lintian errors exist in the current 4.0.9-1 package. https://udd.debian.org/lintian/?packages=electrum[1] In preparing the 4.3.2 update I fixed all the Lintian errors that were directly related to the update as well as any of the low-hanging Lintian errors that did not require invasive changes to the package. My goal was to make contact with, Tristan Seligmann, the package maintainer and also coordinate with upstream about the best way to remove these files, instead using the jQuery that is included with Debian. If I am not able to contact Tristan Seligmann I plan on creating a future upload that does this work anyway, perhaps becoming the package maintainer myself. I also, at the same time, plan to make other more invasive package changes, like replacing the embedded version of Kivy with the Debian-packaged one and replacing the fonts that ship within the python3-electrum package with those in their respective Debian packages. Because this Lintian error existed in the previous packages and because it does not relate the RC bug that this upload is attempting to fix I was planning to wait for a future release to fix it. Do you think it would be best to deal with it now without input from Tristan Seligmann? > I reviewed your changes. Please do not introduce a compat file on packages > that already use debhelper-compat. Thanks for catching that. I went to fix it in the Git repository, but I see you have already done so. > The debian/copyright needs some more > changes. Search the upstream import commit for newly added copyright lines > and new license texts. signature.asc Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
On Monday, October 17, 2022 5:33:07 PM MST Soren Stoutner wrote:
> On Monday, October 17, 2022 5:13:21 PM MST Bastian Germann wrote:
> > Building on amd64, the package builds completely but dh_auto_test fails:
> >
> > [Nfc_manager ] Unable to find any valuable Nfc_manager provider.
> > ModuleNotFoundError: No module named 'electrum.gui.kivy.nfc_manager' File
> > "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> > core_select_lib mod = __import__(name='{2}.{0}.{1}'.format(
>
> Upstream electrum has the option to integrate with NFC hardware wallets. My
> understanding is that this has never worked in Debian, possibly because the
> version of Kivy that ships with Debian does not support it. I believe the
> current version of Electrum in Debian exhibits the same limitation. I
> would be interested in working with the correct people (upstream and Kivy
> maintainers) to enable NFC support in a future package, but I was hoping to
> make contact with the current Electrum maintainer (Tristan Seligmann)
> before chasing down something potentially that invasive. So far, Tristan
> has not responded to my emails.
This open feature request regards adding hardware wallet support. It is a
superset of the
missing NFC hardware support.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913758[1]
> > dummy - ModuleNotFoundError: No module named
> > 'electrum.gui.kivy.nfc_manager' File
> > "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> > core_select_lib mod = __import__(name='{2}.{0}.{1}'.format(
> >
> > [INFO ] [Window ] Provider: sdl2(['window_egl_rpi'] ignored)
> > [CRITICAL] [Window ] Unable to find any valuable Window provider.
> > (/usr/lib/python3/dist-packages/kivy/lib/vidcore_lite/__init__.py) File
> > "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> > sdl2 - RuntimeError: b'No available video device'
>
> Electrum has the option to run on the command line or in a GUI (hence, the
> two binary packages). The command line scripts emit errors explaining that
> you need a GUI if you try to use them to do functions that are GUI specific
> without having a functioning window provider. My guess is this error was
> produced because hd_auto_tests tried to call one of these options.
The python3-electrum package has command-line only use cases and doesn’t have
any
of the GUI dependencies. The electrum package depends on python3-electrum as
well
as having all the other GUI dependencies. This past bug report was a
discussion about
what the prompt should say if a person tried to run the GUI from the command
line
without having the proper packages installed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917032[2]
--
Soren Stoutner
so...@stoutner.com
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913758
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917032
signature.asc
Description: This is a digitally signed message part.
Re: Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
On Monday, October 17, 2022 5:13:21 PM MST Bastian Germann wrote:
> Building on amd64, the package builds completely but dh_auto_test fails:
> [Nfc_manager ] Unable to find any valuable Nfc_manager provider.
> ModuleNotFoundError: No module named 'electrum.gui.kivy.nfc_manager' File
> "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> core_select_lib mod = __import__(name='{2}.{0}.{1}'.format(
Upstream electrum has the option to integrate with NFC hardware wallets. My
understanding is that this has never worked in Debian, possibly because the
version of Kivy that ships with Debian does not support it. I believe the
current version of Electrum in Debian exhibits the same limitation. I would
be interested in working with the correct people (upstream and Kivy
maintainers) to enable NFC support in a future package, but I was hoping to
make contact with the current Electrum maintainer (Tristan Seligmann) before
chasing down something potentially that invasive. So far, Tristan has not
responded to my emails.
> dummy - ModuleNotFoundError: No module named 'electrum.gui.kivy.nfc_manager'
> File "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> core_select_lib mod = __import__(name='{2}.{0}.{1}'.format(
>
> [INFO ] [Window ] Provider: sdl2(['window_egl_rpi'] ignored)
> [CRITICAL] [Window ] Unable to find any valuable Window provider.
> (/usr/lib/python3/dist-packages/kivy/lib/vidcore_lite/__init__.py) File
> "/usr/lib/python3/dist-packages/kivy/core/__init__.py", line 59, in
> sdl2 - RuntimeError: b'No available video device'
Electrum has the option to run on the command line or in a GUI (hence, the two
binary packages). The command line scripts emit errors explaining that you
need a GUI if you try to use them to do functions that are GUI specific without
having a functioning window provider. My guess is this error was produced
because hd_auto_tests tried to call one of these options.
--
Soren Stoutner
so...@stoutner.com
signature.asc
Description: This is a digitally signed message part.
Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "electrum": * Package name : electrum Version : 4.3.2-0.1 Upstream contact : [fill in name and email of upstream] * URL : https://electrum.org/ * License : BSD-2-clause, Expat, OFL, DejaVu * Vcs : https://salsa.debian.org/cryptocoin-team/electrum Section : utils The source builds the following binary packages: python3-electrum - Easy to use Bitcoin client - Python module electrum - Easy to use Bitcoin client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/electrum/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/electrum/ electrum_4.3.2-0.1.dsc Changes since the last upload: electrum (4.3.2-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release (Closes: #1001064). * Switch to new "sourceonly" upstream tarball (see the upstream changelog for release 4.3.1). * debian/compat: Create file and set version to debhelper v13. * debian/control: Update debendencies. * debian/control: Bump Standards-Version to 4.6.1 (no changes). * debian/copyright: Update and reformat copyright and license information. * debian/electrum.install: Include the new electrum.png in usr/share/icons/hicolor/128x128/apps/. * debian/patches: Refresh 0001-Improve-message-about-PyQt5.patch. * debian/rules: Build paymentrequest_pb2.py from the .proto file and remove redundant license files from the binary packages. * debian/source: Remove unneeded include-binaries file. * debian/upstream: Strip extra signatures from signing-key.asc * debian/watch: Update to version 4 and refactor for "sourceonly" tarball. Regards, -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
