Re: hppa nptl switch
Interesting, I wasn't aware that this was a requirement of a partial upgrade. Thanks for bringing this to my attention. I'll go back and have a look at your previous proposal. The static initializer are (re-)exposed by some headers like , . There is no guarantee that library and applications are compiled against the same set of (e)glibc headers. GLIBC does not guarantee this type of compatibility. When upstream GLIBC versioned the pthread_cond_t interfaces there were exactly the same guarantees that I provide now. All parts of the program must use the same ABI. How did debian handle the pthread_cond_t changeover in 2.3.2? I do not know what changed in 2.3.2 in linuxthreads/condvar.c, there is obviously some padding in pthread_cond_t. As long as the size of pthread_cond_t remains the same and "bytes" initialized in the new initializer are the same as "bytes" in the old initializer, it should be OK. Of course, old initializer might initialize more bytes compared to new one. So, every time that upstream breaks ABI, does it cause a serious problem for partial upgrades? There has never been support for a mixed-ABI, which is what you are asking for. I am asking for * sizeof() have to be the same for old and new structures * new functions have to cope with old static initializers properly * pthread_mutex_t.__m_kind have to retain the same offset, similarly for other user specifiable attributes in initializers I would describe it as be-backward-compatible. You did express some concern that these configurations should work, but you never identified that these were specifically important to the debian upgrade process. To clarify, I am not member of release team, in fact I am not even DD. AFAIK, it should be possible to start with plain lenny installation, upgrade some packages to (current) squeeze and all should still work. Cheers Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
Hi, especially Aurelien and Cyril ;-) IMHO, we should discuss it here and to -release sent only result. As announced on dda [RT1], we want to get an impression when releasing Squeeze is feasible. We have proposed a (quite ambitious) freeze in December 2009, and some developers have noted that their planned changes wouldn't be possible in this time frame. So, to find out when releasing would work for most people, it would be great if you could answer the following questions: Do you have any big changes planned? How much time would they take, and what consequences are there for the rest of the project? How many "big" transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? * decide version of kernel and related utilities. It mainly depends on freeze time. Currently we use 7.2. The 8.0 should appear soon, but dot-zero is dot-zero ;-) May be 7.3 would be released before freeze. * get rid of libfreebsd It waits for eglibc 2.10 upload, only 2 or 3 packages which b-d on libfreebsd-dev are not maintained by kfreebsd porters. Some binNMUs will be also needed. * gnat availability on kfreebsd-amd64 gnat have been recently ported/bootstrapped on kfreebsd-amd64, this fact should propagate into debian/control files of ada related source packages. * ghc6 availability on kfreebsd-amd64 ghc6 is not yet available on kfreebsd-amd64, it have to be ported/bootstrapped. The 6.10 series does not support bootstrapping at all, the 6.12 should be much better, it should also eliminate the need of MAP_32BIT flag of mmap(), which is not available under FreeBSD kernel. When ghc6 6.12 become available, there will be need to change debian/control files of ghc6 related source packages. * FTBFS on GNU/kFreeBSD with patches in BTS * entries in Packages-arch-specific * port of Debian Installer for GNU/kFreeBSD What else ? Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
On Wed, Aug 19, 2009 at 10:56:33AM +0200, Petr Salinger wrote: > Hi, Hi, > especially Aurelien and Cyril ;-) > > IMHO, we should discuss it here and to -release sent only result. That was on my TODO list for a few days, but you have been faster ;) >> As announced on dda [RT1], we want to get an impression when releasing >> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December >> 2009, and some developers have noted that their planned changes wouldn't be >> possible in this time frame. So, to find out when releasing would work for >> most people, it would be great if you could answer the following questions: >> >> Do you have any big changes planned? How much time would they take, and >> what consequences are there for the rest of the project? >> >> How many "big" transitions will the upcoming changes cause? When should those >> happen? Can we do something to make them easier? > > > * decide version of kernel and related utilities. > It mainly depends on freeze time. Currently we use 7.2. The 8.0 should > appear soon, but dot-zero is dot-zero ;-) May be 7.3 would be released > before freeze. I think we should definitely offer and support kernel 8.0. However, I am not sure if it should be the default. I agree that 8.1 would be a lot better, not sure when it is planned. > * get rid of libfreebsd > It waits for eglibc 2.10 upload, only 2 or 3 packages which b-d on > libfreebsd-dev are not maintained by kfreebsd porters. Some binNMUs > will be also needed. That should be really easy to do once eglibc 2.10 is in unstable. I don't think it will be a problem for the release. > * gnat availability on kfreebsd-amd64 > gnat have been recently ported/bootstrapped on kfreebsd-amd64, > this fact should propagate into debian/control files of ada related > source packages. I have already asked for Package-arch-specific changes. Maybe we should already fill bug for those ones? > * ghc6 availability on kfreebsd-amd64 > ghc6 is not yet available on kfreebsd-amd64, it have to be > ported/bootstrapped. The 6.10 series does not support bootstrapping > at all, the 6.12 should be much better, it should also eliminate > the need of MAP_32BIT flag of mmap(), which is not available under > FreeBSD kernel. When ghc6 6.12 become available, there will be need > to change debian/control files of ghc6 related source packages. Yes, that's something we definitely need for the release. > * FTBFS on GNU/kFreeBSD with patches in BTS As GNU/kFreeBSD is a release goal, it is now possible to NMU those packages without any problem providing we respect the procedure (actually we already started). The main problem given the number of affected packages is probably the available manpower to do NMU. > * entries in Packages-arch-specific It is very easy to get that changed now. Either fill a bug against buildd.debian.org, or publish your git tree and ask for a merge. We already added a few packages there recently, maybe you have a more detailed list already? > * port of Debian Installer for GNU/kFreeBSD > That is currently on good track, at least for a basic version without all the options enabled (gtk mode, UTF-8 console, ...). Currently the kfreebsd branch is being merged into trunk. The remaining problems that needs a lot of manpower are probably: - porting network related applets of busybox (currently we are using a mix of freebsd-utils and change in netcfg, that's not suitable for official release). - merging busybox patches upstream - provide a way to configure the keyboard (related to the console-setup entry below. > What else ? The release team will judge if this port can be released based on: - percentage of packages built - presence of an installer - infrastructure (DSAed build daemons, DSAed porter machines) - general usability of the port For the two first entries, we are already working on that, we should just hope having enough time to do that before the release; For the infrastructure point, I have already interacted with the DSA team and provided them an installation media, I should probably ping them. For the general usability of the port I would propose to make sure of a few points: - That Xorg works correctly on standard hardware. This is not the case currently as there is a problem with keyboard (already addressed) and mouse (still problematic, see the thread on the mailing list). - Standard desktop environment are installable and work. Gnome and KDE comes to mind, but we should probably check a few more - Standard server packages (web, ftp, dns, mail) works. If we still have more time I think we should probably have the following things working: - ZFS support. Kernel support should be there with the next kernel upload, but there is still all the userland libs/tools to package. - Keyboard configuration with console-setup. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net
Re: Xorg & HAL on GNU/kFreeBSD
On Thu, Aug 13, 2009 at 11:50:11PM +0200, Aurelien Jarno wrote: > - You have to drop the same kind of file for the mouse (see attached > file 10-x11-input-mouse.fdi) to /etc/hal/fdi/policy. I haven't > reported the bug to the BTS, as it don't fully work here. While the > mouse is detected correctly, the cursor doesn't move. It seems to work with an USB mouse, but I still haven't manage to solve the issue with a PS/2 mouse. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
Hi. Aurelien Jarno (19/08/2009): > > * gnat availability on kfreebsd-amd64 > > gnat have been recently ported/bootstrapped on kfreebsd-amd64, > > this fact should propagate into debian/control files of ada related > > source packages. > > I have already asked for Package-arch-specific changes. Maybe we > should already fill bug for those ones? The earlier, the better, I believe. > > * ghc6 availability on kfreebsd-amd64 ghc6 is not yet available on > > kfreebsd-amd64, it have to be ported/bootstrapped. The 6.10 > > series does not support bootstrapping at all, the 6.12 should be > > much better, it should also eliminate the need of MAP_32BIT flag > > of mmap(), which is not available under FreeBSD kernel. When > > ghc6 6.12 become available, there will be need to change > > debian/control files of ghc6 related source packages. > > Yes, that's something we definitely need for the release. I'd like to try harder on this one, be it with 6.10 or 6.11+something. Looks like non-trivial, but possible, provided upstream is responsive. Will look into it. > > * FTBFS on GNU/kFreeBSD with patches in BTS > > As GNU/kFreeBSD is a release goal, it is now possible to NMU those > packages without any problem providing we respect the procedure > (actually we already started). The main problem given the number of > affected packages is probably the available manpower to do NMU. I'll probably concentrate on those, and on RC bugfixes that prevent packages to be built, i.e. FTBFS that appear on every arch. Mraw, KiBi. signature.asc Description: Digital signature
Re: BSD port plans for the squeeze cycle
Cyril Brulebois a écrit : > Hi. > > Aurelien Jarno (19/08/2009): >>> * gnat availability on kfreebsd-amd64 >>> gnat have been recently ported/bootstrapped on kfreebsd-amd64, >>> this fact should propagate into debian/control files of ada related >>> source packages. >> I have already asked for Package-arch-specific changes. Maybe we >> should already fill bug for those ones? > > The earlier, the better, I believe. > OK, I'll fill those bugs then. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
Aurelien Jarno dixit: >> * port of Debian Installer for GNU/kFreeBSD >That is currently on good track makefs is still hanging in NEW (but I hope not for much longer ;) //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
Thorsten Glaser a écrit : > Aurelien Jarno dixit: > >>> * port of Debian Installer for GNU/kFreeBSD > >> That is currently on good track > > makefs is still hanging in NEW (but I hope not for much longer ;) Like hundred of packages... But I am sure it will be out of NEW before squeeze :). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: BSD port plans for the squeeze cycle
* ghc6 availability on kfreebsd-amd64 ghc6 is not yet available on kfreebsd-amd64, it have to be ported/bootstrapped. The 6.10 series does not support bootstrapping at all, the 6.12 should be much better, it should also eliminate the need of MAP_32BIT flag of mmap(), which is not available under FreeBSD kernel. When ghc6 6.12 become available, there will be need to change debian/control files of ghc6 related source packages. Yes, that's something we definitely need for the release. I'd like to try harder on this one, be it with 6.10 or 6.11+something. Looks like non-trivial, but possible, provided upstream is responsive. Will look into it. I gently tried some time ago with upstream snapshot, using instructions http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I failed, attached are preliminary patches, they can be used as a start. Good luck ;-) Petr ghc.tar Description: Unix tar archive
Re: BSD port plans for the squeeze cycle
Aurelien Jarno a écrit : > Cyril Brulebois a écrit : >> Hi. >> >> Aurelien Jarno (19/08/2009): * gnat availability on kfreebsd-amd64 gnat have been recently ported/bootstrapped on kfreebsd-amd64, this fact should propagate into debian/control files of ada related source packages. >>> I have already asked for Package-arch-specific changes. Maybe we >>> should already fill bug for those ones? >> The earlier, the better, I believe. >> > > OK, I'll fill those bugs then. 15 bugs filled (not all of the Ada packages have a restricted list of architectures). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xorg & HAL on GNU/kFreeBSD
On Wed, Aug 19, 2009 at 02:38:08PM +0200, Aurelien Jarno wrote: > On Thu, Aug 13, 2009 at 11:50:11PM +0200, Aurelien Jarno wrote: > > - You have to drop the same kind of file for the mouse (see attached > > file 10-x11-input-mouse.fdi) to /etc/hal/fdi/policy. I haven't > > reported the bug to the BTS, as it don't fully work here. While the > > mouse is detected correctly, the cursor doesn't move. > > It seems to work with an USB mouse, but I still haven't manage to solve > the issue with a PS/2 mouse. Actually PS/2 mice work well with a 7.1 kernel, but not with a 7.2 one. The old version of Xorg from debian-ports works with both 7.1 and 7.2 kernels. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xorg & HAL on GNU/kFreeBSD
On Wed, Aug 19, 2009 at 07:00:48PM +0200, Aurelien Jarno wrote:
> On Wed, Aug 19, 2009 at 02:38:08PM +0200, Aurelien Jarno wrote:
> > On Thu, Aug 13, 2009 at 11:50:11PM +0200, Aurelien Jarno wrote:
> > > - You have to drop the same kind of file for the mouse (see attached
> > > file 10-x11-input-mouse.fdi) to /etc/hal/fdi/policy. I haven't
> > > reported the bug to the BTS, as it don't fully work here. While the
> > > mouse is detected correctly, the cursor doesn't move.
> >
> > It seems to work with an USB mouse, but I still haven't manage to solve
> > the issue with a PS/2 mouse.
>
> Actually PS/2 mice work well with a 7.1 kernel, but not with a 7.2 one.
> The old version of Xorg from debian-ports works with both 7.1 and 7.2
> kernels.
>
Continuing my monologue, I have found that *reverting* the following
patch fixes or workaround the problem. But doing so may also hide a
problem elsewhere. Any idea?
r189870 | rnoland | 2009-03-16 09:21:51 +0100 (lun. 16 mars 2009) | 6 lignes
Teach psm about O_ASYNC
This makes Xorg happy if you aren't using moused.
MFC after: 3 days
Index: sys/dev/atkbdc/psm.c
===
--- sys/dev/atkbdc/psm.c(.../7.1.0/sys/dev/atkbdc) (révision
196387)
+++ sys/dev/atkbdc/psm.c(.../7.2.0/sys/dev/atkbdc) (révision
196387)
@@ -70,7 +70,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -212,6 +215,7 @@
struct cdev *bdev;
int lasterr;
int cmdcount;
+ struct sigio*async; /* Processes waiting for SIGIO */
};
static devclass_t psm_devclass;
#definePSM_SOFTC(unit) \
@@ -1383,6 +1387,7 @@
sc->mode.level = sc->dflt_mode.level;
sc->mode.protocol = sc->dflt_mode.protocol;
sc->watchdog = FALSE;
+ sc->async = NULL;
/* flush the event queue */
sc->queue.count = 0;
@@ -1522,6 +1527,12 @@
/* remove anything left in the output buffer */
empty_aux_buffer(sc->kbdc, 10);
+ /* clean up and sigio requests */
+ if (sc->async != NULL) {
+ funsetown(&sc->async);
+ sc->async = NULL;
+ }
+
/* close is almost always successful */
sc->state &= ~PSM_OPEN;
kbdc_lock(sc->kbdc, FALSE);
@@ -2083,6 +2094,15 @@
break;
#endif /* MOUSE_GETHWID */
+ case FIONBIO:
+ case FIOASYNC:
+ break;
+ case FIOSETOWN:
+ error = fsetown(*(int *)addr, &sc->async);
+ break;
+ case FIOGETOWN:
+ *(int *) addr = fgetown(&sc->async);
+ break;
default:
return (ENOTTY);
}
@@ -2972,6 +2992,9 @@
wakeup(sc);
}
selwakeuppri(&sc->rsel, PZERO);
+ if (sc->async != NULL) {
+ pgsigio(&sc->async, SIGIO, 0);
+ }
sc->state &= ~PSM_SOFTARMED;
splx(s);
}
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xorg & HAL on GNU/kFreeBSD
Actually PS/2 mice work well with a 7.1 kernel, but not with a 7.2 one. The old version of Xorg from debian-ports works with both 7.1 and 7.2 kernels. Continuing my monologue, I have found that *reverting* the following patch fixes or workaround the problem. But doing so may also hide a problem elsewhere. Any idea? Revert it for now. Currently, xorg is the main user of mouse device, we do not support moused yet. It would be much better to have xorg working just now. Thanks for investigating this Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
