How long until you (or your sponsor) have uploaded it?
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Daniel Baumann wrote:
How long until you (or your sponsor) have uploaded it?
It's already uploaded, but in the NEW queue (new binary package names).
See e.g. http://qa.debian.org/developer.php?package=squashfs
bye,
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Any news so far?
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Hello Daniel, Arnaud, Phillip,
Following Daniel's suggest on Debian bug #34 to be able to build squashfs
without patching kernel, I've tried to do the same thing he's already done for
2.6.15 with the latest 2.4 kernel patch. It's a bit trickier as some
definitions don't exist in
Frédéric BOITEUX wrote:
I've tried to
workaround using some 'ext2' definitions, checked it works, but if you can
review it, it would be nice.
I'll look into it too.
Daniel, Arnaud, if we want to support 2.4, we would give both 2.4 and 2.6
sources, perhaps in 2 separate packages ?
No,
Hello,
I haven't answer to this bug report because i have discussed about this
one with Daniel on IRC, following this discussion, a mail to the
upstream author has been sent. I will take a look at module packaging
(including m-a) in the next days ;).
Regards,
Arnaud Fontaine
[EMAIL PROTECTED] wrote:
Your release-tarball contains only the patches against specific
kernel-versions, but we need the files in 'plain format'. In the first
attempt[1] to build the debian package for that, I had to rebuild your
release-tarball. We want to avoid that if possible, so.. what is
Phillip Lougher wrote:
Adding a directory with the Squashfs files in plain format (rather
than as patches) to the release tarball is possible. I've had a look
at [1] and this doesn't look too much extra work. There are a couple
of issues:
Thanks for your quick answer. When can you release a
Package: squashfs
Severity: important
Hi,
[ Disclaimer: this mail should not be taken as an offense, I just want
to get things done quickly. ]
as I wrote you a few days ago, we want the module packages for squashfs
autobuilt (needed for Debian Live[0]). As I didn't got any answer so
far, I made
Hi Daniel,
thanks for your work and sorry for the delay.
Daniel Baumann wrote:
as I wrote you a few days ago, we want the module packages for squashfs
autobuilt (needed for Debian Live[0]). As I didn't got any answer so
far, I made the package[1] on my own. I tested it successfully on amd64,
Hello,
Le lun 06 mar 2006 13:19:52 CET, Daniel Baumann
[EMAIL PROTECTED] a écrit :
Package: squashfs
Severity: important
Hi,
[ Disclaimer: this mail should not be taken as an offense, I just want
to get things done quickly. ]
as I wrote you a few days ago, we want the module
Hi,
Daniel Baumann wrote:
No, please don't do neither. Arnaud is already investigating this issue.
Please coordinate with him. Maybe your patch can just be applied to the
current version (Arnaud, please check the diffs carefully because of
other changes like docs etc.).
one can't just apply a
Roland Stigge wrote:
thanks for your work and sorry for the delay.
np.
No, please don't do neither. Arnaud is already investigating this issue.
Please coordinate with him. Maybe your patch can just be applied to the
current version (Arnaud, please check the diffs carefully because of
other
Frédéric BOITEUX wrote:
I'm not the official maintener but have worked sometimes on this package and
using it. I've looked a bit on your package, and seems not to give any
kernel patch : are they no longer useful for 2.6.15 kernels ?
There is no kernel-patch because we want to build it
Roland Stigge wrote:
one can't just apply a patch between the current one and my one, to be
able to build it out-of-tree, you have to repackage it (like I did).
Why would this be necessary? I would prefer to keep the orig.tar.gz
identical to upstream (e.g. in case of new upstream releases,
Le lun 06 mar 2006 14:15:54 CET, Daniel Baumann
[EMAIL PROTECTED] a écrit :
There is no kernel-patch because we want to build it out-of-tree, not
in-tree.
Ok, it's a nice goal anyway.
Anyway, everybody doesn't use latest kernel version (nor 2.6 kernel), if
you
want to replace the
Frédéric BOITEUX wrote:
* the modules which are autobuilt are for 2.6 only, etch will likely
not ship any 2.4 kernel, so 2.4 autobuilt support would be useless anyway.
mmm. But Etch isn't to be released soon ;-)
So you are seriously suggesting to hack a crapped 2.4 support in it
although
Le lun 06 mar 2006 14:51:13 CET, Daniel Baumann
[EMAIL PROTECTED] a écrit :
So you are seriously suggesting to hack a crapped 2.4 support in it
although that in about 4-5 month, the base system is freezed for etch?
Hm, I don't think this is worthy when we have m-a to semi-autobuild the
Hi Daniel,
Daniel Baumann wrote:
one can't just apply a patch between the current one and my one, to be
able to build it out-of-tree, you have to repackage it (like I did).
Why would this be necessary? I would prefer to keep the orig.tar.gz
identical to upstream (e.g. in case of new upstream
Roland Stigge wrote:
Upstream puts just patches for in-tree compiliation in his tarball, we
need them separately, for out-of-tree compiliation.
What you are doing is taking upstream's code and adjusting it to
out-of-tree compilation. Since you are shipping patches (dpatch ...)
anyway, it
Hi,
Debian Live[0] is the initiative to create the official live system for
Debian. It is based on squashfs (and unionfs). As we will (and have to)
use the normal linux-images from the Debian archive, we need to build
the squashfs-module out-of-tree.
Your release-tarball contains only the
Hi,
Daniel Baumann wrote:
What you are doing is taking upstream's code and adjusting it to
out-of-tree compilation. Since you are shipping patches (dpatch ...)
anyway, it still seems to be possible to prevent repackaging (which
should be tried as far as possible).
No. Atm you have to repackage
Roland Stigge wrote:
Provide a kind of kernel source stub, apply the upstream patch and our
new package specific patches/changes. Yes, ugly. Thanks for already
contacting upstream. :-)
That is uglier than repackaging the orig.tar.gz.
We need to accept native packages that were not
23 matches
Mail list logo
