Bug#976183: ITP: golang-github-godbus-dbus -- Native Go bindings for D-Bus
Package: wnpp Severity: wishlist Owner: Hayley Hughes X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name : golang-github-godbus-dbus Version : 5.0.3-1 Upstream Author : * URL : https://github.com/godbus/dbus * License : BSD-2-clause Programming Lang: Go Description : Native Go bindings for D-Bus dbus is a simple library that implements native Go client bindings for the D-Bus message bus system. Required for packaging golang-github-containers-toolbox (See: #972674)
Re: Debconf - adding "treeselect" type(s)?
Hallo Steve McIntyre, 30.11.20 16:36 Steve McIntyre: > I'll admit that I'm thinking of this *mostly* in terms of the needs of > tasksel so far, but I'd expect switching to a new template type is > likely to need a rethink to make best use of them anyway. In my mind there is also locales where we should have three levels: de de_AT de_DE [ ] de_DE [ ] de_DE@euro [ ] de_DE.UTF-8 en en_DK en_GB en_US Grüße Timo signature.asc Description: This is a digitally signed message part.
Bug#976184: ITP: golang-github-cobaugh-osrelease -- Golang package to read and parse /etc/os-release
Package: wnpp Severity: wishlist Owner: Hayley Hughes X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name : golang-github-cobaugh-osrelease Version : 0.0~git20181218.a93a0a5-1 Upstream Author : Andy Cobaugh * URL : https://github.com/cobaugh/osrelease * License : BSD-3-clause Programming Lang: Go Description : Golang package to read and parse /etc/os-release A Go package to make reading in os-release files easy. . See https://www.freedesktop.org/software/systemd/man/os-release.html Required for packaging golang-github-containers-toolbox (See: #972674)
RE:deduplicating jquery/
What about doing something similar to sphinx. Create a package with the doxygen jquery and link to files of this package for all documentations generated via doxygen. provide a dh_doxygen to do this link like dh_sphinxdoc Cheers Fred
Re: deduplicating jquery/
Il 01/12/20 08:18, Niels Thykier ha scritto: Russ Allbery: The root problem, at least as I understand it, is that the two relevant upstreams (and probably lots more) have followed those practices to vendor and pin versions of jQuery, and are not regularly updating those pins, so the current version in Debian may or may not work. As I recall, in the doxygen case the "jQuery" is in fact jQuery + modifications. So it is not even trivial to fix this with symlinking even if the version "match". ~Niels Yes, but at least for doxygen, upstream is working in the direction of making it easier for us to "debundle". See this issue and related PRs: https://github.com/doxygen/doxygen/issues/7361 Paolo
Re: deduplicating jquery/
On 2020-12-01 11:00, PICCA Frederic-Emmanuel wrote: > What about doing something similar to sphinx. > Create a package with the doxygen jquery and link to files of this package > for all documentations generated via doxygen. > provide a dh_doxygen to do this link like dh_sphinxdoc +1 In addition, with every new release of doxygen and its jquery, all -doc packages built with dh_doxygen would need rebuilding. Best, Andrius
Re: deduplicating jquery/
Quoting Andrius Merkys (2020-12-01 10:28:16) > On 2020-12-01 11:00, PICCA Frederic-Emmanuel wrote: > > What about doing something similar to sphinx. > > Create a package with the doxygen jquery and link to files of this package > > for all documentations generated via doxygen. > > provide a dh_doxygen to do this link like dh_sphinxdoc > > +1 > > In addition, with every new release of doxygen and its jquery, all -doc > packages built with dh_doxygen would need rebuilding. If the reason is that the file must be real (cannot be a symlink), then I guess there is the option of having the shared doxygen-jquery install a dpkg-trigger to do that update. Result would be that we at least de-bloat the binary packages, even though the installed system is still bloated. More importantly, it means that if a later release of doxygen fixes that annoying requirement to bloat the system, we can fix it by updating the trigger (no need _then_ to go over all packages). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: deduplicating jquery/
Il 01/12/20 10:00, PICCA Frederic-Emmanuel ha scritto: What about doing something similar to sphinx. Create a package with the doxygen jquery and link to files of this package for all documentations generated via doxygen. provide a dh_doxygen to do this link like dh_sphinxdoc Cheers Fred I'm afraid this is not possible as explained by the previous doxygen maintainer here: https://salsa.debian.org/debian/doxygen/-/blob/master/debian/README.jquery Paolo
Re: deduplicating jquery/
Quoting Paolo Greppi (2020-12-01 10:53:11) > Il 01/12/20 10:00, PICCA Frederic-Emmanuel ha scritto: > > What about doing something similar to sphinx. > > Create a package with the doxygen jquery and link to files of this package > > for all documentations generated via doxygen. > > provide a dh_doxygen to do this link like dh_sphinxdoc > > > > Cheers > > > > Fred > > > > I'm afraid this is not possible as explained by the previous doxygen > maintainer here: > https://salsa.debian.org/debian/doxygen/-/blob/master/debian/README.jquery That file includes this passage: > The second option requires architecture independent binNMUs. Since the > archive does not do any architecture independent auto-building this is > not available either. This is not the first time I see a need for arch-independent auto-building. Can someone remind me: Why is it that we cannot do arch-independent auto-building? Is there actual technical blockers for doing that, or is it simply that we have not enabled some switch on the arch-indep buildds? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debconf - adding "treeselect" type(s)?
Timo wrote: >-=-=-=-=-=- > >Hallo Steve McIntyre, > >30.11.20 16:36 Steve McIntyre: >> I'll admit that I'm thinking of this *mostly* in terms of the needs of >> tasksel so far, but I'd expect switching to a new template type is >> likely to need a rethink to make best use of them anyway. > >In my mind there is also locales where we should have three levels: >de > de_AT > de_DE >[ ] de_DE >[ ] de_DE@euro >[ ] de_DE.UTF-8 >en > en_DK > en_GB > en_US ACK. For the tasksel work I'm also looking at a 3-level tree to organise the Blends stuff, at least. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> Can someone remind me: Why is it that we cannot do arch-independent
> auto-building?
We can and do autobuild arch-independent packages (since 2015: on the
timescale of multi-release transitions, this is relatively recent).
However, we cannot currently do arch-independent *binNMUs*, because a
large number of packages have patterns like this:
Source: foo
Package: foo-bin
Architecture: any
Depends: foo-data (= ${source:Version})
Package: foo-data
Architecture: all
which is based on the assumption that foo-data cannot be binNMU'd.
For example, consider foo_1.2-3, and suppose it has been binNMU'd 5
times on amd64, so we have foo-bin_1.2-3+b5_amd64.deb and
foo-data_1.2-3_all.deb. foo-bin Depends: foo-data (= 1.2-3) and the
dependency is satisfied.
Now suppose we also binNMU foo-data. We get foo-data_1.2-3+b1_all.deb,
which no longer satisfies foo-data (= 1.2-3), so foo-bin is uninstallable.
https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html lists
622 affected packages. I don't know whether there are other problematic
patterns that Lintian does not detect.
Possible solutions:
- Change at least 622 packages so they have something more like
Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
(also hope that all of their maintainers can get those runes right, taking
into account what the binNMU suffix is, and hope that it won't break
derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
compares less than +b1)
- Change at least 622 packages so that when foo-data is binNMU'd, it
automatically gets Provides: foo-data (= 1.2-3)
- Change some more central component so that the dependencies are edited
or the Provides is added globally
- Something clever that I haven't thought of
smcv
Re: Architecture: all binNMUs (was: deduplicating jquery/)
Quoting Simon McVittie (2020-12-01 11:56:28)
> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> > Can someone remind me: Why is it that we cannot do arch-independent
> > auto-building?
>
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-release transitions, this is relatively recent).
Yes - thanks for catching and tightening my far too sloppy framing of
the issue at hand.
> However, we cannot currently do arch-independent *binNMUs*, because a
> large number of packages have patterns like this:
>
> Source: foo
>
> Package: foo-bin
> Architecture: any
> Depends: foo-data (= ${source:Version})
>
> Package: foo-data
> Architecture: all
>
> which is based on the assumption that foo-data cannot be binNMU'd.
>
> For example, consider foo_1.2-3, and suppose it has been binNMU'd 5
> times on amd64, so we have foo-bin_1.2-3+b5_amd64.deb and
> foo-data_1.2-3_all.deb. foo-bin Depends: foo-data (= 1.2-3) and the
> dependency is satisfied.
>
> Now suppose we also binNMU foo-data. We get foo-data_1.2-3+b1_all.deb,
> which no longer satisfies foo-data (= 1.2-3), so foo-bin is uninstallable.
>
> https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html lists
> 622 affected packages. I don't know whether there are other problematic
> patterns that Lintian does not detect.
Thanks for the excellent explanation.
(and sorry for my failing memory: I am sure someone explained it to me
at least once before, related to debian-installer image building)
> Possible solutions:
>
> - Change at least 622 packages so they have something more like
> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
> (also hope that all of their maintainers can get those runes right, taking
> into account what the binNMU suffix is, and hope that it won't break
> derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
> compares less than +b1)
>
> - Change at least 622 packages so that when foo-data is binNMU'd, it
> automatically gets Provides: foo-data (= 1.2-3)
>
> - Change some more central component so that the dependencies are edited
> or the Provides is added globally
>
> - Something clever that I haven't thought of
- Introduce a control field "Build-Dependencies-Require-Rebuild: no"
(similar to "Rules-Requires-Root: no")
I mean, we could limit BinNMUing to packages that pre-declares that they
have taken into account the possibility of version skew not only for
arch-specific but also arch-independent package relations.
Yes, It feels wrong to introduce an explicit control field for that, but
there is a real benefit here for packages using doxygen, and there is a
real benefit for JavaScript packages in general, and I am sure other
areas as well (including possibly the debian-installer images?).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, 01 Dec 2020 at 10:56:28 +, Simon McVittie wrote:
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-release transitions, this is relatively recent).
>
> However, we cannot currently do arch-independent *binNMUs* [because...]
I've thought in the past that if the inability to do arch-independent
binNMUs can be fixed, it would be a good way to deal with some problems
that we currently face.
If I understand correctly, one of the ftp team's objections to discarding
and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3,
and they discard my binary upload and rebuild it on the buildds, this
would result in having two binary builds of foo-bin_1.2-3_amd64.deb and two
binary builds of foo-data_1.2-3_all.deb with the same version number but
potentially different content, breaking the important design principle
that things that are different should have different names.
In the Open Build Service (OBS), which is analogous to wanna-build + sbuild,
the normal configuration is that binaries built by OBS *always* get a
build suffix. For example, if I upload foo_1.2-3 to the OBS instance used
by SteamOS, the result will usually be foo-bin_1.2-3+bsos1_amd64.deb and
foo-data_1.2-3+bsos1_all.deb, because SteamOS' OBS was configured to use
suffix +bsos (where bsos is mnemonic for "built for SteamOS"
and is an automatically incremented integer).
At the moment, builds in OBS cannot make use of Debian's binNMU machinery
for this, because if they did, they would break the same ${source:Version}
assumption I described in my previous message. The result is that they
have to behave as though +bsos1 was a new sourceful upload, and
foo-bin_1.2-3+bsos1_amd64.deb and foo-data_1.2-3+bsos1_all.deb both have
Source: foo (= 1.2-3+bsos1). Consumers have to "just know" that to
get the source code for foo-bin_1.2-3+bsos1_amd64.deb, you strip the
/\+bsos[0-9]+$/ suffix from the version number before looking for the
foo=1.2-3 source package. Obviously, this scales poorly if you are looking
at multiple derivatives each with its own pseudo-binNMU suffix.
If we had a way to do Architecture: all binNMUs, then OBS would be able to
use it for all builds: for instance, foo-bin_1.2-3+bsos1_amd64.deb and
foo-data_1.2-3+bsos1_all.deb could both have Source: foo (= 1.2-3).
Similarly, we could consider using it in Debian to address the ftp
team's valid concern about having buildd-built binaries whose version
matches different maintainer-built binaries. Instead of starting from
the absence of a binNMU suffix, the buildds could start from +b1, so
that we'd have this workflow:
- maintainer builds, tests and uploads foo_1.2-3
- maintainer's packages are foo_1.2-3.dsc, foo-bin_1.2-3_amd64.deb and
foo-data_1.2-3_all.deb
- or perhaps they would be foo_1.2-3.dsc, foo-bin_1.2-3+b0_amd64.deb and
foo-data_1.2-3+b0_all.deb
- (if NEW) ftp team inspects maintainer-built source and binaries
- ftp machinery discards maintainer-built binaries
- buildd receives foo_1.2-3.dsc
- buildds produce foo-bin_1.2-3+b1_ARCH.deb for each architecture
- Architecture: all buildd produces foo-data_1.2-3+b1_all.deb
and if, later, the release team triggers some binNMUs for a transition:
- buildds produce foo-bin_1.2-3+bN_ARCH.deb, N >= 2, for each architecture
and/or
- Architecture: all buildd produces foo-data_1.2-3+bN_all.deb, N >= 2
smcv
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> Possible solutions:
>
> - Change at least 622 packages so they have something more like
> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
> (also hope that all of their maintainers can get those runes right, taking
> into account what the binNMU suffix is, and hope that it won't break
> derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
> compares less than +b1)
>
> - Change at least 622 packages so that when foo-data is binNMU'd, it
> automatically gets Provides: foo-data (= 1.2-3)
>
> - Change some more central component so that the dependencies are edited
> or the Provides is added globally
>
> - Something clever that I haven't thought of
>
Make no-change-other-than-version-bump source uploads easier?
Cheers,
Julien
Re: Architecture: all binNMUs (was: deduplicating jquery/)
Le 01/12/2020 à 12:19, Jonas Smedegaard a écrit :
> Quoting Simon McVittie (2020-12-01 11:56:28)
>> On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
>>> Can someone remind me: Why is it that we cannot do arch-independent
>>> auto-building?
>>
>> We can and do autobuild arch-independent packages (since 2015: on the
>> timescale of multi-release transitions, this is relatively recent).
>
> Yes - thanks for catching and tightening my far too sloppy framing of
> the issue at hand.
>
>
>> However, we cannot currently do arch-independent *binNMUs*, because a
>> large number of packages have patterns like this:
>>
>> Source: foo
>>
>> Package: foo-bin
>> Architecture: any
>> Depends: foo-data (= ${source:Version})
>>
>> Package: foo-data
>> Architecture: all
>>
>> which is based on the assumption that foo-data cannot be binNMU'd.
>>
>> For example, consider foo_1.2-3, and suppose it has been binNMU'd 5
>> times on amd64, so we have foo-bin_1.2-3+b5_amd64.deb and
>> foo-data_1.2-3_all.deb. foo-bin Depends: foo-data (= 1.2-3) and the
>> dependency is satisfied.
>>
>> Now suppose we also binNMU foo-data. We get foo-data_1.2-3+b1_all.deb,
>> which no longer satisfies foo-data (= 1.2-3), so foo-bin is uninstallable.
>>
>> https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html lists
>> 622 affected packages. I don't know whether there are other problematic
>> patterns that Lintian does not detect.
>
> Thanks for the excellent explanation.
>
> (and sorry for my failing memory: I am sure someone explained it to me
> at least once before, related to debian-installer image building)
>
>
>> Possible solutions:
>>
>> - Change at least 622 packages so they have something more like
>> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
>> (also hope that all of their maintainers can get those runes right, taking
>> into account what the binNMU suffix is, and hope that it won't break
>> derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
>> compares less than +b1)
>>
>> - Change at least 622 packages so that when foo-data is binNMU'd, it
>> automatically gets Provides: foo-data (= 1.2-3)
>>
>> - Change some more central component so that the dependencies are edited
>> or the Provides is added globally
>>
>> - Something clever that I haven't thought of
>
> - Introduce a control field "Build-Dependencies-Require-Rebuild: no"
> (similar to "Rules-Requires-Root: no")
+1 !
Thanks!
Re: Debconf - adding "treeselect" type(s)?
On 11/29/20 11:37 PM, Timo Weingärtner wrote: > What are the proposed semantics of this multitreeselect? > > If we imagine something like: > > [ ] a > [ ] a/b > [ ] a/c > [ ] b > [ ] b/a > > Would checking "a" automatically also check "a/*"? > Is it only about UI, meaning "a/*" would be collapsed under "a"? > Shall it be possible to check "a", but uncheck "a/b"? > > Grüße > Timo I very much agree that this needs to be discussed, then specified correctly. Also, would that sound crazy if we were to introduce the tree as described with json? That's simple enough, so that even a human can do it by hand, and also understood by all languages. Otherwise, what would be the way to describe a tree? Cheers, Thomas Goirand (zigo)
Re: Debconf - adding "treeselect" type(s)?
On 11/30/20 11:18 AM, Steve McIntyre wrote: > I'm envisaging treating the Choices *mostly* like in an existing > select/multiselect, but with extra decoration to indicate the position > in the tree for display. It would then be up to the frontend to decode > that and work out a sensible way to display things as best it can. Not > sure on the best way to do the decoration, hoping there'll be an > available special character or similar that we could use in strings to > avoid too big an upheaval here. 囧 [1] >> Although these require manual selection, I think they do have at least >> some use, and I'd rather keep them going. It shouldn't be too hard to >> get full coverage, pulling in help from specialists if necessary. > > I guess so. How would it be pre-seeded? Just like a multiselect? With only leafs that could potentially be in the pre-seed? Cheers, Thomas Goirand (zigo) [1] https://www.urbandictionary.com/define.php?term=%E5%9B%A7
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 1, 2020 at 11:36 AM Julien Cristau wrote: > Make no-change-other-than-version-bump source uploads easier? `dch --rebuild` already exists, so this would just need support in wanna-build/sbuild for generating such uploads and support in dak for accepting sourceful uploads from wanna-build/buildds rather than maintainers. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 01, 2020 at 12:28:38PM +0100, Julien Cristau wrote:
> On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> > Possible solutions:
> >
> > - Change at least 622 packages so they have something more like
> > Depends: foo-data (>= ${source:Version}), foo-data (<<
> > ${source:Version}+c)
> > - Change at least 622 packages so that when foo-data is binNMU'd, it
> > automatically gets Provides: foo-data (= 1.2-3)
> > - Change some more central component so that the dependencies are edited
> > or the Provides is added globally
> Make no-change-other-than-version-bump source uploads easier?
+1000.
For anyone who uses rebuilt packages outside of official Tier-1
infrastructure, binNMUs are nasty.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Videoconference tomorrow, Wednesday 2020-12-02 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))
Hi, several European countries are back to lockdown again. May be this might give some more people a motivation to join our effort. The video conferences of the Debian Med team are an established means to continue the COVID-19 hackathon in April[1] and we do it twice per month on every 2th and 17th of a month. So the next meeting is tomorrow 18:00 UTC For those who would like to join our next videomeeting it will happen at Friday https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20201202T19&p1=37&ah=1 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon[1]. The topic is what contributors have done in the past week and to coordinate the work for next week. Here are the reports of some past meetings: https://wiki.debian.org/DebianMed/Meeting/WeeklyCovid19 May be this meeting can be used to coordinate our December bug squashing party[2]. Finally I'd like to repeat myself: Newcomers are always welcome. I will not be able to join the meeting tomorrow but I wish all attendees a good conversation Andreas. [1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html [2] https://lists.debian.org/debian-med/2020/11/msg00334.html -- http://fam-tille.de
check all the things?
Hello I was curious about https://qa.debian.org/daca/ (and sorry if -devel was wrong, and I should I have used -qa instead), so I've made myself a copy of Debian sid source packages, and run it against: - graudit (listed from the daca page, but I haven't found the output very useful) - flawfinder - codespell (I'll probably run some more statistics on all the source files and put them at that place). Maybe it comes handy, or interesting for someone else. The results are here: http://sid.ethz.ch/debian/report/ (directory listings might be slow, so feel free to pick the corresponding tar.xz from the same directory and unpack it locally for consumption). I'm aware the do* and whatever scripts are online there might be highly slow/inefficient, I might create a gnu parallel version of them if one or another run makes sense to be run periodically. Best,
Bug#976232: ITP: ustreamer -- Lightweight and fast MJPG-HTTP streamer
Package: wnpp Severity: wishlist Owner: Sam Reed * Package name: ustreamer Version : 2.2 Upstream Author : Maxim Devaev * URL : https://pikvm.org/ * License : GPL-3 Programming Lang: C Description : Lightweight and fast MJPG-HTTP streamer µStreamer is a lightweight and very quick server to stream MJPG videofrom any V4L2 device to the network. All new browsers have native support of this video format, as well as most video players such as mplayer, VLC etc. µStreamer is a part of the Pi-KVM project designed to stream VGA and HDMI screencast hardware data with the highest resolution and FPS possible. ustreamer is used as part of Pi-KVM (a Raspberry Pi based IP KVM), to stream video to a web browser. It is intended to get this packaged so it will eventually be available in Raspberry Pi OS (and other Debian derivatives), allowing Pi-KVM to be used on those OS rather than using Arch. I currently use it as part of the Pi-KVM project, and hopefully when it is packaged, also use it as part of OctoPrint and the OctoPi OS (version of Raspberry Pi OS). MJPG-Streamer is alternative software providing the same function, however it is currently not packaged for Debian either, though it is available in a snap. I'm happy to work on packaging/maintaining it in future, and I believe the upstream Author (Maxim) may be interested too, but is currently busy with other work, hence me packaging it.
Bug#976237: ITP: golang-github-containers-dnsname -- name resolution for containers
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: dnsname Version : 1.1.1-1 Upstream Author : Containers * URL : https://github.com/containers/dnsname * License : Apache-2.0 Programming Lang: Go Description : name resolution for containers dnsname pluginOverview This plugin sets up the use of dnsmasq on a given CNI network so that Pods can resolve each other by name. When configured, the pod and its IP address are added to a network specific hosts file that dnsmasq reads in. Similarly, when a pod is removed from the network, it will remove the entry from the hosts file. Each CNI network will have its own dnsmasq instance. . The dnsname plugin was specifically designed for the Podman (https://github.com/containers/podman) container engine. Podman 2.2 uses this for resolving names to containers in other networks
Bug#976243: ITP: deepin-log-viewer -- System log viewer of Deepin Desktop Environment
Package:wnpp Severity: wishlist Owner: Tu Qinggang X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : deepin-album Version : 5.8.0.13.1 Upstream Author : Deepin Technology Co, Ltd. * URL : https://github.com/linuxdeepin/deepin-log-viewer License : GPL-3.0 Programming Lang: C++ Description : System log viewer of Deepin Desktop Environment deepin-log-viewer is a fast and lightweight application for viewing system log Log viewer provides a graphical interface for viewing system logs It is part of Deepin software and DDE (Deepin Desktop Environment) I intend to co-maintain this package inside the pkg-deepin group.
Re: [External] Re: Lenovo discount portal update (and a few other things)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2020-11-04 at 13:45 -0500, Mark Pearson wrote: > I've started chasing this directly myself, but last week was crazy busy. > I have the owner of a number of S and Central America countries looking > into it - I need to go chase some others. > Sorry - really slow going :( Hi Mark, I hope a monthly ping is ok for you. Did you have a chance to talk to EU geos people? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl/HQ7AACgkQ3rYcyPpX RFvvFAgA0TUoJRfJ7v+KlhCSOtXB0Kzp0b1Yr+dmEngejNjBR2wOF9ttEbAeAVpI 5nEYDKSs6KgoqABUNG8+CIxkSnH3o1O9lwApLJ5xTqUakso9JAQpW9Z3eMSeB9Hf K3kSSui+SJM3SAxEzFQS7vHPNKpa1ckbgi9u+xDO3C3ObOOiXFkapsYJdUtI4f6i wrBikX9GzMOskG/E5OSdI3fcUFih5/E5km74/lA8pLYtIJDXWVqsDqKFyHh8VCI3 DHPsFWfmbiELbqasFyhLdWA7F/g56tmdM/tqzWHDgOFQHkj+NVeQ/N1iFIf/Xgsr xXAdwRoPZjQ8cqqBHJJfVxlYms7VRw== =eT6s -END PGP SIGNATURE-
