devscripts uninstallable in Debian Sid due to unmet dependencies
Hello! It seems devscripts cannot be installed in Sid at the moment. I was not able to find a bug report about this on bugs.debian.org and I cannot follow up the dependencies on what package actually is stopping it. Anybody else experiencing this as well? $ docker run -it debian:sid bash root@dda7794f2e25:/# apt update Get:1 http://cdn-fastly.deb.debian.org/debian sid InRelease [139 kB] Get:2 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages [8244 kB] Fetched 8383 kB in 8s (1107 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 24 packages can be upgraded. Run 'apt list --upgradable' to see them. root@dda7794f2e25:/# apt install devscripts Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: devscripts : Depends: libipc-run-perl but it is not going to be installed Depends: libmoo-perl but it is not going to be installed Depends: libwww-perl but it is not going to be installed Recommends: libgitlab-api-v4-perl but it is not going to be installed Recommends: licensecheck but it is not going to be installed Recommends: lintian but it is not going to be installed Recommends: liblwp-protocol-https-perl but it is not going to be installed Recommends: libsoap-lite-perl but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@dda7794f2e25:/# apt install lintian Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: lintian : Depends: libapt-pkg-perl but it is not going to be installed Depends: libcgi-pm-perl but it is not going to be installed Depends: libclass-accessor-perl but it is not going to be installed Depends: libclone-perl but it is not going to be installed Depends: libemail-valid-perl but it is not going to be installed Depends: libio-async-loop-epoll-perl (>= 0.20) but it is not going to be installed Depends: libipc-run-perl but it is not going to be installed Depends: liblist-moreutils-perl but it is not going to be installed Depends: libmoo-perl but it is not going to be installed Depends: libxml-simple-perl but it is not going to be installed Depends: libyaml-libyaml-perl but it is not going to be installed Recommends: libperlio-gzip-perl but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@dda7794f2e25:/# apt install libmoo-perl Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libmoo-perl : Depends: libimport-into-perl but it is not going to be installed Depends: libmodule-runtime-perl (>= 0.014) but it is not going to be installed Recommends: libclass-xsaccessor-perl (>= 1.18) but it is not going to be installed Recommends: libsub-name-perl (>= 0.08) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Re: devscripts uninstallable in Debian Sid due to unmet dependencies
Hello, Otto Kekäläinen, le dim. 06 oct. 2019 10:40:17 +0300, a ecrit: > It seems devscripts cannot be installed in Sid at the moment. I was > not able to find a bug report about this on bugs.debian.org and I > cannot follow up the dependencies on what package actually is stopping > it. > > Anybody else experiencing this as well? Everybody, yes. Please read debian-devel-announce: the perl 5.30 transition was announced there yesterday. Samuel
Re: devscripts uninstallable in Debian Sid due to unmet dependencies
Hi Otto, On 06-10-2019 09:40, Otto Kekäläinen wrote: > It seems devscripts cannot be installed in Sid at the moment. I was > not able to find a bug report about this on bugs.debian.org and I > cannot follow up the dependencies on what package actually is stopping > it. https://lists.debian.org/debian-devel-announce/2019/10/msg0.html Perl transition. Paul signature.asc Description: OpenPGP digital signature
RE:devscripts uninstallable in Debian Sid due to unmet dependencies
perle 5.30 transition whcih was announced here https://lists.debian.org/debian-devel-announce/2019/10/msg0.html
Re: source only upload with git-buildpackage
On 06.10.19 08:18, Attila Szalay wrote: > That option means that the system will create not only the binary > .amd.changes but another changes too which contains only the source > packages. And I would like to use this method to be sure the package > compiles, to be able to run the lintian against the package and even > be able to test it before the upload. > Sounds cool, right now i use a different workflow: Build and sign source packages and send them to pbuilder (different machine) - build in two architectures, lintian is part of the build process, pbuilder hook. So i was a bit irritated :) Cheers Alf
Re: source only upload with git-buildpackage
On Sun, Oct 6, 2019 at 6:27 PM Alf Gaida wrote: > > On 06.10.19 08:18, Attila Szalay wrote: > > That option means that the system will create not only the binary > > .amd.changes but another changes too which contains only the source > > packages. And I would like to use this method to be sure the package > > compiles, to be able to run the lintian against the package and even > > be able to test it before the upload. > > > Sounds cool, right now i use a different workflow: Build and sign source > packages and send them to pbuilder (different machine) - build in two > architectures, lintian is part of the build process, pbuilder hook. So i > was a bit irritated :) I'm not sure what's your configuration. But I use git buildpackage, too. Seems you're using pbuilder / cowbuilder to do the real build, rather than git buildpackage. So you need to set up ~/.pbuilderrc, instead of ~/.gbp.conf Personally, I set up "SOURCE_ONLY_CHANGES=yes" in ~/.pbuilderrc. And I think you can get more info about pbuilder / cowbuilder by: - https://wiki.debian.org/PbuilderTricks - https://wiki.debian.org/git-pbuilder If you need more help, I think you should share your ~/.gbp.conf and ~/.pbuilderrc Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Debian and our frenemies of containers and userland repos
On Sat, 05 Oct 2019 at 12:41:55 -0400, Nicholas D Steeves wrote: > AFAIK sbuild has had this support for a while with --chroot-mode > autopkgtest, --autopkgtest-virt-server (lxc, lxd, or qemu), and > --autopkgtest-virt-server-opts='name of container goes here' will also > do the trick; however, it's still marked experimental. > > https://manpages.debian.org/unstable/sbuild/sbuild.1.en.html > > Yes, I also find it strange that one has to use arguments named > "autopkgtest" to build on LXC, but that seems to be what the fine manual > indicates how it works. FYI, this is because autopkgtest has an abstraction for multiple container/virtualization mechanisms (lxc, lxd, qemu, schroot), which some other tools (sbuild, reprotest, vectis) have reused as a way to avoid having to invent their own equivalent abstraction. sbuild doesn't know anything about lxc specifically, but it does know how to use an arbitrary autopkgtest-virt-* backend, and autopkgtest-virt-lxc is one of those. (There's an autopkgtest merge request open to add a docker backend, which I'll try to fix up enough to get it merged at some point.) smcv
Bug#941860: ITP: ruby-statistics -- ruby gem for statistics inspired by the jStat js library
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-statistics Version : 2.1.1 Upstream Author : Esteban Zapata Rojas * URL : https://github.com/estebanz01/ruby-statistics * License : Expat Description : ruby gem for statistics inspired by the jStat js library This gem is intended to accomplish the same purpose as jStat js library: to provide ruby with statistical capabilities without the need of a statistical programming language like R or Octave. Some functions and capabilities are an implementation from other authors and are referenced properly in the class/method. signature.asc Description: OpenPGP digital signature
Re: source only upload with git-buildpackage
Hi, > I'm struggling with it for a while now and I couldn't find the solution. > I have a package maintained with git-buildpackage. And now, that I > "cannot" upload binary packages I tried to compile the new version with > the option to create a source-only changes file too. But for some reason > that changes files are not created. I'm using this alias: % type git-bcS git-bcS is an alias for gbp buildpackage --git-builder='debuild -i^\.git -i^\.travis.yml -I.git -S -d' That should do what you want :) Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Discussion tooling
On 05/10/19 22:20, Samuel Henrique wrote: On Wed, 2 Oct 2019 at 14:51, Antonio Terceiro wrote: Note that email already has a "tree-like" structure, since forever. You just don't see it if you (ironically) use web application email clients like gmail that decided to not show it. Most console/desktop clients that I ever saw do support it. Hm, but I wonder of the ones you saw how much they are used, because from the ones I see people using, I would say less than 5% (by usage) has this. And even then we are talking about tools that are either console or desktop-only, there is still the smartphone user cases and, most importantly, being able to follow the discussions without the need to authenticate and being subscribed to the list, which would be useful for outsiders (and an outsider is someone who will become a contributor eventually). As a non-DD and lurker, personally I like the NNTP interface at linux.debian.devel, which I believe is provided by Marco d'Itri. This doesn't require me to subscribe to the list and avoids clogging up my email, although it does require me to have a news server configured and Usenet is of only minority interest these days. It is better than trying to read the web archives and much easier to reply to. I think the header munging works well enough for my occasional posts to be properly threaded. I should add that K-9 Mail for Android has an option for a threaded view and is moderately popular (5-10 million downloads from Google Play plus more from F-Droid). Roger PS I had forgotten that one does have to be registered with the news to mailing list gateway in order to post through it.
RE:source only upload with git-buildpackage
And what about dgit --gbp push-source ?
Re: source only upload with git-buildpackage
On 10/6/19 11:15 PM, PICCA Frederic-Emmanuel wrote: > And what about > > dgit --gbp push-source ? not going to touch that. dgit is imho way to over-engineered while having requirements at the same time, that I don't want to have (like using dgit.debian.org...). We have salsa as central repository, there is absolutely no need to have something else. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Discussion tooling
On 2019-10-06 22:02:19 +0100 (+0100), Roger Lynn wrote: [...] > As a non-DD and lurker, personally I like the NNTP interface at > linux.debian.devel, which I believe is provided by Marco d'Itri. [...] Thanks for the reminder! I had forgotten this was even available, and will strongly consider switching to it. A fairly large free/libre open-source project I'm involved with has been considering bridging its extremely high-volume mailing lists via NNTP, and I personally think it's a great idea. I have fond memories of Usenet, and suspect it would still be an underpinning of forums today if it hadn't been the first line breached in the spam wars. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Discussion tooling (was: Bits from the DPL (August 2019))
Hello, On Sat 05 Oct 2019 at 10:13PM +01, Samuel Henrique wrote: > I don't understand the argument of it being a social problem, isn't our > own constitution a technical solution to a social problem? Hmm, I think that "social problem" is not what I meant. It's difficult to communicate effectively in writing, and we do not have good ways of collating best practices for doing that and passing them on to new and existing contributors. Further, communicating effectively in writing takes energy that isn't always available. To my mind, this is what's responsible for us communicating less effectively. When I say that's it's not a technical problem, I just mean that it seems like a problem we can't program our way out of. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian and our frenemies of containers and userland repos
On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > FYI, this is because autopkgtest has an abstraction for multiple > container/virtualization mechanisms (lxc, lxd, qemu, schroot) It seems like this abstraction should be split out of the autopkgtest source and then depended on by autopkgtest. Do any other such abstraction layers exist? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian and our frenemies of containers and userland repos
Quoting Paul Wise (2019-10-07 03:38:55) > On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > > FYI, this is because autopkgtest has an abstraction for multiple > > container/virtualization mechanisms (lxc, lxd, qemu, schroot) > It seems like this abstraction should be split out of the autopkgtest > source and then depended on by autopkgtest. Do any other such > abstraction layers exist? I do not know of any other such abstraction layers but would warmly welcome them not only for the purpose of including them in sbuild. Specifically, currently autopkgtest is limited to providing a read-only layer for certain backends and its upstream has no intention of widening the scope of the software [1]. This means that to upgrade an autopkgtest backend, the user has to apply backend-specific actions which defeats the purpose of having a unified abstraction layer for multiple backends in the form they get used by sbuild. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332 This is also one of the main reasons why the autopkgtest backend is still marked as experimental by sbuild as other contributors to this thread already noticed: sbuild-update will never be able to upgrade autopkgtest-based backends. :( Thanks! cheers, josch signature.asc Description: signature
