unittest from Python standard
> library [6]. There is a script called nose2pytest [7] which can
> assist with migrating from nose to pytest.
xraylarch (U)
Fixed in git.
--
Neil Williams
=
https://linux.codehelp.co.uk/
pgpnnISiYOXxe.pgp
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: pyimagetool
Version : 1.0
Upstream Author : Kyle Gordon
* URL : https://github.com/kgord831/PyImageTool
* License : GPL3
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: xrt
Version : 1.4.0-1
Upstream Author : Konstantin Klementiev
* URL : https://github.com/kklmn/xrt
* License : Expat
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: looktxt
Version : 1.5-1
Upstream Author : Emmanuel Farhi
* URL : https://github.com/farhi/looktxt
* License : GPL-2
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: epicsapps
Version : 0.9.2
Upstream Author : Matthew Newville
* URL : https://github.com/pyepics/epicsapps
* License : EPICS
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: wxutils
Version : 0.2.4
Upstream Author : Matthew Newville
* URL : https://github.com/newville/wxutils
* License : Expat
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: wxmplot
Version : 0.9.46
Upstream Author : Matthew Newville
* URL : https://github.com/newville/wxmplot
* License : Expat
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: python-model-bakery
Version : 1.4.0
Upstream Author : berinfontes
* URL : https://github.com/model-bakers/model_bakery
* License
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: xraydb
Version : 4.4.7
Upstream Author : Matthew Newville
* URL : https://github.com/xraypy/XrayDB
* License : Public domain
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: pyobjcryst
Version : 2.2.1-1
Upstream Author : Prof. Simon Billinge
* URL : https://github.com/diffpy/pyobjcryst
* License
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: libobjcryst
Version : 2021.1.1-1
Upstream Author : Vincent Favre-Nicolin vinc...@users.sourceforge.net
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: horae
Version : 071~svn537-3
Upstream Author : Bruce Ravel
* URL : https://github.com/bruceravel/horae
* License : custom
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-platformdirs
Version : 2.4.0
Upstream Author : Bernát Gábor
* URL : https://github.com/platformdirs/platformdirs
* License : MIT
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: ifeffit
Version : 2:1.2.11d-11
Upstream Author : Matt Newville
* URL : https://cars.uchicago.edu/ifeffit/Documentation
* License
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: xrstools
Version : 0.15.0+git20210910+c147919d-1
Upstream Author : European Synchrotron Radiation Facility
* URL : https
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: navarp
Version : 1.0.0-1
Upstream Author : Federico Bisti
* URL : https://gitlab.com/fbisti/navarp
* License : GPL3
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: dmrgpp
Version : 6.00-1
Upstream Author : Gonzalo Alvarez
* URL : https://github.com/g1257/dmrgpp
* License : UT Battelle
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: clpeak
Version : 1.1.0-1
Upstream Author : Krishnaraj Bhat
* URL : https://github.com/krrishnarraj/clpeak
* License : The
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: pyocd
Version : 0.12.0+dfsg
Upstream Author : ARM Limited
* URL : https://github.com/mbedmicro/pyOCD
* License : Apache-2.0
Programming Lang: Python
Description : ARM Cortex-M
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: intelhex
Version : 2.1
Upstream Author : 2005-2016 Alexander Belchenko
* URL : https://github.com/bialix/intelhex
* License : BSD
Programming Lang: Python
Description : Intel HEX
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: mando
Version : 0.6.4
Upstream Author : 2013 Michele Lacchia
* URL : https://github.com/rubik/mando
* License : MIT
Programming Lang: Python
Description : command line argument
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: radon
Version : 2.3.1
Upstream Author : 2012-2017 Michele Lacchia
* URL : https://github.com/rubik/radon
* License : BSD
Programming Lang: Python
Description : Code metric generator
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: black
Version : 18.6b4
Upstream Author : Łukasz Langa
* URL : https://github.com/ambv/black
* License : BSD-3-Clause
Programming Lang: Python
Description : uncompromising Python
cares about architectures, another large area where Debian needs
to have precise and accurate details.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpOruIt8X7yL.pgp
Description: OpenPGP digital signature
ows may be hit by this.
>
> Should there be another TPMDIR? Like DTMPDIR, pointing to the
> underneath disk, where size is limited by the capacity available to
> partition/disk ?
>
> This could allow developers to choose one over the other based on
> their needs. It could als
install
> to /usr/share/doc/libargtable2-doc. Am I missing some option that
> would make that easy?
debhelper is doing the right thing. /usr/share/doc/libargtable2-doc/ is
correct as the package name is foo-doc (it's not the source package
name, it's the binary package
er
> freedoms based on the software being free, and being a good citizen
> within the free software community. Saying that you must be a good
> citizen to exercise the grants of the free software license goes
> against the principle of free software.
That is obviously absurd.
ose changes in ways that do not match how
upstream would accept those changes for inclusion into a future release
may follow the letter of the licence but it certainly is not being a
good community citizen.
It can be enough hassle for upstream when patches don't apply, let alone
when the effect of the patch has to first be converted to a different
format. Debian needs to encourage things that make collaboration easy,
upstream and downstream.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpzNgFdVEgys.pgp
Description: OpenPGP digital signature
symlinks:
https://sources.debian.net/src/lava-server/2016.6-2/share/javascript.py/
and a file (in this case maintained by upstream) to specify handling:
https://sources.debian.net/src/lava-server/2016.6-2/share/javascript.yaml/
This is then just called from debian/rules:
https://sources.debian.net/
quot;
or "wise" to add backports and install packages from backports.
Packages which may have a history that has caused such reactions need
to be brought in line.
> This is a 100% larger conversation, and it's not about a hacky deb,
> it's about how our plac
On Sun, 08 May 2016 07:18:40 -0400
The Wanderer wrote:
> On 2016-05-08 at 03:45, Neil Williams wrote:
>
> > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard
> > wrote:
>
> Even if running unstable, I would certainly expect that something
> which is known to break ce
able. That's why the advice is to move this box
to stable - ask for backports of any packages which need updates from
testing.
You have four years to decide whether to replace this hardware or
continue running jessie without support.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp3rfDRI8DYQ.pgp
Description: OpenPGP digital signature
lease notes somewhere?
> I'm sure they will be there in the stretch release notes.
Adding the bug back to CC.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpDAjcwennXO.pgp
Description: OpenPGP digital signature
on of apt.
> This involves a lot of keypresses, and I'm incredibly lazy ;)
> I was just wondering if apt could be more interactive, or if it is a
> design choice not to ask too many questions.
If you want interactive, use aptitude or synaptic.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpZ08fn8x7ew.pgp
Description: OpenPGP digital signature
ady shows you which packages are to be brought in as Recommends
on every invocation and unless you use the -y option you get the
option to quit. You can already choose to quit and call apt with the
--no-install-recommends option for this specific invocation of apt.
--
Neil Williams
=
ht
On Fri, 8 Apr 2016 00:02:08 + (UTC)
Felipe Sateler wrote:
> On Wed, 06 Apr 2016 17:16:18 +0100, Neil Williams wrote:
>
> > On Wed, 6 Apr 2016 15:27:48 + (UTC)
> > Felipe Sateler wrote:
> >
> >> On Wed, 06 Apr 2016 00:18:10 +0200, Ondřej Surý
Also, packages may provide services to a lot more users than just the
ones with it and popcon installed. There are many the packages which
depend on a webserver of some kind - a single install can have many
thousands of users.
popcon data can be handy for humans who bother to go after the
package-s
oolchain changes.
Clearer records exist at ci.debian.net.
> I get the impression that more upstream packages have built-in tests
> that can be run as part of dpkg-buildpackage (e.g Python, Perl, Ruby,
> Java and Go) but maybe that's just because I've been working in those
> environments recently.
Not all unit test suites can run during the build.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpUEiH363o2e.pgp
Description: OpenPGP digital signature
rocess *is* to
forcibly orphan the package?)
The individual metrics need to be aggregated to a score but fine
tuning that score algorithm is more work than most people want to do on
packages which are already uninteresting.
What has happened in the past is that a BSP close to a release has had
a
On Wed, 30 Mar 2016 10:42:53 +0200
Ansgar Burchardt wrote:
> Neil Williams writes:
> > On Tue, 29 Mar 2016 21:25:26 -0700
> > Afif Elghraoui wrote:
> >> The package in question, circlator, depends on two
> >> architecture-dependent packages that can only
rimarily so that the relevant dependencies can exist to allow the
package to not only be installed but to actually *work*.
> Is there something I can do to help fix this?
New upload which is not Arch:all.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpcyVWP1eobQ.pgp
Description: OpenPGP digital signature
On Sun, 17 Jan 2016 10:21:15 +0100
Marc Haber wrote:
> On Sun, 17 Jan 2016 08:39:02 +0000, Neil Williams
> wrote:
> >On Sun, 17 Jan 2016 09:07:56 +0100
> >Marc Haber wrote:
> >
> >> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl
> >> wrote:
and bug reports, right up
until the last steps of the release.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpzTpNsrKaLV.pgp
Description: OpenPGP digital signature
correct *if* the original prefix is retained - and it shouldn't
overly worry any developers. It's a necessary step to actually getting a
release.
However, this is so far off-topic now that it is pointless to continue.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpAFN0gH052q.pgp
Description: OpenPGP digital signature
. It just depends on what gets enabled in the
kernel. There's some things to do if that is to be an NFS boot but
that's manageable too, depending on the kernel config. Debian kernels
don't have that config (and don't need it), but then if you've got a
Debian kernel, y
is-list: false
> uploaders-count: 0
> comaintenance: 0
Classic debhelper, not dh. This is not necessarily a problem.
> What's wrong ? What do I have to do ?
0: Follow the instructions on Lucas' page more carefully.
1: Decide whether anything actually needs to be done for po-d
On Mon, 30 Nov 2015 20:41:15 +1100
Brian May wrote:
> Neil Williams writes:
>
> > So the reference to bootstrap.js needs to be patched out to refer
> > to a static location which can be put in place using a Depends in
> > debian/rules.
>
> Still trying to work
On Sun, 15 Nov 2015 11:42:31 +1100
Brian May wrote:
> Neil Williams writes:
>
> >> E: python3-ajax-select: privacy-breach-uses-embedded-file
> >> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js
> >> You may use libjs-jquery-ui
tual packages that may need the tool.
Even with a trivial package, scan-copyrights produces output which
if used as debian/copyright would get rejected by lintian and ftpmaster.
Much more work needs to be done, IMHO, especially considering the
dozens of dependencies which typically ne
On Sat, 14 Nov 2015 20:23:38 +1100
Brian May wrote:
> Hello,
>
> For django-ajax-selects in git[1] I am getting the following errors
> and warnings:
Many of these need work upstream, some can be replaced with symlinks,
some are not packaged in Debian due to problems with the minifier used
in th
*actually do a release*).
It looks like a shed, it sounds like a shed, it's a shed.
There is no time or appetite for another round of bikeshedding and we
don't need more TLAs, please allow dak to get me a bikeshed soon!
please!
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpsevALwj1Dv.pgp
Description: OpenPGP digital signature
d it to the version.
ava-dispatcher 2015.9.3908.875bd74-1 amd64
The rev-list takes care of the hash not being a reliable sort as the
hash is effectively hidden from the sort algorithm. It's added because
it's a simple way of looking up the commit on gitolite etc.
--
Neil Williams
=
http://
On Fri, 04 Sep 2015 17:54:30 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 09:32 +0100, Neil Williams
> :
>
> [Applying patch to pre-minification source]
> >> Getting the same min.js is not a goal (we don't try to get the same
> >> binaries than ups
On Fri, 04 Sep 2015 10:07:13 +0200
Vincent Bernat wrote:
> ❦ 4 septembre 2015 08:29 +0100, Neil Williams
> :
>
> > For those upstreams who have to embed JS not available in Debian,
> > then the upstream code often cannot be processed in Debian, neither
> > can th
ss we solve the problem of being able to apply security fixes, the
location of the package within the archive is completely irrelevant.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgptJ5nnQ8Zhk.pgp
Description: OpenPGP digital signature
he security problems worse by
introducing it's own bugs by not building the .min.js in the same way
as the JS upstream. It's also about implementing a method which allows
JS maintainers to keep up to date with JS upstreams so that embedding
upstreams don't have to do any of this in the first place.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgprkWwZuZgRK.pgp
Description: OpenPGP digital signature
On Wed, 2 Sep 2015 13:14:31 -0400
Marvin Renich wrote:
> * Neil Williams [150902 10:22]:
> > Upstream is another recipient of code distributed under copyleft.
> > Having changes in a format which upstream can use is absolutely a
> > sensible and sane criterion for what is
ges
in a format which is suitable for modification and that includes
the work of modification required to incorporate those changes into the
next upstream release. To rule out upstream requirements is nonsense.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpw8VDlMGOXt.pgp
Description: OpenPGP digital signature
SS tool to do this? Is it all just special
snowflake optimisations for what has to be / should be a simple process
of removing whitespace and collapsing the formatting?
Usable software needs usable tools.
As a likely victim of the result(s) of this discussion, I'm going to
say right now that I'
e only packages which are
directly affected by this EOL are those with the specified domains as
the first column?
(Typically, this kind of announcement is done by identifying the
packages likely to be affected and passing that list to dd-list rather
than what looks more like a pre-generated
end on this metapackage; they will rather
> depend on the individual programs.
>
> Or am I abusing the metapackage system here?
Different use cases, I think.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpXD1efR2AVd.pgp
Description: OpenPGP digital signature
into which this can be included instead of wasting mirror space
on the whole packaging overhead? (Listing in Packages.gz, Contents.gz,
mirrors, packages.debian.org and /var/cache/apt/ etc.) Or just add it to
a utils.py in the project which uses it?
--
Neil Williams
=
http://www.
manager.
An entire package for just 18 lines of python? 3 of those lines are
docstring. Even if a few packages import it, it doesn't really seem
worth packaging separately. Just wondering.
https://github.com/stefanholek/conditional/blob/master/conditional/conditional.py
--
Neil Will
poppler/0.26.5-2/utils/pdftotext.cc/?hl=166#L166
That leads here: https://tracker.debian.org/pkg/poppler
and then to http://poppler.freedesktop.org/, which leads to
http://lists.freedesktop.org/mailman/listinfo/poppler
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp0NLU_8PFML.pgp
Description: OpenPGP digital signature
ilding shared
> libraries without really understanding how they work, but it's so
> hard to properly manage library upgrades without symbol versioning.
Yet these are precisely the packages (and upstreams) which are most in
need of such a requirement.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgppkkShkwh1J.pgp
Description: OpenPGP digital signature
ian.org/ to see the version available in stable and
other suites.
However, as Paul mentions, what actually gets installed is dependent on
what options you choose in the installer.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpizMr7Qb92R.pgp
Description: OpenPGP digital signature
Debian, not
Fedora or Arch and that means that if you change it, you are
maintaining a fork, not just making packaging changes.
> We work on Ubuntu 14.10 and use debchange and
> git-buildpackage (thanks to Neil Williams
> https://lists.debian.org/debian-devel/2015/05/msg00375.html) as
s for these packages quite regularly but something
does seem to be wrong at some level.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpVeWAhfDqMy.pgp
Description: OpenPGP digital signature
On Thu, 14 May 2015 23:25:20 +0200
Vincent Bernat wrote:
> ❦ 14 mai 2015 14:57 +0100, Neil Williams :
>
> >> More seriously, but this needs some additional work, it should be
> >> easier to manage persistent build dependencies. The first time you
> >> build a
On Thu, 14 May 2015 15:45:01 +0200
Vincent Bernat wrote:
> ❦ 14 mai 2015 14:02 +0100, Neil Williams :
>
> >> 1. Gitlab;
> >> 2. Isolated build environment inside Docker containers (where we
> >> usually do `git clone && mk-build-deps &&
can be sufficiently flexible.
Personally, my own build needs have essentially gone away as my
development is now almost exclusively in python (and a tiny bit of
perl). git-buildpackage is all we need and this codebase has no
requirement for any isolation beyond the simplest chroot - and even
that
On Wed, 6 May 2015 20:36:25 +0200
Samuel Thibault wrote:
> Neil Williams, le Wed 06 May 2015 12:03:30 +0100, a écrit :
> > If the patch *is* trivial and testable then it is up to the porters
> > to arrange a fully tested NMU.
>
> How can a porter fully test a package? On
ference:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#override-file
So, no, there isn't something broken - the uploader needs to file the
bug as set out in the developer reference.
(BTW - the problems section doesn't transfer to the tracker version, so
this notice is onl
On Wed, 6 May 2015 12:49:44 +0200
Samuel Thibault wrote:
> Neil Williams, le Wed 06 May 2015 11:39:29 +0100, a écrit :
> > It's not at all that the maintainers are "lazy" or that those
> > maintainers could have done anything differently. Those maintainers
> >
ilar in DI - standard system utilities could include
more packages than a simple debootstrap would provide, like cron and
others.
Maybe we need to split the discussion based on what should be in a
minimal debootstrap and what should be in standard system utilities in
DI?
--
Neil Wi
On Wed, 6 May 2015 18:18:34 +0800
Paul Wise wrote:
> On Wed, May 6, 2015 at 6:11 PM, Neil Williams wrote:
>
> > You've admitted that the port cannot keep pace because it needs
> > changes to be made by maintainers who do not see the port as a
> > particular pri
On Wed, 6 May 2015 11:35:45 +0200
Samuel Thibault wrote:
> Neil Williams, le Wed 06 May 2015 09:47:36 +0100, a écrit :
> > Lack of widespread interest in any particular port is a problem with
> > that port not having widespread appeal.
>
> And lack of helping maintainers
On Wed, 6 May 2015 10:11:02 +0200
Samuel Thibault wrote:
> Neil Williams, le Wed 06 May 2015 08:56:38 +0100, a écrit :
> > Ports which take so long to develop that a stable release is
> > deemed unlikely will also struggle. That is a problem caused by that
> > port, not by
not create
a precedent for, or necessarily have any applicability for, non-release
ports.
5: All non-release architecture ports are unofficial and the decision
on release architectures is down to the release team.
How does that sound?
--
Neil Williams
=
http://www.linux.codeh
ave a "removal timebomb" already primed.
Use a bespoke repository which is available to the people who actually
use it - you may find that it is simpler to then only build the package
against current stable as that is probably what users are actually
running.
[0] https://qa.debian.org/dev
I'm also not sure that I could be that intermediary due to a likely
lack of time. There really isn't a good reason to not have multiple
remotes and pull from whichever the contributor is best able to use.
It makes no sense for a team to actively block the distributed side of
git.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp1nxcAxoJYT.pgp
Description: OpenPGP digital signature
by github users, we are
happy to oblige as the setup is trivial and it "just works".
(So I'm in Linaro and Debian organisations now on github. Yay!)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp92vtlLHcr9.pgp
Description: OpenPGP digital signature
On Sun, 19 Apr 2015 19:00:33 +1000
Ben Finney wrote:
> Neil Williams writes:
>
> > On Sat, 18 Apr 2015 17:55:17 +1000
> > Ben Finney wrote:
> >
> > > GitHub's pull request feature is proprietary to GitHub, it can
> > > only work between
On Sat, 18 Apr 2015 18:04:40 +0800
Paul Wise wrote:
> On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote:
>
> > git won the DVCS argument a long time ago. github won the DVCS UI
> > argument a long time ago - it is clearly the one UI that the
> > largest number of g
ey have chosen (or have never been aware they made the choice) to
> make it much harder to interact with them using the existing,
> standard, federated Git ‘request-pull’ feature, instead opting to
> exclude anyone who doesn't want an account on a specific vendor's
> service.
Sorr
umm, no - really, no and neither should it become so.
Github provides that service and the people who are offering this code
want to use it. Why would I refuse to use that service to open up my own
locked-down server without the admin hassle of creating hundreds of new
accounts?
The people are
otes?
github.com/debian is a very useful service and I intend to use it
fully. I think a lot more Debian folk and a lot more upstream folk
should too. It's a hub, use it as a hub, as one of your remotes. Why
not use the biggest, easiest hub to reach the biggest number of
potential contributors?
What's not to like?
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpWHS151aLMJ.pgp
Description: OpenPGP digital signature
ush" command.
Alioth cannot be another github, random other upstreams cannot be
another github. Sourceforge well, just no really.
Github is exactly that - a hub. Use it to push the code out from within
the access constraints of a typical upstream project. It's easy for
o
cember 2014 and has 3
RC bugs.
https://tracker.debian.org/pkg/refpolicy
So it depends on your need for binaries provided by refpolicy. If I
understand it correctly, existing policies will work and policies can
still be defined but the default references have unfixed
release-criticial
bian organisation on github? (Ping me off-list
if the potential number of enquirers would be unmanageable.)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpJkh7_pJ_BQ.pgp
Description: OpenPGP digital signature
t any DD from writing to their VCS.
>
> Any opinions?
I don't want have write permissions on every project on Alioth and I
don't see that others need write permissions to repos not in
collab-maint. Submit a bug and a patch, just like everyone else.
--
Neil Williams
===
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: django-kvstore
Version : 1.0-1
Upstream Author : 2010 Six Apart Ltd.
* URL : https://pypi.python.org/pypi/django-kvstore
* License : BSD
Programming Lang: Python
Description
package names and work nicely with together - that includes working
with the Debian versions of the same upstream. The technical issues can
be fixed with bug reports. It's only if there is a particularly toxic
social relationship between Debian and upstream that a packag
quot;bad" .deb which ignores Policy and breaks
your system completely.
It is in everyone's interest that the Debian package has the same name
as the source package released by upstream - unless there is a
different package, from a different upstream, already in the archive
with that name or the upstream uses a inappropriate or overly generic
name.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp3cRkviula1.pgp
Description: OpenPGP digital signature
arch. Conflict with (or add Breaks depending on how you
wnat to do it) for the relevant version of that metapackage in the
versions which implement multiarch.
Document in the current version that third-party plugins must Provide:
this metapackage for future support to work.
--
Neil Williams
=
pting configuration tools. Those often need custom
modules to work with particular packages but at least those modules do
not have to become part of the main archive - it makes the security
issues local to the admins.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpuvbgnYty0F.pgp
Description: OpenPGP digital signature
f
the /usr/lib directory. Such files are exempt from the rules that
govern ordinary shared libraries, except that they must not be
installed executable and should be stripped.
A common example are the so-called "plug-ins", internal shared objects
that are dynamically loaded by programs
ildd support. With
linux-any it relies on a list of architectures in a table in dpkg - the
same could be done for other groups.
The mechanisms exist, the question is how many other variants would be
created by adopting this?
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpaT0kgbPNR0.pgp
Description: OpenPGP digital signature
m where we are or contribute elsewhere.
Contribute code or stop wasting everyone's time on the mailing lists.
Nothing will change without someone doing the work - whatever the issue.
If that isn't you, then do everyone a favour and stop posting to these
endless threads.
Come in
On Thu, 27 Nov 2014 16:24:12 +0100
Matthias Urlichs wrote:
> Hi,
>
> Neil Williams:
> > By having separate source packages, a stable API becomes mandatory.
>
> You're correct in that it is easier to keep an API stable when you
> have separate repositories. But t
1 - 100 of 1111 matches
Mail list logo
