Re: Packaging an application with unpackaged dependencies
On 2024-05-24 16:39 +0200, David Given wrote: > I'm try to put together a package for a big, complex application. One of > its dependencies isn't in Debian yet. What do I do? Package the dependency first. > - package up the dependency and somehow get both packages sponsored at the > same time (how?); > - package up the dependency and get it sponsored first... meaning that I'll > be trying to get a library added which has no users. This is what I do. All packages have no users before they enter the archive so that's not really a problem. I quite often find that there in fact other packages using a library in the archive but they've bundled it (because that's easier and is often what upstream has done). So a 3rd step is to file patches for those other packages to use your library. sources.debian.org is a good place to look for such instances. You can do both at once but I find it easier if the libraries go in first, then you can be sure everything works without having to have 'special' build environment with your extra library packages present. Mostly it depends how fast you want to move. Either is fine. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: packaging help
On 2024-05-04 03:44 +, james smith wrote: > I am trying to package ly[1] I got everything up to the rules part, I am > stuck thinking on how to edit/make the makefile, if you have any tips or > tools that can make this a easier process, I would be much grateful Any editor will do - note that tabs are syntactically important in makefiles A tool like debmake will make you a template/base rules files (as well as sample/template/base all the other files), or you can copy-and-modify one from almost any other package that isn't hopelessly out of date (debmake is a better approach). These days most rules files look like: #!/usr/bin/make -f #DH_VERBOSE=1 %: dh $@ with maybe a few instances of environement variables and override rules # see ENVIRONMENT in dpkg-buildflags(1) export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic or override_dh_clean: -mv Doxyfile.orig Doxyfile -mv libsquish.pc.in.orig libsquish.pc.in dh_clean Does that help? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: How to name a similiar package?
On 2024-03-17 14:09 +0100, Sven Wick wrote: > Hi, > > I maintain the package **ssh-tools** > and upstream as well. > These are a mix of Bash and Perl scripts. > > Recently I do more stuff with Go > and have new tools written in Go > and don't want to mix them with the Bash and Perl Scripts > because that would be difficult to package (also for other Distros and OSes). > Currently it's ssh-toolz (with a "z") > since I found examples like **python3-toolz**. > But I also thought about ssh-tools2 sind there is **wget2**. > > Any suggestion what the best practice is to name similar packages? Are the new tools replacements or additional? I don't see why adding a 3rd language to the 2 already used makes things 'hard to package', but obviously if you want to have a separate upstream repository (e.g. because you want to supesede the old repository eventually) then that's up to you as upstream. > I am not sure how to name the new tools upstream repo > and therefore the package name. If the new stuff is intended to be a replacement then ssh-tools2 or ssh-tools-ng (for 'next generation') are typical patterns. If they are just more tools then ssh-tools-extra would make sense, or just keep them all in one package/repo as 'ssh-tools' which I think users would like best. ssh-toolz is fine as a name, but obviously users will have no idea what the difference between ssh-tools and ssh-toolz is, so at least be very clear in the long description, and give a clue in the short one if possible. And thanks for thinking about it before it's too late to fix. Names that are clear to users are definitely helpful. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Is there a way to set up a sid environment at this time?
On 2024-03-12 19:25 +0530, Shriram Ravindranathan wrote: > Dear Mentors, > > Unfortunately, my SD card got corrupted (SD Card moment) and I do not have > access to a sid environment right now. Is there a way to debootstrap a sid > environment for packaging (from trixie perhaps) while the time_t transition > is going on? Yes. I made one yesterday evening with debootstrap (for amd64) and it worked fine. But things are both in flux and in a less-than ideal state at the moment so I think it's a bit random exactly what does and doesn't work at any given moment. We are working on unbunging things so we can get back to our usual level of smooth updates soon. I expect unstable to be rather more unstable than usual for another week or two. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Rebuilding Debian packages
On 2024-03-04 08:18 +0200, Tommi Höynälänmaa wrote: > Hello > > If the dependency graph of a binary package in the unstable distribution is > changed (e.g. because of the 64-bit time_t transition) shall the binary > package be rebuilt in the distribution? Any package that has a direct dependency on a library package changing name due to the t64 transition will be rebuilt by the team managing the transition (once everything is available). i.e. package maintainers don't have to do anything specific. And this only applies to direct dependencies (on libraries), not other sorts of dependency, nor packages furtuer down the tree. I hope that answers your question? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: FWD: Copyright in LGPL projects
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. > 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. 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 ' Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1064346: Source is missing errors on HTML source files
On 2024-02-22 11:37 +0530, Shriram Ravindranathan wrote: > Thank you Bastien, > I tried doing this but it appears that the scripts to build these example > files all depend on having the highlight binary itself installed on the > machine. I am unsure whether it is okay to have the package depend on itself > for building. Packages that use themselves to build are problematic for bootstrapping and cross-building. When cross-building you can't (usually) run the binaries just built because they are the wrong architecture. When bootstrapping packages that depend on themselves cause dependency loops which are a pain (we can't build foo because we don't have foo yet). We have 'build profiles' (older name 'staged builds') to deal with this. i.e you define a minimum 'stage1' build profile which does not have the circular dependency (and the normal build which does) so the building of the final version can be automated. The choices here are to 1) use the binary just build during the build 2) have a self dependency and use a packaged binary 1) Is simple but prevents the package cross-building. Usually the best thing to do is just skip that part if cross-building (you can live without the examples) Just ensure that the build doesn't fail due to missing files. 2) Works for cross-building (by the magic of multiarch) but you should add a stage notation so it can easily be built for new architectures, which is a bit of a faff. In case '2' you have to worry about version skew. How much does it matter if examples/whatever are built with the previous/an older version of the package? Case '1' avoids this. This is very specific to the package in question: sometimes it needs to be exactly the same, sometimes a version from a decade ago will be just fine. This is the main reason people usually pick option '1'. https://wiki.debian.org/BuildProfileSpec https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/CrossBuildPackagingGuidelines All the above is quite a lot to take in, and you don't need to worry too much, but it is a good idea to at least have this stuff in the back of your mind when packaging. Ideally this would all work correctly on the whole archive, and packagers are the ones best-placed to stick in the necessary runes. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Building a package for arm64 only on amd64 machine
On 2024-01-14 20:31 +, David James wrote:
> Dear Mentors,
>
> I am trying to package a small library that will be a dependency for a larger
> application. The thing is the library will only be a dependency if the
> application is built on arm64. The CMake file has the lines:
> if ("arm64" IN_LIST ARCHITECTURE)
> add_subdirectory(oaknut EXCLUDE_FROM_ALL)endif()
>
> Oaknut is the library I'm trying to build. The problem stems from the fact
> that the tarball depends on the catch2, a package that contains
> Catch2WithMain.a. Oaknut won't build at all when I try to compile natively.
> When I try to cross compile to arm64 on my amd64 machine it gives me errors
> about relocations in ELF (62) related to /usr/lib/Catch2WithMain.a. I'm
> guessing that it's trying to link to the amd64 Catch2WithMain.a that is
> installed on my machine.
>
> Ideally, I would like to use the arm64 version of catch2, however I don't
> know how to specify this in the control file. If I run sbuild with
> --host=arm64, it fails in the same way as above because it's trying to
> cross-compile but with the amd64 version of catch2. If I put catch2:arm64 in
> the control file sbuild tells me "catch2:arm64 [is] not installable."
Debian builds (for the archive) are always native so you don't need to
specify foreign-arch build-deps like this. You might need to qualify
build-deps by architecture if they are actually incompatible, but in
this case you just build-dep on catch2. So it's always available, even
if it's only actually used for the arm64 build.
catch.hpp is an architecture-independent file (it's just a header) and
is exactly the same for amd64 and arm64 so installing catch2:arm64 has
exactly the same effect as installing catch2:amd64 anyway. Any issues
with linking are to do with cross-compilation, not what is being
installed.
> I am clearly going about this the wrong way. I don't know how I can build an
> arm64 only package and ensure it only uses arm64 build dependencies. Do I
> need to use a VM? If I can't get this library packaged, I would have to
> exclude arm64 from the software I am packaging, which I really don't want to
> do unless absolutely necessary. Any advice would be warmly appreciated.
This is debian so we try to avoid the use of bundled stuff, as you
know. The CMAKE file has an option "OAKNUT_USE_BUNDLED_CATCH" so
making sure that is off for your build is correct.
To test the arm64 build you need to use either real arm64 hardware or
a qemu chroot. Testing the cross-build is a different thing, and
whilst it would be good to have that working too, it won't be used by
the buildds.
I had a quick go with a trivial packaging and yes it didn't build on x86
/usr/bin/c++ -I/home/wookey/packages/oaknut/debian/oaknut-1.2.2/tests
-I/home/wookey/packages/oaknut/debian/oaknut-1.2.2/include -g -O2
-ffile-prefix-map=/home/wookey/packages/oaknut/debian/oaknut-1.2.2=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++20 -Wall -Wextra -Wcast-qual -pedantic
-pedantic-errors -Wfatal-errors -Wno-missing-braces -MD -MT
CMakeFiles/oaknut-tests.dir/tests/vector_code_gen.cpp.o -MF
CMakeFiles/oaknut-tests.dir/tests/vector_code_gen.cpp.o.d -o
CMakeFiles/oaknut-tests.dir/tests/vector_code_gen.cpp.o -c
/home/wookey/packages/oaknut/debian/oaknut-1.2.2/tests/vector_code_gen.cpp
/home/wookey/packages/oaknut/debian/oaknut-1.2.2/include/oaknut/feature_detection/read_id_registers_directly.hpp:
Assembler messages:
/home/wookey/packages/oaknut/debian/oaknut-1.2.2/include/oaknut/feature_detection/read_id_registers_directly.hpp:15:
Error: no such instruction: `mrs %r15,s3_0_c0_c0_0'
...
because indeed
include/oaknut/feature_detection/read_id_registers_directly.hpp
contains an asm section which is arm64 but not architecture gated in
any way so the scripts try to build it on x86 which is silly and won't
work. Is this library intended to only build on arm64?
I must admit to being a bit confused about the purpose of this
code. What does this code-generator do that gcc doesn't do? And why
would a complier for arm64 be written to only build on arm64?
Does the upstream _actually_ need oaknut, or would a normal assembler do? (gcc
or clang or tbb etc)
If the library really does only build on arm64 then putting:
Architecture: arm64
in th control file will mean it only gets built on an arch where it will build.
In this case the package that _depends_ on oaknut will need a
conditional dependency because oaknut will only exist on arm64, not on
other arches.
The syntax is:
Build-Depends: oaknut [arm64]
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: Questions about package dependencies with no upstream version
On 2023-11-21 16:39 +, David James wrote: > Dear Mentors, > > I would like to package the Citra emulator in the future. There are currently > a few dependencies that need to be added as packages before Citra itself can > be built from a tarball. > > A couple of these dependencies have no version upstream. Is there a precedent > for this? Can these dependencies be packaged? Yes. I normally use 'date' for unversioned software. It's important to use it in the right way so that if they start using versions later their '0.1' is newer than your made-up dates (which it won't be if you used the obvious '20231118' (version 20-million-ish)). So you need to version it like this: 0~20231118 0~20240315 etc This is in the debian docs somewhere, but I forget where. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Question about non-responsive key-signing mate
On 2023-11-14 19:11 +0100, Maarten van Geijn wrote: > I turn to you with this question: is there any procedure to persuade an > individual to sign a key he promised to sign during a key-signing meeting? No. It is always entirely up to them. [key was not signed] > Does this happen more often? Yes, lots of people you swap material/ID with may never sign your key. I am a very unreliable key-signer for instance. I often never get round to signing, or never uploading the sig, or not sending an email with the sig back, or sign things months or years later when I find the fingerprint stash collection. It's not personal. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
On 2023-11-11 19:36 +0530, Shriram Ravindranathan wrote: > when I run dpkg --print-architecture it says arm64 but when I run the > command arch it says aarch64. > Am I doing something wrong here? how do I get it to build for aarch64? Just to clarify your confusion: arm64 is the debian (and kernel) name for the architecture aarch64 is the manufacturers/GNU-toolchain name for the architecture They are the same thing, just different nomenclatures. dpkg-architecture -aarm64 will show you the various names/features. amd64 has the same situation with 'amd64' and 'x86_64' None of this has anything to do with your actual lintian error, as you have worked out :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Debian versioning question
On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote: > On 10.11.2023 03:10, Wookey wrote: > > Hi Wookey, > > > I think your options are > > 1) add an epoch (which exists to deal with this sort of problem) > > > Well, would like to avoid it, if possible. There is no real reason to avoid epochs but they always feel a bit 'ugly' so people do tend to avoid them if they can. > > 3) upload a 'nobbled' version number, which is often done to deal > > with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1 > > dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $? > > > You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b, > 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal > versioning? Yes, exactly (sorry my example was a bit confused - I had the 1.3.8 and 1.3.8a ordering backwards in my head, but it doesn't affect the mechanism). And yes, once you get to 1.3.9 you can go back to normal version numbering. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Debian versioning question
On 2023-11-09 23:06 +0100, Hilmar Preuße wrote: > On 10/13/23 01:32, Mattia Rizzolo wrote: > > On Thu, Oct 12, 2023 at 11:52:30PM +0200, Preuße, Hilmar wrote: > > Hi Mattia, > > > > The upstream minor versions are always determined by letters, so I'm > > > unsure > > > how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints? > I just noticed that it is not just a display issue on the web page, but a > real issue: my latest uploaded was rejected telling me: > > Your upload included the source package proftpd-dfsg, version 1.3.8a+dfsg-1, > however testing already has version 1.3.8+dfsg-8. > Uploads to unstable must have a higher version than present in testing. > > Can we override that anyhow? No. What's in the archive is in the archive. (Well I think you can ask FTPmasters to remove something but that usually needs a better reason, like "it contains illegal stuff"). > I can open an issue at upstream trying to > remove the RfC files, but I guess he's not really interested in these Debian > internals. Further it does not solve the issue for this particular upload. Right this is a Debian problem not upstream. I think your options are 1) add an epoch (which exists to deal with this sort of problem) 2) wait till the next (numerical) release 1.3.9 and upload that. Do releases happen often? This approach only really makes sense if you/your users can put up with the old version until a higher-versioned one appears 3) upload a 'nobbled' version number, which is often done to deal with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1 dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $? I'd probably go with option 3 in this case. Ugly but temporary. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Mysterious uscan problem
On 2023-10-31 04:57 +, Phil Wyett wrote: > On Tue, 2023-10-31 at 04:23 +0000, Wookey wrote: > > uscan is doing something very strange with version numbers and I > > don't understand what's going on. > > > > However, whilst it now finds the current v3.5.0 it insists that the > > version number is 3.5.0.3.5.0 > > So it downloads mbedtls-3.5.0.tar.gz but symlinks it as > > mbedtls_3.5.0.3.5.0.orig.tar.gz > > and then proceeds to put 3.5.0.3.5.0 for the version everywhere, > > which is clearly wrong. > > > > This is my watch file: > > version=4 > > opts="searchmode=plain, \ > > filenamemangle=s%v?@ANY_VERSION@%mbedtls-$1\.tar\.gz%, \ > > pgpmode=none" \ > > https://api.github.com/repos/Mbed-TLS/mbedtls/tags \ > > https://api.github.com/repos/Mbed-TLS/mbedtls/tarball/refs/tags/v(@ANY_VERSION@) > > debian uupdate > First change last line ending from: > v(@ANY_VERSION@) debian uupdate > to: > v?@ANY_VERSION@ debian uupdate > > and check results. OK. And that indeed fixes the problem. Thank you sir! But why? I thought brackets in regexes (this is a regex, right?) were just for saving matches into parameters. Why does it make the version number double-up in this case? (I see the brackets are only there because I changed this from an earlier version. They are not in the modern example for Github on the wiki any more) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Mysterious uscan problem
://github.com/ARMmbed/mbedtls/tags .*/v?(\d\S+)\.tar\.gz
debian uupdate
uscan info: Parsing filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/mbedtls-$1\.tar\.gz/
uscan info: line: https://github.com/ARMmbed/mbedtls/tags .*/v?(\d\S+)\.tar\.gz
debian uupdate
uscan debug: $self->{'pgpmode'}=default, $self->{'pgpsigurlmangle'}=undef
uscan info: Last orig.tar.* tarball version (from debian/changelog): 2.16.9
uscan info: Last orig.tar.* tarball version (dversionmangled): 2.16.9
uscan debug: watch file has:
$base= https://github.com/ARMmbed/mbedtls/tags
$filepattern = .*/v?(\d\S+)\.tar\.gz
$lastversion = 2.16.9
$action = uupdate
mode = http
pgpmode = default
versionmode = newer
$site= https://github.com
$basedir = /ARMmbed/mbedtls/
uscan debug: line: search()
uscan info: Requesting URL:
https://github.com/ARMmbed/mbedtls/tags
uscan info: redirections: https://github.com/Mbed-TLS/mbedtls/tags
uscan info: Matching pattern:
(?:(?:https://github.com)?\/ARMmbed\/mbedtls\/)?.*/v?(\d\S+)\.tar\.gz
https\:\/\/github\.com\/Mbed\-TLS\/mbedtls\/.*/v?(\d\S+)\.tar\.gz
uscan debug: Resolving urls with query part unimplemented
uscan info: Found the following matching hrefs on the web page (newest first):
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz (3.5.0)
index=3.5.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz (3.5.0)
index=3.5.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz (3.5.0)
index=3.5.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.1.tar.gz (3.4.1)
index=3.4.1-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.1.tar.gz (3.4.1)
index=3.4.1-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.1.tar.gz (3.4.1)
index=3.4.1-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.0.tar.gz (3.4.0)
index=3.4.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.0.tar.gz (3.4.0)
index=3.4.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.4.0.tar.gz (3.4.0)
index=3.4.0-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.5.tar.gz
(2.28.5) index=2.28.5-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.5.tar.gz
(2.28.5) index=2.28.5-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.5.tar.gz
(2.28.5) index=2.28.5-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.4.tar.gz
(2.28.4) index=2.28.4-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.4.tar.gz
(2.28.4) index=2.28.4-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.4.tar.gz
(2.28.4) index=2.28.4-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.3.tar.gz
(2.28.3) index=2.28.3-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.3.tar.gz
(2.28.3) index=2.28.3-1
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v2.28.3.tar.gz
(2.28.3) index=2.28.3-1
uscan info: Looking at $base = https://github.com/ARMmbed/mbedtls/tags with
$filepattern = .*/v?(\d\S+)\.tar\.gz found
$newfile =
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
$newversion = 3.5.0
$lastversion = 2.16.9
uscan debug: line: get_upstream_url()
uscan info: Matching target for downloadurlmangle:
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
uscan info: Upstream URL(+tag) to download is identified as
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
uscan debug: line: get_newfile_base()
uscan info: Matching target for filenamemangle:
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
uscan debug: safe_replace
input="https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz;
uscan debug: safe_replace with regexp=".+\/v?(\d\S+)\.tar\.gz",
replacement="mbedtls-$1\.tar\.gz", and flags=""
uscan debug: After filenamemangle: mbedtls-3.5.0.tar.gz
uscan info: Filename (filenamemangled) for downloaded file: mbedtls-3.5.0.tar.gz
uscan debug: line: cmp_versions()
Newest version of mbedtls on remote site is 3.5.0, local version is 2.16.9
=> Newer package available from:
=> https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
uscan debug: line: download_file_and_sig()
uscan die: Already downloaded a file named mbedtls-3.5.0.tar.gz: use
filenamemangle to avoid this [Devscripts::Uscan::WatchLine: 1241] at
/usr/share/perl5/Devscripts/Uscan/Output.pm line 77
TIA
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#1051879: RFS: ncdu/1.19-0.1 [NMU] -- ncurses disk usage viewer
On 2023-09-13 22:35 +0200, Christian Göttsche wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "ncdu": I have to go to a conference right now, but if no-one has sorted this by Tue next week I can do it for you (I use and enjoy this package). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
On 2023-05-16 14:46 +0200, Oliver Reiche wrote: >I'm basically aware of the build dependencies >policy and all of my binary and header-only dependencies are satisfied >from packages. However, my package additionally depends on 11 proto files >(i.e., architecture-independent interface of data encoding [1]) from >google-apis [2] and bazel-remote-apis [3] as a pure build dependency. ... >3. Taking the longer road and package google-apis and bazel-remote-apis >first. This is the right way to fix this. I noticed in 2021 whilst doing tensorflow packaging that quite a few packages were using parts of these but nearly everyone had just embedded some files. We do have parts of the api packaged (e.g ruby-googleapis-common-prootos-types, and there are also ITPs for python-google-api-core and ruby-google-apis-discovery-v1 from jan 2023) but not the whole thing for all the languages. So I started on fixing it properly, and have a build that works for C, C++, java, python3 and ruby, but some language bindings did not build, and clearly I stalled part-way through the process of fixing those. I'm not sure which bindings we actually care about and which we can leave for now. I think I started an email about this somewhere, but am failing to find it right now, so I can't remember exactly where I got to. >However, that raises a few more questions: > a. google-apis is not versioned/tagged upstream. What version would I >use? I've seen that Fedora uses the version string >"0-1.git". I used 0~0-1 to start with. 0~ is a quite a good way of versioning things like this that don't have versions. (that 0~ lets you switch neatly to real versions in the future should they appear). Adding git hashes mostly makes for unreadable versions and doesn't add much IMHO, but we can do that if it's important. > b. Where should proto files be installed to? I know that libprotobuf-dev >puts it in /usr/include, but /usr/share could be also viable. What is the >recommended location? Good question. The right answer may depend on the language. > c. As the file structure of google-apis changes rather frequently, >should there be any prefix, so multiple versions could be installed in >parallel? Debian generally tries to pick a version and make depending packages work with it, rather than try to suport multiple versions unless it really is necessary. I do not have a good feel for what the best approach here is, and would greatly appreciate input from someone more familiar with the codebase on what the best approach in debian might be. >Could you please comment on which option you would suggest to take, and >also briefly address the potential follow-up questions? I suggest we compare notes on this in a specific ITP bug for google-apis. If you have a bit of time to put into this it would be great to actully (finally) get this fixed for the general case. I can provide debian packaging and build expertise to complement your knowledge of google-apis. (and then maybe we can give bazel-remote-apis a very similar treatment). I will put my unfinished project on salsa, file an ITP, and find my notes, then mail you and we can see if we can sort this with a reasonable level of effort. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: GPG user ID policy - online persona/brand
On 2022-11-14 13:44 +, Dániel Fancsali wrote: >Hello, >I was just wondering the other day, what is and isn't acceptable as the >"user id" of my package signing key? >What if I have a separate online persona as a tech blogger, and I'd like >attach the packages I create to that brand? >Would the mentors project accept that? Would the debian mainstream accept >that, if I make it so far that I got to be part of the Debian project? >Is there any official policy/documentation/best-practices-list for this >situation? My understanding of policy is that what we really care about is that the GPG key securely attests to a particular identity. We prefer that to be somone's 'actual/real/offical' identity, but it can be another identity if it is consistently used. I believe we do have a few DD's that do not use their 'official/conventional' name within debian. I'm not sure what people would think of using a 'brand' identity, but it might be OK if that is how someone normally/consistently presents themselves within debian. This is just my personal understanding. I'm fairly sure there is some actual policy written down somewhere, probably in the 'DD/DM application process' info. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel
On 2022-11-01 08:57 +0500, Akbarkhon Variskhanov wrote: > On Mon, Oct 31, 2022 at 7:02 PM Wookey wrote: > > The description could be more useful. > > "The plugin supports common mathematical operators (+, -, *, /, ^) with > > usual > > precedence rules, and some common functions such as abs(x), sqrt(x), sin(x) > > and cos(x)." > > If it were possible, I wouldn't even write a long description for this > package. I feel like repeating what's already there in the short > description is counter-productive, You may feel that, but I disagree. Good descriptions, both long and short, are important. Imagine somone reading through a list of our thousands of packages (who maybe never have even _heard_ of XFCE) when writing descriptions. The description needs to tell them enough to decide whether or not they might want to install this thing. > and Xfce panel plugins are Xfce > panel plugins. They depend on having xfce4-panel and anyone who's ever > used Xfce knows where their panel is, what their panel has. Besides, > I'm completely lost as to what else I can say here (aka lacking > creativity). It is an Xfce panel plugin (determined by its name > already), provides a calculator functionality on the Xfce panel > (again, it's in the name). Hence, I've been using XFCE daily for 20 years and I'm still asking for a more useful description because I _don't_ know what this package is/does. What you've said above is pretty good, and I've now actually tried it, so I came up with this: "An XFCE desktop panel plugin, which provides a 'paper mode' style calculator as a box in the panel." The important distinction here is between something that launches a desktop calculator or something that provides a box in the panel that will do calculations. It sounds from what you have said that it is the latter (and I have just installed it to check that that is indeed the case). I was actually a lot more excited about it when I thought it was a quick way to keep something like galculator to hand. > > It needs to say what this _is_. Perhaps something like > > "Provides on-screen calculator from toolbar", then details as above. > > would be wrong, and even with corrections, pointless and/or duplicated info. That fact that I got it wrong after reading your ITP and examining the packaging illustrates the need for the description to clarify what the package actually is/does. > Let me contact upstream for their explanation and rationale for > including LGPL in the source tree. That'll be the best way to work out what was intended. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel
On 2022-10-30 21:54 +0500, Akbarkhon Variskhanov wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "xfce4-calculator-plugin": > > * Package name : xfce4-calculator-plugin >Version : 0.7.1-1 >Upstream contact : > https://gitlab.xfce.org/panel-plugins/xfce4-calculator-plugin/-/project_members > * URL : > https://docs.xfce.org/panel-plugins/xfce4-calculator-plugin/start > * License : GPL-2.0+ > * Vcs : [fill in URL of packaging vcs] >Section : xfce Thanks for packaging this. > The source builds the following binary packages: > > xfce4-calculator-plugin - calculator plugin for Xfce panel The description could be more useful. "The plugin supports common mathematical operators (+, -, *, /, ^) with usual precedence rules, and some common functions such as abs(x), sqrt(x), sin(x) and cos(x)." It needs to say what this _is_. Perhaps something like "Provides on-screen calculator from toolbar", then details as above. I'd add Adrian Dimitrov to the copyright list and the package includes the LGPL COPYING.LIB at top level, although it's not obvious if that actually applies to any of the code. If it does then the LGPL should be listed (maybe you already checked this?). Otherwise it looks fine. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021364: RFS: ghostwriter/2.2.0-1 [RC] -- Distraction-free, themeable Markdown editor
On 2022-10-10 23:56 +0200, Sebastien Chavaux wrote: >Good evening; >I set build dependency in debian/control file "node-react" and >"libs-mathjax". For now and to test if the package builds well, I removed >the 3rdparty/MathJax/ and 3rdparty/react/ sources. It builds and works >well that way. What would be best next, remove those two folders from >sources, leave them but ignore them, or whatever? How should I do the >thing? Either complies with policy. There is nothing wrong with the 3rdparty stuff from a copyright POV. However, I prefer to remove it as it often makes a dramatically smaller source package, and avoids accidental regressions (to using the embedded copy) in later updates. It's good practice to adjust the version number to show that the tarball has been repacked from what upstream released. Just put 3rdparty into files-excluded: in the debian/copyright file, and setup up the watch file to repack/rename. https://wiki.debian.org/Javascript/Repacking https://wiki.debian.org/UscanEnhancements Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1021364: RFS: ghostwriter/2.2.0-1 [RC] -- Distraction-free, themeable Markdown editor
On 2022-10-10 17:30 +0200, Sebastien CHAVAUX wrote: >Hello, Thank you for the advice, precisely I'm curious, I would be >interested in replacing all his "needs" of the "3rdparty" file by what is >available in the Debian repositories, is this possible? It is recommended where possible. > How should I go >about it? I just have to name them in the debian/control file as >"Build-Depends"? Ideally, that is all that is required. You may have to adjust internal paths to make sure that the system version (in /usr/share/javascript) is used (referred-to as http://localhost/javascript/) If that version is too old then investigate if it can be updated (without breaking other depending packages) If the package is not yet present then ideally package that too. Info here: https://wiki.debian.org/Javascript Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Self dependent package, build profiles and buildd servers
On 2022-09-20 13:20 +0200, Fab Stz wrote: > Ok I just tried this by adding dependent targets in d/rules. It was a bit > tricky to do so as to still use dh at the same time but it seems to work. > Thanks for putting me on the way. > > However, what is actually the difference between the two alternatives you > mention? Build twice vs build twice the binutils way ? The distinction I was making was a) build twice but only put the final build in a binary package b) build twice and make two debian packages > The d/rules actually configures/builds first the host-build, which I'm able > to > use directly in the configuration parameters when configuring/building the > android-build (which is the second build performed automatically). > In the end, this produces pkgA & pkgB binary packages all with a single dpkg- > buildpackage run. OK. But do people really need both packages in the archive? Or is only the pkgB actually useful? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Self dependent package, build profiles & buildd servers
On 2022-09-17 10:25 +0800, Paul Wise wrote: > On Fri, 2022-09-16 at 19:53 +0200, Fab Stz wrote: > > > How does is this actually managed on the official buildd servers? How > > does it actually know which DEB_BUILD_PROFILES to apply on each run? > > The Debian buildds currently do not have support for build profiles, > for now build profiles are only for bootstrappers/porters/maintainers. > > It sounds like you are going to have to fix the upstream build system > to use the first build products during the second build product build. As Paul says, build profiles will not help here if you have to do this _every time_ you build the package, as opposed to doing it once, then using that to build the real package the first time in order to get it ready for the archive. i.e. build profiles are for bootstrapping, and the results do not end up in the archive. The normal way to fix this in Debian is for the debian build to run the build twice, using the components built on the first run for the second run. Can you do this easily, or do they have to be installed in system paths to work? You can also have the debian build run the build twice, one producing pkg-A and one producing pkg-B, so that both end up in the archive. Binutils is an example of a package that does this (building both native and cross versions). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Do autopkgtest for non-listed architectures prevent migration?
On 2022-01-22 15:06 +0100, Markus Blatt wrote: > For why 32bit architectures are not listed: > Many tests of the buildsystem of the upstream package fail because of Y2K38 > bugs. > Upstream does not see that as a problem as running a simulation on these > architectures > or simulations of just 16 years is not a goal. Fixing this in Debian would be > much hard work and might not be worth it. Which is why would like to prevent > it. If the package builds on the 32bit arches then I would advise that you let it build. We always try to build for all arches in debian and it is very annoying if you have say an armhf machine and something is not available just because there was some test failure so upstream simply excluded builds completely. Packges should only be excluded on an arch if they are known not to build or to be genuinely useless there. If there are too many problems with the tests to fix for now then don't run the tests on those architectures, or mark them in the autopackage tests as expected to fail (Not sure if we support 'test X on arch Y known to fail' markings, but if we do then such markings would be best). As Hilmar pointed out you mark which arches to run tests on separately from which arches to build. If the package is available then maybe someone who cares will fix it. If it isn't they probably won't even try. A note in the Debian.README about this known issue would be helpful. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: The purpose of marking a package Multi-Arch: foreign
On 2022-01-16 12:56 -0500, Tong Sun wrote:
> On Fri, Jan 14, 2022 at 4:42 PM Tong Sun wrote:
>
> I have a question regarding marking
> golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign
> what's the purpose of it?
>
> I did find an explanation from https://wiki.debian.org/Multiarch/HOWTO:
>
> > If a package is marked 'Multi-Arch: foreign', then it can satisfy
> > dependencies of a package of a different architecture (e.g
> > 'debhelper:amd64' will satisfy a dependency on debhelper for
> > any-architecture package).
>
> Yet, I'm unable to digest that -- e.g., why an arm64 architecture
> needs dependencies of a package from amd64?
I find it helpful to think of packages as 'tools' or
'libraries'. Tools are those packages marked MA:foreign, and their use
is architecture-independent. e.g. 'doxygen' or 'ps2pdf' does the same
thing whatever arch you run them on - they spit out some
documentation. If when cross-building for arm64 (on amd64) the build
asks for 'ps2pdf' to process a file, it's fine if that dependency is
fulfilled by the amd64 ('foreign arch') version. For things like
libraries the build-dependency can only be satisfied by a
matching-arch (arm64 in this case) package, because library linking
only works between libraries of the same architecture.
The point being than when cross-building on amd64 you cannot run most
other architecture tools. Only amd64 (and i386) will actually work, so
it is usless to satisfy a build-dependency for something that will
actually get run ('tools') with an arm64 arch package.
Does that help?
>
> I guess I don't understand the concept and implication of Debian's
> cross built, as I see that easygen is being cross built without
> 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev
> is not, despite having the 'Multi-Arch: foreign' .
>
> https://buildd.debian.org/status/package.php?p=easygen vs.
> https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser
This is not cross-building. This is native building. Cross-building is
building one package on a machine of another architecture.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: Bug#1003306: RFS: mbedtls/2.28.0-0.1 [NMU] -- lightweight crypto and SSL/TLS library
On 2022-01-08 16:54 +0100, Andrea Pappacoda wrote: > > Il giorno sab 8 gen 2022 alle 01:52:47 +, Wookey > ha scritto: > > However, I have already packaged v3.0.0. It's not been uploaded yet > > because it fails some tests intermittently, and I am in discussion > > with upstream about why this only happens sometimes. That has been > > stalled for a while so maybe I should just upload this 2.28, but it > > might be worth me giving them a prod and us waiting another week or so > > to see if v3.0.0 will happen? > > Hi, thank you for your reply! I have not packaged 3.0.0 myself because it is > not an LTS release, and I believe that packaging an LTS version is > preferable for how Debian releases work. That's a very good point. Although I kind of assume we'll get another LTS release before bookworm so it may not matter that much in practice. I guess we shouldn't rely on there being another LTS release in time (or that it gets packaged) so sticking with 2.28 does make sense. > Also, packaging LTS versions is preferable for licensing issues. MbedTLS is > usually released under the terms of the Apache 2.0 license, while LTS > versions are licensed under the Apache-2.0 OR GPL-2.0-or-later OK. I had not appreciated that the LTS and dev versions have different licencing. I don't see how they can do that in practice. The requirement is to make all contributions under both apache-2 and GPl2-or-later, so surely that always applies to whatever is in the dev repo, whether or not it is officially sanctioned as a dual-licenced LTS release? (maybe they miss some non-GPL bits out of the LTS releases?) > When the MbedTLS developers will release an LTS version of the 3.x branch > I'll be happy to work on it, and we could help each other too - we could > even unofficially co-maintain the MbedTLS package starting from now, as the > original maintainer has not responded to my emails in months... My interest was primarily via work as there have been significant optimisations on the ARM side in recent versions, hence updating what was in bullseye. But I didn't go beyond 2.16 then because there were API changes which would require updates in other packages and that would have been too intrusive at that time. I don't actually use this code, so I'm very happy if you actually want to look after it without me sticking my oar in. But equally I can help out too if you'd prefer to do it that way. I just tested 3.1.0 and it has the same problem as 3.0.0 with test failures. So I'll pester upstream. Hmm. And with your 2.28. That's interesting (maybe it's my sbuild setup?): The following tests FAILED: 79 - psa_crypto_persistent_key-suite (Failed) 82 - psa_crypto_slot_management-suite (Failed) 84 - psa_crypto_storage_format.current-suite (Failed) 85 - psa_crypto_storage_format.v0-suite (Failed) 86 - psa_its-suite (Failed) Errors while running CTest make[2]: *** [Makefile:74: test] Error 8 make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j12 test ARGS\+=--verbose ARGS\+=-j12 returned exit code 2 We should probably take it off debian-mentors at this point to discuss the boring details Although one item is worth public discussion: You changed the watch file to only look for updates to version 2.28, as opposed to updates in general. So if I run uscan under 2.28 it tells me there are no updates, even though 3.1.0 is available upstream. I'm not sure if that's the right thing to do? Even if we've decided that only LTS releases are going in debian, as a packager I still expect uscan to show me what's available? Not sure if polcy has anything to say about this? (also is it really better to rely on the github API than just downloading files?) I guess we could put sections for both 'this LTS' and 'all versions' into the watch and one could uncomment-as-desired. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#1003306: RFS: mbedtls/2.28.0-0.1 [NMU] -- lightweight crypto and SSL/TLS library
On 2022-01-07 22:46 +0100, Andrea Pappacoda wrote: > I am looking for a sponsor for my package "mbedtls": > > * Package name: mbedtls >Version : 2.28.0-0.1 Thanks for doing that. I'm happy to upload it in principle (subject to a look over the details). However, I have already packaged v3.0.0. It's not been uploaded yet because it fails some tests intermittently, and I am in discussion with upstream about why this only happens sometimes. That has been stalled for a while so maybe I should just upload this 2.28, but it might be worth me giving them a prod and us waiting another week or so to see if v3.0.0 will happen? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Salsa Maintainer access
On 2021-04-21 18:54 +0100, Peter wrote: > Hi, > > I am the maintainer of flam3 > https://tracker.debian.org/pkg/flam3 <https://tracker.debian.org/pkg/flam3> > > > Could someone grant me access to the VCS, so I can bring it up to date? > https://salsa.debian.org/debian/flam3.git > <https://salsa.debian.org/debian/flam3.git> Hmm, last touched 3 years ago. A long way behind the package. Done. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#985893: Forking on MMSD
On 2021-04-14 18:39 +, Marius Gripsgard wrote: > I would really like to avoid a fork, it's not worth doing dual > work. Did you ping ofono devs at irc? Also have you sent upstream > patches? If a fork is the way you want to go, you will need to > rename it as the existing packages need to follow upstream, we can't > just rip an existing packages away from upstream. Debian can package mmsd with whatever set of patches it sees fit. If the end result is ChrisT's version, with Modem Manager support, then I think that's reasonable. mmsd is not currently packaged in debian so I don't think a rename is required. Ultimately it's up to maintainers to choose which upstream is most appropriate. There used to be only one, but increasingly one gets a choice of varying degrees of active maintenance. (This can be a huge pain making life quite awkward for maintainers, and I find Debian is the only org trying to unify a diverse set of versions where a load of people have scratched their own itch and then just left it like that.) Ultimately we want the best functionality for our users, and if the old upstream has been inactive for years then using this new, maintained version of mmsd may well be the best course. Efforts should continue to either give Chris access to the original repo or officially declare it 'under new management' so that there is a canonical place for the codebase, but in the meantime it's OK for debian to have a big patch. Versioning could be tricky in some situations, but SFACT the ofono mmsd is just 0.0 so the debian version can be 0.0.something and remain compatible with a shift back to that repo at some point. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#981715: RFS: xpra/3.0.9+dfsg1-1.1 [NMU] [RC] -- tool to detach/reattach running X programs
On 2021-02-02 23:42 -0700, Antonio Russo wrote: > I am looking for a sponsor for my NMU of the "xpra" package, which is blocked > migrating to testing for the last ~6 months [1] due to a FTBS on armel and > armhf [2]. > > Also, I do not have access to arm* hardware to test this on, so, while I can > confirm that this builds (and works) on amd64, it would be nice if someone > could check that it works correctly on arm. I've tested the builds on arm64 and armhf. I'm short of non-headless boxes here to test the X functionality on. So I've uploaded to get the migration going and allow others to test. I should be able to contrive a non-headless armhf machine too, given a bit of time (not today) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Package ghostwriter E source-is-missing
On 2021-01-24 12:05 +0100, passiongnuli...@gmail.com wrote: > hello Robin, > > Thanks for this answer, I suddenly have to remove the "3rdparty" folder > from the sources, because otherwise Lintian will give me other errors > and look for dependencies from the Debian repositories. Am I good? Oh, and I forgot to say; once you have worked out how much of the 3rdparty dir to get rid of (ideally all of it), the right way to repack the upstream source is to use 'Files-Excluded:' in the copyright file, indicate that it is repacked in the version numer, and modify the watch file to do the renaming. Details are described here: https://wiki.debian.org/Javascript/Repacking i.e don't just manually delete the dir and then call that file 'orig' because it's not the original source tarball/git checkout (even though it should be if the world did things properly, like wot we do :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Package ghostwriter E source-is-missing
On 2021-01-24 12:05 +0100, passiongnuli...@gmail.com wrote: > hello Robin, > > Thanks for this answer, I suddenly have to remove the "3rdparty" folder > from the sources, because otherwise Lintian will give me other errors > and look for dependencies from the Debian repositories. Am I good? That is quite a good way to deal with the issue. It stops you shipping code that is not strictly free software (not in preferred form), removes bloat, and ensures that system versions of libraries are being used (you may need to patch upstream to make this actually work - just removing the dir may or may not be sufficient depending on how the code is linked/used. You may also find that _some_ of the 3rd party stuff is not in debian already so you will need to package that first. Or you may find that it is modified from the debian versions (in ways that matter) in which case you need to get thosepatches into the debian package, or stick with the 3rd-party version. Or it requires a different version from the one(s) available in debian inwhich case agin you either need to fix it to work with the version in debian or stick with the 3rd-party version. Does that all makes sense? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#978724: RFS: dhcpcd-dbus/0.6.1-1 [QA] -- DBus bindings for dhcpcd
On 2020-12-30 18:39 -0300, Leandro Cunha wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "dhcpcd-dbus": > > * Package name: dhcpcd-dbus > Version : 0.6.1-1 > Upstream Author : Roy Marples > * URL : https://roy.marples.name/projects/dhcpcd > * License : BSD-2 > * Vcs : [fill in URL of packaging vcs] > Section : net > > It builds those binary packages: > >dhcpcd-dbus - DBus bindings for dhcpcd > > To access further information about this package, please visit the following > URL: > >https://mentors.debian.net/package/dhcpcd-dbus/ > > Alternatively, one can download the package with dget using this command: > >dget -x > https://mentors.debian.net/debian/pool/main/d/dhcpcd-dbus/dhcpcd-dbus_0.6.1-1.dsc > > Changes since the last upload: > > dhcpcd-dbus (0.6.1-1) unstable; urgency=medium > . > * QA upload. > * New upstream release. > * Fixed Lintian reports. > * debian/control: > - Bumped Standards-Version to 4.5.1. > - Added Rules-Requires-Root: no. > - Updated homepage field. > * debian/watch: > - Fixed problem to import tarball via uscan. > - Updated version of 3 to 4. > * debian/copyright: > - Updated year upstream author. > - Updated source field. > - Updated file following DEP-5. > - Added files debian/* and people involved with year of contribution. > - Added myself. > * debian/rules: > - Set ignore dh_auto_test to fix FTBFS (Fails To Build From Source) and > thanks to Simon McVitie maintainer of the dbus who helped me with > this. > * Added debian/gbp.conf. > * Added debian/upstream/metadata. > * Added debian/test/control to autopkgtest. > * Added debian/salsa-ci.yml. OK. That all looks sensible. I note that lintian complains about the dbus policy: W: dhcpcd-dbus: dbus-policy-without-send-destination etc/dbus-1/system.d/dhcpcd-dbus.conf https://lintian.debian.org/tags/dbus-policy-without-send-destination.html says: The package contains D-Bus policy configuration that uses one of the send_* conditions, but does not specify a send_destination, and is not specific to root. Rules of the form allow messages with the given interface to be sent to any service, not just the one installing the rule, which is rarely what was intended. Similarly, on the system bus, rules of the form are redundant with the system bus's default-deny policy, and have unintended effects on other services. This check ignores rules of the form which are commonly used for the "agent" pattern seen in services like BlueZ and NetworkManager: a root-privileged daemon calls out to one or more per-user user interface agent processes with no specific name, so send_destination is not easily applicable. However, such rules should still be made as specific as possible to avoid undesired side-effects. - I'm not sure if this is something that should be fixed or ignored? The config file has not changed from what is in the current version and the file _does_ seem to specify a send_destination, so is there in fact a lintian bug? http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression
On 2020-06-11 17:58 -0400, Qianqian Fang wrote: > I hope these are acceptable solutions. the only error left is the "UNRELEASED" > in the changelog. should I set it to "unstable"? Yes. dch -r is the conventional way to do that (and change the timestamp at the same time), but you can just edit it. The idea is that you leave it as 'UNRELEASED' until you really have stopped fiddling and are ready to upload. Some tools take note of this field to stop you accidentally uploading before you are ready. (I don't personally find this useful, but that's why it's there). > will the package be backported > automatically in the future to stable? No. Someone will have to do the work of making any adjustments needed to build in stable and doing an upload to -backports. That can't be done until after it has been accepted into the archive (which can take a while (days to months) after initial upload). https://wiki.debian.org/BuildingFormalBackports https://wiki.debian.org/Backports Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Looking for help towards my first Debian package (ITP#962603)
On 2020-06-11 15:35 +0800, Paul Wise wrote: > Looks like what you haven't isn't correct, it should be libzmat1 > instead of libzmat in the control file, since the library package name > is supposed to be based on the SONAME of the library. Are you sure you are not being excessively categorical here? libzmat1 is preferred, but libzmat is not 'wrong'. (Hmm, checks policy - OK, maybe it is wrong :-) The point is that when the SONAME is included in the package name then packages depending on this library can transition to the new libzmat2 one by one, as they are built after the SONAME=2 version of zmat is uploaded one day. Older packages built earlier which depend on libzmat (SO=1) and depend on libzmat1 package carry on working and libzmat1 package stays on the system until nothing depends on it any more because the depending packages have all been upgraded to depend on libzmat2. If you just have 'libzmat' then this process is not possible and when you upload a new libzmat (SO=2) one day all the packages that depend on it have to be rebuilt against the new version, and only when all are done can the packages transition into testing. In practice this can cause huge delays, so we developed the practice of putting SONNAMES into package names to make the whole thing work rather better. So if for some reason it is not safe to have two versions of the library simultaneously installed then an unversioned library package (libzmat) makes sense but that's rare. So Bouyang's "Either one is okay in this case." is misleading. The -dev package should usually not contain the SONAME in the package name - that's only needed when you need people to be able to link explicitly against libzcat1 or libzcat2. (makes sense for something like a big GUI toolkit: QT4 and QT5, but not a leaf compression library) Library naming conventions are subtle and the reasons for _why_ one might want to do one thing or another are not obvious. Details are given in policy: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.
On 2020-05-27 09:26 +, Vasyl Gello wrote: > >You should be building your packages in a chroot (possibly using wrapper > >tools such as pbuilder or sbuild) to, as from what you said you aren't > >building them in sid. > > I am building in chroot but targeting buster as primary target of this chroot > is Kodi :) OK, but you have to build new packages in a sid chroot too to check they work, as that's the suite they get uploaded to. It's fine to package in such a way that the package also builds in buster, but the primary target of a new package in debian is always sid (unstable). The sbuild-debian-developer-setup package provides a very convenient way to set this up if you haven't already. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Question about naming
On 2020-04-22 15:13 -0400, Aaron Boxer wrote: > > > Thanks a lot, Wookey! I think I will just change my library name. At this > stage, no other libraries > that I'm aware of are relying on the name. Right. If you are upstream and can do this, then yes just picking a non-clashing name is the best plan, removing all difficulties. There is a basic assumption that all pubic library names are unique. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Question about naming
On 2020-04-22 11:13 -0400, Aaron Boxer wrote: > Hello!, > > I have created a new package for a library (grok) with the same name as an > existing debian package, so I have named my package grok-jpeg2000, because it > is an image coder for the JPEG 2000 standard. Will this mismatch between my > library name and my package name be a problem getting the package accepted ? No. You can call the package whatever is reasonable, and of course avoiding name clashes is necessary. And the source package name can be nearly anything. However you can't (easily) just rename the library itself, because things that depend on it will look it up by name and fail to find it. This is fine - that package can be grok-jpeg200 (I see arch linux has used the same name), and the library libgrok-jpeg200 or libgrokn-jpeg2000, but the _binaries_ it installs are /usr/lib//libgrok* That means that even with the binary package name clash avoided it will not be co-installable with the other libgrok, because both provide /usr/lib//libgrok. That may or may not be a problem in practice (would anyone ever want both?) In this case you should mark both packages as conflicting. Not idea, but hard to fix. You could fix this by using a different library name and fixing up the name in all packages that depend on it, but that would still be a problem for compiling external projects that depend on this libray. They may have wildly differing sonames and rates of change that are likely to avoid filename clashes that way (i.e there would be /usr/lib//libgrok.so.1 in libgrok1 and /usr/lib//libgrok.so.23) in libgrok23, and not much danger of the first putting out 22 more versions without the 2nd advancing, although there is always some risk of that going wrong one day. The best thing to do depends on the popularity and satbility of these projects and how many other packages/external projects use them. Contacting the grok maintainer to discuss what would be best is in order IMHO Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Git bare debian repository format and python packages
On 2020-04-22 13:28 +0200, Birger Schacht wrote: > Hi *, > > I am a fan of the git bare debian repository format. I am using gbp to > build my packages: > gbp buildpackage --git-builder=sbuild -A -v -d unstable > --source-only-changes > > Usually that works without problems, but with python packages, when > dh_auto_clean is run *before* the sources are extracted that leads to > the build process being stopped :( > dh_auto_clean runs pybuild --clean (in my case its set to use distutils > as buildsystem) which does not find a `setup.py` which leads to an error > which stops the whole build process. > Is there a recommended way of handling this situation? It is a feature of the way sbuild works that 'debian/rules clean' is run in the containing OS, not in the chroot, in order to make the source. Lots of packages have dependencies used in the clean rule, and these are not declared separately from the normal build-dependencies. To build these with sbuild you need to have those dependencies installed in the outside OS, and hope that the likely differences in version between inside and outside do not matter. Fortunately there is a farily small set of packages that will let you run the clean rule on the vast majority of debian packages. I am not aware of any better solution than simply installing those dependencies in the containing OS. I would be useful to maintain a list somewhere, or even a metapackage, so people who wanted to reliably build every package using sbuild had an automated way of doing it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: sbuild & cross build
On 2020-04-15 00:02 +0200, Hilmar Preuße wrote: > Hi, > > I'm pretty sure this is a dumb question. I'm using sbuild to cross > compile packages, e.g. texlive-bin. This works fine for release arches. > Now I try to build for a non-release arch like this: > > sbuild --host=sparc64 -d unstable --extra-repository='deb > http://ftp.de.debian.org/debian-ports unstable main' > --extra-repository-key=/usr/share/keyrings/debian-ports-archive-keyring.gpg > texlive-bin > > The build fails, the build log tells me that some B/D's could not be > fulfilled. However I know that the packages in question do exist for > that arch. What am I missing? It's because libc6 is out of date on sparc64 compared to amd64 (the arch I assume you are building on) (unstable-amd64-clean-home)wookey@e110476-lin:~$apt policy libc6-dev:sparc64 libc6-dev:sparc64: Installed: (none) Candidate: 2.30-2+sparc64 Version table: 2.30-2+sparc64 500 500 http://ftp.de.debian.org/debian-ports unstable/main sparc64 Packages -bash: __git_ps1: command not found (unstable-amd64-clean-home)wookey@e110476-lin:~$ apt policy libc6-dev libc6-dev: Installed: 2.30-4 Candidate: 2.30-4 Version table: *** 2.30-4 500 500 http://deb.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status -bash: __git_ps1: command not found you can't install mismatched versions of libc6 so none of the cross-dependencies will install. Once glibc 2.30-4 is built on sparc64 theings should work (so long as no other libraries are version-skewed). Building in testing is one way to avoid this problem, if that's any use to you. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Seeking Daniel Schepler
On 2020-01-18 12:34 +, David Griffith wrote: > > I'm trying to get in touch with Daniel Schepler . He > maintains several packages related to Interactive Fiction and I have some > private questions about some stuff he has written. Has anyone communicated > with him recently? He's been discussing stuff on debian devel this week, using Daniel Schepler So yes, he's active and around. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Understand Debian Keyring
On 2020-01-05 10:01 -0500, Tong Sun wrote: > Now, before I redo the upload (and get it stuck again), let me try to > understand the situation -- > > The reason it was stuck might be because my key was *considered* > expired. The problem is, I renewed it two or three weeks ago, and sent > it to pgp & > Ubuntu key servers. > > The mentors.debian.net accepted my (renewed) key, but ftp-master > didn't. Might that my key on ftp-master.debian.org is somehow not > refreshed? Anyway, I tried to fix the issue by refreshing my key to > keyring.debian.org. However, on reading https://keyring.debian.org/, I > stated to wonder that if it good enough *now*: > > > We will include your changed key in our next keyring push (which happens > > approx. monthly). > > What does it really mean? Shall I need to wait a month before uploading again? One thing is check that you are signing the packages with the new key and not the old one (not sure if 'renewing' counts as a new key or not?). If both are around (gpg -K will show available secret keys), it's very easy to sign with the wrong one, and then ftp-master quietly throws away your packages without telling you. I know this because I've had this problem for some time (my machine defaults to using the wrong key despite having default-key set in .gnupg/gpg.conf so I have to sign with an expicit key (debsign -k)). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: debhelper versions
On 2019-11-22 14:10 +0100, Ake Hedman wrote: > Hi, > > I am packaging a bunch of projects that are supposed to install on > Ubuntu/Debin/Raspian preferable on as old versions as possible. I am > trying to make scripts that make the packages automatically with > pbuilder and I get a bit confused on how to handle the different > debhelper versions. > > For example I have the dependency setting in the debian/control file. If > I want it to work for raspian jessie i need to set this to debhelper (>= > 8) On buster it is (>= 11) and on Ubuntu there is other versions etc. Set both the dependency and the 'compat' file to the oldest one you need (e.g. '8' for Raspian jessie in this case). That should continue to work everywhere (until actually deprecated in debhelper). Ignore Lintian if it grumbles and only move it up when you are no longer supporting something that only has '8'. > And should the compat file be 11 in all cases? No, the compat file should match the dependency, and determines the actual behaviour of debhelper in the packaging. i.e. that's the important bit, and the control file dependency is just being set to match. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Sharing a script between two "Multi-Arch: foreign" packages
On 2019-08-06 16:45 +0200, Jens Reyer wrote: > Hi all, > > is there a way for two different, arch-specific packages (from the same > source package) to share an identical file (script)? Only if those two arch-specific packages have the same name - i.e. they are the 'same' package from dpkg's point of view, just arch-specific variants of it. > This works for "Multi-Arch: same" packages: > $ dpkg -S /usr/share/doc/libwine/changelog.Debian.gz > libwine:i386, libwine:amd64: /usr/share/doc/libwine/changelog.Debian.gz > > > $ dpkg -S /usr/lib/wine/wineserver > wine32:i386, wine64:amd64: /usr/lib/wine/wineserver If I understand correctly you want 'wine32' and 'wine64' (different packages) to share a file. dpkg has special magic to notice that files in multiarch:same packages which are in fact identical may be installed over each other without complaining about clashes, and mark tham as being owned by all the install arch variants, and not remove them until the last version of the package is removed. Otherwise a file is always owned by exactly one package. So if you could arrange to just have a 'wine' binary that was 32 or 64 as required then you could make this work as you want. Otherwise you need both those packages to depend on another wine-startup or whatever that contains the shared file. (I think - I admit I haven't fully groked the wine package layout) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
webapp packaging
I have been packaging a small cgi webapp (for accounting). This has generated some queries about webapp packaging. Do we have policy on this? Or a place to disuss such things other than here? The app consists of one main program file (boc.pl), a config file, and a set of resource files (html, images and some internal perl modules). Upstream intends all the files to be dropped into one location which is made cgi-executable (for *.pl), (and www-data readable) but this doesn't really fit very well with debian policy/default config, where the config file in in /etc and the the cgi-bin file is in /usr/lib/cgi-bin and the rest is in /usr/share/package. It also uses a git repo as a data store. (which needs to be r/w by www-data). The root of that is set in the config file. So. To my questions: 1) This won't work without cgi enabled in apache. Cgi (mod_cgi or mod_cgid) is installed but disabled in a fresh install of apache. However none of the packages I looked at that install things in /usr/lib/cgi-bin turns mod_cgi or mod_cgid on. Is it in fact policy that packages should not enable webserver features like this, and it has to be an admin task? Currently I have a postinst that works out which module is needed (with a2query -M) and then enables it with a2enmod. Should it in fact not do this? 2) Where should a default data dir for a web-app live? /var/www/package? /var/lib/package? Somewhere else? And for the app itself? dwww puts stuff in /var/www/dwww and /usr/share/dwww as well as the binary in /usr/lib/cgi-bin. I'm really not quite sure how one decides what goes where. 3) There is some tension between heavily debianfying such a package (so it just works after install and looks debian-packagey' and leaving it more like upstream 'all in one dir, sort out your own config'. One doesn't know how the webserver will be set up (vhosts etc). Especially if having things in different dirs meand significnat patching of upstream - that seems like a maintenance burden and potential bug-source. 4) It's nicer (in 2019) to have a URL like http://localhost/package/ or http://localhost/package/boc.pl than one with cgi-bin in it: http://localhost/cgi-bin/boc.pl Is there policy on this or other guidelines? Other packages seem to do all sorts of things. 5) Should a package support other web-server configs than apache? That'll do for now. not-quite finished package is here: http://wookware.org/files/bankofcucc/ Cheers for any clues. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: How specific must Copyright be?
On 2019-06-12 09:08 +0200, Birger Schacht wrote: > Dear mentors, > > I ITP (#929666) a software that lacks a copyright statement. I asked > upstream to clarify the copyright in the LICENSE file and upstream now > plans to use > > Copyright 2018-2019 github.com/containers authors > as a copyright statement. This seems a bit vague to me, in my experience > the copyright statement usually refers to persons or legal entities. > Would a copyright statement like the one above be acceptable in a > d/copyright file? Is it even legally valid? A copyright ownership statement is not a free software licence, and as someone pointed out, it defaults to 'entirely proprietary, all rights reserved', which is not suitable for Debian. The vagueness of the statement is not really a problem (specific statements tend to be increasingly out of date over time unless someone keeps them updated, anyway). But the point is that the software needs to have a free software licence otherwise it's not free software. So they need to decide if they want expat/apache/GPL, or something else approved by the OSI (https://opensource.org/licenses) (or something else followed by a long argument about whether or not it meets the DFSG - this is a very foolish route to take without a _really_ good reason), and write it down. Once they've declared a free licence, Debian is happy. How they choose to record their authorship copyrights is entirely up to them - just copy it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On 2018-12-07 17:06 -0800, John Horigan wrote: > On Fri, Dec 7, 2018 at 8:36 AM Wookey wrote: > On 2018-12-07 08:27 -0800, John Horigan wrote: > Normally the library package > libfoo is shared, and the libfoo-dev package contains the static > version. You already have the static version in libagg-dev, so why not > just add libagg as the shared version, and be like any other library > in debian? > > That makes much more sense. I tried it, and the packages all build with no > lintian errors or warnings. I was able to remove all my lintian overrides too. Good. > > Can you explain why you think there should be two -dev packages? > > If I create a new version of libagg-dev package and add shared libraries then > dependent packages that use the new version will link against the shared > library instead of the static library. Well, it's up to the depending package whether it builds against the shared or the static library. > The resulting binaries will then depend > on the shared libraries being installed. Wouldn't this break things? Why should it? This is the normal state of afairs for the vast majority of libraries in Debian. Any depending package building against the shared version needs to declare that dependency. But if it continues to build aginst the static version then it can continue to not mention such a dependency. > I created > libagg2-dev so that libagg-dev users would not get shared libraries that they > don't expect. How are the depending packages configuring this library? Are they using pkg-config, or do they just have fixed makefile configs? Or some other kind of config-script ? If that config is coming from the libagg-dev package then you can (probably) control which is the default. If it's coming from the depending package then the behaviour should continue as before (unless it was only falling-back to the static lib after failing to find the shared lib?) So I still don't think you need more than the standard: libaggN (shared library) libagg-dev (static library, headers, maybe pkgconfig file) Then check if any depending packages builds break. We don't normally control dynamic/static linking in debian by having two alternative libfoo-dev packages. We always provide both and let packages choose which they want to use. It is probably _possible_ to do what you suggest, but I don't see any reason to try and do so yet. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On 2018-12-07 08:27 -0800, John Horigan wrote: > I maintain a static library package, libagg-dev. There is an outstanding > request for a shared library of libagg. I'm leaving the original libagg-dev > binary package as it is, with just the static libraries. I'm adding binary > packages libagg2-dev and libagg2. libagg2-dev has everything that libagg-dev > has, plus the shared library. libagg2 has just the shared library. This is atypical for debian packages. Normally the library package libfoo is shared, and the libfoo-dev package contains the static version. You already have the static version in libagg-dev, so why not just add libagg as the shared version, and be like any other library in debian? Can you explain why you think there should be two -dev packages? > I can't find any definitive information about what should be in a shared > library SONAME-dev package and SONAME (runtime) package in the /usr/lib/ > directory. But I looked at the installed files in many libfoo-dev/ > libfoo package pairs and it seems like I should have this: > > ~john$ ls -l libagg2-dev/usr/lib/x86_64-linux-gnu/ > total 1584 > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so > ~john$ ls -l libagg2/usr/lib/x86_64-linux-gnu/ > total 216 > lrwxrwxrwx 1 root root 15 Dec 6 23:14 libagg.so.2 -> libagg.so.2.0.4 > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so.2.0.4 > > libagg2-dev has the .so file with the name libagg.so and libagg2 has the .so > file with the name libagg.so.2.0.4 and the symlink libagg.so.2. > > But I get a lintian error: > > E: libagg2-dev: ldconfig-symlink-missing-for-shlib usr/lib/x86_64-linux-gnu/ > libagg.so.2 usr/lib/x86_64-linux-gnu/libagg.so libagg.so.2 > > I also put in lintian overrides because libagg2-dev installs a .so file with > the SONAME libagg2 but the package is called libagg2-dev: > > libagg2-dev binary: package-name-doesnt-match-sonames * > libagg2-dev binary: non-dev-pkg-with-shlib-symlink * > > So what is the deal with -DEV packages and shared libraries? What am I > supposed > to do? I can help explain this in more detail (as I've been doing a lot of this recently, and I agree it's confusing), but lets sort out whether you really need libagg-dev _and_ libagg2-dev first. I think you don't, and that's just complicating matters. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: compiled binary file in source package
On 2018-02-08 23:46 +0100, David Rabel wrote: > Hi there, > > I am maintaining jugglinglab. The upstream source package contains a > compiled binary file. What is the cleanest solution to get rid of it? Is it actually doing any harm? Does it get included in the package? Does it get rebuilt? If it gets rebuilt then just remove it in the clean rule. If it doesn't get included then you could just ignore it. It's not doing any harm, unless it's known to be non-free. > Story behind that: > > When I started packaging jugglinglab in 2016 I just deleted the file > with a patch. > > This is unclean and for example sbuild refuses to build the package, > because it does a dh_clean before which also deletes the binary and then > complains that the patch cannot delete a file that isn't there. a '-' in front of a make command stops it erroring out. It is often appriate for clean rules that remove a file (it's fine if the deletion fails because the file is already not there) - rm foo You don't need the patch as well. Is that there because otherwise dpkg-source complains about changes? It should ignore removed files. > So, after more than a year, I think he won't answer. So I have to come > up with another solution. I just don't have an idea, what is the best > way to do that. Can you help me? Repacking the source without it is probably neatest. But just removing it in the clean rule is also fine. Or ignoring it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Fixing incorrect .orig
For reasons of confusion and general incompetence I've ended up uploading a package where the .orig tarball is not actually the upstream .orig. It's a) the .orig plus the set of patches that would normally be in debian/patches, and b) one subdirectory (the important one) of the upstream tarball moved up 4 levels. b) was because I thought that a dkms package had to be constructed this way, but it's actualy not true, and I've now worked out how to do it for an arbitrary layout, so I _can_ just use the upstream tarballs a) was because someone else helped with the patches and my git-foo was weak and I didn't realise they'd got incorporated into the orig. I have now assembled things properly and worked out how to use upstream tarballs as-supplied. There is no licencing problem with them so even though there is some cruft in there it's better to just use them as they come. This makes updates easier in future and simplifies traceability. There is also the matter of licence compliance, in passing on 'the source' (although only useless, unused, bits are missing, and we do allow repacking, that's not really the point). Anyway, the question is, what's the best way to fix this? I can't upload a new .orig until the upstream part of the version number is bumped - right?, because any -n debian suffix assumes the same .orig for the base base version IIRC. Or is there some way to do this? If I just move everything an upload a -4 to replace -3, I'll get an 800K+ debian diff, removing the whole of the orig source and replacing it with the same stuff in a different dir, which is silly. I don't want to upload a new upstream version (yet) because it will break compatibility with other packages (and in the hypothetical case of this questions there might well not be one, now, or maybe ever). So I can either just leave it like it is until it _is_ time to update to new upstream, at which point this will get fixed, or I can make up some suitable base version bump and re-upload. Is there a suffix typically used for this situation of essentially 're-done upstream source' (a bit like we use ds for 'debianised source' or somesuch when it's been repacked, usually to remove non-free things or non-source things)? Or should I just reupload 16.0 as 16.0.0 ? dpkg --compare-versions tells me that 16.0-3 is less than 16.0.0-1 so that should work. This seems like the best plan, but I wondered if there was anything niftier? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Dependencies across architectures
On 2018-01-07 19:23 +0800, Paul Wise wrote: > On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote: > > > If we take Multi-Arch serious, this shouldn't be the case, right? > > I guess the release team might accept patches to britney for this but > I've also a vague memory that they prefer arches to be self-contained. This issue affects so few packages that no-one has put in the effort to make this (automatic migration with cross-arch dependencies) work. I talked about it with respect to doing this for cross-compilers and they were OK with doing this properly this so long as there was a good reason (but in the end cross-compilers were done a different way so there was no need). In the meantime there is a rather hacky whitelist for the few packages that do need this (basically wine IIRC). So yes there is sort-of an assumption that architectures are self-contained, but clearly we'd like things to work as well as possible for the cases where they aren't/can't be. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multi-arch header conflict and pkg-config
On 2017-10-27 12:12 +, Hugh McMaster wrote:
> Hi Wookey,
>
> Apologies for the delayed response.
>
> On Thursday, 26 October 2017 12:23 AM, Wookey wrote:
> >> The header was previously installed with other headers in
> >> /usr/include/.
> >> Due to the conflict, I've modified debian/rules to:
> >> 1. Override dh_auto_install,
> >> 2. Create a directory in debian/tmp/usr/include//
> >> using mkdir -p; and
> >> 3. Move the conflicting header to the newly created directory using mv.
>
> > OK, that sounds sensible, presuming that the header _should_ be
> > arch-dependent.
> >The alternative is to fix up the header so it's no longer arch-dependent.
>
> The header contains an arch-specific path to Python plugins.
Right - the way to make such headers arch-independent is typically to
have a list of #ifdefs for paths and arches. It's up to you whether
you prefer one (ugly) arch-indepedent file or lots of mucvh cleaner
arch-specific files.
> > This is because the debian toolchain puts both
> > /usr/include, and /usr/include/${DEB_HOST_MULTIARCH} on the system search
> > path so a
> > #include should find header.h in both
> > /usr/include/package/ and /usr/include/${DEB_HOST_MULTIARCH}/package/
> >or at least I think that's how it's expected to work.
>
> I tested this and can confirm that your explanation is correct.
> Headers are found in both of those directories.
Cool. I meant to test it, but ran out of time and posted
anyway. Thanks for confirming.
> > How exactly are you testing this?
> I was including the header directly; i.e. without the package prefix.
> That didn't work; hence this email to the D-Mentors list.
>
> Replacing
> #include
> with
> #include
> allowed gcc to find the header, even though it was installed in the
> multi-arch include path.
This should probably be explained on a wiki page somewhere, probably
this packager-oriented one
https://wiki.debian.org/Multiarch/Implementation and or this usage-oriented one:
https://wiki.debian.org/Multiarch/HOWTO
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Re: Multi-arch header conflict and pkg-config
On 2017-10-23 12:41 +, Hugh McMaster wrote:
> Hi all,
>
> I'm attempting to resolve a multi-arch conflict with a header file in a
> package
> I'm working on.
>
> The header was previously installed with other headers in
> /usr/include/.
> Due to the conflict, I've modified debian/rules to:
> 1. Override dh_auto_install,
> 2. Create a directory in debian/tmp/usr/include//
> using mkdir -p; and
> 3. Move the conflicting header to the newly created directory using mv.
OK, that sounds sensible, presuming that the header _should_ be arch-dependent.
The alternative is to fix up the header so it's no longer arch-dependent.
> While these steps resolve the conflict, allowing the package to become
> M-A: same, test programs no longer find the header in the triple include path.
>
> pkg-config --cflags also just outputs -I/usr/include/.
>
> Does pkgconfig support multiple paths like this?
It does, you just output a list; but of 135 .pc files in my
/usr/lib/x86_64-linux-gnu/pkgconfig only 7 (all core python packages)
need to do this.
This is because the debian toolchain puts both
/usr/include, and /usr/include/${DEB_HOST_MULTIARCH} on the system search path
so a
#include should find header.h in both
/usr/include/package/ and /usr/include/${DEB_HOST_MULTIARCH}/package/
or at least I think that's how it's expected to work.
So very few packages should need to explicitly list both of those, if
using a debian toolchain.
How exactly are you testing this?
> If so, how do I modify the pkg-config file to handle multiple /usr/include
> paths?
by putting
Cflags: -I${includedir}/package -I${includedir}/${DEB_HOST_MULTIARCH}/package
in your .pc file. (and making sure that ${DEB_HOST_MULTIARCH} gets substituted.
But I'd check whether you really need to do that first.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Re: Help to build library in generic form, avx and sse3
On 2017-03-14 15:46 +0100, Andreas Tille wrote: > Hi, > > I've started packaging Phylogenetic Likelihood Library[1]. Since it > makes heavy use of amd64 features it comes with specific support of AVX > and SSE3. My plan is to provide binary packages amd64 only named > libpll-avx1 and libpll-sse3-1 with the according features plus a generic > library libpll-generic1 for all architectures. > 2. What do you think about the plan to support specific hardware > features in separate binary packages? It's OK, but short-changes other arches unless you do one with neon enabled for armhf, or altivec for powerpc. It's much better to build one version for each arch that can dynamically use available HWCAPS, but of course that's tricky if upstream doesn't support it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: artifacts in upstream, re: pristine source
On 2017-05-16 12:52 +0800, Paul Wise wrote: > On Tue, May 16, 2017 at 12:42 PM, Brian Smith wrote: > > > Regarding the "pristine source" requirement (i.e. no build artifacts) in the > > source archive: should the upstream tarball be imported to the upstream > > branch "as is", and the tar command for orig.tar.gz should be configured to > > omit build artifacts? Or should artifacts either be removed from or not > > imported to the upstream branch? > > Contact upstream and ask them to remove them from their VCS and source > tarballs and put them into their binary tarballs/packages. If they > refuse, then add Files-Excluded to debian/watch Files-Excluded goes in debian/copyright, not debian/watch. (unless there is some new feature I'm not aware of). It would arguably make more sense in watch, but that's not how it works. See man mk-origtargz for details. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: how best to package when using hardware vectorization with vector-unit specific code?
On 2017-05-10 09:17 +0200, Kay F. Jahnke wrote: > Hi group! > > I have code which optionally makes use of hardware vectorization. This is > done generically by using Vc: > > https://github.com/VcDevel/Vc > > When compiling with Vc, the resultant machine code is for a specific vector > unit only, like AVX or SSE. There are several possible ways of dealing with > these processor-dependent binaries: > > - create a set of complete target-specific executables and select which one > to deploy/run on the target machine As Henrique, just implied, you can package each flavour as a separate package and have users manaully install a suitable one. i.e you can generate package package-sse package-neon package-sse4 package-avx and so on. A small number of packages do this already, where the optimisations make enough difference that it is worth maintaining the variants: e.g. glibc used to produce glibc glibc-i686 (only on the i386 architecture) https://packages.debian.org/wheezy/libc6-i686 which is a version using the i686 ISA, for use only on machines that can run it. It has since stopped doing this, either because of runtime detection or because the arch moved forward to an i686 baseline. Some other packages do this sort of thing too. radiance radiance-sse3 (did - that one has been removed). This does require the user to notice the choice and pick a suitable version, but it's fairly simple to do and could be smoothly upgraded to runtime function/library level detection in the future if you did that. You definitely don't want 15 flavours though. Work out which ones _really_ matter (> 10% speed difference overall?) and package those, perhaps. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: how best to package when using hardware vectorization with vector-unit specific code?
On 2017-05-10 18:01 +0200, Kay F. Jahnke wrote: > @pabs > > @wookey > > > There is (as yet) no mechanism in packing to select packages by > > hardware variant or optimisation. It has been mooted, and could be > > done, but it's a big job, which would take years to roll out, and > > no-one has stepped up to make it work. So for now your favourite > > mechanism is not possible. > > I had something simpler in mind. I had hoped that a debian package would > provide some sort of target-side script which is run when the application > deploys with the user. Then it would be easy to have a bit of code à la > > #! /bin/bash > > for instruction_set in mmx sse sse2 sse3 ssse3 sse4 sse4a sse4.1 sse4.2 avx > avx2 avx512f avx512pf avx512er avx512cd > do > if [[ $( lscpu | grep $instruction_set ) ]] > then > bestarch=$instruction_set > fi > done > > mv myprogram_$bestarch $target_bin/myprogram OK. You can run a script on install which would do something like, and would work under most circumstances. https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html You should use a link rather than mv, and remember to tidy it up correctly on removal. Note that such scripts should be idempotent. Because it is install-time, not run-time, detection it would go wrong in a range of circumstances, so is frowned-upon. (Installing images, hardware which gets upgraded, keeping the OS image, cross-installing, NFS-mounting, containers etc). But yes, it is possible in the absence of more correct solutions. It would be much better to run such a 'choose-binary' script at runtime and have it run the right one as that would work in all the circumstances I can think of offhand. How fat would 15 versions of the program be (on x86)? Do you really need all 15? Might a subset suffice., > > Does this software only work on x86 or does it work on other > > architectures, with other vector units (neon, altivec)? Remember to > > consider more than just x86 when pondering this issue. > > I am using Vc, so whatever Vc supports, my software supports as well. Vc is > a generic C++ library to abstract away the architecture. I've coded so that > my program will also run without using the vector units OK. Looks like neon support is 'in development'. And you can run on non-vectorised hardware (but only very slowly). > Am 10.05.2017 um 13:56 schrieb Christian Seiler: > > pardon me, but what's an RC bug? 'Release Critical'. i.e so bad the software is not good enough for release in Debian stable with this bug. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: how best to package when using hardware vectorization with vector-unit specific code?
On 2017-05-10 13:56 +0200, Christian Seiler wrote: > On 05/10/2017 11:52 AM, Wookey wrote: > > Debian requires packages to run on the base level ISA defined for each > > architecture (which does change slowly over time). > > Well, kind of. What Debian requires is that if it is at all feasible > software should run on the base ISA - which in practice means that > very often the software is only compiled for the base ISA itself, > resulting in the binaries being slower than they need to be on more > modern hardware. > > However, there are a couple of packages that can't easily be ported > to the base ISA (such as packages that use tons of SSE assembly), and > in this case the consensus was that it's better to have the packages > in Debian at all, even if they aren't available for all users. Yes. You put that much better than I did. By 'must run on the base ISA', what I mean is that if it can't, but is still useful for many, then it should give a sensible error (as you point out), rather than just exploding. So upstream/packagers have to do _something_ to check for the optional features used and run corresponding code accordingly, even if the fallback code is just "This program cannot run here". Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: how best to package when using hardware vectorization with vector-unit specific code?
On 2017-05-10 09:17 +0200, Kay F. Jahnke wrote: > Hi group! > > I have code which optionally makes use of hardware vectorization. This is > done generically by using Vc: > > https://github.com/VcDevel/Vc > > When compiling with Vc, the resultant machine code is for a specific vector > unit only, like AVX or SSE. There are several possible ways of dealing with > these processor-dependent binaries: > > - create a set of complete target-specific executables and select which one > to deploy/run on the target machine > > - create a single binary with all variants linked in, calling only > target-specific code at run time > > - create a set of shared libraries, deploy one or all and load the > target-specific one at run-time > > - create only one compromise binary using some commonly available vector > unit > > The first alternative is nice because the binary is small and simple, but > the binary will only run on a specific target, so there would have to be a > way to do target-specific deployment, or, alternatively, a population of > additional superfluous binaries cluttering .../bin. So far, I have only seen > architecture-dependent packages, and I haven't managed to figure out if the > package installation process can be made more specific to deploy only code > for a specific vector unit. But I'd like to go along this path if possible. Debian requires packages to run on the base level ISA defined for each architecture (which does change slowly over time). I don't know what level of vectorisation that implies on other arches (perhaps SSE can be assumed on x86_64 or i386?), but on armel and armhf it assumes no vector unit (i.e you cannot assume that NEON instructions are present: there must be a runtime check before using them) On arm64 neon is part of the base spec so you can assume that it is present. (In practice almost no armel-using hardware, and the very large majority of armhf hardware will have neon.) There is (as yet) no mechanism in packing to select packages by hardware variant or optimisation. It has been mooted, and could be done, but it's a big job, which would take years to roll out, and no-one has stepped up to make it work. So for now your favourite mechanism is not possible. > The second alternative would require case-switching inside the code > The third alternative is [...] tearing the code apart into the > 'main' program and some library doing the number crunching. > The fourth alternative is to create a target using only > SSE instructions, which are available on most machines. Does this software only work on x86 or does it work on other architectures, with other vector units (neon, altivec)? Remember to consider more than just x86 when pondering this issue. If at all possible you should arrange for the software to work for all debian arches on the base spec. IT is obviously then highly worthwhile using hardware optimisations where available at runtime. Which method you use inside the codebase to cope with different hardware is up to you. Various libraries and mechanisms exist for this sort of optimisation-switching, such as ifunc in glibc. You don't say what language your codebase is in. I would agree with you that moving thise code into a library is a cleaner solution, but internal case-switching will also work fine. Use the HWCAPS mechanism to determine at runtime what vector unit, if any, is available. You are not the first person with this problem so there is probably some code already available for the checks and switching in your language. For arm there is the ne10 package for useful optimised neon functions, but it doesn't help with any other architectures, or the fallback/variant-switching part, but it may still be helpful. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#859776: rejection
On 2017-04-11 09:33 +0200, Paride Legovini wrote: > [Note for whoever lands here: the package has been rejected from NEW > because of unattributed files in lua/lexers]. > > Hello Adam, > > I didn't realize that some files in lua/lexers were not fully attributed > in debian/copyright. Regarding those files: there is one main author > (that is attributed), then many single-file contributions from about 40 > different authors. > > Should I list all these authors in debian/copyright, or can I do like > it's done for the Linux kernel: > > Files: * > Copyright: 1991-2012 Linus Torvalds and many others > License: GPL-2 > > hence writing: > > Files: lua/lexers/* > Copyright: 2007-2016 Mitchell <mitch...@foicica.com> and many others > License: MIT > > What do you suggest? The thing that really matters is the licence. If the whole thing is definitely under the same licence then you can just list it as one stanza with lots of authors. But if there are different licences for the contributed parts then you really need to add stanzas for those. Ideally you put in stanzas for all the logically separate pieces (say several lexers from different conributors, even if they have the same licence). But this level of detail is not required. Even if you put it as one stanza because it's all one licence, it's good practice to include all the authors names (that have indicated their copyright by putting their names on something). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Debian packaging for packages that provide the same files
On 2017-01-11 14:25 -0800, J.T. Conklin wrote:
> Niels Thykier <ni...@thykier.net> writes:
> And now that I've refreshed my memory by reading
> (https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install),
> I see that *.install files can specify both the source and destination
> paths. So maybe I can forgo configure/make/install entirely and have
> each debian/.install file copy files directly from the sources.
You can. I've just been doing this for a package which just installs
binary drivers from existing upstream collections of drivers. This is
exactly analagous to your set-up, I think, in that I have a lot of
'hardware/arch/usage/' dirs, and each one is packed up
into a very similar-looking package called
foo-hardware-usage-driver_ver_arch.deb
I have an ugly shell script to generate the control file listing all
the packages and the set of executable *.install files to do the
copying (below).
That's pretty-much what you want, I think. Please don't copy my shell
script, it's currently embarassing and rather too specific and
fragile, but it illustrates that this is actually fairly
straightforward :-)
You should do something rather fancier that actually traversed the
available directories rather than hardcoded it. You could also use
make to ensure that it was actually run to keep things uptodate, etc.
#!/bin/sh
set -e
#set -x
EGLDEPS="libegl1-x11, libgles1, libgles2, libopencl1"
# make install file and control entry for each platform/arch/gpu/display flavour
mkpkg() {
# generate dh_install file
installfile="mali-${1}-${2}-driver.install"
echo "#! /usr/bin/dh-exec" > "${installfile}"
echo "${1}/\${DEB_HOST_ARCH}/${2}/* /usr/lib/\${DEB_HOST_MULTIARCH}/" >>
"${installfile}"
chmod +x ${installfile}
#then add control entry
case "$1" in
4xx)
CODENAME="utgard"
;;
t60x|t62x)
CODENAME="midgard"
;;
t76x)
CODENAME="bifrost"
;;
esac
case "$2" in
fbdev)
TYPE="framebuffer"
DESC="the kernel framebuffer"
;;
x11)
TYPE="x11"
DESC="x11"
;;
wayland)
TYPE="wayland"
DESC="wayland"
;;
fbdev-wayland)
TYPE="wayland(no DRM)"
DESC="wayland without DRM"
;;
wayland-fbdev)
TYPE="wayland"
DESC="wayland"
;;
esac
cat >> control < control
#nasty hack for arch support - fixme!
ARCH1=armhf
ARCH2=arm64
mkpkg t62x fbdev ${ARCH1} ${ARCH2}
#mkpkg t62x wayland ${ARCH1} ${ARCH2}
#mkpkg t62x x11 ${ARCH1} ${ARCH2}
ARCH=arm64
mkpkg t62x wayland-fbdev ${ARCH}
mkpkg t62x fbdev-wayland ${ARCH}
ARCH=armhf
mkpkg t60x fbdev ${ARCH}
mkpkg t60x x11 ${ARCH}
mkpkg t62x wayland ${ARCH}
mkpkg t62x x11 ${ARCH}
mkpkg t76x fbdev ${ARCH}
mkpkg t76x x11 ${ARCH}
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
qbs building (with qt)
qbs is yat-another build system. From the QT people. Allegedly it is quite sensible (according to someone familiar with Make, qmake, and cmake). I am trying to package something that uses it. Is anyone familiar with this in debian-world? Especially with respect to selected qt4 or qt5? Some docs are here: http://doc.qt.io/qbs/configuring.html with some info on selecting qt versions here: http://doc.qt.io/qbs/qt-versions.html A typical build seems to look something like this: qbs-setup-toolchains --detect qbs-setup-qt /usr/bin/qmake default qbs build -f .qbs profile:default except you actually need to add qbs config profiles.default.baseProfile gcc (if both gcc and clang are installed, because the toolchain --detect stage finds both.) The problem with this is that it detects qt4, and thus fails to build a qt5 project. using the alternative qbs-setup-qt --detect also chooses qt4 if it is installed. (i.e generates a profile called 'qt-4-8-7') qbs expects you to be able to point at a different binary path for qmake(qt4 version) and qmake (qt5 version). But in debian qmake seems to be a wrapper from the qtchooser package. I can't see a way to say 'default to qt5 for anything that asks'. I've not yet followed all the details of how qbs-setup-qt does its selection, and maybe there is some debian rune for default-setting that I have missed. Perhaps what is actually needed is for the debian packaging of qbs to work together with qtchooser to DTRT? It doesn't seem to be possible to install just qt5, as installing it pulls in qt4. And having both installed is quite likely to be needed in various circumstances, so we need to make it possible to get qbs to use the right one. OK, doing QT_SELECT=5 qbs-setup-qt /usr/bin/qmake default generates a 'default' profile which points at qt5. Is the recommended way to do it? QT_SELECT=5 qbs-setup-qt --detect makes two profiles: 'qt-5-6-1' and 'qt-4-8-7' (not just the qt5 one for some reason) I can then use qbs build -f .qbs profile:qt-5-6-1 to build with the right stuff, but this is not much use for putting in a rules file because that profile name is going to change every time qt is updated. Also builds leave a directory called -debug in the source directory after builds. Is there a standard way to get qbs to tidy up after itself, or does the rules file have to do that. (rm -rf *-debug works so long as there is nothing already called that in the sources...) Anyway, clues very welcome from anyone familiar with this stuff. I'll carry on prodding in the meantime to try and grok it all. OK. I got it to build eventually, but it may not be optimal as described above. My rules file looks like this. Assuming this is about right, I guess it would be good to teach debhelper and dh_make about qbs. %: dh $@ override_dh_auto_configure: qbs-setup-toolchains --detect QT_SELECT=5 qbs-setup-qt /usr/bin/qmake default # choose gcc as if clang is installed too you have to pick one qbs config profiles.default.baseProfile gcc override_dh_auto_build: qbs build -f dewalls.qbs profile:default override_dh_clean: # tidy up qbs profile builddirs qbs clean profile:default rm -r *-debug dh_clean Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: How do you delete a sbuild an sbuild chroot and start over?
On 2016-08-05 14:28 -0500, Paul Elliott wrote: > dpkg-deb: building package 'sbuild-build-depends-core-dummy' in > '/<>/ > resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'. > dpkg-deb: error: failed to make temporary file (control member): No such file > or directory > Is there any way to figure out what directory does not exist? (control member) <> tells you what it is at the top of the log: e.g. I: NOTICE: Log filtering will replace 'build/most-Ru6goH/most-5.0.0a' with '«PKGBUILDDIR»' I: NOTICE: Log filtering will replace 'build/most-Ru6goH' with '«BUILDDIR»' I: NOTICE: Log filtering will replace 'var/lib/schroot/mount/sid-arm64-sbuild-9ba727aa-c9d7-4d64-9d2a-679b6ad14a8e' with '«CHROOT»' So you can find out what directory it is trying to use. I guess maybe you have a permissions problem? You may also find that --log-external-command-output and --log-external-command-error will help. --debug will give you buckloads of output, which again may help clarify the issue. I think there is a way to stop it putting i the <> substitutions, but I can't find that now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: How do you delete a sbuild an sbuild chroot and start over?
On 2016-08-03 13:12 +0200, Johannes Schauer wrote: > Hi, > > Quoting Paul Wise (2016-08-03 12:41:28) > > > As far as I know, schroot still doesn't > > > document how to delete a chroot. > > > > Seems to me like sbuild should have an sbuild-deletechroot command > > that should call the relevant tool for the chroot in question and > > schroot should have a corresponding command that would DTRT. > > it is unlikely, that there will be a schroot command that does the right thing > because schroot also leaves it up to the user to create the chroot in the > first > place. This is also why sbuild-createchroot is doing everything manually > including assembling the right schroot configuration file. schroot does have the info it needs though - to lok up where the chroot is stored and remove it, so it could... > My last attempt at implementing a command that does this was stopped early on > by the question how this tool should best be called: > > - sbuild-deletechroot > - sbuild-removechroot > - sbuild-destroychroot > > Maybe a native English speaker could tell me the most natural choice for a > tool > that does the opposite of what sbuild-createchroot does. 'destroy' is closest to the opposite of 'create'. But 'remove' sounds a bit less cataclysmic :-) Either will do fine. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: help2man usage with pybuild / debhelper packaging workflow
On 2016-06-03 18:30 +0200, Christian Seiler wrote: > On 06/03/2016 06:25 PM, Ghislain Vaillant wrote: > > And I don't mind for a handful of scripts. But what if you have 20 or > > 30? > > Well, you could add a custom target to debian/rules that calls > help2man for all these scripts - so that you as a maintainer > can refresh the manpages every now and then. (And store them > in debian/ in the packaging.) That way, you don't break cross > builds (manpages are pre-generated), but still automate it to > a large extent. Yep, that's a reasonable plan. Missing man pages is better than things that gratuitously won't cross-build. Just copying the help into a man page is mostly makework to shut lintian up. They are often very poor manpages. If the help is there already or upstream documentation is some other format (e.g. html), then if you _really_ can't be bothered making man pages, just leave it as upstream supplied. Using help2man is a worse 'solution' than doing nothing. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: help2man usage with pybuild / debhelper packaging workflow
On 2016-06-03 16:43 +0100, Ghislain Vaillant wrote: > Dear all, > > Are there any successful examples of integration of help2man with a > pybuild / debhelper workflow for an arbitrary number of scripts? help2man breaks cross-building so is best avoided if you can. Please just write a man page. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Mass-rebuilding packages
+++ Sean Whitton [2016-05-01 13:13 -0700]: > Hello, > > I need to rebuild all packages that depend on dh-elpa to check for > FTBFSs. Does anyone have a script that tells sbuild or pbuilder to do > this? I can write one, but I thought I'd ask first. Any of debomatic, pybit, debile or rebuildd can help you with this, but they all need a bit of config to set up your chroots (suite, arch etc), and a list of packages to build. build-rdeps (from devscripts) is handy for listing all the packages you want. (or dctrl-tools if you want to do fancier things). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Packaging mmh (fork of nmh)
+++ Jakub Wilk [2016-04-10 17:15 +0200]: > * Wookey <woo...@wookware.org>, 2016-04-10, 15:49: > >>nmh installs it's binaries (~20) into /usr/bin/nmh. > > Actually it installs to /usr/bin/mh, ... > > >>Now I try to do the same, and install mmh's binaries into /usr/bin/mmh, > >>but Lintian complain about FHS violation. The only allowed subdir of > >>/usr/bin is /usr/bin/mh. > > > >So nmh is not following FHS either. > > ...which is permitted by FHS. Right. I took what the OP said at face value, rather than checking up :-) > >>Installing mmh into /usr/bin/mh would be impolite to `nmh', since `mh' > >>is historical name, like `vi'. So mmh should probably just use /usr/bin/mh as well? (and C+R+P). Any reason why that wouldn't work? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Packaging mmh (fork of nmh)
+++ Dmitry Bogatov [2016-04-10 08:34 +0300]: > > [CC nmh maintainer] > > Hello! > > I am packaging mmh (http://marmaro.de/prog/mmh), which is fork of > nmh. Both of them are mail user agents. > > nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to > do the same, and install mmh's binaries into /usr/bin/mmh, but > Lintian complain about FHS violation. The only allowed > subdir of /usr/bin is /usr/bin/mh. So nmh is not following FHS either. > Installing mmh into /usr/bin/mh would be impolite to `nmh', since > `mh' is historical name, like `vi'. Are nmh and mmh intended to be co-installable? I presume that you want one or the other, so making them conflict like MTAs would make sense. > So I consider using alternatives mechanism. Unfortunately, > `mmh' and `nmh' are not totally equivalent -- mmh has lesser > count of commands. I think about alternatives not for binaries, > but for whole directories: > > /usr/bin/mh -> /usr/lib/nmh | /usr/lib/mmh > /etc/mh -> /etc/nmh | /etc/mmh > ... > > Is it allowed? Is it good solution? It seems sensible to me. > And what to do with man pages? > For example, both provides `scan(1)', but only `nmh' has `mhshow(1)'. Well, if you only install one or the other this isn't a problem - they both just provide a suitable set of manpages. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#816169: RFS: fake-factory/0.5.3-1
+++ Mattia Rizzolo [2016-03-27 12:39 +]: > On Sun, Mar 27, 2016 at 12:21:33PM +0100, Wookey wrote: > > +++ Christopher Baines [2016-03-27 10:49 +0100]: > > > On 20/03/16 03:12, Mattia Rizzolo wrote: > > > A possible alternative would be to include a manpage made with help2man, > > > and not generate it for this version (and switch to generating it later)? > > > > Help2man breaks cross-building and is thus best avoided if > > possible. Adding support for a 'nodocs' profile to skip its use is one > > way to (mostly) deal with that. > > How can this be a problem for arch:all builds? Well I think it still breaks if one tries to cross-build arch:all packages, but you are right that one doesn't need to do that so it's not actually a problem there. (I jumped in, so wasn't sure if we were discussing something arch:all or not) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#816169: RFS: fake-factory/0.5.3-1
+++ Christopher Baines [2016-03-27 10:49 +0100]: > On 20/03/16 03:12, Mattia Rizzolo wrote: > A possible alternative would be to include a manpage made with help2man, > and not generate it for this version (and switch to generating it later)? Help2man breaks cross-building and is thus best avoided if possible. Adding support for a 'nodocs' profile to skip its use is one way to (mostly) deal with that. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: public-domain in the debian/copyright
+++ Gustavo S. L. [2016-02-04 11:37 -0200]: > hello mentors > > lintian say that about one party for my archive by copyright "The files > paragraph in the machine readable copyright file references a license, for > which no standalone license paragraph exists" Right. I hit this recently for ros-rviz, which has tongoproject icons (public domain). It insisted on a licence paragraph even where there wasn't one. > but in the manual of the copyright that if license is public-domain "the > remaining lines of the field must explain exactly what exemption the > corresponding files for that paragraph have from default copyright > restrictions" > > but I did not find example I just copied the text of the public domain statement from the website in this case: https://tracker.debian.org/media/packages/r/ros-rviz/copyright-1.11.10%2Bdfsg-1 (which then cause another (wrong) lintian warning about the GPL as that is mentioned in the text) That text came from the bottom of http://tango.freedesktop.org/ Can you find a similar statement for your project? HTH Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Again about Multi-Arch and Pre-Depends
+++ Thomas Schmitt [2016-01-28 18:04 +0100]:
> Hi,
>
> i need advise about
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020
> where Matthias Klose asks me to add
> +Multi-Arch: same
> +Pre-Depends: ${misc:Pre-Depends}
> to debian/control.
The pre-depends is no longer needed. It was a transitionary measure for
upgrading from squeeze.
Adding the "Multi-Arch: same" field to libraries (and making them install in
the arch-specific localtions) is good.
So yes, apply doko's patch, and just remove the Pre-Depends: line as it is no
longer needed.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Re: RFS: snetmanmon, a simple network manager and monitor
+++ Alexander Holler [2016-01-12 21:04 +0100]: > Am 11.01.2016 um 21:22 schrieb Gianfranco Costamagna: > > >and fix the below: > >-changelog: one single entry with "initial debian version or whatever and > >Closes: #ITP bug" > >-control: seems fine, you can drop the debug package now that Debian has > >ddbg infrastructure > >(automatic debug packages creation) > > std-version should be 3.9.6 > > Can do that. > > >-format should be 3.0 quilt not native > > That doesn't work. I already have had spend time before with trying to use > 3.0 and it didn't played well with the build system I'm using for snetmanmon > (cmake). I've not been following this thread, so may be off the mark, but just thought I should say that I've just uploaded about 50 packages which use quilt 3.0 and cmake (and are built from git with git-buildpackage) http://anonscm.debian.org/cgit/debian-science/packages/ros It works fine, although you do need to use dpkg-source --after-build . to tidy up build artifacts before doing clean builds in sbuild for some packages. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Re: Re: mentor wanted
+++ Stephan Foley [2016-01-09 22:02 -0500]: > Hi Gianfranco, > > Gianfranco Costamagna wrote: > > A whole set of issues, but mentors as said by Paul is regarding > > mostly packaging issues > > Well, the whole idea behind blends is packaging. For example, to > have tasks posted to the website I need a control file in a Debian > folder. I need a rules file, I need metafiles, etc, etc. > > I can understand you guys not wanting to get involved and that is > fine by me. I can always read the documentation. I was just going > by the manual which lead me to expect more general help in this > mailing list. It's not so much a matter of not wanting to get involved - it's just that few of us know anything about the details of blends. We know about packaging. So we can't actually help much. I am aware that blends are mostly implemented by way of special packages but not what goes in them... So do please ask here again if you have packaging problems, or you don't get any help on the blends list, but honestly, asking there (+self-help of course) is the best advice from what you've explained so far. And unless you _need_ to ask something in private for some reason, it's much better to ask in public. That way the question is already answered for the next person who comes along and searches. It's doesn't matter if the questions feel dumb - we all had to start somewhere. The instruction you found about mentoring 'via private email' possibly meant to refer to the contact being by private mail, not to the asking and answering of queries, although I agree it could be read either way. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: O: wicd -- wired and wireless network manager
+++ toogley [2016-01-07 19:49 +0100]: > Hey, > > honestly thanks a lot for the friendly support. Especially Axel, thanks for > offer to sponsor me. I hope, I won't disappoint you. I'm happy to help too. I use wicd all the time so want to see it in good shape. I can help with testing, packaging advice, and as backup sponsor. > Question: Jessie has currently this package > https://packages.debian.org/jessie/git-remote-bzr which would allow us > (since upstream uses bazaar) to fetch new upstream changes more easily. But > i don't know if its appropriate for debian packaging, since it's an > additional dependency for the process of maintaining itself. If it's just a tool you use locally to update your sources/repo then it's not a build-dependency, so just use it, but no need to change anything in the packaging. Possibly worth noting in a debian/README.source on how you do updates/new releases (especially for anyone else that takes over in future or has to update/build it locally for other reasons) > Again, thanks for your support. Of course, I hope, i won't disappoint any of > you guys :D Don't worry. You'll be fine :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Failed to stop defining RPATH in libncl
+++ Andreas Tille [2016-01-04 11:40 +0100]: > Hi, > > I'm trying to package libncl[1] but I failed to fight the following > lintian error: > > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter > /usr/lib/x86_64-linux-gnu/ncl > N: > N:The binary or shared library sets RPATH. This overrides the normal > N:library search path, possibly interfering with local policy and causing > N:problems for multilib, among other issues. > N: > N:The only time a binary or shared library in a Debian package should set > N:RPATH is if it is linked to private shared libraries in the same > N:package. In that case, place those private shared libraries in > N:/usr/lib/. Libraries used by binaries in other packages should > N:be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in > N:which case RPATH is unnecessary. If this is just a library then it should be in /usr/lib/. Only plugins that are used internally and never externally should be in /usr/lib//. And because this is not on the normal search path an rpath may be needed to load them. In this case the above lintian warning is not an error. So you probably want to move the library to /usr/lib/. But if it's internal then leaving it in /usr/lib// and letting it have an rpath is fine. The brute force way to fix this is to use chrpath to remove the rpath from the binary at the end of the build. Better is to stop it being generated with CMAKE: SKIP_BUILD_RPATH TRUE autotools: See https://wiki.debian.org/RpathIssue for details (that whole page is useful - but maybe you read it and tried that stuff already?) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Failed to stop defining RPATH in libncl
+++ Andreas Tille [2016-01-04 16:19 +0100]: > On Mon, Jan 04, 2016 at 03:07:40PM +0000, Wookey wrote: > > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter > > > /usr/lib/x86_64-linux-gnu/n> > The brute force way to fix this is to use > > > chrpath to remove the rpath > > from the binary at the end of the build. > > This is what I have now. OK. I used to discourage chrpath usage because it broke cross-builds (because it didn't understand foreign-arch binary elf formats), but chrpath has since become arch-agnostic so it doesn't really matter these days (except insofar as it's a workaround, rather than a proper cure, and thus unpleasing :-). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: unreproducible Build-Attempted
+++ Jerome BENOIT [2015-12-03 05:55 +0100]: > Hello Forum: > > One of my last package, gmp-ecm, not to mention it, failed to built on the > mips architecture: > https://buildd.debian.org/status/fetch.php?pkg=gmp-ecm=mips=6.4.4%2Bds-5=1449086277 > > Fortunately enough, I have access to a mips Debian porter right > now. So I tried to reproduce the issue: without success so far. > > Is there a way to ask for a new build-attempt ? yes, you send mail to m...@buildd.debian.org. but in fact it seems to have been done already, so either someone noticed or you found a comms channel. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: general question about quilt patch handling
+++ Werner Detter [2015-12-01 13:01 +0100]: > Hi, > > > Have you got any reason not to simply refresh your patches? > > Something like: quilt pop -a; while quilt push; do quilt refresh; done > > well, there is no reason. I'm asking because this is the first time > I have this topic. Sure, refreshing all patches would be probably the > best - but do I have to mention that in the changelog? If the changelog says 'removing/updating foo support because blah no longer available' then there is no need to say 'and I refreshed all my patches' too - that's just as anspect of makig it work nicely. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: [cmake][multipackaging] best practices
e over the other? Good question. Probably some tools will get confused if things don't match up, or packages might get rejected, depending on what is wrong. > I do not know if "dh" can do a "cpack -G DEB" (with potential > additional parameters such as the revision). I also do not know if > there is an automatic variable that indicates the revision in the > debian/rule, or the package being built (which then can be handled > with "cmake -DCOMPONENT=`component_name` -P cmake_install.cmake"). > I would be happy if all those can be done in "dh" directly, but as > far as I understood, "dh" handles the cmake configuration and the > "make" + "make install" step, and then passes the installed files to > debian tools. I would like "dh" to configure, make and ask cmake to > generate the packages directly (without any "make install"). dh can have a '--with cmake' if you write a dh-cmake package. Possibly this would be the right way to integrate things better. But completely taking over the install step is quite radical. You would need to show that it didn't actually break anything to get it accepted. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: [jitsi-dev] Jitsi in Debian
+++ Damian Minkov [2015-10-18 14:17 -0500]: > > (Also, you need tackle the embedded code libraries. At least show some > > progress! And to avoid getting you on the wrong path, as you mentioned > > maven on jitsi-dev -- you cannot download dependencies at build time.) > > If you mean to get the dependencies out of jitsi, I havn't seen any > interest of that from anybody so not sure it is worth the effort at > this point. Debian is very keen on packing each project as a separate package (because it is right), not all bundled into one source, or even worse repeatedly bundled into lots of sources. So Debian is interested, (as are all its derivatives), and we'll do our best to help with that. This is much easier if upstream is on-board with that, otherwise there can be significant build-system patch maintenance. Are they? (It can be acceptable to leave embedded copies if they are only used by one project, but in general it's bad (for bloat and security reasons). > I'm aware of the downloading while building problem, but you mean > there is no way to reuse maven stuff while packaging, as the list of > dependencies is maybe 30-40 libraries? Maven and Debian policy go together very badly. If the project doesn't already use maven then _please_ don't change to it. It's terrible for security and reproducibility. Nothing about getting the project packaged would be helped by such a change - in fact it would be a major hindrance. > The problem is that the packaging of such complex project, cannot keep > up with the rapid development that happens which at some point is a > big problem. Lots of complex projects manage to get maintained in Debian. So it can be done. It is much easier if they use sensible build systems and upstream is interested in helping. I am interested in seeing jitsi properly maintained in debian so may be able to help a bit (although I can't promise much as I currently have a pile of other pending Debian work). This thread should really be copied to the ITP, so people can at least see what is going on. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768 Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#800759: RFS: sdcc/3.5.0+dfsg-1
+++ Gudjon I. Gudjonsson [2015-10-03 13:48 +0200]: > Package: sponsorship-requests > Severity: normal > > Dear mentors > > I am looking for a sponsor for my package "sdcc" I'm interested in seeing sdcc kept up to date in debian, so will do an upload for you. But happy if anyone beats me to it. > Changes since the last upload: > > * New upstream release (Closes: #789831) > * Improve manpages as and sdcc > * Add manpages sdar, sdas390, sdasrab, sdasstm8, sdastlcs90, > sdldstm8, sdnm, sdobjcopy, sstm8 > * Remove manpage savr > * Remove patches, 02_fix_spelling and 03_fix_compilation. Fixed > in upstream. > * Bump standards version to 3.9.6 > * Remove unneeded lines from clean target in rules file > * Update description i control file (Closes: #766325) > * Move sdar from sdcc-ucsim to sdcc > * Add binary file sdldstm8 to sdcc > * Add provides c-compiler to control file (Closes: #768307) > * Add huge memory model libraries (Closes: #768307) > * Add deoendency on graphicsmagick-imagemagick-compat > * Exclude example code from compression Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Bug#800759: RFS: sdcc/3.5.0+dfsg-1
+++ Wookey [2015-10-03 14:05 +0100]: > +++ Gudjon I. Gudjonsson [2015-10-03 13:48 +0200]: > > Changes since the last upload: > > > > * New upstream release (Closes: #789831) > > * Improve manpages as and sdcc > > * Add manpages sdar, sdas390, sdasrab, sdasstm8, sdastlcs90, > > sdldstm8, sdnm, sdobjcopy, sstm8 > > * Remove manpage savr > > * Remove patches, 02_fix_spelling and 03_fix_compilation. Fixed > > in upstream. You also removed 01_disable nonfree. Is that no longer relevant? > > * Bump standards version to 3.9.6 > > * Remove unneeded lines from clean target in rules file > > * Update description i control file (Closes: #766325) > > * Move sdar from sdcc-ucsim to sdcc > > * Add binary file sdldstm8 to sdcc > > * Add provides c-compiler to control file (Closes: #768307) I'm not quite sure about this one. Yes sdcc is a c-compiler, but it's not a 'standard' one and if something is depending on c-compiler because it doesn't care whether gcc or clang is used, it may not be expecting to get sdcc instead? On the other hand bcc and tcc and gcc-avr also provide it. There seem to be 8 packages in the archive tha thave this dep: icecc, ikiwiki-hosting-web, intercal, ksplice, laby, libinline-c-perl, libtool, pmk How many of those work with sdcc instead of gcc? The string c-compiler does not appear in policy, so I must admit that I'm not quite sure what exactly it is intended to mean/be used for. I've added this to the bugreport. > > * Add huge memory model libraries (Closes: #768307) > > * Add deoendency on graphicsmagick-imagemagick-compat > > * Exclude example code from compression Any reason why you didn't apply 766478 (use autotools-dev to update config.* files for new arches) too? Doing this is in general good practice (and as a porter I like to see such bugs fixed :-) Apart from those queries I don't see anything amiss. I've not checked a clean build due to desperate shortage of disk space. Assuming that goes OK, I could upload what you have, but I'd prefer to see 766478 fixed too, and a bit more discussion abut whether 768307 is actually 'right'. (maybe skip that until a conclusion is reached, rather than delay uploading what is done). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Multi-Arch and debian/control
+++ Thomas Schmitt [2015-09-21 15:13 +0200]:
> Hi,
>
> Jakub Wilk wrote
> > "Pre-Depends: ${misc:Pre-Depends}" was necessary to squeeze->wheezy
> > upgrades; it is no longer required.
>
> Ok. No such headers. Despite online docs.
> (Were to complain about outdated wiki.debian.org articles ?)
I have updated the page a bit to indicate that this was only needed in wheezy
(for updates from squeeze).
I have not updated to remove the advice to add the variable, because
it is presumably still a good idea for backports and LTS reasons? (I
am thinking about derivatives upgrading from Ubuntu LTS for example,
where presuambly this will apply for some time yet.)
Should we in fact be advising removal of this stanza entirely now?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Re: Bug#799390: linuxbrew-wrapper: over-restrictive architecture setting?
+++ lumin [2015-09-20 12:19 +]: > Hi Aaron M. Ucko, > > On Fri, 2015-09-18 at 13:11 -0400, Aaron M. Ucko wrote: > > > linuxbrew-wrapper's control file declares amd64 to be the only > > supported architure. Is that restriction really necessary? From what > > I gather, Linuxbrew is perfectly capable of building software from > > source, so it should be no big deal if prebuilt binaries aren't > > available for other architectures. > > Please consider changing the Architecture value to linux-any, or even > > any. It certainly builds fine on arm64. (It may not actually be very useful but as it's just a shell and ruby script, I don't see why it should do whatever it does. I don't really understand how brew works, but from what I do understand, I don't see why it should only work on amd64. And anyway brew is not in this package. This package itself is not arch specific, and in fact seems to be arch-independent, so should realy be Arch: all, not Arch: any and certainly not Arch: amd64 > Agree with you. > Linuxbrew upstream declares that it only supports amd64, > and there is only amd64 machines for me to test, so I wrote > amd64 in Architecture. > > This is quoted from upstream README: > > Linuxbrew does not currently support 32-bit x86 platforms nor > platforms other than x86. It would be possible for Linuxbrew to > work on 32-bit x86 platforms with some effort. > > which means users under ARCHs other than amd64 may need to take care > of themselves. > > I don't think it's appropriate to bump Architecture from "amd64" > to a wildcard without sort of notice to user. This package is not 'linuxbrew'. It does not seem to have anything arch-dependent about it. In debian we built lots of stuff for arches where they are never used, just in case it's useful for someone. We default to building everything that will build on all architectures, no matter how useless. In this case it should just be arch all IMHO, whatever actual limitations there are in the wrapped linuxbrew. Then if someone makes linuxbrew more capable one day this wrapper will at leastbe available on all arches already. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Re: Help getting a bug report in order
+++ Jeffrey Walton [2015-09-21 00:26 -0400]: > Hi Everyone, > > We took a bug report from a Debain maintainer under Debian's X32 > environment (https://wiki.debian.org/X32Port). Our bugs triggered some > Debian bugs as we worked through some of the issues. > > One of the issues we encountered was GDB's inability to debug a C++ > program. It was reported at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799556. > > I'm trying to tidy it up, but https://www.debian.org/Bugs/Developer > and its email control messages are not very helpful. > > At this point, I *think* I need to perform 3 tasks, with an optional 4th task: > > (1) add the "port-x32" tag or category to the report because the > fellow writing the X32 wiki page appears to monitor it (see Bug > Reports at the end of https://wiki.debian.org/X32Port). > (2) add the BTS "upstream" tag because the bug satisfies the condition > "This bug applies to the upstream part of the package" per > https://www.debian.org/Bugs/Developer. > > (3) add the BTS "patch" tag because the fix satisfies the condition "A > patch or some other easy procedure for fixing the bug" per > https://www.debian.org/Bugs/Developer. bts tag 799556 + port-x32 patch upstream (install devscripts ifyou don't have the 'bts' command) This does need to be rnu on a machine where email works. > (4) it would probably be helpful to other X32 developers to ensure the > new GDB is built and made available. Prepare a patch so that it is easy for the maintainer to apply it and upload. File it in the bug. Then just wait till the maintainer uploads a new version with your patch. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Re: Bug#796828: RFS: xfce4-equake-plugin/1.3.8
+++ Jeroen van Aart [2015-08-27 15:37 -0700]: > On 08/27/2015 01:20 AM, Gianfranco Costamagna wrote: > >3) control/rules file: what about using dh-autoreconf instead of > >autotools-dev? > > Would I have to use dh-autoreconf? I tried it but it causes some > build errors I can't seem to fix. As far as can see it's not a > requirement and things have worked fine using autotools-dev. This page explains why it is a good thing (but also, as you say, not an actual requirement yet): https://wiki.debian.org/Autoreconf It also gives some clues for things to fix if you get errors. So it is good practice for a package to be autoreconfable as that means that it will build on more architectures, and new architectures correctly. But if you cannot easily fix it this is not a reason to delay upload (but you should probably tell upstream that their autofoo is broken/outdated). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Bug#791901: RFS: frozen-flask/0.11-1 [ITP]
+++ Orestis Ioannou [2015-07-09 13:24 +0200]: python-frozen-flask - Freezes a Flask application into a set of static files. python3-frozen-flask - Freezes a Flask application into a set of static files. OK, I'd like to see these in debian, so I took a look. http://mentors.debian.net/package/frozen-flask Comments: 1) You've licenced the debian files (GPL-2+) differently from the upstream file (BSD-3). That's OK if you only want to contribute on a GPL basis, but if you don't have strong feelings it usually best to put the debian packaging under the same licence as upstream, just for simplicity. 2) The artwork has a different licence but this is not recorded in the copyright file. 3) No Homepage or vcs fields in the control file 4) No multi-arch metadata in the control file (The binary packages should be Multi-Arch: foreign in this case) Otherwise it looks good. I know very little about python and less about its packaging so I don't know if there are things missing - I'm assuming that: export PYBUILD_NAME=frozen-flask %: dh $@ --with python2,python3 --buildsystem=pybuild will just DTRT Someone with some python-clue could perhaps take a look (and would be a better sponsor in that regard) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150709120218.gr17...@halon.org.uk
Re: Making Debian package with multiple opensource package
+++ dp [2015-06-07 19:35 -0700]: Hi Mentors, I am trying to create a .deb that has dependency on multiple opensource packages. These packages come from different sources . Few are available through apt-get, but few are on git clone or mirrored on personal websites. They have variety of compression mechanism such as .gzip, .bz2 etc. and individual make files. I wonder how do I pull the sources and/or binary to create .deb out of multiple opensources ? this .deb need to be installable on architecture types i386, amd64 etc. It is not normally correct to pull multiple upstream tarballs into one debian package. Usually each one should be packaged separately and the dependencies marked. Only if they are so closely related that they cannot be sensibly used separately, or by any other packages, does combination make sense. So it is _sometimes_ correct to do this (have more than one upstream tarball in a package) (I had to once), and there are packaging tools to help with the mechanics. Back in the day only dbs could do this, but that's deprecated and now you can use the standard tools: https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150610125706.gp26...@halon.org.uk
Re: mipsel -m64 testing
+++ Michael R. Crusoe [2015-05-27 20:19 +]: Hello, With regards to the FTBFS below, is Debian mipsel always 64 bit, always 32 bit, or a mix? mipsel (and mips) are 32-bit ABIs. mips64el (and mips64) are the debian names for the 64-bit ABIs. How would I test that? dpkg-architecture -amipsel -qDEB_HOST_ARCH_BITS From: Andreas Tille andr...@an3as.eu Hi Michael, On Wed, May 27, 2015 at 01:37:30PM +, Michael R. Crusoe wrote: I interpret '-m64' as a signal that the developer only supports 64 bit OSes/hardware. From what I can find, mipsel can be 32 or 64bit. So I would suggest removing mipsel from the supported architecture series. 'gcc -m64' (on mipsel) is multilib speak for gcc-mips64el-linux-gnuabi64 Debian should be fixing up these multilib shortcuts because they are not consistent between architectures. '-m64' means different things on different arches. Using an explicit GNU triplet in toolchain invocations will always work both natively and for crossing. See https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib Does that make sense? Not really since it also fails on arm64 with the same error. adding -m64 on arm64 to a gcc invocation will result in an error because it is meaningless. In general we should (IMHO) simply not be using -m32 or -m64 in debian builds. Not sure if I have understood you properly there? Maybe there is some other reason for the build failure. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015052734.ge24...@halon.org.uk
Re: why dpkg-buildpackage doesn't care my build targets in debian/rule
+++ Mattia Rizzolo [2015-05-22 17:04 +0200]: On Fri, May 22, 2015 at 6:31 AM, lumin cdlumin...@gmail.com wrote: override_dh_auto_build: # well. let's copy config back again. cp ./debian/my/Makefile.config.cpuonly ./Makefile.config debian/my/00-fix-caffe-include-path-debian.sh $(MAKE) all $(MAKE) test $(MAKE) runtest also, that test things should go in a override_dh_auto_test target, not in the build one. Right, so that DEB_BUILD_OPTIONS=nocheck works, which is often important for cross-building. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150522180834.go24...@halon.org.uk
Re: tuxonice-userui: can architecture be changed to linux-any ?
+++ Julien Muchembled [2015-01-01 22:15 +0100]: When I saw someone was using TuxOnIce on ARM[1], I wondered if the architecture could be changed to linux-any and I prepared a patch[2] However, my sponsor disagrees because such change should only be done after knowing it actually works on the added architecture, either by testing or asking upstream. I'm just so convinced to be right that I seek another opinion, so that I can move on. Originally, the architecture was 'any' and it was changed because of bug #389325 (FTBFS). Later, the problematic source file was removed so I first see no reason not to revert a change that was only done because of this. For the majority of (*-)any packages, I think upstream is unable to answer for something else that i386/amd64. Maybe also arm/powerpc, but for the other architectures, there are so few users. So by default, it looks like Debian would just check it builds. I searched a little through Git histories and the ML and could not find anything architecture-specific code. It seems that TOI is supposed to work on any machines for which classical hibernation works. Debian packages should be built for all arches unless there is a good reason why not (known not to build, known not supported, part of arch-specific dependency chain). So there is an assumption that things are 'any' by default, and only restricted if necessary. It is not a bad thing to build packages for arches where they are almost never used and may not even work, because it least then it is easy for people with the necessary hardware to test. By that reasoning this packages does indeed sound like it should be 'any'. It would have been useful to cc the sponsor who disgrees on this mail so we can hear if there is some good reason why 'any' is in fact not appropriate. I suggest you file a debian bug with this patch, so that any necessary debate will be recorded there. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150304090300.gm4...@stoneboat.aleph1.co.uk
Re: From mentors to Debian repo
+++ T o n g [2015-01-11 20:11 +]: Hi, What happens when I have *more than one* version uploaded to mentors, then ftp master upload the package to the official Debian repo? I don't think the version on mentors matters here. What matters is what versions are uploaded to the Debian archive. It happened to me twice, and twice had the older package appear in official Debian repo, instead of my newly uploaded latest version. To take the dbab example, which I am familiar with as sponsor. What happens is this: 1) You upload 1.1.2 to mentors. I review and upload 1.1.2 to Debian. Sits in NEW queue. 2) You upload 1.2.2 to mentors. I review and upload 1.2.2 to Debian. Sits in NEW queue. 3) FTPmaster gets to review dbab and OK's it in queue. They can easily not notice that there is a second version already uploaded (I suspect their interface makes it hard to notice as this has happened to me a couple times). FTPmaster OKs dbab 1.1.2 so it is now in unstable. 1.2.2 is also in the archive, but now in a sort of limbo. 4) I try to re-upload 1.2.2 but it fails due to 'already in the archive/mismatched checksums'. 5) Before I get round to fixing this something (FTPmaster or some cleanup code, I don't know), notices 1.2.2 and it migrates into unstable. So, none of this is really anything to do with the versions uploaded to mentors. It's best not to upload a second version before the first one is out of NEW, because there is a quite a high risk of something like the above happening, which is not a big deal, just a bit annoying. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150111211525.gy4...@stoneboat.aleph1.co.uk
Re: launchpad for debian and autobuilders
+++ Leopold Palomo-Avellaneda [2014-12-12 08:57 +0100]: Hi, do you know if exist some place where someone could dput a debian source package and it was built in a clean environtment for a debian distro, as launchpad service for ubuntu? Debian is (slowly, as ever, help very welcome) working on PPA-equivalents. In the meantime the only public service I'm aware of for this is OBS: https://build.opensuse.org/ There are debian packages for the client end (obs-build) which you can install, prepare your package, and specifiy what distros/suites you want it built for, then OBS will do that for you. The architecture support does not cover all of debian's arches. And, if it doesn't exist, could some of you explain why we don't have this? It's mostly designed, but is waiting for the tuits to implement it. Or, should I have to create a something similar to a jenkins infrastructure to test and build my own packages? It should be loads easier than it is for a random person to install a little local autobulder. We have been very bad at making this easy. It is relatively painless to install: rebuildd, debile or pybit and get things rebuilt-on-checkin, but only for your local arches unless you have a handy pile of foreign-arch machines lying around or can be bothered to set up qemu-builders or cross-builders. (And all of those packages have issues to some degree). But that doesn't solve the 'having somewhere public for others to download from' or the 'building other arches natively' issues. I have looked at this issue a few times and would love to have more time to spend to spend on it... Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212122911.gh27...@stoneboat.aleph1.co.uk
Re: Please sponsor dbab, the dnsmasq-based ad-blocker
+++ Tong Sun [2014-12-12 09:52 -0500]: Dear mentors, I'd like to bring your attention again to dbab, the innovative dnsmasq-based ad-blocker that will benefit most people. I'll keep reposting this request regularly in hoping someone will pay attention to it. OK. This sounded interesting the first time. And you seem to be keen, so I had a look: I could be persuaded to sponsor. dget -x http://mentors.debian.net/debian/pool/main/d/dbab/ dbab_1.1.1-1.dsc Some comments: * remove the dh_make boilerplate from debian/rules, postinst, postrm. * There should be a systemd service file as well as an init script * Any reason why dh compat level is 8 not 9? * The package has a .pc dir but there is no patch series Other than that it looks simple enough Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212214906.gm27...@stoneboat.aleph1.co.uk
Re: Please sponsor dbab, the dnsmasq-based ad-blocker
+++ Wookey [2014-12-12 21:49 +]: +++ Tong Sun [2014-12-12 09:52 -0500]: Dear mentors, I'd like to bring your attention again to dbab, Other than that it looks simple enough Oh, and a man page would be nice. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212215129.gn27...@stoneboat.aleph1.co.uk
Re: Qemubuilder for arm64?
+++ Daniel Stender [2014-11-19 21:41 +0100]: Hi, I'm trying to get Qemubuilder run for arm64 package building, but fails so far. I've got a proper kernel and initrd, but breaks with: Your architecture arm64 does not seem to be supported. Maybe that's exactly how it is, is it? I am not familiar with qemubuilder. What does it do? I can tell you that qemu works fine for arm64 and has for a while. qemu-debootstrap will make you a qemu-ready chroot you can build in. Does anybody has got Qemubuilder run for arm64, or have any pointers to other cross-package-building solutions other than building in a Qemu box itself? amd64-arm64 cross-toolchains for Jessie and unstable exist: https://wiki.debian.org/CrossToolchains has details. This stuff is still quite new and I'm moving things around at the moment. Note that the unstable cross-toolchains are uninstallable for a couple of days after each new gcc upload until new ones are rebuilt to match. Updated packages should be uploaded tomorrow. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141119231403.gj27...@stoneboat.aleph1.co.uk
Re: Making a package multiarch (for real)
+++ Mathieu Malaterre [2014-11-06 18:10 +0100]: [CC me please] I am trying to make CharLS a true multiarch capable package. However I fail to understand what I did wrong. Steps: $ apt-get source charls $ cd charls-1.0 $ vim debian/control - mark libcharls-dev as `Multi-Arch: foreign` and libcharls1 as `Multi-Arch: same` In general -dev packages should be :same, along with the library packages, then -dev packages for build and host arches can be co-installed for cross-compiling. I know the docs are out of date on this point, but please do both unless it is difficult for some reason. Build on both amd64 and i386: $ dpkg -I libcharls1_1.0-5_amd64.deb | grep same Multi-Arch: same $ dpkg -I libcharls1_1.0-5_i386.deb | grep same Multi-Arch: same shared lib are using proper multiarch paths: $ dpkg -c libcharls1_1.0-5_amd64.deb drwxr-xr-x root/root 0 2014-11-06 17:53 ./ drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/ drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/ drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/share/doc/libcharls1/ -rw-r--r-- root/root 750 2014-11-06 16:23 ./usr/share/doc/libcharls1/changelog.Debian.gz -rw-r--r-- root/root 1860 2014-11-06 16:23 ./usr/share/doc/libcharls1/copyright drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/lib/ drwxr-xr-x root/root 0 2014-11-06 17:53 ./usr/lib/x86_64-linux-gnu/ -rw-r--r-- root/root198824 2014-11-06 17:53 ./usr/lib/x86_64-linux-gnu/libCharLS.so.1.0 lrwxrwxrwx root/root 0 2014-11-06 17:53 ./usr/lib/x86_64-linux-gnu/libCharLS.so.1 - libCharLS.so.1.0 and: $ dpkg -c libcharls1_1.0-5_i386.deb drwxr-xr-x root/root 0 2014-11-06 17:54 ./ drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/ drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/ drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/share/doc/libcharls1/ -rw-r--r-- root/root 750 2014-11-06 16:23 ./usr/share/doc/libcharls1/changelog.Debian.gz -rw-r--r-- root/root 1860 2014-11-06 16:23 ./usr/share/doc/libcharls1/copyright drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/lib/ drwxr-xr-x root/root 0 2014-11-06 17:54 ./usr/lib/i386-linux-gnu/ -rw-r--r-- root/root198060 2014-11-06 17:54 ./usr/lib/i386-linux-gnu/libCharLS.so.1.0 lrwxrwxrwx root/root 0 2014-11-06 17:54 ./usr/lib/i386-linux-gnu/libCharLS.so.1 - libCharLS.so.1.0 Install: $ sudo dpkg -i libcharls1_1.0-5_amd64.deb libcharls1_1.0-5_i386.deb (Reading database ... 252480 files and directories currently installed.) Preparing to unpack libcharls1_1.0-5_amd64.deb ... Unpacking libcharls1:amd64 (1.0-5) over (1.0-5) ... Preparing to unpack libcharls1_1.0-5_i386.deb ... Unpacking libcharls1:i386 (1.0-5) over (1.0-5) ... Setting up libcharls1:amd64 (1.0-5) ... Setting up libcharls1:i386 (1.0-5) ... Processing triggers for libc-bin (2.19-12) ... But then: $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: libcharls1:i386 : Conflicts: libcharls1 but 1.0-5 is installed E: Unmet dependencies. Try using -f. I presume you are on an amd64 box? It's not obvious what's wrong there. Is your package available somewhere to look at? How do I get a detailed diagnosis of the conflicting files ? Good question. I usually use aptitude but it's not great for multiarch issues. does apt-get -f install help? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106175709.gk28...@stoneboat.aleph1.co.uk
