specs", and LDFLAGS gets
"-specs=/usr/share/dpkg/pie-link.specs".
[1] as found in GCC's debian/rules.defs:
pie_archs = amd64 arm64 armel armhf i386 mips mipsel mips64el \
ppc64el s390x sparc sparc64 kfreebsd-amd64 kfreebsd-i386
Thanks,
--
Pino Toscano
signature.a
In data sabato 29 ottobre 2016 12:54:25 CEST, Paul Hardy ha scritto:
> James & Pino,
>
> On Sat, Oct 29, 2016 at 12:44 PM, Pino Toscano wrote:
> > In data sabato 29 ottobre 2016 20:34:31 CEST, James Clarke ha scritto:
> >> Your dependency is not satisfied because
In data sabato 29 ottobre 2016 20:34:31 CEST, James Clarke ha scritto:
> Your dependency is not satisfied because libwx-perl FTBFS:
> https://buildd.debian.org/status/package.php?p=libwx-perl&suite=unstable
More precisely, libwx-perl fails to build on hurd-i386 because of
bug #821194.
sysinfo() is not portable anyway, (b) might fail one day
if a platform provide a different implementation with the same name
(it's not standard after all).
Hope it helps -- feel free to ask more.
Thanks,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
the same way.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/a6a592ec046a1461c41d1e71ece58...@pino.toscano.name
making sure to ship mountpoint(1) and
its
man page everywhere, while the rest (i.e. the current content) only
on Linux.
IMHO (a) would be the cleaner solution, but of course any other idea is
welcome.
Thanks,
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
and then...
Anyway, I'm providing the patch I had, feel free to pick it up,
I cannot work on it at the moment.
--
Pino Toscano--- a/aclocal.m4
+++ b/aclocal.m4
@@ -271,12 +271,15 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V
nto-qnx)
test -z "[$]2" || eval "[$]2=
2 would be "ENOENT", and so on.
Please do not accept this workaround, which is unreliable and not
suitable for upstream.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
On 2014-10-22 10:59, Svante Signell wrote:
On Wed, 2014-10-22 at 10:29 +0200, Pino Toscano wrote:
On 2014-10-22 10:21, Svante Signell wrote:
> On Wed, 2014-10-22 at 01:21 +0200, Samuel Thibault wrote:
>> Svante Signell, le Tue 21 Oct 2014 12:34:22 +0200, a écrit :
> +
ib has g_strdup_printf, so just make use of it instead of doing
custom malloc code; also, use g_free instead of free.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/9ca0ed59b99f7c0d53979596f64dd...@pino.toscano.name
reveals that the package builds fine. The
attached patch adds hurd-i386 to the list.
This was already bug #712975. Please do *look* at packages, before
opening new bugs.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
On 2014-09-25 14:05, Svante Signell wrote:
Hi Pino
On Thu, 2014-09-25 at 10:08 +0200, Pino Toscano wrote:
On 2014-09-24 19:11, Philipp A. Hartmann wrote:
> I would probably do it like this (untested):
>
> const char *path =
> QFile::encodeName(fi.absoluteFilePath(
dangling pointer.
const QByteArray path = QFile::encodeName(fi.absoluteFilePath());
and then use path.constData() whenever needed.
std::vector s(sb.st_size + 1);
Please use QByteArray instead.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a
On 2014-06-03 13:36, Svante Signell wrote:
On Tue, 2014-06-03 at 13:18 +0200, Pino Toscano wrote:
> And it might be so that the Debian
> Maintainer choose to approve the patch before upstream,
Or it can be the other way round, where maintainers do want
issues/patches filed/fixed up
On 2014-06-03 13:09, Svante Signell wrote:
On Tue, 2014-06-03 at 12:53 +0200, Pino Toscano wrote:
On 2014-06-03 12:19, Svante Signell wrote:
> Source: cups-pk-helper
> Version: 0.2.5-2
> Severity: important
> Tags: patch
> User: debian-hurd@lists.debian.org
> Use
skills to search into bug/issue trackers or
in VCSes. This will avoid duplicating work already done by someone
else.
Thanks,
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian
ear:
https://github.com/mpruett/audiofile/commit/34c261034f1193a783196618f0052112e00fbcfe
Upstream has just not released a new version since then.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
s
not installed). GNOME team: if you could help on this, that would be
great.
Thanks,
--
Pino Toscano--- a/debian/control.in
+++ b/debian/control.in
@@ -26,7 +26,7 @@ Build-Depends: cdbs (>= 0.4.41),
desktop-file-utils,
appdata-tools,
gsettings
stallation
so I'm inclined to say this specific issue is Hurd-specific, yes.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/05d9
)
b) fix pthread_key_create in Hurd's libpthread, changing it to
__pthread_key_create and declaring pthread_key_create as strong
alias, just like it is done in NPTL
IMHO most probably (b) is the most realistic and easy to do.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hur
I have no idea what these files represent, did you find that out?
I can see these entries on GNU/Linux. Will this work on Hurd too or
should the build/installation of them be disabled?
Also, our procfs is currently read-only, so this tool would fail at the
moment.
--
Pino Toscano
--
To UNSUBSCR
m release 2.4.0.
[1] https://github.com/python-imaging/Pillow/pull/511
[2]
https://github.com/python-imaging/Pillow/commit/cb309c9f59c6d4d9511112d0377b97c0b1a35a13
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
On 2014-04-17 09:45, Samuel Thibault wrote:
emacs24 currently FTBFS due to using a linux-only header, I guess
some
people would be interested in fixing it :)
Do you mean like #725099?
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of
386 Depends on libbz2-1.0 [ hurd-i386 ] <
none > ( none ) can't be satisfied!
Attached patch adds library udeb needed by recent hurd versions.
Or even better, we just disable the bz2 support in the udeb build,
since it is not much useful during the Debian installation.
--
Pino Tosca
ld system abuses a bit the
parallel build, using more jobs than those requested.
Luckly it can be disabled, and #714084 is exactly about it.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
bmemcached version in unstable (not the one in
experimental though) uses.
It is pending a transition, so no need to ping/poke that one.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
y.
For the record, this is the query I used:
Maybe a way to avoid the (few) cases where linux/i386 is lagging behind
(due to FTBFS) could be running it against amd64 as well, and not
considering the sources not appearing in both.
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-h
passing a
> compilation parameter. I've done so for armel and sh4, so only armhf
> will switch to double.
My option goes on keeping the status quo of qreal as it was, on
architectures that managed to build qtbase-opensource-src already.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
sing the file/dir notifications, etc), not building
on that $OS until there is native folder watcher implemented
You should ask upstream which way they prefer/want, so eventual porting
efforts could go according to that.
Note that I did not inspect owncloud-client further for other prorting
eed to do this ENODATA→EPIPE mapping
> > themselves too.
>
> This is not part of my patch. Address this to upstream/debian
> maintainer directly.
I don't care whether it is yours or not, I just reviewed it since all
the proposed changes are now discussed with pkg-owncloud people.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
maintaining glibc, with the help of Samuel and Thomas
- help maintaining arch-specific packages
- triage and fix arch-specific bugs
- help Samuel maintaning the "exodar" porter box
I am a DD.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
sted regarding fcntl.h).
> #ifdef _WIN32
> #include
> #include
> @@ -50,6 +54,11 @@
> #define geteuid() 0
> #endif
>
> +#ifndef ENODATA
> +#define ENODATA EPIPE
> +#endif
This may be problematic. c_copy in src/std/c_file.c uses ENODATA as
errno in a couple of er
Hi,
Alle martedì 13 agosto 2013, Pino Toscano ha scritto:
> it seems the recent upgrade of libparted0debian1 from 2.3-13 to
> 2.3-14 makes the Hurd unbootable (boot stucks right after trying to
> startup the essential servers).
Update: the version 2.3-15 of parted allows to boot safely
[0]
http://snapshot.debian.org/archive/debian/20130509T215232Z/pool/main/p/parted/libparted0debian1_2.3-13_hurd-
i386.deb
Sorry for the inconvenience,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
nk" much
similar to a bind mount.
Indeed, setting up a firmlink translator and trying the commands earlier
mentioned in this bug (#714733) gives the same failure, while they work
when the root directory of both source and destination is not under a
firmlink-ed node.
Though, I have not investigated
> Additionally a lot of patches are pending (due to the long freeze
> period) see e.g.
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=hurd;users=debian-h
> u...@lists.debian.org so the percentage could be much higher.
"a lot of patches" is surely not true (and we had the a similar amount
also in non-freeze period), and a number of those won't give actually
much.
With the above changes and Michael Banck's note that it is a "Debian
GNU/Hurd port release", it'd be good IMHO.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
tag 704998 + pending
thanks
Alle venerdì 12 aprile 2013, Guillem Jover ha scritto:
> On Fri, 2013-04-12 at 12:02:54 +0200, Pino Toscano wrote:
> > Alle lunedì 8 aprile 2013, Guillem Jover ha scritto:
> > > A dist-upgrade broke the system as the hurd package got upgraded
>
in hurd-libs0.3 are in a multiarch libdir,
unlike the old location in hurd, so there is nothing which should have
prevented unpacking/configuring hurd-libs0.3 with hurd < 20130226-2.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
red flag among these before I submit the removal
> request?
No red flags from my side.
Thanks for this cleanup,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
ig and
> libx11-dev (neither was installed by apt-get build-dep hurd, or
> build-essential or devscripts).
Those have been added by Samuel in the packaging repository some time
ago, and will be part of the next upload.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
ng like that if it helps with
> porting;
You still seem to assume there must be some magic MAX constant giving
you some upper limit...
Consider that Hurd does not provide PATH_MAX, I personally think it
would be a mistake providing the two XATTR_*_MAX defines just for the
sake of applications not actually checking their return values.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
lution (although no patch for
now).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
lling of
the payload data is not done, which makes things like D-Bus or gamin not
work.
I saw glib has the API wrapping for socket credentials, but I decided to
skip supporting Hurd there until cmsgcred would actually work on Hurd.
(Of course, anybody else is free to prepare such patch.)
--
ross
compiling), so just a notice would be enough.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
e these packages when resolving build-dependencies for
> other packages in the main repo? One example is clamav. If not,
> there is not much use having those packages at debian-ports (except
> usage of themselves)
http://lists.debian.org/debian-hurd/2012/10/msg00013.html
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
check)? With both versions there is a
failure and a stuck test in libtest/unittest, and a failed test
application_doesnotexist_BINARY. On linux/x86_64, the tests of 1.0.8
later stuck, while the tests of 1.0.12 all pass.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
rn XMLString::transcode(curDir, manager);
> +XMLCh *ret = XMLString::transcode(curDir, manager);
.. this, which has an indentation change.
> A new patch attached. OK now?
With the above fixed, yes.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
not forget to:
a) send the patch upstream
b) send the updated patch to the Debian bug, otherwise there's only
and old (and wrong) patch
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Alle venerdì 5 ottobre 2012, Svante Signell ha scritto:
> On Fri, 2012-10-05 at 15:13 +0200, Pino Toscano wrote:
> > Alle venerdì 5 ottobre 2012, Svante Signell ha scritto:
> > > On Fri, 2012-10-05 at 13:59 +0200, Pino Toscano wrote:
> > > > Alle venerdì 5 ottobre 2
Alle venerdì 5 ottobre 2012, Svante Signell ha scritto:
> On Fri, 2012-10-05 at 13:59 +0200, Pino Toscano wrote:
> > Alle venerdì 5 ottobre 2012, Svante Signell ha scritto:
> > > Follow-up questions:
> > > 1) What to do about the Debian bug #599789
> > > - upl
d upstream, and
the 4.x serie is the active one.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
me, len, "%s/%s", directory, ent->d_name);
Just realloc the fname buffer if the new len is greater than the old one
(which needs to be saved), otherwise the current patch just does an
inefficient malloc/free job every iteration which (most probably
upstream won't like).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
ated (but
nothing related to it).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
succeed that does not work - that only results in that
> the execution get stuck in the loop.
What are the exact C strings passed as arguments to rename()?
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
> I just changed that block of code to use a different variable name
> rather than errno (see attached patch). Does this make sense?
Yes, it does. (I usually put "errnum", but it's mostly style.)
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
e something like this:
class Buffer
{
public:
Buffer(char *b) : b_(b) {}
~Buffer() { free(b); }
operator char*() { return b_; }
private:
char *b_;
}
and then
Buffer b(get_current_dir_name());
// use b as if it were a char*
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Hi,
Alle martedì 31 gennaio 2012, Pino Toscano ha scritto:
> (a proper subject would have helped a bit more...)
>
> Alle martedì 31 gennaio 2012, Svante Signell ha scritto:
> > Be careful not to upgrade to initscripts 2.88dsf-21 or 2.88dsf-22
> > is you want to play saf
already (which has been fixed for Hurd,
unlike that copy that fails)
Furthermore, please disable (or make it optional) the use of ccache;
while it may be useful during test builds, it is close to useless when
doing builds in buildds.
Last, I attached a preliminary version of patch for Hurd su
as the rred segfault problem, and 0.9.4
> seems to FTBFS (from trhe buildds). What to do?
... the rred issue seems to be solved with apt 0.9.5.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
create a dummy target as you did for libusb?
sane-backend-extras and libdrm can be simply ignored.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
ws about
unfinished patches, can you please just do all the discussion on d-hurd@
and only when the patch is okay send it to the bug report?
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
an
empty getCurrentExecutablePath() like this:
| #elif OS(HURD)
| CString getCurrentExecutablePath()
| { return CString(); }
[1] http://www.unix.com/man-page/FreeBSD/5/procfs/
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
< sb.st_size)
| resultString = CString(readLinkBuffer, result);
| free(readLinkBuffer);
| return resultString;
note in this case the CString constructor does not need the \0 byte
at the end of the buffer (since it takes the char count), but take care
you should have elsewhere done like
readLinkBuffer[result] = 0;
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
, like the one used for the test.
I reported this issue to bug-hurd[1], upstream's Hurd development
mailing list, and apparently it is not easy to fix.
[1] http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg0.html
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Alle domenica 5 febbraio 2012, Samuel Thibault ha scritto:
> Pino Toscano, le Sun 05 Feb 2012 12:56:39 +0100, a écrit :
> > note I don't think it should be forwarded upstream, as it is not
> > clean and kind of working around the lack of realtime signals in
> > Hurd.
tream, as it is not clean and kind of working around the lack of
realtime signals in Hurd.
--
Pino Toscano
--- a/src/c/unixint.d
+++ b/src/c/unixint.d
@@ -1073,6 +1073,8 @@
{
#ifdef SIGRTMIN
# define DEFAULT_THREAD_INTERRUPT_SIGNAL SIGRTMIN + 2
+#elif defined(__GNU__)
+# define DEFA
ompiled on Hurd (but I didn't
investigate neither mono nor ecl that much regarding to this).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
ailing list. A
> bcc?
No, he just bounced the email to the ml (see the Resent-* headers).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
tils sysv-rc initscripts bootlogd
A solution for this is already being investigated with Roger Leigh.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Alle giovedì 26 gennaio 2012, Svante Signell ha scritto:
> On Thu, 2012-01-26 at 19:10 +0100, Pino Toscano wrote:
> > Alle giovedì 26 gennaio 2012, Svante Signell ha scritto:
> > > x gch6, still unsolved!
> >
> > theorically this version in ports could
ly cross-buildable) from another architecture
> hdf5: ports: 1.8.4-5, sid:1.8.8-5: remove
once the hdf5 transition (which is ongoing) is complete, yes
> sudo: ports: 1.8.3-2 sid: 1.8.3-3: FTBFS: build-dep on
> libselinux1-dev
I see an empty folder in the pool? anyway, it's #65
eglibc),
I think we could also fix unlink() on the Hurd bits of glibc to give
EINVAL on NULL parameter, or that would be considered (too) broken code
anyway?
> or should I go ahead and submit the attached patch via the BTS?
+1 on the patch already sent (you can usually avoid sending changes
size);
> +int sc_get_cache_dir(sc_context_t *ctx, char *buf);
other than the problem above, this looks like a public function (as also
the .exports file confirms) of a public library, so changing its
signature is an API and ABI break; this needs to be discussed upstream
directly
--
Pino
Alle lunedì 19 dicembre 2011, Samuel Thibault ha scritto:
> Pino Toscano, le Mon 19 Dec 2011 00:25:57 +0100, a écrit :
> > - op/stat.t: on my VM `ls /dev` hangs now, so I had to disable
> >
> > (with the attached patch) 6 checks in it
>
> This is odd, I don'
I'm missing anything, the following tests could not need any
more skip on Hurd:
- syslog.t (hurd_test_todo_syslog.diff)
- socketpair.t (hurd_test_skip_socketpair.diff)
- recv.t (hurd_test_skip_recv.diff)
- libc.t (hurd_test_skip_libc.diff)
--
Pino Toscano
--- a/t/op/stat.t
+++ b/t/op/s
limit the flush_lines according to the current platform */
> flush_lines = IOV_MAX;
> +#endif
conditional yes, but on the IOV_MAX definition, not on a per-OS check.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
sively (e.g. rb_dump_backtrace_with_lines (sets binary_filename) ->
fill_lines -> follow_debuglink (sets binary_filename) -> fill_lines ->
...). With your patch, it would also cause the binary_filename pointer
to be stale over runs.
--
Pino Toscano
signature.asc
Description: Thi
Alle giovedì 29 settembre 2011, Svante Signell ha scritto:
> On Thu, 2011-09-29 at 10:33 +0200, Pino Toscano wrote:
> > Alle giovedì 29 settembre 2011, Samuel Thibault ha scritto:
> > > Could somebody have a look at the non-installability of
> > > gobject-introspecti
n rebuilt
succesfully for the pytthon 2.7 transition.
I'd rebuild it with nocheck, and then try again with gtksourceview3.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
attached one, but never got around polishing an
sending it. Should do a bit more allocations than the code using
PATH_MAX-sized arrays, but also quite less OS-specific code paths to
maintain (the __GLIBC__ one is valid for basically almost all the Linux
developers, so won't rot easily).
ransition involving it, see #630511.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
there.
To the specific bug, who posted the patch also said that is untested
other than "it compiles". If you want to NMU something, then you must be
sure it also *works*.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Alle sabato 23 luglio 2011, Samuel Thibault ha scritto:
> Pino Toscano, le Sat 23 Jul 2011 21:41:41 +0200, a écrit :
> > since a couple of days, I've started trying to integrate sysvinit
> > in Debian/Hurd, and I got some positive results (but also some
> > problems).
>
nd runttys init scripts.
With the premise that I might have got something totally wrong, what do
you think about this? Feedback of any kind would be welcome.
[1] http://lists.gnu.org/archive/html/bug-hurd/2006-02/msg00081.html
[2] called by killall15, invoked in /etc/rc6.d/S20sendsigs (w
lly tracked without getting also
the kfreebsd bugs.
What about a generic:
User: debian-de...@lists.debian.org
Usertags: wildcard-archs
?
A couple of notes for packages in your list:
- google-gadgets, qtmobility
they have been fixed already in their git packaging repository,
so their next
Alle mercoledì 9 febbraio 2011, Pino Toscano ha scritto:
> Alle domenica 6 febbraio 2011, Cyril Brulebois ha scritto:
> > xorg-server 1.9 build-depends on mesa with a version higher than
> > the one available in sid, and both mesa 7.9 and 7.10 FTBFS on
> > non-Linux for now. I
ose
> FTBFS, so I'd appreciate if somebody could have a look. You can send
> patches to debian-x@ or to the BTS.
Some months ago I managed to compile mesa 7.8.2 (from exp) on Hurd. I
just rebased the patches I did, and started a build of mesa 7.10 on
Hurd.
(I was waiting for mesa to compile o
provided in
Debian (you can pick it from snapshot.debian.org), as gdb >= 7.1 does
not work correctly on Hurd.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
le/directory locking in Hurd?
Yes, there are. I just sent a message to the bug, explaining shortly the
issue (ours), and a fix in the python-apt packaging that could help us
to build it without the test suite (until the file locking is not
fixed).
Thanks,
--
Pino Toscano
signature.asc
Descriptio
o, but I now bisected this down to perlmagick
> being installed vs. not being installed. Involving Pino Toscano who
> recently did some imagemagick patching
> (cf. <http://bugs.debian.org/551017>) -- Pino, please note that I'm not
> saying that you're responsible for
Hi,
> On Thu, 2009-12-17 at 22:47:40 +0100, Pino Toscano wrote:
> > The solution I found (patch attached) is to apply the patches before the
> > configure run. It looks working correctly in both my Hurd VM, and on
> > strauss.
> >
> > --- a/debian/rules
> >
patch is
applied, so such run will always fail.
The solution I found (patch attached) is to apply the patches before the
configure run. It looks working correctly in both my Hurd VM, and on strauss.
--
Pino Toscano
--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,7 @@
build: build-arch build-ind
92 matches
Mail list logo
