n 32 bit archs? It's definitely possible to
have different versions in the archive for different architectures.
Matt
--
Matthew Johnson
http://www.matthew.ath.cx/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
urce could even have an option to test for patch: and apply the
patches when it unpacks (I assume the wig&pen format will do essentially
that)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
o
call any git commands myself. Implementation details are essentially
irrelevant.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
If we will, adding features to it is a
> good idea, if we won't, let's just focus on how to let it be expressive
> enough to encode in it all what we use as new features upstream from it.
> And as a matter of a fact, quilt is enough for that.
Full ACK
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
CS
system, however, which _has_ been suggested. (It may be technically
superior, but let me change when I'm ready by demonstrating the
virtues and providing tutorials, don't force me to use it because it's
the new source format)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Tue Feb 05 22:43, Ben Finney wrote:
> Matthew Johnson <[EMAIL PROTECTED]> writes:
>
> > I am against patch system users being forced to changed to a DVCS
> > system, however, which _has_ been suggested.
>
> I've not seen that suggested in this thread.
On Tue Feb 05 14:16, Lars Wirzenius wrote:
> On ti, 2008-02-05 at 12:07 +0000, Matthew Johnson wrote:
> > Also: * The package format should be standardised such that the same
> > workflow works for everyone.
>
> If that's a reference to my first post to
t case, "dpkg-source -b" is expected to work.
Don't forget:
Case 4: Some wig&pen or patches.tar.gz source format which can apply the
patches on unpack (maybe this is Case 2.5).
It solves the "don't trust debian/rules" problem.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
cific. Allowing obscure quilt-only features wasn't what I'd
understood from the discussion.
Anyway, given that many VCSen seem to be gaining quilt-compatible
interfaces, it doesn't really seem like forcing people to use quilt.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
the security team to
know '*every* patch bundle system' or to know how to deal with a DVCS.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: trilead-ssh2
Binary package(s): libtrilead-ssh2-java
Version: 211-1
Licence: BSD
Author: Tril
h causes the "smart" build systems of these
> packages to detedct and link against it, which is NOT what I want.
Which is something you should probably do anyway to satisfy the 'builds
the same in a dirty build environment' goal. Although I do agree that
fetching extra build-dep
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: xbmc
Binary package(s): xbmc
Version: 0.0~02032008
Licence: GPLv2
Author: Various
Homepage
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: nxproxy
Binary package(s): nxproxy
Version: 3.1.0-2-1
Licence: GPL
Author: NoMachine
Ho
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: nxcl
Binary package(s): libnxcl1 libnxcl-dev libnxcl-bin
Version: 0.9-1
Licence: GPL
Author: Seb James
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: nxcomp
Binary package(s): libxcomp3 libxcomp-dev
Version: 3.1.0-6-1
Licence: GPL
Author: NoM
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: qtnx
Binary package(s): qtnx
Version: 0.9-1
Licence: GPL
Author:
Homepage:
Descripti
rking with the freenx people who have a patch to nxproxy so that it
doesn't need nxssh.
These ITPs are for an NX client with the above patches so that openssh
can be used rather than nxssh.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
.
I believe this is still required to be in contrib (certainly I have
packages meeting that description), the binaries depend on something
outside of main to run...
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
and those people are also our target
audience.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
hp then your process is running with the same uid as the
web server, ergo, it can read the memory of the apache process. The php
interpreter doesn't have much to do with it, as long as system() and
friends are enabled.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
; just builded the package with an up to date pbuilder.
do you have updated devscripts? debsign signs the dsc then updates the
md5 hash in the changes before signing that. It needs to update the sha
checks as well. The latest devscripts does.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
depends where you run debsign. I've backported devscripts to the
machine I run debsign on, which isn't running unstable, so pbuilder
builds in a sid chroot and then I sign outside of it.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ttps://wiki.ubuntu.com/MultiarchSpec
I have offered to help with this, if someone can tell me what needs to
be done.
This is something I'd hoped would be pushed out through Debian to other
distributions, not yet another thing which Ubuntu innovates and then we
merge back in later.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Mon Jun 29 21:50, Goswin von Brederlow wrote:
> > There is work going on recently. Steve Langasek drafted a plan that he
> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
> > reality inside De
On Sun Jul 19 18:04, Raphael Geissert wrote:
> This is a follow up to my previous thread, with a slightly different proposal.
>
Sounds like a good plan, I really hope we can go ahead with this for
squeeze.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ly_ happen. Hence why I like the xdg-browser suggestion,
which keeps the same semantics.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ough the pain of a formal resolution.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
about fixing the
package in normal Debian mode, I can look at Debian rules and see what's
going on, not have to go look at some other file which contains the real
debian/rules.
This is all far nicer than (for example) the packaging for the kernel,
which is really scary, but does have the ri
them is a good idea
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
reason for users of graphical logins to care
which VT it is on most of the time.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: pescetti
Binary package(s): pescetti
Version: 0.5-1
Licence: GPL-2
Author: Matthew Johnson
Homepage: http
in the clean target could be an option, but I really
> hate
> to modify my source tree that much while packaging.
Why do you think there's a difference between this and at patch time.
> So no way to do it with quilt?
There's definitely no way to do it with quilt.
Ma
any case they are
still shipped in the upstream tarball and dpkg-source ignores missing
files when creating the diff.gz
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
will build if only their build-depends are
installed or if their build system is the current alternative, but not
if they were installed in a different order.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ve done numerous clean installations), and in those
cases it is made a lot harder for the existing users who suddenly find
gbib has disappeared.
I'm not arguing against the removal of xmms, but I am arguing against
the removal of perfectly good pieces of software just because the are
no-longer upstream supported.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: python-scriptutil
Binary package(s): python-scriptutil
Version: 1
Licence: BSD
Author: Muharem Hrnj
s to
be manipulated by users with keys in the Debian keyring? Obviously this
could be created by someone with a LP account and a bouncer that checks
the Debian keyring, but it would probably be better to have Ubuntu on
board with this.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Wed Jul 23 16:13, Reinhard Tartler wrote:
> Matthew Johnson <[EMAIL PROTECTED]> writes:
>
> > Given that Ubuntu takes things directly from Debian, and hence all
> > Debian Developers have a vested interest in Ubuntu packages, would it
> > make sense to (provide|as
>buildd maintainer thought it was hardware-dependent.
>
> It would be nice if buildd admins told people they were doing it, of
> course, so that maintainers don't have to guess why their packages
> mysteriously aren't being built...
>
Or at least didn't block t
e content of the current release
> notes...
Or, ask all the contributors to the NewInLenny page if they could agree
to licence their contributions in a compatible fashion (what _are_ the
relevant licences anyway?!)
--
Matthew Johnson
signature.asc
Description: Digital signature
ays good
Matt
--
Matthew Johnson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: fcoretools
Binary package(s): fcoretools
Version: 1.0-1
Licence: GPLv2
Author: Dave Plonka <[EMAIL
;s
> under the release team attention, and the usually take care of it.
Yes, but the maintainer has to make the upload to t-p-u (or send the
unblock etc)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
you should leave the project is
completely untenable. It's a ridiculous suggestion and I am shocked that
anyone would entertain the thought.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ls (U)
Matthew Johnson
bluemon
Simon Kelley
dnsmasq
Anand Kumria
yum
Jonny Lamb
libosso (U)
odccm
osso-gwconnect (U)
Roger Leigh
cups (U)
Jeff Licquia
cups (U)
Patrick Matthäi
mumble (U)
Kyle McMartin
wpasupplicant (U)
Loic Minier
avahi (U)
libosso (U)
On Sat Jan 03 17:58, Matthew Johnson wrote:
> All that needs to be done to fix this is to edit the config file which
> is dropped in /etc/dbus-1/system.d/ to allow all of the incoming method
> calls and outgoing signals. Method replies/errors and introspection
> already have exce
pection, but only sends signals so it's not
critical. Filed a bug at normal
>
> > Debian Maemo Maintainers
> >libosso
>
Ships a config file which disables all the security checks on the whole
system bus[0]. Filed RC bug
> > Matthew Johnson
> >blue
All of these have the send_destination policy so look like they should
be fine.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
i-support-base when the architectures
of its dependencies change.
> I'd rather that this is fixed generically for all archive software and
> all suites.
Also a good idea (if possible).
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ue.
In some cases it's a non-problem, yes, but it a lot it won't be, so I'd
still be in favour of a solution which doesn't transition the other
package.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
at out itself? (assuming that we are only considering
archives which are meant to be self-contained).
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
'm trying to build it now with
> Gtk2 but not having much luck so far.
And, it's not in Lenny anyway...
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
(I have to admit that I didn't check it myself, since I
> haven't developed an application which uses gnome-keyring yet).
Well, if they are using DBUS this should be fine. You cannot connect to
a session bus with a uid other than the one it is running as (including
root)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sat Jan 24 14:08, Josselin Mouette wrote:
> Le samedi 24 janvier 2009 à 10:05 +0000, Matthew Johnson a écrit :
> > Well, if they are using DBUS this should be fine. You cannot connect to
> > a session bus with a uid other than the one it is running as (including
> > root
efault) menu entries and should be dealt with by fixing that
program, not by removing all the other entries.
Having said that, I do agree with moving to .desktop by default, but
that does not address the issue of what should be in the menus, just
how.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
I'm sure would many of my 350*(popcon factor)
users.
Thanks,
Matt
--
Matthew Johnson
Trinity Hall IT Support
signature.asc
Description: Digital signature
x27;t think anyone disagrees
that the account creation wait should be shorter; by making access
control more fine grained it makes it easier to delegate at least some
of the decisions and tasks for those access permissions which aren't as
wide ranging. This may assuage the concerns some hav
bian/ does
that cause a new upstream release to happen? There are lots of reasons
why you would want to make debian releases out of sync with upstream
releases (in both directions).
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
get their
system adopted faster than just putting it out there and see what happens.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e
the option to change it. This seems like a regression which kinda makes all the
effort on dash and bashims a little pointless..
It looks like this was introduced in 4.0-7 which fixes #546516.
Thanks,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Fri Apr 09 10:52, Matthew Johnson wrote:
> Having just had an argument on IRC about /bin/sh diversions, it appears that
> the situation in Sid has changed again since I last looked at it.
Hmm, thanks to bwh for pointing out my mistake, sorry for the noise.
Matt
--
Matthew J
owards fixing all the
applications, without making them instantly RC buggy in the mean time. It
smacks of 'uncoordinated transition' to me.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
one setting then the standard would
say "only this setting is compliant with POSIX". Since it does not, we must
assume that a sysadmin choosing either value results in a POSIX-compliant
system. If an application fails to work on such a system it must ipso facto not
be POSIX-compliant
On Thu Aug 12 11:51, Russ Allbery wrote:
> > No. There is no sensible way to do this. The problem is inherent:
> > the binary packages in main have to be rebuildable using the source
> > package (and supporting binary packages eg compilers) in main.
>
> > If you have this situation you have to h
On Mon Aug 16 12:00, Ian Jackson wrote:
> I just had to tell NoScript "forbid debian.org" because I wanted to
> read a bug report.
>
> I don't want to be a spoilsport but, honestly!
You should read bugs.d.o in IE, they don't show up there
Matt
signature.asc
Description: Digital signature
On Thu Sep 09 12:03, Karsten Hilbert wrote:
> Here comes the bug: GNUmed will, given appropriate
> circumstances, OVERWRITE the first allergy against Sugar.
Sounds like "grave: , or causes data loss, ..." to me, which is RC.
I was also going to suggest it could be considered a sec
On Thu Sep 09 14:42, Tshepang Lekhonkhobe wrote:
> > Rather than RC (which is only about whether the severity of the bug is
> > sufficient to delay the release of Debian), what is the severity of the
> > bug?
>
> AFAIK, this is not the sort of package that would delay Debian's
> release. At worst
On Mon Sep 27 15:18, Russ Allbery wrote:
> > Unless I missed it in a previous discussion, I can't see what's wrong
> > with simply mandating support with a new Standards-Version as Bernhard
> > suggested. Could you elaborate on why Build-Features seems preferable
> > since this appears to be a sim
other distributions to
> take a part from the beginning.
the FHS should certainly continue to exist and be coordinated between
distros though. I agree that if it needs taking over we should do so in
cooperation with the other big distros.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
or .desktop files in some fashion. Owned by root is
probably fine (since you've basically already lost if that's the case)
as is setting the execute bit (but things should be cautious as always
about setting it)
Matt
--
Dr Matthew Johnson
signature.asc
Description: Digital signature
andards exist for this reason. And sane upstreams would
> certainly adhere to standards.
Since when are all upstreams sane?
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e spelling given by the OED, so it is correct in all
locales. It doesn't even list localisation as an alternative spelling.
The -ise form here is purely a reaction to American spelling, it's not
actually right.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
> allows me to auto-tag packages from that section, based on reliable
> information provided by the maintainers.
Should Java libs be in lib or libdevel (they are both). This is one of
the reasons we've wanted a Java section.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ute. It still requires a maintainer who will work with
Jorg, who has been hostile in the past about things like patching his
software and working with the Linux kernel rather than insisting
everything be done like solaris. Debian routinely patches software it
ships for many reasons and this is
repared to sponsor a package if
Jorg plays nice (and I will, of course, try to do the same in return),
but if not I'll just have it removed again.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
nservative interpretations of copyright law and licences
which is unlikely to change. If you want us to distribute it you'll have
to do so under a licence we're happy with. This wouldn't be the first
time we've disagreed with people about the freeness of a licence...
Matt.
--
Matthew Johnson
signature.asc
Description: Digital signature
he case with static linking, the FSF hold that
dynamic linking is equivalent.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e nothing else to say on the subject. My offer still stands.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
t to create it, otherwise I could clearly
steal anyone's work merely by adding enough useless code to it.
Hence we reach the same conclusion that Debian did some time ago.
matt
--
Matthew Johnson
signature.asc
Description: Digital signature
gainst any proposal which doesn't require this.
If you want to be nice, you should give the maintainer time to respond
before doing this and file patches etc (as suggested in the dev ref...),
but for things which are 0day NMUable that's obviously not
always practical.
Matt
* insert pr
holdups are with multiarch. What is there
that people like myself and the ia32-libs guys can do to get it working?
I would really like to see it in squeeze if that's possible.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Matthew Johnson
X-Debbugs-CC: debian-devel@lists.debian.org
Source package: live-f1
Binary package(s): live-f1
Version: 0.2.7-1
Licence: GPL-2
Author: Scott James Remnant
Homepage:
Description
ckage, then you should just add yourself to
uploaders, surely...?
That said, the option so far which is least bad is "Team Upload" in the
same way as "QA Upload", i.e. no NMU version number, no NMU procedures,
no delay, etc, just something to ack the mismatch of changed-by and
uploaders/maintainer.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
out if there are _known_ situations
for which it's required.
By all means print large warnings or only make it available in expert
mode, or whatever, but please don't break existing functionality.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Mon Apr 06 11:07, Goswin von Brederlow wrote:
>
> So lets get grub2 working everywhere. :) A worthy goal.
>
Sure, but don't remove lilo until we're happy that grub2 does work
everywhere.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Tue Apr 07 10:38, Charles Plessy wrote:
> so in the end, can we use the “ * QA upload.” special first line for
> non-uploader uploads without breaking the QA infrastructure?
That's wrong if the maintainer is not debian...@lists.
Matt
--
Matthew Johnson
signature.asc
Descripti
gelog trailer. That's certainly what I do with
pkg-java.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
do on all of my machines
--
Matthew Johnson
signature.asc
Description: Digital signature
ny, though the one about
> read-only /usr was appropriate.
More to the point, has anyone actually presented any real arguments why
_not_ to allow it? I've not actually seen anything other than the OP
saying "things might need changing to support it" and then refusing to
go into d
vailable on full
> CD set (if we provide an alternative image for usage by those old
> machines) and I'd also support it not being available for all
> installer flavours but I do think we can't just drop support for those
> machines.
Can't d-i autodetect CPU features
o be out by a factor of
60...
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
standard. I've CC'd debian-java
in case anyone there isn't reading debian-devel.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
o a pseudonym. Anyway, I have no idea whether my sponsorees
who I have never met and haven't gone through ID check are using their
real names. If I don't care about that, why should I care about someone
who is using a pseudonym that doesn't look like a real name.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
gt;
> That's the point, "haven't gone through ID check". He could well maintain his
> package in Debian, just because he's not responsible for the upload.
Yeah, that was my point (-:
If he's happy to be sponsored all the time, he can be maintainer or
upstream.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
. If you don't have anywhere to
upload it I suggest mentors.debian.net.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
96 matches
Mail list logo
