Bug#1016612: ITP: tanidvr -- tool for DVRs and IP cameras based on DVR-IP protocol used by Dahua
Package: wnpp Severity: wishlist Owner: Marcos Talau X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tanidvr Version : 1.4.1 Upstream Author : Daniel Mealha Cabrita * URL : http://tanidvr.sourceforge.net * License : GPL-3 Programming Lang: C Description : tool for DVRs and IP cameras based on DVR-IP protocol used by Dahua TaniDVR is a CLI tool for accessing DVRs and IP cameras used for CCTV surveillance systems based on the proprietary DVR-IP protocol (port 3/TCP). . The main use of TaniDVR is to dump video from a device. With this you can record to a Matroska (MKV) file or play the video in realtime with an external player. . TaniDVR works with OEM DVRs and IP cameras produced by Dahua, sold under several brands, such as: * Apollo * Acorn F&S * BCS * C2Max * DVR365 * GWave * Intelbras * IntelliPix * Kompsos * Mace S. P. * New Surway * NextVision * Q-See * WatchNet (and dozens more) . But if the device works with the DVR-IP protocol, it is expected to work. . TaniDVR is confirmed to work with the following devices: * BCS BCS-DVR0801QE II * BCS BCS-DVR1602Q * BCS BCS-DVR3208M * BCS BCS-IPC-HFW2100 * BCS BCS-NVR0802 * BCS BCS-TIP1130IR * Dahua DH-DVR0404HF-AN * Dahua DH-DVR1604HF-U-E * Dahua DH-NVR3816 * Dahua IPC-HDB3200C * Intelbras VD 8E 240 * Intelbras VD 16E 480C * QVIS Apollo (see updated list at TaniDVR's website)
Bug#1016606: ITP: libpanel -- IDE paneling library for GTK
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: libpanel-1-1 (etc) Version: 1.0~alpha Upstream Author: Christian Hergert License: LGPL-3+ Programming Lang: C Description: IDE paneling library for GTK libpanel is a collection of GTK widgets for IDE-like applications targeting GNOME using GTK 4 and libadwaita. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/libpanel It is a required dependency for GNOME Builder 43 which will use GTK4. Thanks, Jeremy Bicha
Re: Bug#1016575: sbuild aborting when dh-python isn't installed locally
Hi Matthias, no idea why you CC-ed debian-devel@lists.debian.org with your bug. This is a bug about using Debian so the correct mailing list would be debian-u...@lists.debian.org. The mailing list you chose is for the development of Debian. I'm closing this bug because what you experienced is actually a feature. Explanation below. Quoting matthias.geiger1...@tutanota.de (2022-08-03 10:04:32) > I just did a clean testing install and set up sbuild as usual. When trying to > build a package the Build-depends: on dh-python sbuild aborts: > > sbuild > dpkg-source: info: using options from secrets-6.2/debian/source/options: > --extend-diff-ignore=^[^/]*[.]egg-info/ > dh clean > dh: error: unable to load addon python3: Can't locate > Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the > Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 > /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 > /usr/share/perl/5.34 /usr/local/lib/site_perl) at (eval 13) line 1. > BEGIN failed--compilation aborted at (eval 13) line 1. > > make: *** [debian/rules:4: clean] Error 255 > E: Failed to clean source directory /home/werdahias/Packaging/secrets-6.2 > (/home/werdahias/Packaging/secrets_6.2-1.dsc) > > This shouldn't be an issue as sbuild *should* just install dh-python itself. > It worked once I installed dh-python on the host machine. No, sbuild should *not* just install dh-python on your host system. There are multiple reasons for that but one is, that when you run sbuild, the expectation is, that this will not change your host system. That's a big part of the reason why many people use sbuild: so that the things that are needed to build a source package do not clutter their host system but are instead installed into a fresh buildd chroot environment. Another reason why sbuild cannot even do this in principle is, because sbuild is not run as root. So it doesn't even have the necessary privileges to install anything on your host system -- which is a good thing! To go a bit further into why what you experience is a feature and not a bug: The usual input to sbuild is a source package (a *.dsc). From what I can see, you are running sbuild without any arguments from within an unpacked source package directory (I assume that's what /home/werdahias/Packaging/secrets-6.2 is). This would usually not be possible because an unpacked source package is not a source package. Because the input to sbuild is a source package, you first have to build said source package from your unpacked source package tree. To make this as convenient as possible for sbuild users, sbuild has a feature that allows it to build the source package automatically if you run it from within an unpackaged source package tree. As part of building that source package it is running the "clean" target of your debian/rules and in your case, the clean target needs dh-python installed which you do not have installed and thus results in the failure you observe. I can think of two ways to fix this: a) give up on this convenience feature of sbuild and build the *.dsc yourself in any way you want and then feed that to sbuild b) run sbuild with --no-clean-source which will not run the "clean" target and thus not require dh-python in your case. But beware that this means that you are responsible for making sure that your unpacked source directory is clean Thanks! cheers, josch signature.asc Description: signature
Re: Coq packages in Debian : difficult transitions
Hi,
Le lundi 01 août 2022 à 14:20 +0200, Joachim Breitner a écrit :
>
> Am Sonntag, dem 31.07.2022 um 12:33 +0200 schrieb
> julien.pu...@gmail.com:
> > I have a little script that tells me the following packages needs
> > to be
> > rebuilt when a transition has to be done ; for example:
> >
> > $ ./planif_transition.py mathcomp-finmap
> > mathcomp-finmap
> > mathcomp-analysis mathcomp-multinomials
> > coqeal
> >
> > (the lines are meaningful: same line means parallel build is
> > possible)
> >
> > So far, so good. But managing transitions is pretty annoying:
> >
> > (1) The checksums are arch-dependent, which is annoying to write
> > ben
> > transition scripts. I just need to trigger builds in the right
> > order.
> > How do I tackle it?
> >
> > (2) The other C-style lib* packages don't need maintainers to write
> > transitions: the automatic ones just work. How can I have libcoq-*
> > packages work like this?
> >
>
> it looks like you re-created the setup that the Haskell and Ocaml
> packages use, with the provides/depends and hashes.
>
Yes, dh-ocaml has been a great inspiration. I didn't know any Perl
before...
> We have a tool that produces a file with the necessary commands to
> pass to wanna-build, see for example in
> https://people.debian.org/~iliastsi/binNMUs-haskell.txt
>
> I used to produce a file like this for Ocaml, but it’s gone since I
> disabled my account. It’s configured via a simple regex,
> libghc-(.*)-dev-([0-9.]+)-([0-9a-f]{5})
> in the case of Ocaml.
>
> The source code is at
> https://salsa.debian.org/haskell-team/tools/-/tree/master/binnmus
>
> It may be useful to you too
Yes ; as I mentioned I have a tool that prints the steps to follow to
rebuild, so I might be able to make it evolve to produce wanna-build
scripts.
Cheers,
J.Puydt
Re: Coq packages in Debian : difficult transitions
Le dimanche 31 juillet 2022 à 12:43 +0200, Sebastian Ramacher a écrit : > On 2022-07-31 12:33:35 +0200, julien.pu...@gmail.com wrote: > > Hi, > > > > I tried to ask on debian-release because it seemed more sensible > > but didn't get feedback. [1] > > Please file a transition bug. The mailing list has a high volume and > non-bug mails may be overlooked. Bug 1016416, but that doesn't look that efficient. J.Puydt
