Re: [Fwd: Request to give back glibmm2.4 on kfreebsd-amd64 and kfreebsd-i386]
Hi Mattias, glibmm2.4 built fine after given back. I asked for help on the #debian- buildd IRC channel. Maybe you can do the same next time too. On Sat, 2018-09-15 at 04:53 +0200, Mattias Ellert wrote: > Hi! > > I sent this to the wb-team list, but there was no response. But they > are probably nor respomsible for giving back kfreebsd builds, so now > I resend this to this list.
[Fwd: Request to give back glibmm2.4 on kfreebsd-amd64 and kfreebsd-i386]
Hi! I sent this to the wb-team list, but there was no response. But they are probably nor respomsible for giving back kfreebsd builds, so now I resend this to this list. Mattias Vidarebefordrat meddelande Från: Mattias Ellert Till: debian-wb-t...@lists.debian.org Ämne: Request to give back glibmm2.4 on kfreebsd-amd64 and kfreebsd- i386 Datum: Mon, 27 Aug 2018 05:48:01 +0200 The builds of glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386 failed with: error: 'g_application_set_option_context_parameter_string' was not declared in this scope According to https://developer.gnome.org/gio/stable/GApplication.html#g-application-set-option-context-parameter-string g_application_set_option_context_parameter_string is available since glib2.0 vesrion 2.56. However, the glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386 were attempted using glib2.0 version 2.54: Selecting previously unselected package libglib2.0-dev:kfreebsd-amd64. Preparing to unpack .../90-libglib2.0-dev_2.54.2-1_kfreebsd-amd64.deb ... Unpacking libglib2.0-dev:kfreebsd-amd64 (2.54.2-1) ... The glib2.0 version 2.56.1-2 is now available on kfreebsd-amd64 and kfreebsd-i386, so a give-back should succeed (or at least not fail for the same reason). The Build-Depends in the glibmm2.4 source package states libglib2.0-dev (>= 2.50.0), which is insufficient and should be changed to libglib2.0- dev (>= 2.56.0). Related to this: The build of nordugrid-arc 5.4.2-4 on kfreebsd-amd64 and kfreebsd-i386 failed due to a known bug in glibmm2.4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889648 The bug is fixed in the latest version (but the BTS bug has not been closed). So once the above give-backs are completed and the new builds are installed, I would like to request a giveback of nordugrid-arc on kfreebsd-amd64 and kfreebsd-i386 that uses the new version. Mattias signature.asc Description: This is a digitally signed message part
Re: Request for kFreeBSD (and Hurd) porters
Hi Steven, Glad to see you back on the mailing list! On Mon, Jul 30, 2018 at 10:19 AM, Svante Signell wrote: > On Mon, 2018-07-30 at 09:17 +0100, Steven Chamberlain wrote: >> Hi, >> >> Svante Signell wrote: >> > The Debian GNU/kFreeBSD port recently obtained a buildd building >> > packages for the sid distribution, kamp. Thank you very much for >> > your effort making this happening jrtc27 :) >> >> Thanks very much for this James! It was a really nice surprise to >> see packages building again. > > :) > >> May I ask who has provided the hardware/hosting? And what is the DNS >> hostname of the machine? (kamp.buildd.org does not resolve for me). > > That's me :D The machine is NATed so has no public address nor a real hostname. The use of `kamp.buildd.org` is merely for mail purposes (there are only MX records that point to my mail server, from which kamp retrieves messages by fetchmail). >> Also, how are the i386 builds done: is that a kfreebsd-i386 chroot >> on a kfreebsd-amd64 system? Or is it a separate VM running >> "natively" on the 32-bit kernel? > > It's a kfreebsd-i386 chroot running on a kfreebsd-amd64 system. As Svante said; the downside is k-a has priority over k-i (though sid k-i still comes before exp k-a). >> By the way, since 4 days or so many packages are Built but not >> Installed in the archive. Is that because a DD must manually check >> and sign them? > > Yes, this is a drawback. James does all signing manually whenever he > has time. I'm not a DD so I'm not authorized to do such things. I try to do it at least every other day. The recent holdup has been waiting for the util-linux/shadow transition (takeover of su(1)), as the two must be upgraded in lockstep, so if one is built and uploaded but not the other, wanna-build will regard every package as uninstallable, blocking builds until the other is also built and uploaded. They've been built on both k-a and k-i now though so I will be resuming signing when I get home this evening. James
Re: Request for kFreeBSD (and Hurd) porters
On Mon, 2018-07-30 at 09:17 +0100, Steven Chamberlain wrote: > Hi, > > Svante Signell wrote: > > The Debian GNU/kFreeBSD port recently obtained a buildd building > > packages for the sid distribution, kamp. Thank you very much for > > your effort making this happening jrtc27 :) > > Thanks very much for this James! It was a really nice surprise to > see packages building again. :) > May I ask who has provided the hardware/hosting? And what is the DNS > hostname of the machine? (kamp.buildd.org does not resolve for me). That's me :D > Also, how are the i386 builds done: is that a kfreebsd-i386 chroot > on a kfreebsd-amd64 system? Or is it a separate VM running > "natively" on the 32-bit kernel? It's a kfreebsd-i386 chroot running on a kfreebsd-amd64 system. > By the way, since 4 days or so many packages are Built but not > Installed in the archive. Is that because a DD must manually check > and sign them? Yes, this is a drawback. James does all signing manually whenever he has time. I'm not a DD so I'm not authorized to do such things.
Re: Request for kFreeBSD (and Hurd) porters
Hi, Svante Signell wrote: > The Debian GNU/kFreeBSD port recently obtained a buildd building > packages for the sid distribution, kamp. Thank you very much for your > effort making this happening jrtc27 :) Thanks very much for this James! It was a really nice surprise to see packages building again. May I ask who has provided the hardware/hosting? And what is the DNS hostname of the machine? (kamp.buildd.org does not resolve for me). Also, how are the i386 builds done: is that a kfreebsd-i386 chroot on a kfreebsd-amd64 system? Or is it a separate VM running "natively" on the 32-bit kernel? By the way, since 4 days or so many packages are Built but not Installed in the archive. Is that because a DD must manually check and sign them? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Request for kFreeBSD (and Hurd) porters
Hi all, Cc: debian-devel The Debian GNU/kFreeBSD port recently obtained a buildd building packages for the sid distribution, kamp. Thank you very much for your effort making this happening jrtc27 :) The buildd is now soon up-to- date building packages being outdated. As you know GNU/Hurd packages are also built for sid, having two buildds: ironforge and mahler. Now is the time to submit patches for failing packages. In the beginning this will be low hanging fruit, like patches not applying for glibc, a line missing one entry in the symbols file for mpfr4, etc. GNU/kFreeBSD and GNU/Hurd share many common interests. Mainly most of the build-related problems are due to non-portable software, i.e. Linux only designs. Please help us out by submitting bugs with patches to sub...@debian.org to make kFreeBSD a first class citizen too, in addition to GNU/Hurd. Thanks!
Bug#781161: dovecot-core: Can't log in via imap on kFreeBSD amd64 (Auth request missing a file descriptor)
Package: dovecot-core
Version: 1:2.2.15-1
Severity: important
Dear Maintainer,
After upgrading my Debian kFreeBSD machine from Wheezy to Jessie,
dovecot imap stopped working. The version from experiemental was also
broken in the same way.
After I attempt to sign in with valid information, the following messages
are logged:
dovecot: imap: Error: Auth request missing a file descriptor
dovecot: imap-login: Error: read(imap) failed: Remote closed connection
(service's process_limit reached?)
When direcly invoking imap (mutt's set tunnel=/usr/lib/dovecot/imap),
all is well. When I attempt to sign in with invalid information, the
incorrect password is diagnosed. So this problem is not actually with
authentication.
I was not able to determine the exact cause of the problem, but I did
determine that the problems pertains to the fd-passing code, fd_send() /
fd_read(). In the imap process, fd_read succeeds but CHECK_CMSG(cmsg)
is false.
Neither defining BUGGY_CMSG_MACROS nor redefining CHECK_CMSG as for
LINUX20 resolved the problem; doing the latter caused read_fd to fill
out *fd with an invalid file number. Anyway, fdpass.c looks
substantially similar from 2.1 to 2.2 so perhaps the problem lies
elsewhere and this was a red herring.
[most information below pertains to the *working version*,
1:2.1.7-7+deb7u1]
-- Package-specific info:
dovecot configuration
-
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: GNU/kFreeBSD 10.1-0-amd64 x86_64
auth_verbose = yes
debug_log_path = /tmp/dovecot.debug
disable_plaintext_auth = no
lda_mailbox_autocreate = yes
mail_location = maildir:~/Maildir
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = failure_show_msg=yes
driver = pam
}
passdb {
args = /etc/dovecot/extra.passwd
driver = passwd-file
}
postmaster_address = postmas...@unpythonic.net
protocols = imap
ssl = required
ssl_cert = /etc/dovecot/ssl/dovecot.cert
ssl_key = /etc/dovecot/ssl/dovecot.key
userdb {
driver = passwd
}
userdb {
args = /etc/dovecot/extra.passwd
driver = passwd-file
}
verbose_ssl = yes
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dovecot-core depends on:
ii adduser 3.113+nmu3
ii libbz2-1.0 1.0.6-7+b2
ii libc0.1 2.19-15
ii libpam-runtime 1.1.8-3.1
ii libpam0g1.1.8-3.1
ii libssl1.0.0 1.0.1k-1
ii openssl 1.0.1k-1
ii ucf 3.0030
ii zlib1g 1:1.2.8.dfsg-2+b1
dovecot-core recommends no packages.
Versions of packages dovecot-core suggests:
pn dovecot-gssapinone
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
pn dovecot-lmtpd none
pn dovecot-managesieved none
pn dovecot-mysql none
pn dovecot-pgsql none
pn dovecot-pop3d none
pn dovecot-sieve none
pn dovecot-solr none
pn dovecot-sqlitenone
ii ntp 1:4.2.6.p5+dfsg-5
Versions of packages dovecot-core is related to:
ii dovecot-core [dovecot-common] 1:2.1.7-7+deb7u1
pn dovecot-dbgnone
pn dovecot-devnone
pn dovecot-gssapi none
ii dovecot-imapd 1:2.1.7-7+deb7u1
pn dovecot-ldap none
pn dovecot-lmtpd none
pn dovecot-managesieved none
pn dovecot-mysql none
pn dovecot-pgsql none
pn dovecot-pop3d none
pn dovecot-sieve none
pn dovecot-sqlite none
-- no debconf information
--
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/20150325132651.30624.15231.reportbug@localhost
Bug#749157: forwarded libusb.h LIBUSB_CALL request upstream
forwarded 749157 http://www.freebsd.org/cgi/query-pr.cgi?pr=190204 thanks Forwarded the bug to http://www.freebsd.org/cgi/query-pr.cgi?pr=190204 -- 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/CANg8-dBR_v+tvcy09MOwB_LVvdehT0yGq6=-0zvokgxmz8f...@mail.gmail.com
Re: unblock request for kfreebsd-downloader 9.0-3+deb70.1
On 2013-06-20 0:25, Robert Millan wrote: +kfreebsd-downloader (9.0-3+deb70.1) stable; urgency=low + + * Switch to people.debian.org URL for kernel.txz download. +(Closes: #712816) Out of interest, where did you get the version scheme +deb70.1 from? I don't think I've seen that one before (our suggested version would have been +deb7u1, as per dev-ref). Regards, Adam -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a9e261f01df9935943734325b2b31...@mail.adsl.funky-badger.org
Re: unblock request for kfreebsd-downloader 9.0-3+deb70.1
On 20/06/13 13:06, Adam D. Barratt wrote: On 2013-06-20 0:25, Robert Millan wrote: +kfreebsd-downloader (9.0-3+deb70.1) stable; urgency=low + + * Switch to people.debian.org URL for kernel.txz download. +(Closes: #712816) Out of interest, where did you get the version scheme +deb70.1 from? I don't think I've seen that one before (our suggested version would have been +deb7u1, as per dev-ref). It was probably based on the last kfreebsd-9 security upload (9.0-10+deb70.1). Not sure where that one came from either :) 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: http://lists.debian.org/51c308f4.7070...@pyro.eu.org
Re: unblock request for kfreebsd-downloader 9.0-3+deb70.1
2013/6/20 Adam D. Barratt a...@adam-barratt.org.uk: Out of interest, where did you get the version scheme +deb70.1 from? I don't think I've seen that one before (our suggested version would have been +deb7u1, as per dev-ref). Steven just pointed out (correctly). I take note that +deb7u1 is preferred. Hopefully I can even apply this, if memory serves ;-) -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxoknwavkhsouyob8soe3nnhnx6vk2ax_yno-tyzcpv...@mail.gmail.com
Re: Bug#675842: Retest request.
On 26/06/12 18:02, Raúl Sánchez Siles wrote: I would greatly appreciate if you could test the build again. I don't have access to a kfreebsd machine and hence I'm unable to test this on time before the freeze. Hi, It seems to build OK now on kfreebsd-i386 after this commit fixed the build-stamp problem: http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/webkitkde.git;a=commit;h=83adb0b59f231c0b59bd5c87e763cb8095af59bf 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: http://lists.debian.org/4fedf048.3010...@pyro.eu.org
Bug#675842: Retest request.
Hello: I have updated the [0] version of the package yet again, now in sync with latest upstream version. I would greatly appreciate if you could test the build again. I don't have access to a kfreebsd machine and hence I'm unable to test this on time before the freeze. Please, don't hesitate to ask for whatever you need to test this. [0] http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/webkitkde.git Best regards, -- Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 signature.asc Description: This is a digitally signed message part.
Bug#668026: Acknowledgement (libusb: FTBFS[kfreebsd]: error: 'struct usb_ctl_request' has no member named 'request')
Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-bsd@lists.debian.org (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Aurelien Jarno aure...@debian.org If you wish to submit further information on this problem, please send it to 668...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 668026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668026 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.668026.b.13338845115835@bugs.debian.org
Request
-- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7dbd81.0b0cb5.02...@m132-177.yeah.net
Re: request for test build on kFreeBSD machine
On 10/12/10 16:36, Hans-Christoph Steiner wrote: I'm trying to fix bugs 605821-605830 in my packages, and since I am not a DD or DM, I don't have access to the Debian build machines. Could someone please try a test build to see if I have indeed fixed the problem? Then I'll request an upload. (I'm not on this list, so please keep me cc'ed). The easiest way is using git-buildpackage: apt-get install git-buildpackage puredata debhelper quilt git clone \ https://alioth.debian.org/anonscm/git/pkg-multimedia/pd-pmpd.git cd pd-pmpd git-buildpackage Thanks! .hc Built successfully (Log attached). Cheers, Dererk -- BOFH excuse #222: I'm not sure. Try calling the Internet's head office -- it's in the book. pd-pmpd.buildd.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Re: request for test build on kFreeBSD machine
On Dec 15, 2010, at 1:06 PM, Dererk wrote: On 10/12/10 16:36, Hans-Christoph Steiner wrote: I'm trying to fix bugs 605821-605830 in my packages, and since I am not a DD or DM, I don't have access to the Debian build machines. Could someone please try a test build to see if I have indeed fixed the problem? Then I'll request an upload. (I'm not on this list, so please keep me cc'ed). The easiest way is using git-buildpackage: apt-get install git-buildpackage puredata debhelper quilt git clone \ https://alioth.debian.org/anonscm/git/pkg-multimedia/pd-pmpd.git cd pd-pmpd git-buildpackage Thanks! .hc Built successfully (Log attached). Cheers, Dererk Awesome, thanks! Now I am just looking for an uploader! :) .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2897ca08-d2ac-46e0-96f6-188bbeafd...@at.or.at
request for test build on kFreeBSD machine
I'm trying to fix bugs 605821-605830 in my packages, and since I am not a DD or DM, I don't have access to the Debian build machines. Could someone please try a test build to see if I have indeed fixed the problem? Then I'll request an upload. (I'm not on this list, so please keep me cc'ed). The easiest way is using git-buildpackage: apt-get install git-buildpackage puredata debhelper quilt git clone \ https://alioth.debian.org/anonscm/git/pkg-multimedia/pd-pmpd.git cd pd-pmpd git-buildpackage Thanks! .hc -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292009807.2764.7.ca...@palatschinken
Re: v4l howto and help request
Hi! This is a short guide on how to build webcamd and a request for help. webcamd is a port of Linux v4l drivers as a system daemon. I'm tryng to get it working so that I can migrate my desktop someday. Webcam support is mandatory or my sister will be upset ;-) Here are my steps: 1. Install libusb2 8.1-5 or later (to fix bug #594330) 2. Download kernel source. Put it in /usr/src/sys 3. ln -s x86_64 /usr/src/sys/amd64 4. Download fetch script from bug #594483 and put it in your path 5. Add /usr/lib/freebsd to your path 6. Build cuse4bsd as in step 3 in http://www.selasky.org/hans_petter/video4bsd/ 7. kldload cuse4bsd.ko and copy the library to /usr/lib 8. Build webcamd as in step 4 in http://www.selasky.org/hans_petter/video4bsd/ But then when I run webcamd, get this weird error: Attached ugen0.2[0] to cuse unit 0 webcamd: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1))) ((old_top)-size 0x1) ((unsigned long)old_end pagemask) == 0)' failed. Aborted Heap corruption maybe? I also obtained a gdb backtrace. It seems that this is something related with threads. What does sigsuspend do? Is the problem with handling of this signal or is the signal itself something that shouldn't happen? This part really gets me confused. Some help would be nice! It looks like the cuse4bsd assumes BSD implementation of threads. Namely the cuse_client_command() contains struct thread *entered. We use a different implementation. The sigsuspend() is used by our thread implementation. Some tweaking of cuse4bsd would be needed to map user to kernel for thread identification. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.62.1008312007010.22...@sci.felk.cvut.cz
v4l howto and help request
Hi! This is a short guide on how to build webcamd and a request for help. webcamd is a port of Linux v4l drivers as a system daemon. I'm tryng to get it working so that I can migrate my desktop someday. Webcam support is mandatory or my sister will be upset ;-) Here are my steps: 1. Install libusb2 8.1-5 or later (to fix bug #594330) 2. Download kernel source. Put it in /usr/src/sys 3. ln -s x86_64 /usr/src/sys/amd64 4. Download fetch script from bug #594483 and put it in your path 5. Add /usr/lib/freebsd to your path 6. Build cuse4bsd as in step 3 in http://www.selasky.org/hans_petter/video4bsd/ 7. kldload cuse4bsd.ko and copy the library to /usr/lib 8. Build webcamd as in step 4 in http://www.selasky.org/hans_petter/video4bsd/ But then when I run webcamd, get this weird error: Attached ugen0.2[0] to cuse unit 0 webcamd: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1))) ((old_top)-size 0x1) ((unsigned long)old_end pagemask) == 0)' failed. Aborted Heap corruption maybe? I also obtained a gdb backtrace. It seems that this is something related with threads. What does sigsuspend do? Is the problem with handling of this signal or is the signal itself something that shouldn't happen? This part really gets me confused. Some help would be nice! Thanks a lot backtrace Description: Binary data
[Fwd: Bug#565550: acd0: unknown CMD (0x03) illegal request asc=0x20 ascq=0x00]
Hi, I guess this is best handled by the kfreebsd team. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ---BeginMessage--- Package: hal Version: 0.5.14-1 Severity: normal After installing hal on a kfreebsd port of Debian on a kvm platform (Debian/Squeeze Linux 2.6.32) it spams tty1 (Ctrl Alt 1) and syslog with the shown message in the title of this bugreport. Best Regards Georg Gast -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 7.2-1-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hal depends on: ii adduser 3.112 add and remove users and groups ii dbus 1.2.16-2 simple interprocess messaging syst ii freebsd-utils 8.0-2 FreeBSD utilities needed for GNU/k ii hal-info 20091130-1 Hardware Abstraction Layer - fdi f ii libblkid1 2.16.2-0 block device id library ii libc0.1 2.10.2-2 GNU C Library: Shared libraries ii libcam0 8.0-3 FreeBSD CAM (Common Access Method) ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.82-2 simple interprocess messaging syst ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libglib2.0-0 2.22.3-1 The GLib library of C routines ii libhal-storage1 0.5.14-1 Hardware Abstraction Layer - share ii libhal1 0.5.14-1 Hardware Abstraction Layer - share ii libusb2 8.0-3 FreeBSD userspace USB programming ii libusbhid48.0-3 FreeBSD library to access USB HID ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip ii pciutils 1:3.1.4-4 Linux PCI Utilities ii usbutils 0.86-2 Linux USB utilities Versions of packages hal recommends: ii consolekit 0.4.1-2 framework for defining and trackin ii eject 2.1.5+deb1+cvs20081104-7 ejects CDs and operates CD-Changer Versions of packages hal suggests: pn gnome-device-manager none (no description available) -- no debconf information ---End Message--- signature.asc Description: OpenPGP digital signature
Re: Request for advise with struct stat, ACL, xattr, zlib
I have tried to react on the warnings of buildd on kfreebsd. The release is planned to come soon. Please note that libisofs/builder.c:209: warning: passing argument 2 of 'aaip_cleanout_st_mode' from incompatible pointer type is not problem in your code. Your code only detected problem in our code ;-) It have been fixed in eglibc 2.10.2-5 upload. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for advise with struct stat, ACL, xattr, zlib
Hi, me: None of the optional libraries and system features is used in the buildd compile runs: - libacl - support for Extended Attributes - zlib Nevertheless, the aspects of ACL and xattr are also porting issues. Guillem Jover: This is a general packaging bug, there's missing Build-Depends This is promised to be adjusted when the next release of libisofs comes out. The package shall depend on all three if available at all. Can we assume libacl to be installed on vanilla Debian/kfreebsd systems ? I have tried to react on the warnings of buildd on kfreebsd. The release is planned to come soon. Any hints about differences between ACL APIs of Linux and FreeBSD ? What about xattr ? (Extended Attributes, Linux getfattr(1), attr/xattr.h) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
libisofs/builder.c:209: warning: passing
argument 2 of 'aaip_cleanout_st_mode' from
incompatible pointer type
Is stat.st_mode not of type mode_t ?
The line in question is:
aaip_cleanout_st_mode(a_text, (info.st_mode), 4 | 16);
Argument number two is a component of
struct stat info;
The function prototype is
int aaip_cleanout_st_mode(char *acl_text, mode_t *st_mode, int flag);
Can somebody please have a look into
sys/stat.h
whether
struct stat.st_mode
is of different size than mode_t ?
The warning appears on amd64 and on i386.
Unfortunately yes:
/* Structure describing file characteristics. */
struct stat
{
__dev_t st_dev; /* Device containing the file. */
__ino_t st_ino; /* File serial number. */
__uint32_t st_mode; /* File mode. */
__uint32_t st_nlink;/* Link count. */
__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group. */
__dev_t st_rdev;/* Device number, if device. */
struct timespec st_atim;/* Time of last access. */
struct timespec st_mtim;/* Time of last modification. */
struct timespec st_ctim;/* Time of last status change. */
__off_t st_size;/* Size of file, in bytes. */
__blkcnt_t st_blocks; /* Number of 512-byte blocks allocated. */
__blksize_t st_blksize; /* Optimal block size for I/O. */
__uint32_t st_flags;/* User defined flags. */
__uint32_t st_gen; /* Generation number. */
__quad_t __unused1[2];
};
Similar problem might be with nlink_t (16 bit also). Both are mandated by POSIX
http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
IMO, we should fix our headers, but retain binary compatibility
which on little endian should be doable by
-__uint32_t st_mode;/* File mode. */
-__uint32_t st_nlink; /* Link count. */
+__mode_t st_mode; /* File mode. */
+__mode_t __pad_mode; /* __mode_t is 16 bit, align to 32 bit to
retain previous ABI */
+__nlink_t st_nlink;/* Link count. */
+__nlink_t __pad_nlink; /* __nlink_t is 16 bit, align to 32 bit to
retain previous ABI */
And the stat16_to_stat() should zero __pad_mode and __pad_nlink.
Aurelien, Cyril do you agree with this (eglibc) change ?
Petr
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
Petr Salinger petr.salin...@seznam.cz (04/01/2010): Aurelien, Cyril do you agree with this (eglibc) change? I'm really not the person to talk to about those kind of things. But speaking of eglibc, I guess you already know about the build failures we're facing with the latest upload (2.10.2-3)? Mraw, KiBi. signature.asc Description: Digital signature
Re: Request for advise with struct stat, ACL, xattr, zlib (2nd try)
That looks fine given that the kernel syscall is using 16 bits. For big endian targets, given we have none of them, it should not be a problem, they can use the same definition. Committed in glibc-bsd SVN. I will also add to pkg-glibc SVN, just after testsuite finishes. It's a pitty we have such an ABI, as after this change stat16 and stat looks really similar (unless I have missed a difference), modulo the padding. In some time in the past, glibc-bsd used to use syscalls with struct nstat. But the n comes from NetBSD not new. But we have to carry the ABI ... Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Request for advise with mounting particular ISO 9660 sessions
Hi, looking over the system dependencies in our project i come to the xorriso mount helper. It reads the table-of-content of multi-session media or files and produces a mount command for mounting a particular session. Typically used to retrieve older states from multi-session backups. I read from the porting instructions that i shall assume userland to be like Linux. But this line is a bit obscure to me: Example of uname check: Linux|GNU|GNU/*) I could need an example of the string which uname(uts); returns as uts.sysname Currently recognized: FreeBSD and Linux. Another question is the mount command option by which one can address a non-default superblock in an ISO 9660 image. On Linux:mount -t iso9660 -o sbsector=... On FreeBSD: mount_cd9660 -s ... Given we have an ISO 9660 image with several sessions of which one starts at block number 122880, would this Linux shell command work for the superuser ? mount -t iso9660 \ -o nodev,noexec,nosuid,ro,sbsector=122880 \ /dev/cd0 /mnt On FreeBSD xorriso would issue this line mount_cd9660 -o noexec,nosuid -s 122880 \ /dev/cd0 /mnt PS: I am subscribed now. No need to Cc me any more. The following are test proposals for the case that my question cannot be answered flatly. The mount commands mount the last session on CD by default. The first session has block address 0. So at least this one is easy to find on any multi-session CD. Linux: -o sbsector=0 FreeBSD: -s 0 Typically you will see more files in the last session than in the first session. A multi-session CD-RW is traditionally produced by interaction of mkisofs and cdrecord. First session: mkisofs -graft-points \ /tree1=prepared_for_iso/tree1 | \ cdrecord -v dev=/dev/cd0 blank=fast -multi -eject - Follow-up session: m=$(cdrecord dev=/dev/cd0 -msinfo) mkisofs -graft-points -M /dev/cd0 -C $m \ /tree2=prepared_for_iso/tree2 | \ cdrecord -v dev=/dev/cd0 -waiti -multi -eject - mkisofs and cdrecord stand for the originals or for compatible programs like genisoimage, wodim, xorriso -as mkisofs, cdrskin. The Debian xorriso package can produce multi-session ISO images in disk files. For mount, this should make no difference. First session: xorriso -dev /tmp/image.iso -blank as_needed \ -map prepared_for_iso/tree1 /tree1 Follow-up session: xorriso -dev /tmp/image.iso \ -map prepared_for_iso/tree2 /tree2 Here the first session begins at block 32. At block 0 there is a superblock copy of the last session. (superblock means System Area plus Volume Descriptors. Usually 18 blocks.) When mounting sbsector=0 on CD resp. sbsector=32 in disk file you should only see /mnt/tree1. When mounting with no sbsector option you should see both, /mnt/tree1 and /mnt/tree2. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for advise with mounting particular ISO 9660 sessions
I read from the porting instructions that i shall assume userland to be like Linux. Well, the kernel is the same as in FreeBSD, the libc is the same as in libc. Majority of userland is the same as Linux, but see bellow. But this line is a bit obscure to me: Example of uname check: Linux|GNU|GNU/*) I could need an example of the string which uname(uts); returns as uts.sysname Currently recognized: FreeBSD and Linux. salin...@asdfasdf:~$ uname -a GNU/kFreeBSD asdfasdf 7.2-1-amd64 #0 Tue Oct 6 23:17:13 UTC 2009 x86_64 amd64 AMD Sempron(tm) Processor 3000+ GNU/kFreeBSD salin...@asdfasdf:~$ uname -s GNU/kFreeBSD salin...@asdfasdf:~$ uname -o GNU/kFreeBSD Another question is the mount command option by which one can address a non-default superblock in an ISO 9660 image. On Linux:mount -t iso9660 -o sbsector=... On FreeBSD: mount_cd9660 -s ... Given we have an ISO 9660 image with several sessions of which one starts at block number 122880, would this Linux shell command work for the superuser ? mount -t iso9660 \ -o nodev,noexec,nosuid,ro,sbsector=122880 \ /dev/cd0 /mnt On FreeBSD xorriso would issue this line mount_cd9660 -o noexec,nosuid -s 122880 \ /dev/cd0 /mnt Use the FreeBSD one, as mount is just user friendly interface to kernel specific syscall. salin...@asdfasdf:~$ /sbin/mount_cd9660 -h /sbin/mount_cd9660: invalid option -- 'h' usage: mount_cd9660 [-begjrv] [-C charset] [-o options] [-s startsector] special node This command comes from freebsd-utils package, which is available (and essential) for both kfreebsd-i386 and kfreebsd-amd64, see http://packages.debian.org/sid/kfreebsd-amd64/freebsd-utils/filelist Thanks for your care about GNU/kFreeBSD. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Request for advise with struct stat, ACL, xattr, zlib
Hi, looking over the system dependencies in our project i come to the xorriso mount helper. It reads the table-of-content of multi-session media or files and produces a mount command for mounting a particular session. Typically used to retrieve older states from multi-session backups. I read from the porting instructions that i shall assume userland to be like Linux. But this line is a bit obscure to me: Example of uname check: Linux|GNU|GNU/*) I could need an example of the string which uname(uts); returns as uts.sysname Currently recognized: FreeBSD and Linux. Another question is the mount command option by which one can address a non-default superblock in an ISO 9660 image. On Linux:mount -t iso9660 -o sbsector=... On FreeBSD: mount_cd9660 -s ... Given we have an ISO 9660 image with several sessions of which one starts at block number 122880, would this Linux shell command work for the superuser ? mount -t iso9660 \ -o nodev,noexec,nosuid,ro,sbsector=122880 \ /dev/cd0 /mnt On FreeBSD xorriso would issue this line mount_cd9660 -o noexec,nosuid -s 122880 \ /dev/cd0 /mnt PS: I am subscribed now. No need to Cc me any more. The following are test proposals for the case that my question cannot be answered flatly. The mount commands mount the last session on CD by default. The first session has block address 0. So at least this one is easy to find on any multi-session CD. Linux: -o sbsector=0 FreeBSD: -s 0 Typically you will see more files in the last session than in the first session. A multi-session CD-RW is traditionally produced by interaction of mkisofs and cdrecord. First session: mkisofs -graft-points \ /tree1=prepared_for_iso/tree1 | \ cdrecord -v dev=/dev/cd0 blank=fast -multi -eject - Follow-up session: m=$(cdrecord dev=/dev/cd0 -msinfo) mkisofs -graft-points -M /dev/cd0 -C $m \ /tree2=prepared_for_iso/tree2 | \ cdrecord -v dev=/dev/cd0 -waiti -multi -eject - mkisofs and cdrecord stand for the originals or for compatible programs like genisoimage, wodim, xorriso -as mkisofs, cdrskin. The Debian xorriso package can produce multi-session ISO images in disk files. For mount, this should make no difference. First session: xorriso -dev /tmp/image.iso -blank as_needed \ -map prepared_for_iso/tree1 /tree1 Follow-up session: xorriso -dev /tmp/image.iso \ -map prepared_for_iso/tree2 /tree2 Here the first session begins at block 32. At block 0 there is a superblock copy of the last session. (superblock means System Area plus Volume Descriptors. Usually 18 blocks.) When mounting sbsector=0 on CD resp. sbsector=32 in disk file you should only see /mnt/tree1. When mounting with no sbsector option you should see both, /mnt/tree1 and /mnt/tree2. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Request for advise with struct stat, ACL, xattr, zlib (2nd try)
Hi, Sorry for sending the same old mail again. It should have been this one: I had a look at the buildd logs of our libisofs https://buildd.debian.org/fetch.cgi?pkg=libisofs;ver=0.6.24-1;arch=kfreebsd-amd64;stamp=1255540287 https://buildd.debian.org/fetch.cgi?pkg=libisofs;ver=0.6.24-1;arch=kfreebsd-i386;stamp=1255540772 I am puzzled by this warning: libisofs/builder.c:209: warning: passing argument 2 of 'aaip_cleanout_st_mode' from incompatible pointer type Is stat.st_mode not of type mode_t ? The line in question is: aaip_cleanout_st_mode(a_text, (info.st_mode), 4 | 16); Argument number two is a component of struct stat info; The function prototype is int aaip_cleanout_st_mode(char *acl_text, mode_t *st_mode, int flag); Can somebody please have a look into sys/stat.h whether struct stat.st_mode is of different size than mode_t ? The warning appears on amd64 and on i386. Another unexplainable warning on both and also on Linux i386: libisofs/tree.c:917: warning: 'brk_info' may be used uninitialized in this function I see in http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/scdbackup/annotate/head%3A/libisofs/tree.c line 917: char *ptr, *brk_info, *component; ... no goto , no open blocks ... component = strtok_r(ptr, /, brk_info); and understand from man 3 strtok_r that brk_info is to be initialized by that function. Looking into my local /usr/include/string.h brings no insight either. Does anybody have an idea what the compiler wants to tell me ? None of the optional libraries and system features is used in the buildd compile runs: - libacl - support for Extended Attributes - zlib At least on Linux this astonishes me. I'll have to ask George for exploring the reason. Nevertheless, the aspects of ACL and xattr are also porting issues. It might be that a Linux-centric configure test prevents the use of the prepared ACL adapter for FreeBSD even on the original system. checking sys/acl.h usability... no checking sys/acl.h presence... no checking for sys/acl.h... no Do the buildd machines have ACL support installed ? Are there any header files like sys/acl.h to include ? To test ACL on Debian kfreebsd would require a little hack in ./configure, an #ifdef __FreeBSD_kernel__, and somebody who has files with non-trivial ACLs. (The reward would be a backup engine which can record and restore ACLs in ISO images. The images are mountable but OS kernels show no ACLs in them.) Anybody bored enough to volunteer ? Are there Extended Attributes with any of the kfreebsd filesystems ? See on Linux: man 1 getfattr, setfattr. If yes, then i would have to de-Linuxify ./configure checking attr/xattr.h usability... no checking attr/xattr.h presence... no checking for attr/xattr.h... no and i would need documentation of functions like Linux man 2 listxattr, getxattr, removexattr, setxattr. The lack of zlib is a bit pity: checking zlib.h usability... no checking zlib.h presence... no checking for zlib.h... no as it would allow to write compressed files into the image on-the-fly. Is there zisofs support in the FreeBSD kernel ? (Linux can uncompress zisofs formatted files by its read-only isofs filesystem code. So one can mount ISO images with compressed files and sees them uncompressed.) There is also portable intransparent compression if zlib is available. This produces *.gz files inside the ISO image. You unpack them from mounted images by gunzip. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FAILURE/ILLEGAL REQUEST with kFreeBSD/i386
Hi, Aurel.
OK, I bit the bullet and now I am subscribed. :-)
You guys seem to be quite receptive to a newbie to a new platform and
this seems to be a great place for development.
On Sep 03 2009, Aurelien Jarno wrote:
On Wed, Sep 02, 2009 at 09:46:31PM -0300, Rogério Brito wrote:
Yes, hal *is* the culprit.
QEMU is actually the culprit. These messages do not appear on real
machines.
Oh, thanks. Perhaps This should be reported.
I'll file a bug, so that it becomes formally registered.
Thanks,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FAILURE/ILLEGAL REQUEST with kFreeBSD/i386
Hi.
This is the second time that I got a problem with the i386 system when
installing in a qemu virtual machine (this time, I'm using kqemu, as I
hinted at a previous messge).
The attached dmesg is what I'm getting. :-(
The funny thing is that when I did not upgrade things, everything was
working fine, but I have the suspicion that hal is the culprit (but I
still have to isolate the problematic situation a little bit more to
assert for sure).
Just when I was going to tackle the FTBFS di bug that I mentioned
before. :-(
Well, any comments are more than welcome, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
dmesg-kbsd-i386.txt.gz
Description: Binary data
Re: FAILURE/ILLEGAL REQUEST with kFreeBSD/i386
Hi once again, people.
On Sep 02 2009, Rogério Brito wrote:
I have the suspicion that hal is the culprit
Yes, hal *is* the culprit.
Disabling it completely with update-rc.d makes the system boot
beautifully without any problems (but, then, you have to tweak the
xorg.conf file, if you wish to have any way to use your keyboard and
your mouse).
As soon as I /etc/init.d/hal start'ed, I got exactly those messages that
I reported earlier.
This is mightly annoying (well, depending on hal is, IMVHO, a way to
inflate the dependencies of the installations, leaving smaller systems
almost without an option if you want to run Debian, even if we are
running on Linux).
That's not to mention that the XSF is adopting HAL when it is being
deprecated in favor of device-kit/console-kit/udev.
I'm not exactly sure how the kFreeBSD userland will adapt to this
reliance on udev (which, AFAIK, is limited to Linux).
But installing the good, old fashioned way (and there's nothing wrong
with that) is not a problem.
Regards, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: request for enabling the ae driver for kernel 7.1
[sorry for the double email, I forgot to cc the list] On 28/11/2008, Petr Salinger [EMAIL PROTECTED] wrote: Hi. Could you please consider enablig the ae driver in the next build of the FreeBSD 7.1 kernel? If you can't enable it, can you please suggest me the easier way to compile the ae driver on Debian GNU/KfreeBSD? It is (will be) not available as built-in, but is is (will be) available as a module. The modprobe if_ae should suffice. Great news. Thanks. Do you need amd64 or i686 flavour ? Petr i686. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request for enabling the ae driver for kernel 7.1
Hi. Could you please consider enablig the ae driver in the next build of the FreeBSD 7.1 kernel? If you can't enable it, can you please suggest me the easier way to compile the ae driver on Debian GNU/KfreeBSD? It is (will be) not available as built-in, but is is (will be) available as a module. The modprobe if_ae should suffice. Do you need amd64 or i686 flavour ? Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
request for enabling the ae driver for kernel 7.1
Hi. I saw at [debian_svn] that in Debian svn you are targeting releng_7_1. I saw that the ae driver is not enabled for releng_7_1 ([releng_7_1_conf]), but it is enabled for head ([head_conf]). The ae driver is useful to provide LAN to Asus Eee PC 900, as described at [freebsd_wiki]. Could you please consider enablig the ae driver in the next build of the FreeBSD 7.1 kernel? If you can't enable it, can you please suggest me the easier way to compile the ae driver on Debian GNU/KfreeBSD? Thanks. Luca Favatella [debian_svn] http://svn.debian.org/wsvn/glibc-bsd/trunk/kfreebsd-7/fetch?op=diffrev=0sc=0 [releng_7_1_conf] http://svn.freebsd.org/viewvc/base/releng/7.1/sys/dev/ae/if_ae.c?view=log [head_conf] http://svn.freebsd.org/viewvc/base/head/sys/i386/conf/GENERIC?revision=185281view=markup [freebsd_wiki] http://wiki.freebsd.org/AsusEee#head-6d00dcb960b731976447f2511654a0419ce7cc0f -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
request for upload of net-snmp into unreleased
Hi. I just wrote dirty hack for net-snmp, committed in SVN. Please could someone built it and upload for both kfreebsd-i386 and kfreebsd-amd64. Following packages Build-depends on libsnmp9-dev: php4 php5 apcupsd cacti-cactid cheops cpqarrayd cyrus-imapd-2.2 cyrus21-imapd fwbuilder gkrellm-snmp heartbeat heartbeat-2 hplip hpoj ifstat kdeutils kolab-cyrus-imapd libfwbuilder mbrowse nagios-plugins netmrg nut openipmi snmptrapfmt wmnd Thanks Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request for upload of net-snmp into unreleased
Robert Millan wrote: On Wed, May 03, 2006 at 08:28:59PM +0200, Petr Salinger wrote: Hi. I just wrote dirty hack for net-snmp, committed in SVN. Nice work. This was a though one. Please could someone built it and upload for both kfreebsd-i386 and kfreebsd-amd64. Uploaded to i386 (I don't have amd64 at hand atm). I will do the upload of amd64 after midnight, so that both uploads do not conflict. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Podcast Interview Request
Would anyone from the debian bsd project be interested in doing an interview for a BSD related podcast? You can find the podcast at http://bsdtalk.blogspot.com. -- Will Backman __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Your mail to ipp-request@pwg.org
This pre-recorded message is being sent in response to your recent email to [EMAIL PROTECTED] All routine administrative requests (including subscriptions and unsubscriptions) concerning this mailing list are handled by an automated server. Please read this message carefully to find the information relevant to you. SUBSCRIBING === To subscribe to ipp, send the following in the body (not the subject line) of an email message to Majordomo: subscribe ipp This will subscribe the account from which you send the message to the ipp list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form: subscribe ipp [EMAIL PROTECTED] UNSUBSCRIBING = To unsubscribe from ipp, send the following in the body (not the subject line) of an email message to Majordomo: unsubscribe ipp This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead: unsubscribe ipp [EMAIL PROTECTED] If you don't know what address you are subscribed with, you can send the following command to see who else is on the list (assuming that information isn't designated private by the owner of the list): who ipp If you want to search non-private lists at this server, you can do that by sending a command like: which string This will return a list of all entries on all lists that contain string. HELP To find out more about the automated server and the commands it understands, send the following command to Majordomo: help If you feel you need to reach a human, send email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Donation request
Hi, I belong to a family of twelve adults and several children. We have anything we need and more. I am writting this email to find a way to give away our more to people. Before I arrived to this house they used to thow almost new cloth into the garbage because they "did not want it" or "did not need it". I have been collecting the cloth they dont want anymore and I am trying to find a proper destination for it. Can you please help me? I do not want this cloth to be resold I want to give it away. The cloth is basically pakistani outfits but I also have some shoes and western cloth. Thanks a lot. I dwould like tobe able to help somepeople. It is just a matter of luck in which side I have been born, I could be the one needing help instead of the one giving it. Carolina
Re: [rebuild request] scsh for woody
On Sun, Mar 28, 2004 at 10:39:33PM +0200, Lionel Elie Mamane wrote: Please help me move scsh from woody/main to woody/non-free by rebuilding it for all 32 bit released architectures (don't try on 64 bit architectures, it won't work). I can't do it because I am not a Debian Developer, hence I don't have access to the Debian machines. I've just uploaded scsh_0.6.0-2woody1.diff.gz to woody proposed-updates. For the impatient ones, it's available from http://mdcc.cx/~joostvb/scsh/ too (along with a i386 build). For it to happen, we need to rebuild it for all architectures it is present in in woody. The source I've uploaded is minorly different from the one Lionel has published: I've clarified the debian/copyright file. So those of you who have done builds from Lionel's scsh_0.6.0-2woody0 are very kindly requested to build again, from scsh_0.6.0-2woody1. (I feel the incorrect text in the copyright file justified another source update.) Wouter Verhelst has done a build for m68k ( http://lists.debian.org/debian-68k/2004/debian-68k-200403/msg00120.html). Wouter: would you like to make another build please, and upload the binary? Thanks a lot! Thiemo Seufer has done a build for mips ( http://lists.debian.org/debian-mips/2004/debian-mips-200403/msg00095.html). Thiemo: care for doing another build? If you sign your .dsc and .changes with your own gpg key, I can resign them and do a sponsored upload. Thanks a lot! Colin Watson ( http://lists.debian.org/debian-powerpc/2004/debian-powerpc-200403/msg00739.html): care to build from these sources, and upload the binary, for powerpc? Thanks a lot! I might be able to take care of a sparc build myself: I am now setting up a build environment on my Debian woody sparc box. This means we still need: alpha ( http://lists.debian.org/debian-alpha/2004/debian-alpha-200403/msg00082.html ) arm ( http://lists.debian.org/debian-arm/2004/debian-arm-200403/msg00035.html ) hppa ( http://lists.debian.org/debian-hppa/2004/debian-hppa-200403/msg00084.html ) mipsel ( Digital DECstations - little-endian; Thiemo is working on the mips one ) s390 ( http://lists.debian.org/debian-s390/2004/debian-s390-200403/msg00032.html ) I'll investigate build hosts myself after I've done the sparc build. Please join us in helping Joey to get 3.0r2 out. Bye, Joost PS: please honor Mail-Followup-To, and sent replies to [EMAIL PROTECTED] too. -- . . http://mdcc.cx/ Joost van Baal. . . . http://logreport.org/ . .http://abramowitz.uvt.nl/ signature.asc Description: Digital signature
[rebuild request] scsh for woody
Hi, Please help me move scsh from woody/main to woody/non-free by rebuilding it for all 32 bit released architectures (don't try on 64 bit architectures, it won't work). I can't do it because I am not a Debian Developer, hence I don't have access to the Debian machines. Ready-to-build package at http://www.conuropsis.org/~lmamane/ . scsh is nearly free: Its main license is no-ad BSD, but some non-free parts have escaped the vigilance of upstream. These parts have been ripped out, replaced or relicensed for next version, which shows that upstream is eager to have a fully free program. Still, the version in woody contains non-free parts, so we have to either remove it or move it to non-free. The latter would be obviously better for our users, which, as the recent GR has demonstrated, are and stay our priority, even when they want to use non-free software. It would also be a better signal towards upstream. For it to happen, we need to rebuild it for all architectures it is present in in woody. So, please, let's show that you *mean* what you voted for, and rebuild scsh for some architectures. (While you are at it, you may want to rebuild the package in unstable, so that the new package migrates to testing, and the wrongly labeled ones disappear. But woody first. The unstable / testing issue will be resolved by the release of the next upstream version anyway, maybe in time for sarge.) Thank you in advance, -- Lionel signature.asc Description: Digital signature
Donation request
Attention: Non-profit, Review Corporation. In all forms, civil society is probably the largest single factor in development. American SOS Foundation, Inc. is an American nonprofit and tax-exempt fund registered under Section 501 (c) (3) The mission of American SOS Foundation is to improve the economical growth and the growth of rural economy, recreation sports programs and the medicine. American SOS Foundation also gives assistance to those people who do need help. Mostly the people living in Russian Federation and the surrounding countries (Armenia, Georgia, Ukraine, Kazakhstan, Azerbaijan, Tatars tan, Uzbekistan and more). Our programs directed to children, War veterans, disabled people, refugees and people who need a medical assistance. At this moment we are planning to realize some programs regarding sport and recreation development of the youth. There are some programs concerned with sport development in Russian Federation, which we would like to realize. 1.Sport and Recreation program for Disabled Children Development We would like to present, Special Olympics Kazakhstan has 14 branches all over Kazakhstan. Kazakhstan is a democratic republic and there are about 120 nationalities living in peace. Statistically, the 2-3 % of the population of Kazakhstan are people with mental retardation, it is about 300 450 thousand people. Special Olympics Kazakhstan has 8 500 special athletes with different kinds of diagnostic. Our target is to raise the number of the athletes training in Special Olympics Kazakhstan to 15 000 by the year 2005. Next year we are planning to recruit 3 500 new athletes. Request for donation kids sport uniform for age from 5-17, footwear (sinkers,),sports ware (t- shirts, sport suits, shorts, pants),sports equipment (footballs,, rackets and tennis balls, volley balls, etc),socks size 5-17years. 2. Program for homeless people We would like to present Charity Fund of rehabilitation and social adaptation of homeless people, The Way Home Registration for the homeless people, contacts with different city, region and governmental services in purpose to help the homeless people, the assistance regarding medical testing and hospitalization; Rendering direct assistance to the homeless people (providing hot meal, the medicine and distributing secondhand cloth); At the present moment over 6000 adults and about 850 children and the teenagers are registered in the Homeless Registration Center of The Way Home; Realization of the programs directed to the social adaptation of the homeless people and the people released from prison. Since 1998 about 500 people have had the opportunity to use the services of The Way Homes Center for Rehabilitation and Social Adaptation; Children daily stay at the center created in 2001. About 850 children and the teenagers have been registered in the organization. The initial medical examination is realized in the Center: Realizing the hospitalization if its necessity, giving first social aid to a child (contacting with family, notification of the corresponding children organizations etc.), distributing of clothes, feeding and realizing the education programs as well. Harm Reduction from the non-medical drug use. The program covers 7200 drug users. 250 clients visit the two drop-in centers per day. Request for donation Medical Supplies Syringes 5,0 ml ,syringes 2,0 ml , syringes 1,0 ml, syringes 20,0 ml , bandages , absorbent cotton , antiseptic serviettes , medical plaster , medical gloves , container for used needles, syringes ,condoms ,womens sanitary towels . Medical Equipment Tonometer, thermometer, endoscope, wheelchair, quartz lamp Educational Supplies Copy-book ,linen note-book ,satchel ,drawing-book ,crayon, pencil ,water- cooler ,gouache painting ,pen ,blackboard ,flip-chart .school desk ,tables ,chairs Clothing Jackets (for winter and autumn), trousers .cloth for teenagers, boys, cloth for girls-teenagers, tights ,knitted caps ,knitted gloves ,sports shirt ,blinkers ,baseball cap ,pull-over . Shoes: Shoes for boys and adults, sandals for men, sandals for women, boots. Food Pastry (cookie, biscuit) ,fish canned food ,meat canned food ,fruit jam ,sweetmeats ,oil ,dried milk ,dried soup in package ,tea in package ,dried chicken broth in package ,juices American SOS Foundation Inc. is a non-profit organization under status of 501(c) (3); Your contributions will be tax deductible Any assistance you can provide in helping us would be greatly appreciated
Re: A request from the NetBSD folks [ please discuss ]
On Thu, Dec 04, 2003 at 11:22:36AM -0700, Joel Baker wrote: So. I propose the following, and, barring objections over the next week or so, I'll take steps to update what I can to reflect this: uname -s will remain 'NetBSD'. uname -v will continue to have distinguishing features (I really wish the NetBSD folks had working 'vendor' fields, so I could just fill them in; maybe I should raise this on tech-user, as well, though I did at one point and mostly got told that it has never worked; of course, I didn't offer any patches, either, so I can't much complain). The last part of the config triplet will remain '-netbsd-gnu' (origionally this was supposed to be -netbsd-debian, as a vendor field, but the GNU upstream preferred -gnu as a userland indicator, since that appears to be what the suffix is really intended to reflect). The Debian port name will be Debian GNU/KLNetBSD(i386) (or KNetBSD for Robert's stuff, but that's not mine to decide :) The Debian architecture will remain 'netbsd-i386', with the known issue that we'll have to resolve this at some point with the dpkg maintainers and the ftpmasters. (And, in a week, barring any objections, I'll write a summary of what's going on, and post it to debian-devel and probably mail it to Debian News). This was written last Thursday, mid-day - thus, you have slightly less than 24 hours (assuming I'm feeling pedantic about exactly when I do this, but I won't guarantee anything *more* than 7x24 hours from the origional posting) to raise objections, if you have any. I believe the only one so far (by Robert, regarding the Debian architecture string being used for patches) has been addressed, insofar as it is possible to address, and certainly isn't any worse than what we have today. Thus, barring any other objections, I'll assume everyone is either OK with it, or doesn't much care (okay, it's probably the latter, but that will suffice :) -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpvhLyuxTOX0.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
On Fri, Dec 05, 2003 at 08:21:09AM -0700, Joel Baker wrote: Which works great, if it's libc-dev that's needed. It fails fairly severely, if a specific version of a library is needed due to, say, a fix in an included library that also requires a fix in the application. Not to mention packages like GCC, which use m4 substitution based on ARCH to decide whether to put in a libc12-dev or a libc-6dev, for fairly good reasons. Of course, as I said before, *most* of those changes are already in place anyway. I don't think I've ever filed a patch using arch-specific stuff for netbsd-i386 in the Depends or Build-Depends that did not involve something that would have (msot likely) been different between the two. Changing the libc is such a fundamental thing that it cascades throughout the port rapidly, in any place that it matters in the first place. Which presents a fairly difficult situation. While I'm happy to use system type, when that is, in fact, the applicable switch (and, stipulated, it may well be applicable in some places where ARCH has been used to date), its' going to be fairly difficult to argue that either port is 'useable' when the patches aren't integrated at all. (Plus, frequently, maintainers have asked for changes to the patches, before accepting them; thus, what lives in a CVS area, which is what I did while starting, may often not resemble the final results). Which is all a long way of saying that I don't see an easy solution, and that people are probably right in being frustrated by the entire lack of coherence of the 'Debian BSD port' effort. I don't think we even have enough people to take a meaningful straw poll (though I could be mistaken, of course). I understand your concerns. All I can say is I appreciate your good intention to address compatible architecture handling in the best of our possibilities, and that coherence is a goal that takes time to attain in most situations. So, be patient.. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: A request from the NetBSD folks [ please discuss ]
On Thu, Dec 04, 2003 at 06:46:05PM -0700, Joel Baker wrote: Untill we resolve this, please take into consideration to avoid filing patches that use netbsd-i386 in a way that breaks the other port. I've been careful to keep such incompatible patches without submitting, since I started. A bit late for that, I'm afraid; they're already fairly pervasive, particularly throughout the toolchain. I know that. But I'm not asking you to revert the existing incompatible changes, I understand it wouldn't make sense to do that. I just ask to not add more of them. Except in the case of things like libc. Which tend to pop up more than one might imagine. Unfortunately, it's also true that quite a few maintainers already have ARCH logic, and are not entirely amenable to just randomly up and changing this because we can't figure out what we want to do. You can handle libc dependencies portably I think, instead of: libc12-dev [netbsd-i386] | libc1-dev [freebsd-i386] Just do: libc6-dev | libc-dev -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: A request from the NetBSD folks [ please discuss ]
On Fri, Dec 05, 2003 at 01:28:03PM +0100, Robert Millan wrote: On Thu, Dec 04, 2003 at 06:46:05PM -0700, Joel Baker wrote: Untill we resolve this, please take into consideration to avoid filing patches that use netbsd-i386 in a way that breaks the other port. I've been careful to keep such incompatible patches without submitting, since I started. A bit late for that, I'm afraid; they're already fairly pervasive, particularly throughout the toolchain. I know that. But I'm not asking you to revert the existing incompatible changes, I understand it wouldn't make sense to do that. I just ask to not add more of them. Except in the case of things like libc. Which tend to pop up more than one might imagine. Unfortunately, it's also true that quite a few maintainers already have ARCH logic, and are not entirely amenable to just randomly up and changing this because we can't figure out what we want to do. You can handle libc dependencies portably I think, instead of: libc12-dev [netbsd-i386] | libc1-dev [freebsd-i386] Just do: libc6-dev | libc-dev Which works great, if it's libc-dev that's needed. It fails fairly severely, if a specific version of a library is needed due to, say, a fix in an included library that also requires a fix in the application. Not to mention packages like GCC, which use m4 substitution based on ARCH to decide whether to put in a libc12-dev or a libc-6dev, for fairly good reasons. Of course, as I said before, *most* of those changes are already in place anyway. I don't think I've ever filed a patch using arch-specific stuff for netbsd-i386 in the Depends or Build-Depends that did not involve something that would have (msot likely) been different between the two. Changing the libc is such a fundamental thing that it cascades throughout the port rapidly, in any place that it matters in the first place. Which presents a fairly difficult situation. While I'm happy to use system type, when that is, in fact, the applicable switch (and, stipulated, it may well be applicable in some places where ARCH has been used to date), its' going to be fairly difficult to argue that either port is 'useable' when the patches aren't integrated at all. (Plus, frequently, maintainers have asked for changes to the patches, before accepting them; thus, what lives in a CVS area, which is what I did while starting, may often not resemble the final results). Which is all a long way of saying that I don't see an easy solution, and that people are probably right in being frustrated by the entire lack of coherence of the 'Debian BSD port' effort. I don't think we even have enough people to take a meaningful straw poll (though I could be mistaken, of course). -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpFsmt9VTGXg.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
On Tue, Dec 02, 2003 at 01:50:16PM -0700, Joel Baker wrote: I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about what's going on, and because it doesn't dilute the NetBSD trademark. While the former is less true of, say, my work, the latter is certainly a valid concern. I'm very glad you bring up this point. I think using the K abbreviation for Kernel of would greatly help reducing confusion with the one-true NetBSD system. Of course, this leads to the question of naming things for the ports that use native libc rather than GNU libc. KLNetBSD (Kernel + Libc)? KCNetBSD (Kernel + libC, Kernel + Core)? CNetBSD (Core)? Debian GNU/MostlyNetBSD? NotQuiteNetBSD? :) I've been using the K prefix for my (Glibc-based) ports only, and avoided it for the other ports mainly due to not having discussed this with the people working on them. Strictly on nomenclature issues, I would opt for GNU/KLNetBSD, but this is a decision that belongs to you of course. On the technical issues (uname, system triplet, etc), see my response to Guillem's thread. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: A request from the NetBSD folks [ please discuss ]
There are very important technical reasons for these decisions, not only nomenclature correctness stuff. Let me explain. On Wed, Dec 03, 2003 at 11:33:22AM -0700, Joel Baker wrote: uname -s: GNU/KFreeBSD Uhm. I'd have to turn on my box to check this. I think I may have left uname -s alone, but changed uname -v to something like Debian/NetBSD. A lot of programs tend to use uname for system identification. When they do that, they're primarily checking for libc features. - If uname -s prints NetBSD, programs will assume NetBSD libc and you'll have the most chances to compile your program on NetBSD libc. - If uname -s prints GNU or GNU/*, programs will assume GNU libc. GNU is aka GNU/Hurd, and is already stablished. GNU/* is what we've been using so far for our Glibc-based ports. So you should really use NetBSD for uname -s. config.guess triplet: arch-(pc|unknown)-kfreebsdversion-gnu arch-(pc|unknown)-netbsd-gnu And: arch-(pc|unknown)-knetbsdversion-gnu Similarly to the above, you most likely want to match netbsd* checks, while we want to avoid them because of not having NetBSD libc. Anyway, changing the triplets at this stage is out of question for many reasons. Debian port name: Debian GNU/KFreeBSD Debian GNU/NetBSD As said before, my suggestion is Debian GNU/KLNetBSD here. Debian GNU NetBSD/i386 Uhm.. that (without the slash) would mean NetBSD is a GNU project. Debian arch name: freebsd-arch netbsd-arch (specfically, -i386) I've been using netbsd-arch too, for the reasons Guillem explained. Sorting this out will require long and painful discussion with the dpkg maintainers, but see below.. The Debian arch name is not consistent, because the dpkg maintainers disagreed with the name change, and we didn't want to discuss it endlessly, we wanted the patches integrated to have a functional system. Frankly, they're probably waiting to see who emerges from the smoke and rubble as actually capable of being used as a working port... .. untill someone emerges from the smoke, I don't find it viable to annoy the dpkg maintainers with that. Since the DEB_HOST_ARCH is not that important, I think we can postpone this for now. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: A request from the NetBSD folks [ please discuss ]
On Thu, Dec 04, 2003 at 03:24:51PM +0100, Robert Millan wrote: There are very important technical reasons for these decisions, not only nomenclature correctness stuff. Let me explain. On Wed, Dec 03, 2003 at 11:33:22AM -0700, Joel Baker wrote: uname -s: GNU/KFreeBSD Uhm. I'd have to turn on my box to check this. I think I may have left uname -s alone, but changed uname -v to something like Debian/NetBSD. A lot of programs tend to use uname for system identification. When they do that, they're primarily checking for libc features. - If uname -s prints NetBSD, programs will assume NetBSD libc and you'll have the most chances to compile your program on NetBSD libc. - If uname -s prints GNU or GNU/*, programs will assume GNU libc. GNU is aka GNU/Hurd, and is already stablished. GNU/* is what we've been using so far for our Glibc-based ports. Makes sense. So you should really use NetBSD for uname -s. config.guess triplet: arch-(pc|unknown)-kfreebsdversion-gnu arch-(pc|unknown)-netbsd-gnu And: arch-(pc|unknown)-knetbsdversion-gnu Similarly to the above, you most likely want to match netbsd* checks, while we want to avoid them because of not having NetBSD libc. Also makes sense. Anyway, changing the triplets at this stage is out of question for many reasons. Convenient, then, that we probably don't need to :) Debian port name: Debian GNU/KFreeBSD Debian GNU/NetBSD As said before, my suggestion is Debian GNU/KLNetBSD here. Debian GNU NetBSD/i386 Uhm.. that (without the slash) would mean NetBSD is a GNU project. Mostly, that was a documentation of current practice, not a suggestion. And is, as the whole point of this thread, up for discussion. :) Debian arch name: freebsd-arch netbsd-arch (specfically, -i386) I've been using netbsd-arch too, for the reasons Guillem explained. Sorting this out will require long and painful discussion with the dpkg maintainers, but see below.. The Debian arch name is not consistent, because the dpkg maintainers disagreed with the name change, and we didn't want to discuss it endlessly, we wanted the patches integrated to have a functional system. Frankly, they're probably waiting to see who emerges from the smoke and rubble as actually capable of being used as a working port... .. untill someone emerges from the smoke, I don't find it viable to annoy the dpkg maintainers with that. Since the DEB_HOST_ARCH is not that important, I think we can postpone this for now. Indeed. As long as it's documented, people are probably going to be hand-selecting their APT entries, anyway, so it isn't such a big deal. So. I propose the following, and, barring objections over the next week or so, I'll take steps to update what I can to reflect this: uname -s will remain 'NetBSD'. uname -v will continue to have distinguishing features (I really wish the NetBSD folks had working 'vendor' fields, so I could just fill them in; maybe I should raise this on tech-user, as well, though I did at one point and mostly got told that it has never worked; of course, I didn't offer any patches, either, so I can't much complain). The last part of the config triplet will remain '-netbsd-gnu' (origionally this was supposed to be -netbsd-debian, as a vendor field, but the GNU upstream preferred -gnu as a userland indicator, since that appears to be what the suffix is really intended to reflect). The Debian port name will be Debian GNU/KLNetBSD(i386) (or KNetBSD for Robert's stuff, but that's not mine to decide :) The Debian architecture will remain 'netbsd-i386', with the known issue that we'll have to resolve this at some point with the dpkg maintainers and the ftpmasters. (And, in a week, barring any objections, I'll write a summary of what's going on, and post it to debian-devel and probably mail it to Debian News). -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : (or Debian GNU/KLNetBSD(i386) porter, soon, perhaps `. `' `- pgpT1W9MgD7oe.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
On Thu, Dec 04, 2003 at 11:22:36AM -0700, Joel Baker wrote: Indeed. As long as it's documented, people are probably going to be hand-selecting their APT entries, anyway, so it isn't such a big deal. [...] The Debian architecture will remain 'netbsd-i386', with the known issue that we'll have to resolve this at some point with the dpkg maintainers and the ftpmasters. Untill we resolve this, please take into consideration to avoid filing patches that use netbsd-i386 in a way that breaks the other port. I've been careful to keep such incompatible patches without submitting, since I started. You can fix build issues most of the times by using _GNU_SYSTEM instead of _ARCH variables, though. When it comes to [netbsd-i386] tags in Build-\ Depends fields, both ports will want the same usualy. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: A request from the NetBSD folks [ please discuss ]
On Fri, Dec 05, 2003 at 02:04:20AM +0100, Robert Millan wrote: On Thu, Dec 04, 2003 at 11:22:36AM -0700, Joel Baker wrote: Indeed. As long as it's documented, people are probably going to be hand-selecting their APT entries, anyway, so it isn't such a big deal. [...] The Debian architecture will remain 'netbsd-i386', with the known issue that we'll have to resolve this at some point with the dpkg maintainers and the ftpmasters. Untill we resolve this, please take into consideration to avoid filing patches that use netbsd-i386 in a way that breaks the other port. I've been careful to keep such incompatible patches without submitting, since I started. A bit late for that, I'm afraid; they're already fairly pervasive, particularly throughout the toolchain. You can fix build issues most of the times by using _GNU_SYSTEM instead of _ARCH variables, though. When it comes to [netbsd-i386] tags in Build-\ Depends fields, both ports will want the same usualy. Except in the case of things like libc. Which tend to pop up more than one might imagine. Unfortunately, it's also true that quite a few maintainers already have ARCH logic, and are not entirely amenable to just randomly up and changing this because we can't figure out what we want to do. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpzBs74eD2AI.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
On Wed, Dec 03, 2003 at 09:41:00AM +0100, Guillem Jover wrote: Hi Joel, On Tue, Dec 02, 2003 at 01:50:16PM -0700, Joel Baker wrote: I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about what's going on, and because it doesn't dilute the NetBSD trademark. While the former is less true of, say, my work, the latter is certainly a valid concern. This summer Robert and I were discussing on the naming convention and concluded that we would like to use KFreeBSD wherever possible, for consistrency and to not confuse users or developers, etc. So now we have: uname -s: GNU/KFreeBSD Uhm. I'd have to turn on my box to check this. I think I may have left uname -s alone, but changed uname -v to something like Debian/NetBSD. config.guess triplet: arch-(pc|unknown)-kfreebsdversion-gnu arch-(pc|unknown)-netbsd-gnu Debian port name: Debian GNU/KFreeBSD Debian GNU/NetBSD Debian GNU NetBSD/i386 (yes, it's inconsistant; should perhaps be Debian GNU/NetBSD(i386), or whatever variant on that we end up with) Debian arch name: freebsd-arch netbsd-arch (specfically, -i386) The Debian arch name is not consistent, because the dpkg maintainers disagreed with the name change, and we didn't want to discuss it endlessly, we wanted the patches integrated to have a functional system. Frankly, they're probably waiting to see who emerges from the smoke and rubble as actually capable of being used as a working port... My question is, what names were you thinking on changing (if that change is considered) ? The config.guess triple is going to be exceptionalyl difficult to change at this point, for very little return (and the -gnu suffix is already sufficient to indicate exactly what's going on, in the exact sense that config.guess uses those fields; a NetBSD core, with gnu userland). The port name is trivial to change; I think the only places it shows up regularly are the web pages (which DDs can get access to fix, including myself), and my .signature. :) The arch name isn't going to change, for obvious reasons, I think. I've waffled extensively over what various parts of uname should say, though I'd like to have some rational, useful way of deciding that. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpq6RyeOMOBJ.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
Hi Joel, On Tue, Dec 02, 2003 at 01:50:16PM -0700, Joel Baker wrote: I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about what's going on, and because it doesn't dilute the NetBSD trademark. While the former is less true of, say, my work, the latter is certainly a valid concern. This summer Robert and I were discussing on the naming convention and concluded that we would like to use KFreeBSD wherever possible, for consistrency and to not confuse users or developers, etc. So now we have: uname -s: GNU/KFreeBSD config.guess triplet: arch-(pc|unknown)-kfreebsdversion-gnu Debian port name: Debian GNU/KFreeBSD Debian arch name: freebsd-arch The Debian arch name is not consistent, because the dpkg maintainers disagreed with the name change, and we didn't want to discuss it endlessly, we wanted the patches integrated to have a functional system. My question is, what names were you thinking on changing (if that change is considered) ? regards, guillem
A request from the NetBSD folks [ please discuss ]
I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about what's going on, and because it doesn't dilute the NetBSD trademark. While the former is less true of, say, my work, the latter is certainly a valid concern. Of course, this leads to the question of naming things for the ports that use native libc rather than GNU libc. KLNetBSD (Kernel + Libc)? KCNetBSD (Kernel + libC, Kernel + Core)? CNetBSD (Core)? Debian GNU/MostlyNetBSD? NotQuiteNetBSD? :) But seriously - since it is not unreasonable to view NetBSD as not only /usr/src, but /usr/pkgsrc and the bug system and everything the project does, is there some meaningful way of representing what pieces we *are* using, for those of us using the kernel and libc? -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp5ErcrbL3DU.pgp Description: PGP signature
Re: A request from the NetBSD folks [ please discuss ]
Joel Baker [EMAIL PROTECTED] schrieb am 02.12.03 21:51:20: I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about If the NetBSD people are concerned about that, why should we not help them? Michael what's going on, and because it doesn't dilute the NetBSD trademark. While the former is less true of, say, my work, the latter is certainly a valid concern. Of course, this leads to the question of naming things for the ports that use native libc rather than GNU libc. KLNetBSD (Kernel + Libc)? KCNetBSD (Kernel + libC, Kernel + Core)? CNetBSD (Core)? Debian GNU/MostlyNetBSD? NotQuiteNetBSD? :) But seriously - since it is not unreasonable to view NetBSD as not only /usr/src, but /usr/pkgsrc and the bug system and everything the project does, is there some meaningful way of representing what pieces we *are* using, for those of us using the kernel and libc? -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- __ Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2 Kostenlos downloaden: http://screensaver.web.de/?mc=021110
Re: A request from the NetBSD folks [ please discuss ]
On Tue, Dec 02, 2003 at 10:49:42PM +0100, Michael Ritzert wrote: Joel Baker [EMAIL PROTECTED] schrieb am 02.12.03 21:51:20: I've been contacted by a member of the NetBSD team, who expressed that the general opinion seems to be that Debian GNU/KNetBSD is a better name for the port than Debian GNU/NetBSD, both because it is more specific about If the NetBSD people are concerned about that, why should we not help them? My impression is that 'concerned' might be a bit of an overstatement. It seems more like someone saw 'GNU/KNetBSD', and said Hey, that actually seems like it might be a better way to describe it. However, since I don't want to cause drastic confusion or simply co-opt the name Robert has been using (and since, as noted in the origional message, it's not quite as accurate for the work others are doing), I wanted to raise the issue to the Debian BSD list at large. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpDUYppURsDR.pgp Description: PGP signature
User remove request
This user requested to be removed from your list. They have been automatically removed from the system. Please also make sure to remove: debian-bsd@lists.debian.org from all offline or backup lists you may maintain.
re: NetBSD: 1.6.1 or -current? Major discussion request.
1) __cxa_atexit - This can be worked around (GCC is patched to avoid using it), but it's fugly and really should be fixed. Conveniently, in -current, it is (after a PR requesting it). Can be backported, though I'm not entirely sure I'm comfortable with that, given how it affects every single C++ program ever compiled. i don't see why it would really be such a problem to backport this. 2) ftw()/nftw() - This will be going into -current in a few days (and replace the workaround jftw package). It really belongs in libc, not in a separate library, and it will be there. Backporting this should be fairly trivial, as it's completely new code that doesn't really interact iwth anything else except for calling the pts suite. APT absolutely must have this to build, however. (And it's a POSIX requirement, too.) this should definately go into the netbsd libc. 3) POSIX threads - This is a killer; tcl8.4 *must* be threaded, and is breaking horribly with GNU pthreads (both 1.x and 2.x). Python depends on TCL; a whole *lot* of things depend on python (or TCL), or on something that does. The threading changes are so extensive that it's probably more or less implausible to backport them to a 1.6 tree, since they were started on post-1.6-release code. actually the threading changes were started a couple of years ago :) you are 100% correct that attempting to backport would be a complete waste of time, however. 4) Not-really-an-issue - i386 SMP. There is a working release of the i386/SMP branch against 1.6(.1), so it's by no means crucial, but -current supports this in the core code, and it would be nice to support it where we can (but an SMP patch is probably sufficient, if staying on 1.6.1). also - sparc SMP only exists in -current. So the question is - should I/we bail on trying to build a release on 1.6.x, and do one from -current instead? If it weren't for the POSIX threads problem, I'd consider it, but that change is so invasive *and* pervasive that it affects basically every application on the system in one way or another, and it is COMPLETELY incompatible with anything compiled against GNU pth pthreads - so the transition to 1.7 would be an utter and royal pain in the arse to manage, and/or require a flag day (remove evreything in the archive, upload new stuff). I can do flag days on my archive easily enough (and have been considering it, since the build environment is currently far cleaner than it used to be), but it will be a very bad sign to the ftpmasters if we have to do it once we're in the main archive. Personally, I vote for rebuilding based on -current; however, since I'm far from the only person doing this, and I'd like to have some chance of not crossing over each other's work, I'd like to hear other opinions. the alternative is to get a modern kernel libpthread ( libc? i'm not sure) but to leave the rest of userland alone. then again i've been running netbsd-current systems almost exclusively for nearly 10 years (i have run some work/customer machines with releases... but never my own.) -current works well nearly all of the time. if you pick a snapshot, try it out for a while and if it is good, use it. i could expand more if you want :-) .mrg.
Re: NetBSD: 1.6.1 or -current? Major discussion request.
On Sat, Jun 07, 2003 at 01:45:40PM +1000, matthew green wrote: 1) __cxa_atexit - This can be worked around (GCC is patched to avoid using it), but it's fugly and really should be fixed. Conveniently, in -current, it is (after a PR requesting it). Can be backported, though I'm not entirely sure I'm comfortable with that, given how it affects every single C++ program ever compiled. i don't see why it would really be such a problem to backport this. It probably isn't. There *might* be some care needed to avoid pulling in pthread-related stuff, but overally, I think it would be doable. 2) ftw()/nftw() - This will be going into -current in a few days (and replace the workaround jftw package). It really belongs in libc, not in a separate library, and it will be there. Backporting this should be fairly trivial, as it's completely new code that doesn't really interact iwth anything else except for calling the pts suite. APT absolutely must have this to build, however. (And it's a POSIX requirement, too.) this should definately go into the netbsd libc. The only reason it isn't there yet is because I haven't gotton the final form that's going into -current. :) 3) POSIX threads - This is a killer; tcl8.4 *must* be threaded, and is breaking horribly with GNU pthreads (both 1.x and 2.x). Python depends on TCL; a whole *lot* of things depend on python (or TCL), or on something that does. The threading changes are so extensive that it's probably more or less implausible to backport them to a 1.6 tree, since they were started on post-1.6-release code. actually the threading changes were started a couple of years ago :) you are 100% correct that attempting to backport would be a complete waste of time, however. Well, okay. The *major* ones happened post-1.6, but it's a long and ongoing saga. :) 4) Not-really-an-issue - i386 SMP. There is a working release of the i386/SMP branch against 1.6(.1), so it's by no means crucial, but -current supports this in the core code, and it would be nice to support it where we can (but an SMP patch is probably sufficient, if staying on 1.6.1). also - sparc SMP only exists in -current. Didn't know that, but one more reason :) So the question is - should I/we bail on trying to build a release on 1.6.x, and do one from -current instead? If it weren't for the POSIX threads problem, I'd consider it, but that change is so invasive *and* pervasive that it affects basically every application on the system in one way or another, and it is COMPLETELY incompatible with anything compiled against GNU pth pthreads - so the transition to 1.7 would be an utter and royal pain in the arse to manage, and/or require a flag day (remove evreything in the archive, upload new stuff). I can do flag days on my archive easily enough (and have been considering it, since the build environment is currently far cleaner than it used to be), but it will be a very bad sign to the ftpmasters if we have to do it once we're in the main archive. Personally, I vote for rebuilding based on -current; however, since I'm far from the only person doing this, and I'd like to have some chance of not crossing over each other's work, I'd like to hear other opinions. the alternative is to get a modern kernel libpthread ( libc? i'm not sure) but to leave the rest of userland alone. then again i've been running netbsd-current systems almost exclusively for nearly 10 years (i have run some work/customer machines with releases... but never my own.) -current works well nearly all of the time. if you pick a snapshot, try it out for a while and if it is good, use it. I don't generally have issues with -current, though I don't think I'd want to claim we should release with that as the core. Mostly, the question was should I schedule a Flag Day and wipe out the current NetBSD archive (well, okay, probably 'move it aside' for now), and do a set of builds based on -current. So far, the concensus on IRC and here seems to be 'yes'. -- Joel Baker [EMAIL PROTECTED] pgpTnKFkpOcRd.pgp Description: PGP signature
NetBSD: 1.6.1 or -current? Major discussion request.
So. I've been building stuff based on 1.6(.1) for a while now, since it was the stable release. All well and good. However, recently I've started to run into a fairly serious set of problems (3 of them, total), of which only 2 can be backported. 1) __cxa_atexit - This can be worked around (GCC is patched to avoid using it), but it's fugly and really should be fixed. Conveniently, in -current, it is (after a PR requesting it). Can be backported, though I'm not entirely sure I'm comfortable with that, given how it affects every single C++ program ever compiled. 2) ftw()/nftw() - This will be going into -current in a few days (and replace the workaround jftw package). It really belongs in libc, not in a separate library, and it will be there. Backporting this should be fairly trivial, as it's completely new code that doesn't really interact iwth anything else except for calling the pts suite. APT absolutely must have this to build, however. (And it's a POSIX requirement, too.) 3) POSIX threads - This is a killer; tcl8.4 *must* be threaded, and is breaking horribly with GNU pthreads (both 1.x and 2.x). Python depends on TCL; a whole *lot* of things depend on python (or TCL), or on something that does. The threading changes are so extensive that it's probably more or less implausible to backport them to a 1.6 tree, since they were started on post-1.6-release code. 4) Not-really-an-issue - i386 SMP. There is a working release of the i386/SMP branch against 1.6(.1), so it's by no means crucial, but -current supports this in the core code, and it would be nice to support it where we can (but an SMP patch is probably sufficient, if staying on 1.6.1). So the question is - should I/we bail on trying to build a release on 1.6.x, and do one from -current instead? If it weren't for the POSIX threads problem, I'd consider it, but that change is so invasive *and* pervasive that it affects basically every application on the system in one way or another, and it is COMPLETELY incompatible with anything compiled against GNU pth pthreads - so the transition to 1.7 would be an utter and royal pain in the arse to manage, and/or require a flag day (remove evreything in the archive, upload new stuff). I can do flag days on my archive easily enough (and have been considering it, since the build environment is currently far cleaner than it used to be), but it will be a very bad sign to the ftpmasters if we have to do it once we're in the main archive. Personally, I vote for rebuilding based on -current; however, since I'm far from the only person doing this, and I'd like to have some chance of not crossing over each other's work, I'd like to hear other opinions. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpKUNi9gWCWu.pgp Description: PGP signature
xfree86 4.3.0-0pre1v1 - request for porting help!
Hi guys! You're getting this mail because *BSD doesn't yet support XFree86 4.3.0. As you may or may not know, I have been preparing 4.3.0 packages for some time now, which are soon to become the official packages (an xfree86_4.3.0-0pre1v1 source package from the XSF is expected soonish). Unfortunately, 4.3.0 can't go into sid without all the architectures we support - that's where you guys come in. Porting to XFree86 isn't difficult per se, it just needs a lot of horsepower, and about 4gb of diskspace. The builds for your relevant architectures will fail once: I'll need the debian/MANIFEST.$(ARCH).new file, and I'll then send you an updated source package, which should produce a complete build. If you are interested in porting the XFree86 packages to your architecture (this does not involve code work, most likely), please contact me ASAP, and I will supply you with the source line for preliminary 4.3.0-0pre1v1 packages. I don't want to give it out in public because it isn't released yet, and I fear for my uplink if I do. Thanks for your time, and I hope to hear from some of you soon. :) d -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp20GAVIfn3P.pgp Description: PGP signature
Re: xfree86 4.3.0-0pre1v1 - request for porting help!
On Mon, May 26, 2003 at 10:43:26PM +1000, Daniel Stone wrote: Hi guys! You're getting this mail because *BSD doesn't yet support XFree86 4.3.0. As you may or may not know, I have been preparing 4.3.0 packages for some time now, which are soon to become the official packages (an xfree86_4.3.0-0pre1v1 source package from the XSF is expected soonish). Gah. I kept meaning to get around to looking at those for you. Bad me. Unfortunately, 4.3.0 can't go into sid without all the architectures we support - that's where you guys come in. Porting to XFree86 isn't difficult per se, it just needs a lot of horsepower, and about 4gb of diskspace. The builds for your relevant architectures will fail once: I'll need the debian/MANIFEST.$(ARCH).new file, and I'll then send you an updated source package, which should produce a complete build. Hmmm. This wasn't actually my experience, with 4.2.x; some chunk of the Imakefile stuff had to be changed to handle the concept of BSD kernel/libc/functions, GNU userland, and there was a chunk of changes needed to support the concept of splitting them (or rather, having a new arch ID). If these changes already got rolled into 4.3, though, it should be fairly close and clean. If you are interested in porting the XFree86 packages to your architecture (this does not involve code work, most likely), please contact me ASAP, and I will supply you with the source line for preliminary 4.3.0-0pre1v1 packages. I don't want to give it out in public because it isn't released yet, and I fear for my uplink if I do. Since I did 4.2 for NetBSD, I'm happy to work on 4.3 stuff as well. I have a build machine that can handle it (though it takes about 6 hours for a build). I may have a few other questions for you (Branden ran out of time to try to figure them out for 4.2) about whether certain things need to get built, and whether they have any usefulness. :) If this is the same APT source that you posted to debian-x a while back, I'll grab it from there and try to build it in the next day or two. Thanks for your time, and I hope to hear from some of you soon. Not a problem. Believe me, I want a working X setup. :) Keep in mind that, so far, we don't have either port up to the point where you could really sanely log in and work on a console, probably, so the video stuff hasn't gotton significant testing. The server-X stuff for 4.2 has been running on my box for at least six months, though, and seems to be fine :) -- Joel Baker [EMAIL PROTECTED] pgph1C1amT7o1.pgp Description: PGP signature
Re: xfree86 4.3.0-0pre1v1 - request for porting help!
On Mon, May 26, 2003 at 10:00:03AM -0600, Joel Baker wrote: On Mon, May 26, 2003 at 10:43:26PM +1000, Daniel Stone wrote: You're getting this mail because *BSD doesn't yet support XFree86 4.3.0. As you may or may not know, I have been preparing 4.3.0 packages for some time now, which are soon to become the official packages (an xfree86_4.3.0-0pre1v1 source package from the XSF is expected soonish). Gah. I kept meaning to get around to looking at those for you. Bad me. No worries. :) Unfortunately, 4.3.0 can't go into sid without all the architectures we support - that's where you guys come in. Porting to XFree86 isn't difficult per se, it just needs a lot of horsepower, and about 4gb of diskspace. The builds for your relevant architectures will fail once: I'll need the debian/MANIFEST.$(ARCH).new file, and I'll then send you an updated source package, which should produce a complete build. Hmmm. This wasn't actually my experience, with 4.2.x; some chunk of the Imakefile stuff had to be changed to handle the concept of BSD kernel/libc/functions, GNU userland, and there was a chunk of changes needed to support the concept of splitting them (or rather, having a new arch ID). If these changes already got rolled into 4.3, though, it should be fairly close and clean. I did merge all the 4.2.x debian/patches stuff for *BSD, into 4.3. If you are interested in porting the XFree86 packages to your architecture (this does not involve code work, most likely), please contact me ASAP, and I will supply you with the source line for preliminary 4.3.0-0pre1v1 packages. I don't want to give it out in public because it isn't released yet, and I fear for my uplink if I do. Since I did 4.2 for NetBSD, I'm happy to work on 4.3 stuff as well. I have a build machine that can handle it (though it takes about 6 hours for a build). I may have a few other questions for you (Branden ran out of time to try to figure them out for 4.2) about whether certain things need to get built, and whether they have any usefulness. :) Sure. Thanks a lot. :) If this is the same APT source that you posted to debian-x a while back, I'll grab it from there and try to build it in the next day or two. Nope; I've sent it to you privately. Thanks for your time, and I hope to hear from some of you soon. Not a problem. Believe me, I want a working X setup. :) Keep in mind that, so far, we don't have either port up to the point where you could really sanely log in and work on a console, probably, so the video stuff hasn't gotton significant testing. The server-X stuff for 4.2 has been running on my box for at least six months, though, and seems to be fine :) Ah, OK. Well, I'll be glad to see it completed, too. :) -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpPD5UxT62qo.pgp Description: PGP signature
Re: GPL clarification request (Debian GNU/NetBSD port)
A preliminary inspection indicates that most of the required pieces fall under the old BSD license, with a few under the revised BSD license or the GNU GPL. The majority of these have copyrights by either UCB or The NetBSD Foundation, Inc. (TNF) If the copyright is UCB, you can change the license. UCB already said so. If the copyright is TNF, you can't. I suggest you get these programs from FreeBSD instead of from NetBSD. The FreeBSD people did make that license change. Is it the intent of the GPL, as it currently stands, that this situation (system libraries which are under a 4-clause/old BSD license) should permit binaries licensed under it to link against those system libraries, when the system libraries are distributed as part of one package, and the GPL-licensed binaries as part of a separate package? When they are distributed separately, that is clearly permitted. GPL version 2 does not permit distributing them together, but we have always treated this as ok in the normal cases. In fact, I am trying to rewrite the so-called system library exception for GPL 3 so that this is clearly permitted in the cases that are harmless.
GPL clarification request (Debian GNU/NetBSD port)
[ Please note: this message is sent as an interested party who is working ] [ on the Debian GNU/NetBSD project; I am in no way speaking on behalf of ] [ Debian in any official capacity.] Recently I came across a possible licensing conflict on one of the Debian projects I'm participating in (the Debian GNU/NetBSD port), and after some discussion of it on the debian-legal mailing list, there wasn't much of a concensus other than RMS clarifying it would help. A quick summary: 1) The NetBSD source tree (that is, the sources which can be found at the official NetBSD CVS server, and from which the NetBSD releases are drawn) has a number of sections to it, with widely varying licenses (though most can be classed as 'old BSD', 'revised BSD', 'derived from old BSD', 'GNU GPL', or 'GNU LGPL'). 2) Not all of the sections in 1 are relevant to the Debian/NetBSD port. In fact, quite a few of them are third-party software which is already packaged separately under Debian. However, the sections which can best be classed as the kernel (sys/ in the CVS tree), system libraries (lib/ and libexec/), and potentially some portions of the userland (bin/ and specific cases in usr.bin/ and usr.sbin/) are necessary. A preliminary inspection indicates that most of the required pieces fall under the old BSD license, with a few under the revised BSD license or the GNU GPL. The majority of these have copyrights by either UCB or The NetBSD Foundation, Inc. (TNF) 3) TNF has previously expressed a resistance to requests to move from an old BSD license to a revised one (that is, to drop the advertising clause). While it may be possible to convince them to change this at some point in time, it would be infeasible to assume that this can be accomplished soon, if at all. 4) While significant portions of the code have been retroactively relicensed by UCB's fiat, there remain significant portions which have not, as they are not under UCB's copyright. The question: Is it the intent of the GPL, as it currently stands, that this situation (system libraries which are under a 4-clause/old BSD license) should permit binaries licensed under it to link against those system libraries, when the system libraries are distributed as part of one package, and the GPL-licensed binaries as part of a separate package? (Specifically, both the binary and source forms of the packages would be available in the standard Debian distribution archives.) I understand that this doesn't apply to normal libraries which are not GPL-compatible (Debian does not, of course, knowingly ship packages which have GPL-licensed binaries linked to libraries which are not under a GPL compatible license); this question is solely about linking against the libraries which are build from the non-third-party source found in the NetBSD souce tree. While it would seem likely that prohibiting this is not the intent of the GPL or the FSF (since NetBSD distributes GCC along with it's current releases, and has not, to the best of my knowlege, received complaints), it would be of great assistance in clarifying the situation for Debian if you could comment on it. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgp3fFwPfrKoV.pgp Description: PGP signature
[Fwd: ftp.debian.org: New architecture request]
Original Message Delivered-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] Received: from localhost (localhost [127.0.0.1]) (uid 1032) by quic.net with local; Tue, 14 May 2002 15:13:33 -0400 From: Nathan Hawkins [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: ftp.debian.org: New architecture request X-Mailer: reportbug 1.50 Date: Tue, 14 May 2002 15:13:33 -0400 Message-ID: [EMAIL PROTECTED] Package: ftp.debian.org Version: N/A; reported 2002-05-14 Severity: normal Please add the architecture freebsd-i386 to the archive. This port runs on the FreeBSD kernel and libc. Thanks, ---Nathan -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux romulus 2.4.17-rc1 #1 SMP Sat Dec 15 23:58:13 EST 2001 i686 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Request For Information
Hello, Could you please direct this request to the proper party or department? We would like to get some additional information about your business in an effort to explore the ways that we might be able to work together. If possible, we would like to receive your media package. If you have an interest, please respond to the address below, or visit our web site. Please send to: If by e-mail: [EMAIL PROTECTED] If by mail: WebStream Internet Solutions Outsourcing Department 2200 W.Commercial Blvd. Suite 204 Ft. Lauderdale, FL 33309 USA Thank you very much. Josh Winters [EMAIL PROTECTED] http://webstream.net Design * Programming * Virtual and Dedicated Server Hosting Since 1997
Re: Request For Information
Debian is a non-profit organization for the purpose of promoting free software and the Debian/GNU operating system, which is a functional operating system for a variety of architectures, composed entirely of 'free as in speech' software.. You can find more information about us at this URI: http://www.debian.org/intro/about We are not, however, interested in purchasing commercial web design/hosting services at this time. Also in future, we would appreciate if you do not send unsolicited advertisements/similar requests to our public mailing lists, as it just results in more mail for many busy people. - Brian On Thu, Aug 30, 2001 at 10:04:53AM -0500, [EMAIL PROTECTED] wrote: Hello, Could you please direct this request to the proper party or department? We would like to get some additional information about your business in an effort to explore the ways that we might be able to work together. If possible, we would like to receive your media package. If you have an interest, please respond to the address below, or visit our web site. Please send to: If by e-mail: [EMAIL PROTECTED] If by mail: WebStream Internet Solutions Outsourcing Department 2200 W.Commercial Blvd. Suite 204 Ft. Lauderdale, FL 33309 USA Thank you very much. Josh Winters [EMAIL PROTECTED] http://webstream.net Design * Programming * Virtual and Dedicated Server Hosting Since 1997 -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
