Hi,
two packages[¹, ²] I uploaded are "Rejected due to piuparts
regression". I learned, that this is due to a bug in piuparts.
Any solution on its way? Would I need to re-upload later?
TIA & Cheers
PS: Many thanks for running piuparts anyway. Such bugs happen,
but the extra safety net it provide
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: python-dbussy
Version : 1.1
Upstream Author : Lawrence D'Oliveiro
* URL : https://github.com/ldo/dbussy
* License : LGPL-2.1+
Programming Lang: Python
Description
Quoting Sean Whitton :
Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
(easier) `dgit push-source`.
I prefer to build only once, if possible, generating both binary and
source .changes. Both in a clean chroot. Then I can try out my .debs
and on success just sign and dput.
Quoting Bagas Sanjaya :
Such ads is displayed only when users have Internet connection, and
there is no way to patch ZZZ in order to remove ads (or we have to
buy "pro" version which doesn't contain ads and adds more features).
So it's not free software anyway and does not belong to Debian m
Quoting Jonathan Carter :
It seems clear-cut enough that it doesn't really need advice from
debian-legal. If it's free software then a maintainer is free to patch
out any behaviour of the app that's intrusive or otherwise undesirable.
If the license of the software doesn't allow that, then it's h
Quoting Bagas Sanjaya :
Suppose that an upstream has released a program which its license
conforms to DFSG (named ZZZ), but when I test it, ads placed by the
upstream appear (such as pop up ads). Since ads can affect user
experience of ZZZ, but at the same time the upstream get paid by ad
Quoting Sam Hartman :
I've certainly heard people describe our use of both ar and tar as an
architectural minus especially on embedded platforms just because the
dependency set of dpkg needed to be larger.
On my embedded systems, I don't have ar installed, only tar.
I assume, that dpkg speaks a
On 2019-04-22 09:55, Dmitry Bogatov wrote:
> Alioth did not get in my way.
Salsa does not get into my way neither. I barely use the web
frontend, I do not use the issue tracker at all, nor merge
requests. Works fine for me!
Quoting Mo Zhou :
Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...
Then I would try to diverge as little as possible
from the classical way how Debian packaging works.
On 2019-03-22 00:26, w...@debian.org wrote:
>bootp (#924999), orphaned 2 days ago
> Description: serveur pour le protocole bootp avec gestion de DHCP
...
>bsd-finger (#925001), orphaned 2 days ago
> Description: Programme de recherche de renseignements sur les
>utilisateur
On 2019-02-21 22:15, Jonas Smedegaard wrote:
> Depending on the kinds of tests you need, there is also the option of
> telling ffmpeg to generate some data for you. Saves space :-)
I will look into that!
Hi,
upstream confirms that the files are mainly non-free.
For my purpose, I will just search free replacements.
Thanks & Cheers
On 2019-02-19 23:41, Holger Levsen wrote:
> On Wed, Feb 20, 2019 at 12:06:30AM +0100, Chris Lamb wrote:
> > Noted, but it is not the size that is the concern, but rather the
> > licensing.
>
> once those (licencing concerns) are resolved, I wonder whether it makes
> sense to provide a fate-testdata
On 2019-02-20 06:19, Adam Borowski wrote:
> On Tue, Feb 19, 2019 at 11:52:49PM +0100, W. Martin Borgert wrote:
> > In my case, it's only 3.3 MiB. And it is only in the source package
> > anyway.
>
> So you can just ship it then.
After clarifying the license(s).
On 2019-02-20 00:06, Chris Lamb wrote:
> Noted, but it is not the size that is the concern, but rather the
> licensing.
Sure! If this cannot be clarified, I'll try to either find
similar files with a suitable licsense, or even produce them
myself. Like with the "(Ma)Lena, the cat" photo :-)
On 2019-02-19 22:55, Chris Lamb wrote:
> Dumb question: have you tried consulting upstream?
Not yet. If this question has been clarified inside Debian
before, I'm reluctant pestering upstream again. I know, that
some upstreams get shirty about our insistence on such matters.
But if not, I'll conta
Hi,
a package I'm working on makes use of eight files from the FATE
project for unit testing. The files are multimedia files (image,
audio, video, subtitles). By default it downloads files during
build, but it's easy to just provide them locally. So far, I
could not find any FATE files in Debian.
Hi Simon,
many thanks for taking the time to go through this bug report!
Very much appreciated!
On 2019-02-16 17:02, Simon McVittie wrote:
> Multiarch-qualified directories under /usr/share don't seem like they make
> much sense: the whole point of the $libdir/$datadir duality is that if
> files
Hi,
at the moment, .gir files are placed under /usr/share/gir-1.0/.
However, such files can contain architecture specific content.
What would be the right directory? /usr/share/gir-1.0//?
TIA & Cheers
PS: This is related to #905715
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: social-examples
Version : n/a
Upstream Author : Matías Aguirre
* URL : https://github.com/python-social-auth/social-examples
* License : BSD-3
Programming Lang: Python
D
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: social-app-webpy
Version : 1.0.0
Upstream Author : Matías Aguirre
* URL : https://pypi.python.org/pypi/social-auth-app-django
* License : BSD-3
Programming Lang: Python
D
On 2019-02-09 13:10, Philipp Kern wrote:
> How do others deal with this problem?
In my company, we use leading underscore for all non-human
accounts. Human accounts get lower-case ASCII letters only.
Also, we use the same uid/gid for the same human user on all
machines (1000 + something unique, e
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-pylibsrtp
Version : 0.6.1
Upstream Author : Jeremy Lainé
URL : https://pypi.org/project/pylibsrtp/
License : BSD-3
Programming Lang: Python
Description : Python wrap
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-aioice
Version : 0.6.14
Upstream Author : Jeremy Lainé
URL : https://pypi.org/project/aioice/
License : BSD-3
Programming Lang: Python
Description : library for I
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: python-av
Version : 6.1.2
Upstream Author : Mike Boers
URL : https://pypi.org/project/av/
License : BSD-3
Programming Lang: Python
Description : Pythonic binding for
Quoting Adam Borowski :
The en_US.UTF-8 locale has two purposes:
And I always wondered why other locales than en_DK.UTF-8 even exist!
• promoting C.UTF-8 in our user interfaces (allowing to select it in d-i,
making dpkg-reconfigure locales DTRT, making it the d-i default)
-- nice for Unix
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: omemo-backend-signal
Version : 0.2.2
Upstream Author : Tim Henkes
* URL : https://pypi.org/project/omemo-backend-signal/
* License : GPL-3
Programming Lang: Python
D
Quoting Michael Stone :
Unless the cpu supports rdrand/rdseed, installing rng-tools5 won't
really change anything. If it does support those, it probably makes
more sense going forward to just enable CONFIG_RANDOM_TRUST_CPU
rather than installing another package.
This option is only availab
On 2018-12-26 15:05, gregor herrmann wrote:
> (Can we keep this on one mailing list, please? /me restricts this to
> -devel)
Agreed.
> And besides that, I think the more universal answer is
> bikesheds/PPAs/you-name-it instead of yet-another-suite.
IMHO, this is not the same. Both "volatile/fast
Hi all,
I like the idea of having a volatile archive and I agree with
almost all what Dominik wrote about the motivation.
I would, however, completely separate it from backports. I.e.
- separate NEW queue
- different suffix
- no need to keep a volatile package out of testing
Why?
- volatil
Quoting Ben Hutchings :
Many of the rules in Debian policy are there to support a minority of
users, but we try to follow them anyway.
Hear, hear! I was about to write the same thing.
I personally don't care about usrmerge, but if it is useful to a
relevant minority, we should not reject it.
Quoting John Paul Adrian Glaubitz :
Granted, I don’t really know what the real world distribution of
embedded and desktop/server/laptop devices of arm64 is. But I could
imagine that there will be more arm64 devices in the future which
are desktops, servers or laptops.
There is e.g. this p
Quoting Holger Levsen :
On Thu, Nov 22, 2018 at 10:11:24PM +0100, W. Martin Borgert wrote:
Reminds me of the long /usr/doc -> /usr/share/doc transition in potato
times. And we did not even have dh in those days. Sounds good to me!
ITYM s#potato#slink, potato, woody, sarge, etch and le
Quoting Ansgar Burchardt :
This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without). Less static files would
be on a read-write root file system (if /usr is a sep
Quoting Sean Whitton :
On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote:
On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote:
Before we get there, we should first start autoremoving packages from
unstable, if we consider rc-buggy in unstable to be unacceptable. We
do have
On 2018-11-19 23:40, Bernhard Schmidt wrote:
> Asterisk maintainers have first offerered, then recommended working
> around this issue by shipping a private copy
I suggest to go that way. I really do not like embedded code
copies, but this situation is a perfect excuse for allowing one.
Debian fro
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: gajim-openpgp
Version : 1.1.1
Upstream Author : Philipp Hörist
* URL :
https://dev.gajim.org/gajim/gajim-plugins/blob/gajim_1.1/openpgp/manifest.ini
* License : GPL3
P
On 2018-11-06 11:08, Holger Levsen wrote:
> > I also bootstrapped the Rust compiler and helped fixing issues on armel,
> > mips, mipsel, mips64el. Those are "strange" ports for you? Ok.
>
> no (except armel..)
I'm running Debian armel on, I don't know, 1000 or 2000 devices.
(Not myself, customers
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: pyserial-asyncio
Version : 0.4
Upstream Author : Chris Liechti (zsquareplusc), Robert Smallshire
(rob-smallshire)
* URL : https://github.com/pyserial/pyserial-asyncio/
* License
On 2018-10-04 21:10, Simon Richter wrote:
> We could bring the same to dpkg by moving things out of maintainer scripts
> and into control files. The big items would be
>
> - alternatives
> - diversions
> - statoverride
> - service start/stop
I agree and like to add:
- create system users/gro
On 2018-10-03 23:30, Antoine Beaupré wrote:
> There
> are somewhat low-hanging fruits in there like declarative maintainer
> scripts.
I am very much in favour of declarative maintainer scripts!
AFAIK, Niels Thykier has done a lot of work there, while Ralf
Treinen and colleagues are analysing maint
On 2018-10-04 09:06, Jonathan Dowland wrote:
> What about running Chromium as root? Certainly not recommended, but what
> are the user's expectations if they try it anyway?
With nowadays web, I would disallow this by default. If root
types their sentence ("Yes, I know..."), they can shoot themself
On 2018-09-24 09:38, Russ Allbery wrote:
> Ideally, we would never reuse the name of a binary package for some
> unrelated piece of software,
Nor source package. Why not "elisa-music-player" or whatever?
Quoting Aurélien COUDERC :
I’m working on packaging Elisa, a modern and simple music player based
on the KDE Frameworks stack. [0][1]
I initially named the package elisa, but such a package already
existed in the
archive in the past.
In a similar case, I just renamed the package. There used
Quoting Ben Hutchings :
- Would it make sense to split the changelog, leaving older entries
only in the source package?
As long as the full d/ch is in the source package, I'm fine.
On one of my embedded machines changelogs are 2/3 of /usr/share/doc.
E.g. multiple copies of the same changelog f
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: python-omemo
Version : v0.7.0-alpha
Upstream Author : Tim Henkes
* URL : https://github.com/Syndace/python-omemo
* License : GPL-3
Programming Lang: Python
D
Dear Andreas,
Quoting Andreas Jakowidis :
Because of a long experience in developing Debian-Software since the year
1995 it would be
important/necessary for everyone if you could offer Debian also as a mobile
solution
for smartphone hardware in near future.
Debian has a long history on mobile
On 2018-08-09 19:27, Holger Wansing wrote:
> I am unable to clearsign a file with gpg, always getting
> permission denied errors.
Maybe https://bugs.debian.org/836772 or similar?
On 2018-08-04 14:49, Martin Dosch wrote:
> How should I continue? Zip the folder and send to a member of the go-team?
The best thing is probably to make yourself a guest account at
https://salsa.debian.org/ and host your packaging repository
there. Both the Go team (https://salsa.debian.org/go-tea
On 2018-06-05 23:15, Simon McVittie wrote:
> NetworkManager supports PPPOE (e.g. ADSL), and cellular modems (3G, etc.)
> via ModemManager. It doesn't support the analogue dial-up modems that
> were popular 10-20 years ago. I don't think the major NM alternatives
> (wicd, ConnMan etc.) support those
Quoting Pierre-Elliott Bécue :
I've always found otherwise, ie that packaged stuff makes the administrator
of a service spare a lot of time.
Same here, but it's a matter of taste and requirement diversity.
I wonder then, if a lot of people prefer deploy a service from upstream's
git repo/cook
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: scrapbookq
Version : 0.1.8.0 (2018-01-23)
Upstream Author : Joey Liu
* URL : https://github.com/tahama/scrapbookq
* License : MIT/X11 (see below)
Programming Lang:
On 2018-05-04 21:04, Holger Levsen wrote:
> because this is what the modern web has become in 2018. go gopher go!
Modern web? I don't use Mosaic anymore! :~)
On 2018-05-04 23:22, Moritz Mühlenhoff wrote:
> W. Martin Borgert schrieb:
> > If a software is not in Debian, I just don't use it.
>
> Your call. Don't use the extensions, then.
Alternatively: Do what is possible for me, to keep the software
I like to use in Debian. (
On 2018-05-04 21:12, Moritz Mühlenhoff wrote:
> Same as all previous extension breakages incurred by ESR transitions;
> not at all. Apart from enigmail those are all not updated along
> in stable, this doesn't scale at all. If you want your extensions
> to be kept compatible, get them from the Mozi
Quoting Moritz Mühlenhoff :
Julien Cristau schrieb:
I expect nothing much different from previous ESR cycles: stretch will
move to 60 after 52 goes EOL in September.
Exactly.
How will we deal with breaking extensions?
E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does
not provide
On 2018-04-11 07:41, Paul Wise wrote:
> Is anyone interested in facilitating a privacy-team BoF at DebConf18?
Yes. Would you schedule/organise it? I'm pretty sure, that many
people will join, who are not participating in this thread.
Quoting "Santiago R.R." :
Instead of a new team… I wonder if the pkg-privacy-team could be
interested in addressing this task/idea.
I understand Pauls idea that this would be very different things:
pkg-privacy-team: packages tools and programs related to privacy,
e.g. things around tor etc.
p
Quoting Paul Wise :
I think we need a privacy team. Such a team could verify the privacy
status of packages and record that information centrally.
I agree. And volunteer.
(Messages with the word "volunteer" in the body are never signed.)
Quoting Holger Levsen :
On Mon, Apr 09, 2018 at 03:34:42PM +0200, W. Martin Borgert wrote:
We have apparmor (maybe even by default!) to prevent network accesss
of a music application, which is perfect for Adam, you and me, but it
must also be easy to allow e.g. fetching of lyrics for those
Quoting Holger Levsen :
the solution to that is to confine each and every application by default
and forbid network access. the gnome calculator on every startup fetches
currency exchange information because you might use it to calculate
that. pretty useful. not.
Problem: As Marco pointed out,
On 2018-04-08 23:47, Adam Borowski wrote:
> why do music players shipped in
> Debian default to grabbing lyrics, "LastFM stats", tags, and what not, even
> when playing local media?
IMHO, they should not do that by default. Opt-in is OK.
I'm using quodlibet for listening to music and believe (= ho
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: opcua-widgets
Version : 0.5.0
Upstream Author : Olivier Roulet-Dubonnet
* URL : https://github.com/FreeOpcUa/opcua-widgets
* License : GPL3
Programming Lang: Python
D
Quoting Chris Lamb :
In many cases, there is an issue open about the new binary package
(In my experience, there is not.)
When there is no bug report open at all, well, bad luck.
Well, possbibly, but if one is investing time and effort in changing a
process it seems a shame not to cover the
Quoting Chris Lamb :
Do you have any concrete suggestions for packages that are "Just
Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a
SONAME bump, first upload to experimental, etc. etc.? They do not
have ITP bugs.
In many cases, there is an issue open about the new binary pac
On 2018-03-03 10:22, Chris Lamb wrote:
> This is, of course, not very obvious or initiutive and improved
> transparency on this would obviously be a beneficial to all parties,
> let alone Debian at large.
Indeed. Sometimes I see interesting packages in NEW, but don't
know why they don't pass. A pu
On 2018-02-23 08:41, Daniel Kahn Gillmor wrote:
> On Fri 2018-02-23 14:24:44 +0100, W. Martin Borgert wrote:
> > The link is wrong. The correct one does not ask you for an ¶assword:
> > https://salsa.debian.org/debian/impass
>
> thanks for the correction, i wrote the ITP too
Quoting Adrien CLERC :
* URL : https://salsa.debian.org/impass
Is it normal that this URL requires a login? I guess not, but anyway,
this is not as open-source as it should be ;)
The link is wrong. The correct one does not ask you for an ¶assword:
https://salsa.debian.org/debian/im
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: sat-templates
Version : 0.7D
Upstream Author : Goffi
* URL : https://salut-a-toi.org/
* License : AGPL3+
Programming Lang: Python
Description : collection of tem
On 2018-02-17 13:57, Michael Meskes wrote:
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readab
On 2018-02-16 20:41, Michael Meskes wrote:
> On Fri, Feb 16, 2018 at 08:21:19PM +0100, W. Martin Borgert wrote:
> > But it's probably too much work, preparing infrastructure etc.
>
> Why?
Depends how it would be done. Nixos style would probably very
difficult for Debian. P
On 2018-02-16 11:51, Sean Whitton wrote:
> We cannot feasibly provide security updates when there is more than one
> version of the library in the archive. We do not, and probably never
> will have, the required manpower.
>
> This applies to the nixos/guix solutions too -- we cannot expect our
> s
Quoting Holger Levsen :
I very much disagree that Debian is loosing relevance, like many software
projects Debian usage is still growing. and other projects grow as well.
I agree.
you can use their package managers, and thus these features, on Debian
today. there's also docker containers and
Quoting Samuel Thibault :
What kind of relaxation could we introduce without damaging freeness?
And damaging quality. If a program uses some JS libraries without
any sources easily available, I cannot really promote this software.
Neither in Debian nor outside. This is just bad practice.
Or w
Quoting Pavlo Solntsev :
Now, I want to submit patches to packages, e.g.
libgdamm. What would be the best process: submit a patch via push request
in the Debian repo, or push patches to upstream?
If it is (probably) a Debian bug, submit bug (and patch) to the
Debian BTS. Ideally, using the "rep
Quoting Holger Levsen :
Same here. IMO warnings about the last two policy versions should only be
shown in pedantic mode. If a package is 3 versions behind, then this
should be a normal lintian warning.
Maybe warn about new minor number, but not micro number?
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: gajim-appindicatorintegration
Version : 1.0.1
Upstream Author : Denis Borenko , Philipp Hörist
* URL :
https://dev.gajim.org/gajim/gajim-plugins/wikis/AppindicatorSupportPlugin
On 2017-12-30 13:02, Alex Mestiashvili wrote:
> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
Unfortunately, on some embedded and/or mobile systems, one h
On 2017-12-29 12:42, Paul Wise wrote:
> This is just a symptom of a Debian design flaw that dates back to
> before we started using VCSen for packaging. We include information in
> the source package that can change independently of the source package
> (such as Vcs-*, Homepage, debian/watch, Maint
On 2017-12-26 14:48, Mattia Rizzolo wrote:
> That's now fixed, and you can use $pack...@packages.debian.org in the
> Maintainer field.
Does $package need to be equal to the source or binary package name?
In case of packaging plugins or additional programs to some kind of
"main" program, that are
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: gajim-plugininstaller
Version : 0.20.0
Upstream Author : Gajim authors
* URL :
https://dev.gajim.org/gajim/gajim-plugins/wikis/PluginInstallerPlugin
* License : GPL3
P
tags 850803 + help
thanks
Hi, as I'm not an KDE user and the bug submitter is unreachable:
Can somebody check this bug with gajim 1.0.0~alpha2-1? TIA!
Please comment directly on the bug...
Quoting Ben Finney :
If I understand correctly, the justification of putting a file there
must include that it is overwhelmingly more likely to save *storage
space* overall (by reducing the space in a corresponding number of
‘/usr/share/doc/…/copyright’ files), especially on machines that have
lo
Quoting Markus Koschany :
Why don't we add all DFSG-free licenses to /usr/share/common-licenses or
/usr/share/free-licenses instead? It would save a lot of developer and
maintenance time
...
IMHO using links and
references is just common sense and reduces unnecessary make work.
+1 with "all D
On 2017-12-05 10:33, Jonas Meurer wrote:
> 2. Apart from that, we should improve support and documentation for
>loading non-free firmware from an external medium in the free
>installer.
The combination of the free installer plus nonfree firmware on a
USB memory is not so bad. The problem i
Quoting Andrey Rahmatullin :
On Fri, Dec 01, 2017 at 05:10:37PM +0100, W. Martin Borgert wrote:
> Currently the stable amd64 netinst is linked from the front page (top
> right corner).
It is, indeed. Never saw it before...
It's a relatively recent improvement.
Well, I had
Quoting Andrey Rahmatullin :
Currently the stable amd64 netinst is linked from the front page (top
right corner).
It is, indeed. Never saw it before...
Of course, the stable amd64 netinst is useful only for VMs.
Why?
Quoting Paul Wise :
It would have been best for him to download the ISO with non-free
firmware embedded, do you know how he made the decision to download
the ISO without non-free firmware?
Every time I need a Debian ISO, it takes me minutes to find it.
I didn't even know, that there were an ISO
On 2017-11-28 20:22, Russ Allbery wrote:
> My personal pet "I don't have time" project I'd love to see is extending
> systemd units for as many services in Debian as possible to include
> namespace restrictions and seccomp filter rules,
Hear, hear!
Quoting Ghislain Vaillant :
s/python3-precis-i18n/python-precis-i18n
Unless this source package is Python 3 specific, please consider
renaming the source package to python-precis-i18n, or just
precis-i18n. The "python3-" prefix is for binary packages built for
the Python 3 interpreter. Unless
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: python3-precis-i18n
Version : 0.7.0
Upstream Author : William W. Fisher
* URL : https://pypi.python.org/pypi/precis-i18n
* License : MIT
Programming Lang: Python
D
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: ausweisapp2
Version : 1.12.4
Upstream Author : Governikus GmbH & Co. KG
* URL : https://github.com/Governikus/AusweisApp2
* License : EUPL-1.2
Programming Lang: C++
Quoting "W. Martin Borgert" :
There is still relevant hardware
around which can run "armel", but not "armhf".
Forgot to mention some, that one can still buy:
On https://www.taskit.de/stamp-overview.html the three boards
named "9261", "9G20",
On 2017-11-07 11:08, Julien Cristau wrote:
> Keeping armel on life support for 2 more
> years is a significant drain on DSA and our hosters, for questionable
> benefit.
I agree, that this support comes not for free, but the benefit
is not questionable to me: There is still relevant hardware
around
Hi Drew,
many thanks for your ITP!
Note, that xhtml2pdf is known also as "pisa" - nobody so far could
explain to me, why there is this upstream name confusion.
And pisa is in Debian: https://tracker.debian.org/pkg/pisa
Unfortunately, pisa is not in a good state. It is not in testing,
and did ne
On 2017-10-20 16:59, W. Martin Borgert wrote:
> I would package the new dino under this name, because I don't think
> there is a conflict.
OK, I will better not reuse the name, but go for dino-im (= dino
instant messenger), which fits with its domain name dino.im.
Thanks for all your input!
Hi,
just to be sure, that this is not a problem:
There used to be a package "dino" in Debian until jessie. Upstream
development dried up years ago and dino became extinct.
Recently, a new "dino" appeared on the surface of earth, which is a
completely different program. Like git vs git or node
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: gajim-pgp
Version : 1.2.0
Upstream Author : Philipp Hörist
* URL : https://dev.gajim.org/gajim/gajim-plugins/wikis/pgpplugin
* License : GPL3
Programming Lang: Python
D
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
* Package name: python-test-server
Version : v0.0.27
Upstream Author : Gregory Petukhov
* URL : https://github.com/lorien/test_server
* License : MIT
Programming Lang: Python
D
Package: wnpp
Severity: wishlist
Owner: Python Applications Packaging Team
* Package name: pylci
Version : 2017-03-10
Upstream Author : Pičugins Arsenijs
* URL : https://github.com/CRImier/pyLCI
* License : Apache 2.0
Programming Lang: Python
Description
1 - 100 of 160 matches
Mail list logo
