Re: PC file not exist on libiniparser-dev
Le dim. 31 mars 2024 à 00:55, kwang son a écrit : > Hi, > > I'm a new user to Debian. > I hope this is the right place to ask questions. > > libiniparser-dev does not have pc file. > which is exist on upstream repo [1] > > I want to know > 1. -dev not needs pc file? Not mandatory. *-dev usually distributes headers. Optionally .pc file. > 2. why upstream has, but debian packaging not? > Maintainer of the package probably overlooked installing it - or had a reason not to install it. You can open a wishlist bug asking gently to install that pkgconfig pc file, using reportbug libiniparser-dev In the meantime, use -liniparser and -I/usr/include/iniparser.h (or similar with correct names). Jérémy
PC file not exist on libiniparser-dev
Hi, I'm a new user to Debian. I hope this is the right place to ask questions. libiniparser-dev does not have pc file. which is exist on upstream repo [1] I want to know 1. -dev not needs pc file? 2. why upstream has, but debian packaging not? --- Kwang [1] https://packages.debian.org/sid/libiniparser-dev
Re: Help on updating two python packages
On Sat, Mar 30, 2024 at 03:32:53PM -0400, Qianqian Fang wrote: > info: Hint: make sure the version in debian/changelog matches the unpacked > source tree You should do this. > for pybj, ci tasks finished ok, but the test-crossbuild-arm64 job failed > > https://salsa.debian.org/science-team/pybj/-/pipelines/659410 "/usr/bin/python3.11: Exec format error" is very weird and I cannot reproduce it on a porterbox. > also, I noticed that uscan downloads from pypi appear to include an > .egg-info folder that is not part of my git source repo. is this a problem? Why is it not a prt of your git source repo? Your upstream branch should match your orig tarball. > is monitoring github release/tag a better way or pypi is preferred? git is preferred in case PyPI tarballs are missing some files (most commonly tests). -- WBR, wRAR signature.asc Description: PGP signature
Help on updating two python packages
hi everyone, in 2020, I learned how to package debian packages and created two python packages https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964993 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964994 over the last few years, the upstream git repos of both projects had been updated but the watch files failed to detect new releases. I still have access to both packages on salsa https://salsa.debian.org/science-team/pyjdata https://salsa.debian.org/science-team/pybj I just tried the following steps to update the packages 1. modify the debian/watch file to watch pypi releases 2. run uscan, download the new upstream tarball 3. commit the change of the watch file 4. run gbp import-orig --pristine-tar ../newpackage.orig.tar.gz 5. update files under debian/ 6. git push --all after this, I noticed that pyjdata CI failed with with the following errors https://salsa.debian.org/science-team/pyjdata/-/pipelines/659403 dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/pyjdata_0.3.6-1+salsaci+20240330+8.diff.yssV2X 1094 <https://salsa.debian.org/science-team/pyjdata/-/jobs/5520025#L1094>dpkg-source: info: Hint: make sure the version in debian/changelog matches the unpacked source tree 1095 <https://salsa.debian.org/science-team/pyjdata/-/jobs/5520025#L1095>dpkg-source: info: you can integrate the local changes with dpkg-source --commit 1096 <https://salsa.debian.org/science-team/pyjdata/-/jobs/5520025#L1096>dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 for pybj, ci tasks finished ok, but the test-crossbuild-arm64 job failed https://salsa.debian.org/science-team/pybj/-/pipelines/659410 I am wondering if anyone can help me resolve these issues - was there any problem for the steps I took? any pointers on how to properly update a package to new upstream release would be appreciated. also, I noticed that uscan downloads from pypi appear to include an .egg-info folder that is not part of my git source repo. is this a problem? is monitoring github release/tag a better way or pypi is preferred? thanks Qianqian
Bug#1068101: RFS: mini-httpd/1.30-10 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-10 Upstream contact : Jef Poskanzer j...@mail.acme.com * URL : https://www.acme.com/software/mini_httpd * License : BSD-2-clause * Vcs : https://salsa.debian.org/debian/mini-httpd Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-10.dsc Changes since the last upload: mini-httpd (1.30-10) unstable; urgency=medium * Added patch improving handling of "charset=%s" in error pages and directory listing. Before, a literal "%s" was output as opposed to the actual charset. Now, the correct charset (UTF-8 for dirs and ISO-8859-1 for err) is output. Thanks again, Alexander Foken ! (Closes: #714549) * Added a SystemD DocumentationKey entry fixing lintian warning. This points to the manpage for now. * Added SystemD hardening features to service. The directives I have provided should have no impact. I've confirmed no impact to basic functionality, vhosting, error pages and CGI. I managed to get the service to a "4.7 - OK" rating by using systemd-analyze security mini-httpd (all the way from 9.6). I have NOT enabled hardening features which have a high change of impacting functionality such as removing CAP_CHROOT which would mean mini_httpd's chroot mode of operation is forbidden. Help is welcome in improving these options (maybe someone with a security background could chip in). Regards, -- Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
