On Mon, 13 Jan 2014 18:19:21 +0100
Svante Signell wrote:
> On Mon, 2014-01-13 at 16:59 +0000, Neil Williams wrote:
> > On Mon, 13 Jan 2014 17:38:21 +0100
> > Svante Signell wrote:
>
> > > I like that program very
> > > much. For which reasons,
e level of interest in the
package, beyond whether it is scheduled for removal. Fly-by sponsoring
is not helpful, the sponsor needs to keep an eye on the package - and
work with the maintainer - for the long term.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
On Thu, 30 Jan 2014 13:41:16 +
Wookey wrote:
> +++ Neil Williams [2014-01-30 13:25 +]:
> > On Thu, 30 Jan 2014 13:51:40 +0100
> > Olivier Berger wrote:
> >
> > > I myself isn't very motivated to sponsor packages which I don't
> > > us
fficult.
> The build is done by sbuild, which does not call git-buildpackage.
Not true. There are options to use debuild or pdebuild or
dpkg-buildpackage in-place.
e.g. I use:
[DEFAULT]
#builder = git-pbuilder
builder = debuild
cleaner = fakeroot debian/rules clean
pristine-tar = True
[git-buildpackage]
export-dir = ../build-area/
tarball-dir = ../tarballs/
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
ripts
> package, and am relucant to add new dependencies to it, as this would
> make the new dependency a required package.
sysvinit-utils sounds good to me.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
to create a dedicated
> system user for this services. So I used the tango user which is the
> name of the community in charge of the tango-control system.
Choose a name which is less likely to conflict, e.g. exim uses Debian-exim.
--
Neil Williams
=
http://www.linux.codeh
> > tango-db might make sense, if not maybe something like
> > tango-control-system.
>
>
> no this user will be used by all tango controls system daemon.
The name should not be hardcoded - if it is, patch upstream in each
case and fix it. Don't waste
On Mon, 10 Feb 2014 22:13:45 +0100
Wouter Verhelst wrote:
> Sigh.
>
> On Wed, Feb 05, 2014 at 12:59:23PM +0000, Neil Williams wrote:
> > Using packages to support upstream development is a common problem
/common problem/common source of problems/
> > and this is exa
are that programs are build-dependencies of libraries
which have -dev packages which are build-dependencies of programs.
There are tools which can identify dependency loops, but for a single
run, it is just as effective to try everything, rebuild everything which
broke and repeat, rep
into Debian. Your work needs to speak for
you. Ignore the vocal minority who don't contribute, get the source
code and fix stuff - that's how it works.
Finally, make your own mind up - don't use my reasons or those of anyone
else as the basis for your decision.
--
Nei
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: json-schema-validator
Version : 2.3.1
Upstream Author : Zygmunt Krynicki
* URL : https://github.com/zyga/json-schema-validator
* License : LGPL-3.0
Programming Lang: Python
Description
ibutors who fail to get along with their peers.
It's what you do in Debian that counts. Voting has a place but the vast
majority of decisions which affect Debian are made by someone who is
doing the work. People only choose to do that work as a volunteer when
their co
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: django-restricted-resource
Version : 2014.02
Upstream Author : Zygmunt Krynicki
* URL : https://git.linaro.org/lava/django-restricted-resource.git
* License : LGPL
Programming Lang: Python
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: django-testscenarios
Version : 0.7.3
Upstream Author : Zygmunt Krynicki
* URL : https://pypi.python.org/pypi/django-testscenarios
* License : LGPL
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: django-testproject
Version : 0.1.2
Upstream Author : Zygmunt Krynicki
* URL : https://pypi.python.org/pypi/django-testproject
* License : LGPL
Programming Lang: Python
Description
> benefits if contributors spent time elsewhere.
> Actually, I would ignore the error rather than override it and fix it
> later in some way, but it was not my decision. But I sponsored the
> package and I don't think that it's wrong.
The package is wrong if lintian reports the error. Fix the package.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
mes and uses tab
indentation within code blocks. Minified JS does none of those things.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
the source code of the JS which the package requires does need to be
within the source code of that package. Otherwise, it makes it all but
impossible to debug the JS when the packaged versions migrate.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
it's dealt with for shipped binaries).
No. This is about editing in-place inside the directory created by
apt-get source.
> Unless/until somebody provides compelling reasons (or CTTE or GR), I
> will heed the advice of ignoring this lintian error.
Fix the package properly.
> I was arguing against repackaging source packages.
Then work with upstream to package the required files.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
On Fri, 25 Apr 2014 21:58:57 +1000
Craig Small wrote:
> On Fri, Apr 25, 2014 at 09:41:37AM +0100, Neil Williams wrote:
> > The package is wrong if lintian reports the error. Fix the package.
>
> Not always, the way lintian checks is wrong. I'm not buying into is
> minim
ial and I don't see why it is a problem.
It's quite a bit harder to do the right thing and persuade upstream to
not include them.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: django-longerusername
Version : 0.4-1
Upstream Author : Steven Skoczen
* URL : https://pypi.python.org/pypi/longerusername
* License : BSD
Programming Lang: Python
Description
ource package needs to contain the JS in the preferred
form for modification. *If* that is provided by a package at a
supported version, then a symlink can be used (and a versioned
dependency if the version matters as it does in some of my usecases).
From upstream perspective, provide the JS in the form preferred for
modification and minify during the package build.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-tool
Version : 0.10
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : LGPL
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-coordinator
Version : 0.1.5
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lavapdu
Version : 0.0.3
Upstream Author : Matthew Hart
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL
Programming Lang: Python
Description : LAVA PDU client
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-dispatcher
Version : 2014.05
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL, LGPL
Programming Lang: Python
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: lava-server
Version : 2014.05
Upstream Author : 2010-2013, Linaro Limited
* URL : http://www.linaro.org/projects/test-validation/
* License : GPL, LGPL, AGPL
Programming Lang: Python
on of the compiler - nor does anyone actually want to require
manual intervention to go from gcc-4.8 to gcc-4.9 - that's what we have
the gcc package.
Same is true for the default python interpreter or various other
default packages rather than "package selections" vi
s which
were not manually installed in a list of packages which are potentially
suitable for autoremove.
> This may be a deficiency
> which we want to do something about, but doesn't help right now.
However, apt-mark status is probably not the answer to the original
question which needs
; Thing(tm).
>
> This module is needed (indirectly) by recent releases of
> libmoox-options-perl.
>
> It will be maintained in the Debian Perl team.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
.org/debian-ports
Make sure apt-key list shows something including:
/etc/apt/trusted.gpg.d/debian-ports-archive-2014.gpg
pub 4096R/623DB0B8 2014-01-16 [expires: 2015-01-31]
uid Debian Ports Archive Automatic Signing Key (2014)
scripts, it is the package name,
not a parser for the Packages file. Indeed, in Emdebian Grip processing, we
actually remove this field from the Packages file.
--
Neil Williams
pgpJKdQVEukjI.pgp
Description: PGP signature
package or not)
so that any transitions can be managed.
3: File a bug against your own package if it hasn't been done already.
4: Check if there are other packages which have come to use your
package since the initial data was created.
My own data:
Neil Williams
libcontactsdb (U)#62
ement for ifupdown.
Network-Manager is ruled out because it expects every install to need
to cope with wireless and therefore brings in (currently) gnutls,
gcrypt, tasn, polkit & wpasupplicant type stuff AS WELL as dbus.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgppwGLCgprTM.pgp
Description: PGP signature
cific device and only install the ones I do need.
> The problem here is that it is, currently,
> not being able to handle all the network connection types we want to
> handle.
... independently ...
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp9kkBeUgjrM.pgp
Description: PGP signature
On Sun, 3 Apr 2011 11:38:58 + (UTC)
Sune Vuorela wrote:
> On 2011-04-03, Neil Williams wrote:
> > I'm now getting patches from Ubuntu to catch up the effects of this old
> > Release Goal. I fully support the removal of .la files [0] but it would
> > be good if we
On Sun, 3 Apr 2011 14:57:22 +0200
Mathieu Parent wrote:
> Hi,
>
> 2011/4/3 Neil Williams :
> > http://lists.debian.org/debian-devel/2009/08/msg00808.html
> >
> (...)
> >
> > Let's try and handle the .la file issue across all of Debian.
>
> dh
On Sun, 3 Apr 2011 19:49:22 +0200
Andreas Metzler wrote:
> Neil Williams wrote:
> [...]
> > It is far cleaner to simply not package the .la file than to mangle it
> > with sed in debian/rules - my contention is that removing the file is
> > the best solution
On Sun, 3 Apr 2011 19:45:13 +0200
Andreas Metzler wrote:
> Neil Williams wrote:
> > Andreas: the process you used to create the initial list - is that
> > available as a script somewhere? Can it be re-run? Can the updated
> > output be filtered for the libraries which c
On Sun, 3 Apr 2011 21:09:55 +0200
Helge Kreutzmann wrote:
> Hello Neil,
> On Tue, Mar 17, 2009 at 04:13:15PM +, Neil Williams wrote:
> > Time to launch the debate on the Draft TDeb Specification - DEP-4.
> >
> > Current HTML form: http://people.d
On Sun, 03 Apr 2011 15:04:01 -0700
Russ Allbery wrote:
> Neil Williams writes:
>
> > If you are listed in the attached dd-list, it means that the following
> > tasks should be done REAL SOON NOW in order to smooth the path for
> > Multi-Arch and comply with Policy 1
ore tools
which work together instead of one simple tool which gets side-stepped
by a more complex tool because of a poor design.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpCSFMYAUNM4.pgp
Description: PGP signature
sr/lib where foo is the binary
package name. Depends. You'd need to upload the build log somewhere,
along with the full source, and ask someone at debian-mentors to review
it.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpyACBUNyiZG.pgp
Description: PGP signature
On Mon, 04 Apr 2011 10:49:04 -0700
Russ Allbery wrote:
> Neil Williams writes:
> > The line in the original data is:
>
> > shibboleth-sp2: dependency_libs links-not-existing-la
>
> > The original criteria were:
>
> > 1. "no flag" to remo
On Mon, 4 Apr 2011 16:12:42 -0700
Steve Langasek wrote:
> On Mon, Apr 04, 2011 at 07:33:24PM +0100, Neil Williams wrote:
> > > >> Lintian already checks that *.la files don't contain the problematic
> > > >> dependency_libs setting.
>
> > > Th
ther package changes
across the archive.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpJQqZDBbsPY.pgp
Description: PGP signature
On Tue, 05 Apr 2011 11:47:01 +0100
Ben Hutchings wrote:
> On Tue, 2011-04-05 at 11:25 +0100, Neil Williams wrote:
> [...]
> > Lintian error (and an ftpmaster REJECT) if a binary package (not just
> > a library) has multiarch paths without debhelper compat 9. (This
> > pr
ertainly for
#621246, the upload which is currently 1 day old in sid has the dependency_libs
emptied. I don't think there's any way that the process can reliably catch
uploads that new but thanks for fixing that package.
I'll add the version available on the
h the version retrieval or to check for the
ubuntu usertag yet. Patches are welcome (despite this not actually being
in version control anywhere - I could be persuaded to put this into
Emdebian SVN but it seems like overkill to create an Alioth project).
--
Neil Williams
=
st after I've completed a few more phases.
Severity ping-pong won't get these bugs fixed any quicker. Despite
appearances, bug severity is not a good predictor of maintainer activity
levels across the entire archive outside of a release freeze.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpJ8rPC7S2Zq.pgp
Description: PGP signature
to document the rationale but as dependency_libs is
currently empty and you have a reason to use the .la, it should be fine
to close 621170.
Just hold for a bit, in case there are any further comments from others
on -devel.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpwrGpME2djz.pgp
Description: PGP signature
#x27;t get done,
Debian would be well served by removing the package. Simple really.
I'm quite willing to file the RM bug myself if nothing happens by the
time I come around to looking through the list of orphaned packages
again.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpFQIAzdx2g1.pgp
Description: PGP signature
.
IMHO unless every upstream package in the necessary chain states that static
linkage is supported by upstream, then static linkage is an "exercise left to
the reader" to solve and there's nothing to be done with bugs like this, except
possibly state in the packaging docs that static simply does not work "out of
the box".
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpPVDrTk7MxS.pgp
Description: PGP signature
but that's
nothing to do with pkg-config.)
pkg-config is just config, it is not a pkg checker. Checking that what
you get actually works has to come down to the actual package. Even
then, unless that config is supported, it will (and must be allowed
to) just fail to build.
--
Neil Williams
the data in the .pc file(s) will actually allow
programs to link against the libraries specified. That is the job of
the build system using pkg-config. pkg-config is, after all, a config
tool, not a QA or checking tool.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpCUBJ4VlXKc.pgp
Description: PGP signature
static to make allowances for those dependencies which cannot link
statically. It won't be the last time that's going to be needed.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpuPFnqwRcWl.pgp
Description: PGP signature
ohibiting* translation of descriptive text which is
intended to be helpful to users ought to be an RC bug in and of itself.
Fine if the translation doesn't exist but menu actively prevents
translation. That is simply BUST - RC bust IMNSHO.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpR4Lx3naDVh.pgp
Description: PGP signature
On Tue, 19 Apr 2011 13:34:43 +0200
"Bernhard R. Link" wrote:
> * Neil Williams [110419 12:50]:
> > How can the old Debian menu system be considered as "working" when it
> > has never supported translation? All those titles and longtitles, not
> > a singl
plet" or "Settings" in Categories.
If we're going to bother with this at all, then most of the above must
have *must* downgraded to *should*. At no point must menu entries be
allowed to become the source of RC bugs unless the file validity
breaks the build from source. The i
On Wed, 20 Apr 2011 11:46:31 +0200
"Bernhard R. Link" wrote:
> * Neil Williams [110420 10:47]:
> > Have you examples of desktop files which are not "in shape" currently?
>
> Well, for example currently in squeeze there is
>
> /usr/share/menu/evinc
tion page is just such a list. Simply exporting that list -
possibly as a series of lines for each category of issues - would be
useful.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpbSI2o25doy.pgp
Description: PGP signature
pe layout?
Even if it just results in the package names per-developer as a
separate page consisting of static list of links back to the transition
page for that package, it would help.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpGRRyIgUQjK.pgp
Description: PGP signature
On Sat, 7 May 2011 13:48:00 +0200
Enrico Weigelt wrote:
> * Neil Williams schrieb:
>
> > Not every generated file needs to be cleaned. The list can vary if the
> > package is very old and depends on how the package itself handles the
> > clean internally.
>
&g
t from these being turned into "best practice" and no gain in
Debian from wider adoption of such *preferences*.
> I've already done that for several packages in the OSS-QM project.
> (which is not meant for Debian, but completely distro agnostic)
I've no problem with that as long as you leave my upstreams alone.
;-)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpfyXBNj66gP.pgp
Description: PGP signature
an can justifiably expect from any maintainer.
7 days without email is a good enough reason to assume that the
maintainer isn't going to uploading a fix any time soon.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpccjyUvP9oi.pgp
Description: PGP signature
On Sat, 7 May 2011 15:41:22 +0200
Enrico Weigelt wrote:
> * Neil Williams schrieb:
>
> > No. Reverting the build to the point where it is equivalent to only
> > what is in the VCS adds completely unnecessary build dependencies and
> > build stages.
>
> Which o
On Sat, 7 May 2011 16:51:01 +0200
Enrico Weigelt wrote:
> * Neil Williams schrieb:
>
> > Nonsense. It is not the job of ./autogen.sh to revert to the VCS state
>
> It is it's job to produce a clean state where *all* generated
> files have been regenerated and the ne
ecific jurisdiction or people can die. Debian and autotools are
> > nowhere near that level of importance.
>
> Probably not. But why not learning from the other areas of engineering ?
The benefit has to be transferable across fields - blatantly the
analogy you drew has no relevance to autotools.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpCPLF0vNJQD.pgp
Description: PGP signature
a means to get more rubbish packages
into the archive which the QA team will eventually need to remove.
The emphasis of sponsoring seems wrong to me currently - it is *not
about the packages*, it should be about the people.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpl5GlpouA2w.pgp
Description: PGP signature
On Fri, 20 May 2011 12:01:43 +0200
Jonas Smedegaard wrote:
> On 11-05-20 at 10:22am, Neil Williams wrote:
> > Fly-by sponsoring is *not* helpful to Debian.
>
> I wholeheartedly agree.
>
> ...and non-fly-by sponsoring is what I instead call teamwork:
>
> Personally
e the .la file but these methods do not use
the dependency_libs setting of the .la file which is where the
problems arise. Other plugin methods do not need a .la file.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpAWr8OY4fs4.pgp
Description: PGP signature
cy_libs
> clear dependency_libs
If it is just dependency_libs and there are no plugin issues, it IS
safe to remove the .la file rather than adding sed-based processing.
See these messages and pages for more information:
http://wiki.debian.org/ReleaseGoals/LAFileRemoval
http://lists.debian.org/debian-devel/2011/04/msg00055.html
http://lists.debian.org/debian-devel/2011/04/msg00199.html
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpbzgRNfZO0P.pgp
Description: PGP signature
led.
Everything except dpkg-dev and lintian should be Recommends and most of
the ones above should be Suggests IMHO.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpaRRxbOIWPH.pgp
Description: PGP signature
format but those packages will not use a patch system, ever.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpGf9Uww8skf.pgp
Description: PGP signature
field.
The package build process in Debian deals with providing the
information in ways which are controllable within the single package
build instead of using, what is essentially, archived data from
previous builds as is preserved in the .la files of dependencies.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpGrW12anhNt.pgp
Description: PGP signature
anaged.
So Debian already has evidence that make check DOES continue to work
whether or not .la files exist. It's not as widespread as simple
builds without test suites but the range of packages using make check
in a Debian build is sufficiently wide that I see no reason to worry
about make ch
like to use
> the core packages of Debian release xyz (all the essential
> packages, for example) together with more up-to-date
> packages in testing (kernel & drivers, development tools,
> eye candy, games, etc).
Mixed systems are always awkward because that one system could w
he alternative can never
be as good as the current stable release and the whole exercise is
pointless.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpiCI24fa8fC.pgp
Description: PGP signature
On Sat, 04 Jun 2011 17:07:26 +0200
Harald Dunkel wrote:
> On 06/04/11 12:36, Neil Williams wrote:
> > On Sat, 04 Jun 2011 10:12:42 +0200
> > Harald Dunkel wrote:
> >
> >> Installing testing for the whole system is no option. The base
> >> system (the c
this check before this package is uploaded,
unless the lintian maintainers disagree.
It would also be sensible to have a summary of the quoted paragraph in
the package description.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp0OvFTLVChl.pgp
Description: PGP signature
ndred megabytes even unpacked, it's the apt cache which takes up the
space and that can be cleared with a configuration change) and everyone
using packaging-dev should be expected (required) to use a chroot to
build packages prior to upload.
Recommending chroot build tools is not strong e
watching it a lot
more closely now and I'll be in touch if it gets to be removed. I've no
interest in zookeeper in and of itself, I just care about quality
assurance in Debian.
A new twist on The Streisand Effect, you might say.
;-)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpvQqkkl6y8w.pgp
Description: PGP signature
l be handled if not
fixed. If no-one steps up, for reasons of motivation or whatever else,
then the package will be removed. It's quite simple really, the
package isn't good enough to be in Debian if this bug is left unfixed.
Someone fixes it, I'll be happy. Until then, protests without action
will make absolutely no difference.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpRdycEF1nQt.pgp
Description: PGP signature
ove zookeeper from testing and unstable.
If #626020 is fixed by someone who is not willing to maintain it long
term, it's still less than ideal.
If #629856 is fixed without an active team appearing for zookeeper,
there is no reason to keep zookeeper around - even in unstable.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpol0n5apKxW.pgp
Description: PGP signature
p://wiki.debian.org/PowerPCSPEPort
>
> That's unrelated.
>
> It's a pity (and cause of confusion) of having SPE mean both "Signal
> Processing
> Extension" (for FreeScale parts) and "Synergistic Processing Element" (for
> Cell
>
hat
> /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/odbc
> is better than
> /usr/lib/odbc/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
This is covered in the MultiArch docs but from my understanding, it
would be:
/usr/lib/arm-linux-gnueabi/odbc/
e.g.
libgl1-mesa-dri: /usr/lib/x86_64-linux-gnu/dri
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpqnjJdskdui.pgp
Description: PGP signature
On Sat, 16 Jul 2011 23:58:28 +0200
Robert Millan wrote:
> Title and template description (below) is self-explanatory. 156
> packages are affected (list is attached).
>
More usefully, the dd-list of the packages is attached.
--
Neil Williams
=
http://www.linux.codeh
ed form of the source itself and
hence under the same licence as the source itself.
Declaring the copyright of the source covers any reformatting of the
source which occurs during the building/packaging/distribution process.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
On Mon, 18 Jul 2011 19:54:14 -0400
Nikolaus Rath wrote:
> Neil Williams writes:
> > On Mon, 18 Jul 2011 14:54:53 -0400
> > Nikolaus Rath wrote:
> >
> >> I understand that a DEP5 copyright file lists licenses and copyrights
> >> for files in the debian so
the Sphinx license rather then the
> license of the documentation source files.
>
> On one hand it makes sense to me that /usr/share/[package]/copyright
> should contains information about all files in [package]. But on the
> other hand it doesn't make sense to me to add something li
2 with no deprecated code or just FLTK1.3? (I'm assuming dillo3 for
Debian would change the default build to not statically link FLTK.)
How does the (unreleased) version compare with Arora (my current
candidate for "small but usable web browser") and how soon
bian Policy with a set
of footnotes?
[0] http://lists.debian.org/debian-embedded/2011/04/msg00013.html
[1] http://wiki.debian.org/EmdebianPolicy/Background
[2] http://wiki.debian.org/EmdebianPolicy
[3] http://www.emdebian.org/grip/
[4] http://packages.qa.debian.org/e/emdebian-grip.html
to confusion in bug reports. This is
why the proposed suite names include "grip" rather than "emdebian".
Lots more information on Emdebian on the http://www.emdebian.org
website and the Embedded_Debian parts of the Debian wiki.
[0] http://lists.debian.org/debian-embedded/20
On Mon, 8 Aug 2011 11:41:06 +0200
Holger Levsen wrote:
> Hi Neil,
>
> applause, thanks & good luck to making grip official!
:-)
> just one tiny comment:
>
> On Sonntag, 7. August 2011, Neil Williams wrote:
> > 9.8 Keyboard configuration - Note that many Emdebian
On Mon, 08 Aug 2011 17:43:55 +0200
Tollef Fog Heen wrote:
> ]] Neil Williams
>
> | The discussions have resulted in quite a few points which I've now put
> | on the wiki:
> |
> | http://wiki.debian.org/EmdebianIntegration
> |
> | Please refer to the wiki befo
tures than
Debian and only 10% of the packages in Debian.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpr89PmQIgir.pgp
Description: PGP signature
,
it should be possible to use this support to build the package that way
for bootstrapping purposes, whether or not anyone is aware of a problem
in advance.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpOg33138G83.pgp
Description: PGP signature
be in BIG trouble.
;-)
(Something in late October / November this year anyone?)
It'll be REALLY disappointing if this thread just results in yet more
discussion over semantics and nomenclature.
Debian is a do-ocracy, so 6 years of discussion really needs to end with
something actually being done.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgprYLVlku8Aq.pgp
Description: PGP signature
strapping impossible
without changes in the package(s).)
Source: libfoo
Build-Depends: bar
Package: libfoo3
Package: libfoo-bin
Source: bar
Package: bar
Depends: libfoo-bin
Other examples include poppler:cups:poppler:cups which doesn't involve
documentation at all - see Wookey's talk at DebConf11 for all the gory
detail. (Link in Andreas' original post.)
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp85vvhJ5bxt.pgp
Description: PGP signature
901 - 1000 of 1111 matches
Mail list logo
