Hi *,
why is glibc so old on kfreebsd, can anyone see to getting it fixed?
i have packages failing due to missing reallocarray()…
TIA,
//mirabilos
PS: excuse brevity, cat lies on my arm
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if
Your message dated Sun, 09 Dec 2018 21:50:07 +
with message-id
and subject line Bug#916004: fixed in makefs 20100306-7
has caused the Debian Bug report #916004,
regarding makefs FTBFS with glibc 2.28
to be marked as done.
This means that you claim that the problem has been dealt with.
If
Source: makefs
Version: 20100306-6
Severity: serious
Tags: ftbfs buster sid
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/makefs.html
...
/build/1st/makefs-20100306/builddir/usr.sbin/makefs/nbsrc/sbin/mknod/pack_dev.c:
In function 'pack_native':
/build/1st/makefs-20100306/bu
ybe not yet. I need to fix the type names first.
Fixed in glibc-ports and glibc-ports-2.23 SVN r6029.
Please try to include this in a future glibc upload to experimental
and/or sid. Thank you.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
tags 822143 - patch + moreinfo
thanks
Steven Chamberlain wrote:
> Please could you update patches/kfreebsd/local-sysdeps.diff
> to SVN revision 6019, which adds some things that will be needed
> by kfreebsd 10.3 userland:
Oops, maybe not yet. I need to fix the type names first.
Regards,
--
Ste
Package: src:glibc
Version: 2.22-7
Severity: wishlist
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi Aurelien,
Please could you update patches/kfreebsd/local-sysdeps.diff
to SVN revision 6019, which adds some things that will be needed
by kfreebsd 10.3 userland:
Update sys/n
Steven Chamberlain writes:
> Steven Chamberlain wrote:
>> (I think this is causing the failure to install build-deps of
>> kfreebsd-10 in experimental, and it might affect other packages).
>
> Although on kfreebsd-amd64, where glibc is up-to-date in the buildd
> chroots,
Hi!
Steven Chamberlain writes:
> This happens on Sunday and Wednesday evenings (21:13):
>
> 13 21 * * 0,3 root
> PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
> setup-all-dchroots buildd
>
> but the binNMUs for glibc/2.22 on kfreebsd-i386 did
Steven Chamberlain wrote:
> (I think this is causing the failure to install build-deps of
> kfreebsd-10 in experimental, and it might affect other packages).
Although on kfreebsd-amd64, where glibc is up-to-date in the buildd
chroots, there is still something odd happening:
|
Hi Christoph,
This happens on Sunday and Wednesday evenings (21:13):
13 21 * * 0,3 root
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
setup-all-dchroots buildd
but the binNMUs for glibc/2.22 on kfreebsd-i386 didn't finish until just
after that time yesterday. P
Aurelien Jarno wrote:
> + * patches/kfreebsd/local-sysdeps.diff: update to revision 5932 (from
> + glibc-bsd):
> +- Fix consistency check for PIC code when built with GCC 5. Closes:
> + #817207.
Thanks Aurelien, that's brilliant!
I just tested and it has fixed the
0x memsz 0x flags rwx
It requires a writable and executable stack! which is rather rare, and
probably should be fixed in the affected libraries. The kfreebsd
buildds have disallowed executable stacks since DebConf15 though.
I'm not sure why glibc 2.22 causes any regression here;
Package: src:glibc
Version: 2.22-1
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi,
glibc/2.22 has a major problem on kfreebsd-i386. It built on the
buildds, but the compiled ld-2.22.so is broken as seen on buildd finzi
Steven Chamberlain wrote:
> Unfortunately gdb on kfreebsd doesn't handle threads very well, [...]
I changed the test runner to send a SIGABRT instead of SIGKILL; then
gdb returns a trace of the thread we are interested in:
| #0 memset () at ../sysdeps/x86_64/memset.S:93
| No locals.
| #1 0x000
Package: glibc
Version: 2.21-8
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
| misc/bug18240
| +-+
| TEST misc/bug18240:
| Timed out: killed the child process
Hi,
Aurelien Jarno wrote:
> On 2015-12-23 17:30, Samuel Thibault wrote:
> > So it looks like there are no /usr/include/sys files any more in the
> > kernel headers? If so we can just drop the statement. If you want to
>
> It seems it has been changed in the last kfreebsd-kernel-headers upload.
On 2015-12-23 17:30, Samuel Thibault wrote:
> Hello,
>
> The latest glibc upload, 2.21-5 failed to build:
>
> # Link to any headers found in the old locations first
> find /usr/include/sys -mindepth 1 \
> -exec ln -sf '{}' debian/include/sys ';'
Hello,
The latest glibc upload, 2.21-5 failed to build:
# Link to any headers found in the old locations first
find /usr/include/sys -mindepth 1 \
-exec ln -sf '{}' debian/include/sys ';'
find: `/usr/include/sys': No such file or directory
So it looks like ther
block 765468 by 764692
tags 764692 + patch
thanks
Hi,
To recap, glibc-2.19 no longer implements __FAVOR_BSD. Users of
netinet/tcp.h may have defined that to request a BSD version of
the tcphdr struct.
To fix this, we simply need to merge a change from gnu/netinet/tcp.h
into our unix/bsd/bsd4.4
tags 785796 + patch
thanks
Hi,
Now that all the kfreebsd buildds are upgraded to kfreebsd-10, it is
desirable to define F_DUPFD_CLOEXEC in glibc. I assume we don't
need to be able to build current glibc on an oldstable kernel any
more.
The patch for this is inline here:
https://bugs.debia
u,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- glibc-2.19/debian/sysdeps/kfreebsd.mk 2015-07-09 13:28:06.0 +0100
+++ glibc-2.19/debian/sysdeps/kfreebsd.mk 2015-09-05 20:23:27.708048223 +0100
@@ -16,6 +16,7 @@
else
KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/includ
Steven Chamberlain wrote:
> We can just do the same in kfreebsd.mk, using multiarch headers if
> they're found, or the old locations as a fallback.
Turns out this was not backward-compatible, because other packages
(libc0.1-dev) may create /usr/include/$(DEB_HOST_ARCH)/sys, having
some but not all
n
LINUX_ARCH_HEADERS are used in preference to LINUX_HEADERS, if they
are available.
We can just do the same in kfreebsd.mk, using multiarch headers if
they're found, or the old locations as a fallback.
It also means glibc can apply this patch before kfreebsd-kernel-headers
has made the change
Package: glibc
Version: 2.19-19
Severity: wishlist
Tags: patch
Hi,
We're hoping to move kfreebsd-kernel-headers' files to multiarch
path /usr/include/$(DEB_TARGET_MULTIARCH), so that headers of other
kernels are co-installable on a build machine (for cross-building and
bootstrapping).
Hey Steven!
On Thu, 2015-05-28 at 22:22:06 +0100, Steven Chamberlain wrote:
> Guillem Jover wrote:
> > In any case here's the patches I've prepared to send upstream. Only
> > build tested, though.
>
> Thanks for this.
Thank you for the review and testing.
> Patch 1 would have been a good workar
Hi Guillem,
Guillem Jover wrote:
> In any case here's the patches I've prepared to send upstream. Only
> build tested, though.
Thanks for this.
Patch 1 would have been a good workaround for Debian sid, if Andreas
had accepted it, but I don't think it should be permanent or go
upstream. I don't
200
Subject: [PATCH 1/3] include/c: Define F_DUPFD_CLOEXEC on kFreeBSD systems if
missing
The kernel of FreeBSD version 10 and higher supports this fcntl command,
but the system libc, in this case glibc, might not yet know about it.
Signed-off-by: Guillem Jover
---
include/c.h | 6 ++
1 file changed,
Ahoi!
Christoph Egger writes:
>> Ahoi!
>>
>> Petr Salinger writes:
>>> what is currently used kernel on buildd for kfreebsd-* ?
>>>
>>> According to last log of util-linux (22 May 2015/fayrfax.debian.org):
>>> Kernel: GNU/kFreeBSD 9.0-2-amd64 kfreebsd-amd64 (x86_64)
>>
>> You are indeed right. A
upgraded to 10.1. Thanks for
pointing this out.
Therefore please don't apply this patch to glibc yet... we'll need
a plan B.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe
On Thu, 2015-05-28 at 10:07 +0200, Christoph Egger wrote:
> > Petr Salinger writes:
> >> what is currently used kernel on buildd for kfreebsd-* ?
uname -a:
GNU/kFreeBSD falla 10.1-0-amd64 #0 Tue, 07 Apr 2015 22:13:19 +0100 x86_64 amd64
QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD
GNU/kFreeBSD fils
debian-adm...@lists.debian.org is the right mailadress for that side
Christoph Egger writes:
> Ahoi!
>
> Petr Salinger writes:
>> what is currently used kernel on buildd for kfreebsd-* ?
>>
>> According to last log of util-linux (22 May 2015/fayrfax.debian.org):
>> Kernel: GNU/kFreeBSD 9.0-2-amd
Ahoi!
Petr Salinger writes:
> what is currently used kernel on buildd for kfreebsd-* ?
>
> According to last log of util-linux (22 May 2015/fayrfax.debian.org):
> Kernel: GNU/kFreeBSD 9.0-2-amd64 kfreebsd-amd64 (x86_64)
You are indeed right. All buildds are still running wheezy. Peter from
DSA u
sion: 5714
Modified:
trunk/glibc-ports/kfreebsd/bits/fcntl.h
Log:
provide F_DUPFD_CLOEXEC of POSIX.1-2008, implemented in kfreebsd-10
Modified: trunk/glibc-ports/kfreebsd/bits/fcntl.h
===
--- trunk/glibc-ports/kfreebsd/bits/fcntl.h
Steven Chamberlain, le Wed 27 May 2015 00:52:54 +0100, a écrit :
> (I think that'd be against the rules if the change isn't in sid).
Yes.
Samuel
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive
Dear Glibc Maintainers,
Please try to upload the http://bugs.debian.org/785796 bugfix to sid as
soon as possible, and it would really help us out. Thanks.
Christoph Egger wrote:
> I understand the thing below is the intended fix for util-linux? Is
> there some planned timeline to get i
stevenc-gu...@alioth.debian.org writes:
> Author: stevenc-guest
> Date: 2015-05-24 14:00:19 + (Sun, 24 May 2015)
> New Revision: 5714
>
> Modified:
>trunk/glibc-ports/kfreebsd/bits/fcntl.h
> Log:
> provide F_DUPFD_CLOEXEC of POSIX.1-2008, implemented in kfreebsd-10
>
>
>
retitle 785796 glibc: kfreebsd should define F_DUPFD_CLOEXEC
reassign 785796 src:glibc
found 785796 glibc/2.19-18
affects 785796 src:util-linux
tags 785796 + patch
thanks
Hi,
util-linux FTBFS on kfreebsd as it assumes fcntl supports
F_DUPFD_CLOEXEC (of POSIX.1-2008):
Andreas Henriksson wrote
Processing commands for cont...@bugs.debian.org:
> tags 768108 + pending
Bug #768108 [src:kfreebsd-10] kfreebsd-10: CVE-2014-8476: getlogin kernel
memory disclosure
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
768108: http://bugs.debian.o
Processing commands for cont...@bugs.debian.org:
> tags 767583 + pending
Bug #767583 [src:kfreebsd-10] kfreebsd-10: ar9300_devid.h license restricts
modification
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
767583: http://bugs.debian.org/
Cyril Brulebois wrote:
> Steven Chamberlain (2014-10-26):
> > Hi Christoph,
> >
> > Please could you make this final upload this to unstable, if you have
> > time before midnight UTC?
>
> If you're trying to beat the clock, make that 1952Z.
Also, I'm sorry I didn't ask for this upload sooner;
Steven Chamberlain wrote:
> Christoph Egger wrote:
> > Shall I upload to experimental instead? So things are available for
> > testing in any case?
>
> Sure, sounds like a good idea. Likewise for freebsd-utils if you
> would please.
Also freebsd-buildutils if you like :)
Thanks,
Regards,
--
St
Christoph Egger wrote:
> Shall I upload to experimental instead? So things are available for
> testing in any case?
Sure, sounds like a good idea. Likewise for freebsd-utils if you
would please.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-
Steven Chamberlain writes:
> Cyril Brulebois wrote:
>> Steven Chamberlain (2014-10-26):
>> > Hi Christoph,
>> >
>> > Please could you make this final upload this to unstable, if you have
>> > time before midnight UTC?
>>
>> If you're trying to beat the clock, make that 1952Z.
>
> Thanks, yeah t
Cyril Brulebois wrote:
> Steven Chamberlain (2014-10-26):
> > Hi Christoph,
> >
> > Please could you make this final upload this to unstable, if you have
> > time before midnight UTC?
>
> If you're trying to beat the clock, make that 1952Z.
Thanks, yeah that was the idea.
In that case, please
Steven Chamberlain (2014-10-26):
> Hi Christoph,
>
> Please could you make this final upload this to unstable, if you have
> time before midnight UTC?
If you're trying to beat the clock, make that 1952Z.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Hi Christoph,
Please could you make this final upload this to unstable, if you have
time before midnight UTC?
stevenc-gu...@alioth.debian.org wrote:
> Author: stevenc-guest
> Date: 2014-10-26 18:17:06 + (Sun, 26 Oct 2014)
> New Revision: 5670
> +kfreebsd-10 (10.1~svn273581-1) unstable; urgen
Processing commands for cont...@bugs.debian.org:
> tags 766275 + pending
Bug #766275 [src:kfreebsd-9] kfreebsd-9: CVE-2014-3711: memory leak in
sandboxed namei lookup
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
766275: http://bugs.debian
On 04/10/14 20:33, Petr Salinger wrote:
>>> -@@ -6,8 +6,7 @@
>>> +@@ -6,8 +6,7 @@ SRCS=camlib.c scsi_cmdparse.c scsi_all
>> Do you know how to turn that off? I don't seem to get that, with
>> quilt 0.60-10 when I do:
>> $ quilt refresh -pab --no-index --no-timestamp
> I played with it no
On 13/10/14 00:37, Steven Chamberlain wrote:
> Would a BSD-style netinet/tcp.h be a good candidate to ship in libbsd-dev?
...and also netinet/udp.h, due to udphdr.
More packages (unported yet) that could benefit from BSD struct
tcphdr/udphdr definitions are:
* ntop
* pchar
* scamper
* rtp
Hi Guillem,
Would a BSD-style netinet/tcp.h be a good candidate to ship in libbsd-dev?
> On 12/10/14 16:45, Steven Chamberlain wrote:
>> glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the
>> BSD version of struct tcphdr in netinet/tcp.h cannot be used, [...]
clone 764692 -1
reassign 764692 libc0.1-dev
found 764692 glibc/2.19-11
retitle 764692 glibc: removed __FAVOR_BSD from features.h
thanks
Hi,
On 12/10/14 16:45, Steven Chamberlain wrote:
> glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the
> BSD version of struct tcp
Hi Christoph,
On 22:50, stevenc-gu...@alioth.debian.org wrote:
> -fuse4bsd (0.3.9~pre1.20080208-9) UNRELEASED; urgency=low
> +fuse4bsd (0.3.9~pre1.20080208-9) unstable; urgency=low
Please upload this for me if you can. (There's not get-orig-source
target, but the orig.tar.gz is unchanged since t
On 22:06, Steven Chamberlain wrote:
> On 22:43, Christoph Egger wrote:
> > Christoph Egger writes:
> > > However fuse4bsd ships a mount_fusefs binary and carrys a dependency
> > > on kldutils so it may not be totally useless.
> >
> > Though that could (and should?) be added to freebsd-utils.
>
>
On 22:43, Christoph Egger wrote:
> Christoph Egger writes:
> > However fuse4bsd ships a mount_fusefs binary and carrys a dependency
> > on kldutils so it may not be totally useless.
>
> Though that could (and should?) be added to freebsd-utils.
Aha, we could move the binary there and Provides:/C
On 22:34, Christoph Egger wrote:
> hmm are we going to have a kernel without its own fuse.ko in jessie?
I don't think so. Only if perhaps this was a sid chroot on a wheezy
9.0 kernel, in which case, fuse isn't expected to work anyway?
> are we going to remove 9 completely?
Of course, I assumed
Christoph Egger writes:
> However fuse4bsd ships a mount_fusefs binary and carrys a dependency
> on kldutils so it may not be totally useless.
Though that could (and should?) be added to freebsd-utils.
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Ha
Christoph Egger writes:
>> A lot of packages still depend on that (empty) package:
>> * avfs
>> * bindfs
>> * curlftpfs
>> * encfs
>> * exfat-fuse
>> * fuse-convmvfs
>> * fusedav
>> * gphotofs
>> * jmtpfs
>> * mythtvfs
>> * plptools
>> * python-fuse
>> * rofs
>> * s3ql
Hi!
Steven Chamberlain writes:
>> Btw: should we remove fuse4bsd from unstable? fuse is now part of the
>> main kernel.
>
> Aha I was wondering about that; I'm not familiar with fuse, but seemed
> to remember the package was going away.
>
> A lot of packages still depend on that (empty) pac
On 22:10, Christoph Egger wrote:
> Christoph Egger writes:
> > Btw: should we remove fuse4bsd from unstable? fuse is now part of the
> > main kernel.
>
> kfreebsd-8 should also go I guess?
That's long-gone. (Some packages are Built-Using it, so some tools
think it still exists in sid).
kf
On 22:08, Christoph Egger wrote:
> Steven Chamberlain writes:
> > Please could you upload freebsd-smbfs (10.1~svn272500-1) next.
>
> Steven Chamberlain writes:
> > and also freebsd-utils (10.1~svn272167-1) please (in any order).
>
> Both uploaded!
>
> That should be the most important ones rig
Christoph Egger writes:
> Btw: should we remove fuse4bsd from unstable? fuse is now part of the
> main kernel.
kfreebsd-8 should also go I guess?
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
pgpmb1r0qMG92.pgp
Descripti
Hi!
Steven Chamberlain writes:
> Please could you upload freebsd-smbfs (10.1~svn272500-1) next.
Steven Chamberlain writes:
> and also freebsd-utils (10.1~svn272167-1) please (in any order).
Both uploaded!
That should be the most important ones right (apart from ufsutils maybee)?
Btw: should
On 20:12, Steven Chamberlain wrote:
> Please could you upload freebsd-smbfs (10.1~svn272500-1) next.
and also freebsd-utils (10.1~svn272167-1) please (in any order).
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with
Hello,
Please could you upload freebsd-smbfs (10.1~svn272500-1) next.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.
Steven Chamberlain writes:
> That won't be satisfied by 10.1~4 as it is less than 10.1;
> same for libgeom-dev
Grrf. Thanks for catching!
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
--
To UNSUBSCRIBE, email to debian-bsd-
Hi Christoph,
christ...@alioth.debian.org wrote:
> - kfreebsd-kernel-headers (>= 9.1-2~),
> + kfreebsd-kernel-headers (>= 10.1~4~),
That's correct, but did you also set a dep-wait on >> 10.1 ?
https://buildd.debian.org/status/package.php?p=zfsutils&suite=sid
That won't be satisfied by 10.1~4 as
Ahoi!
Steven Chamberlain writes:
>> > -kfreebsd-10 (10.1~svn272463-1) UNRELEASED; urgency=medium
Uploaded
> and use those to build kfreebsd-kernel-headers 10.1~4 from SVN trunk.
As well
> then build freebsd-libs 10.1~svn272464-1 from SVN trunk, and install:
Waiting for DINSTALL to finish
>
Steven Chamberlain wrote:
> You can begin building this now if you like, and then upload to unstable
> (source-only), as soon as you see the d-i Beta 2 announcement:
>
> On 20:57, stevenc-gu...@alioth.debian.org wrote:
> > New Revision: 5595
> [...]
> > -kfreebsd-10 (10.1~svn272463-1) UNRELEASED;
Hi Christoph,
You can begin building this now if you like, and then upload to unstable
(source-only), as soon as you see the d-i Beta 2 announcement:
On 20:57, stevenc-gu...@alioth.debian.org wrote:
> New Revision: 5595
[...]
> -kfreebsd-10 (10.1~svn272463-1) UNRELEASED; urgency=medium
> +kfreebs
-@@ -6,8 +6,7 @@
+@@ -6,8 +6,7 @@ SRCS= camlib.c scsi_cmdparse.c scsi_all
This is mostly not useful to have in the patches. And reviewing the
diff-of-diffs to see what changed is made more difficult by this.
Do you know how to turn that off? I don't seem to get that, with
quilt 0.60-
On 14:47, Petr Salinger wrote:
> BTW, many thanks for your time spent on 10.1 preparing.
Thanks for you help! It is the first time I've updated the userland
to newer upstream, happily it seems to have worked okay with a
test-rebuild of glibc and some essential and toolchain packages. I
Hi Petr,
On 16:47, ps-gu...@alioth.debian.org wrote:
>trunk/freebsd-libs/debian/patches/02_libcam.diff
>trunk/freebsd-libs/debian/patches/04_libkvm.diff
>trunk/freebsd-libs/debian/patches/05_libipx.diff
>trunk/freebsd-libs/debian/patches/08_libdevstat.diff
>trunk/freebsd-libs/d
On 16:02, Christoph Egger wrote:
> Petr Salinger writes:
> > BTW, many thanks for your time spent on 10.1 preparing.
>
> Speaking of which .. can we go to usntable there?
We can do this today, I think! The d-i Beta 2 builds are finished, but
just waiting for an official announcement in case any
s, I would like to again verify
at least build of glibc. It is now inside testsuite ...
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.lnx.
Petr Salinger writes:
> BTW, many thanks for your time spent on 10.1 preparing.
Speaking of which .. can we go to usntable there?
Christoph
--
9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer
--
To UNSUBSCRIBE, email to debian-bsd-requ...@
Did you shorten it to "$FreeBSD$" by hand?
It might be nice to do this automatically in the get-orig-source step.
After some testing:
The keywords are not expanded for old svn:
$ svn --version
svn, version 1.6.17 (r1128011)
compiled Jun 7 2013, 08:51:48
$ svn export https://svn0.us-west.fre
Hi.
How did you strip the revision tag here?
- * $FreeBSD: stable/10/sys/sys/queue.h 251887 2013-06-18 02:57:56Z lstewart $
+ * $FreeBSD$
Currently if I get-orig-source then the patches don't cleanly apply.
Refreshing them would only change it to "$FreeBSD: releng/10.1/..." etc.
Did you
Hi Petr,
How did you strip the revision tag here?
On 08:24, ps-gu...@alioth.debian.org wrote:
> --- branches/experimental/kfreebsd-10/debian/patches/userland.diff
> 2014-09-28 23:41:28 UTC (rev 5574)
> +++ branches/experimental/kfreebsd-10/debian/patches/userland.diff
> 2014-10-04 08:24:1
tags 762404 + patch
thanks
Hi,
> Encountered regressions that don't match expected failures
> (debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc):
> tst-execstack-needed.out, Error 1
> tst-execstack.out, Error 1
> tst-execstack-prog.out, Error 1
I decided to simply add those t
Package: glibc
Version: 2.19.11
Severity: serious
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
During a test rebuild for kfreebsd 10.1 transition, I noticed that glibc
fails to build from source already on kfreebsd 10.0:
Encountered regressions that don't match expected fai
Processing commands for cont...@bugs.debian.org:
> tags 755739 + pending
Bug #755739 [src:kfreebsd-10] VGA-mode newcons very slow
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
755739: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755739
Processing commands for cont...@bugs.debian.org:
> tags 750836 + pending
Bug #750836 [kfreebsd-kernel-headers] machine/atomic.h broken, missing
__compiler_membar macro
Added tag(s) pending.
> tags 756553 + pending
Bug #756553 [kfreebsd-kernel-headers] kfreebsd-kernel-headers missing
/usr/include
Hi!
I've pushed a git mirror of the svn repo to alioth, which in theory
should get updated on each svn commit, that can be used either to just
track the svn repository using read-only git:
<http://anonscm.debian.org/gitweb/?p=users/guillem/glibc-bsd.git>
or to bootstrap a gi
On 14/09/13 12:31, Robert Millan wrote:
> a/sys/boot/forth/beastie.4th
> -+++ b/sys/boot/forth/beastie.4th
> -@@ -123,6 +123,76 @@
> - 0 25 at-xy
> - ;
> -
> -+: tribute-art ( x y -- ) \ see tribute[bw]-logo
> -+2dup at-xy ." CEO Workstation" 1+
> -+1+
> -+2dup at-xy ." Nakat
What I like Git for mostly is its simple offline working, but that can
still be done locally just with `git init && git commit -a` inside an
SVN working copy. Providing a .gitignore file might be a nice convenience.
What about using git-svn on user side ?
(I didn't try it myself yet).
Petr
-
I possibly agree now with Robert we are better off not using Git for the
packaging repos, at least for now. Mostly it works okay, until
something throws the workflow off completely, then the way to fix it is
really not intuitive for most people.
What I like Git for mostly is its simple offline wo
Hi.
I opened a ticket in Alioth for this already:
https://alioth.debian.org/tracker/index.php?func=detail&aid=314307&group_id=1&atid=21
We (glibc-bsd) use script from subversion-tools,
and location of that script have changed.
Our post-commit hook script have to be altered
Hi Petr,
I opened a ticket in Alioth for this already:
https://alioth.debian.org/tracker/index.php?func=detail&aid=314307&group_id=1&atid=21
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". T
Can someone look at it ?
The current SVN is at revision 4614, but mailing list archive says:
http://lists.alioth.debian.org/pipermail/glibc-bsd-commits/2013-June/thread.html
Starting: Mon Jun 3 04:42:02 UTC 2013
Ending: Sat Jun 8 17:10:10 UTC 2013
Messages: 3
[Glibc-bsd-commits] r4512
2013/5/27 Guillem Jover
> Agreed, didn't want to post a summary yet, because I'm not confortable
> doing the switch until Robert and Aurelien have posted their opinions,
> given their amount of commits.
>
Not that I'm actively using it now... my last commit was 10 months ago.
But if you want my
Hi,
On 27/05/13 08:06, Petr Salinger wrote:
> - one common repository x repository per package
> repository per package
I just read that Gitweb on anonscm.d.o can now show a filtered index of
packages 'per project'. So with a repository per package, it is
possible to see a list of them e.g.:
Hi!
On Mon, 2013-05-27 at 09:06:33 +0200, Petr Salinger wrote:
> On Sun, 19 May 2013, Guillem Jover wrote:
> >I'd even volunteer to switch the repositories
>
> Outcome of discussion seems be:
>
> - use svn or git
> switch to git
>
> - packaging-only or full content
> packaging-only
>
> - o
On Sun, 19 May 2013, Guillem Jover wrote:
I'd even volunteer to switch the repositories
Outcome of discussion seems be:
- use svn or git
switch to git
- packaging-only or full content
packaging-only
- one common repository x repository per package
repository per package
Petr
--
To U
On 20/05/13 17:54, Steven Chamberlain wrote:
> On 20/05/13 07:56, Petr Salinger wrote:
>> - one common repository x repository per package
>> I slightly prefer one common.
> And I think the commit log of Git works globally, [...]
Also I think it would be near impossible to do merges, if multipl
Hi Petr,
On 20/05/13 07:56, Petr Salinger wrote:
> - one common repository x repository per package
> I slightly prefer one common.
What might be the advantage of this?
And could submodules possibly provide the same convenience? (A
repository that points to all the others).
A downside to a
py the upstream code to glibc-bsd.git/$package/ and have
lots of .gitignore magic. Both does not sound appealing if you ask me.
Or at least, not better than the status quo.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description:
I'd like to propose switching and splitting the glibc-bsd repo from svn
to git repositories
My position:
- use svn or git
It does not matter for me.
- packaging-only or full content
I strongly prefer packaging-only.
- one common repository x repository per package
I slightly prefe
Hi Guillem!
This sounds like a good idea. Git would seem easier to work with, for
exactly the things you mentioned.
I still think it is best to fetch upstream source using Subversion; but
certainly we are free to choose something else for the packaging.
Regards,
--
Steven Chamberlain
ste...@p
Hi!
Guillem Jover writes:
> I'd like to propose switching and splitting the glibc-bsd repo from svn
> to git repositories, because svn is increasingly painful compared to git,
> when it comes to at least partial commits, tagging (we don't seem to
> be tagging much),
es. For those missing the
familiarity of a single huge chunk of a repository we could use git
submodules.
However, I find working on the shallow glibc-bsd repository increasingly
painful. Given the sheer amount of code I agree we probably do not want
to include lots of upstream code in our repos
1 - 100 of 489 matches
Mail list logo
