Re: status of flash9/flash10 support in RELENG_7 ?
On Sun, Jul 26, 2009 at 08:20:09AM +0200, barbara wrote: > > > > An example of the URLs that is giving me problems is the following > > > > http://tv.repubblica.it/copertina/massa-colpito-da-un-detrito/35446?video > > > > (basically all videos from that site cause the same problem). I would be > > grateful if you cold check it. > > > > > The video looks fine here, even if I'm getting a warning about the flash > version. > http://img24.imageshack.us/img24/2741/screenshotmassacolpitod.png > > I've found that on 7, the better combination for me is > linux-flashplugin9, linux_base-fc4 and compat.linux.osrelease=2.4.2. Same here: the video plays fine on 7.2-S with linux_base-fc4 and linux-flashplugin9 > On CURRENT, using linux_base-f10, I get much more stuck process, while > on 7 it barely happens. On 8-BETA2 with linux_base-f10 and linux-f10-flashplugin10 that video makes npviewer "coredumping". -- Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: regression with jexec?
On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jamie Gritton wrote:
> > Michael Butler wrote:
> >> i...@aaron:/home/imb> sudo jexec 5 tcsh
> >> jexec: Unable to parse jail ID.: No such file or directory
>
> >
> > The symptom in jexec can be fixed by this little patch:
> >
> > Index: usr.sbin/jexec/jexec.c
> > ===
> > --- usr.sbin/jexec/jexec.c(revision 195879)
> > +++ usr.sbin/jexec/jexec.c(working copy)
> > @@ -248,6 +248,7 @@
> > if (argc < 2)
> > usage();
> > if (strlen(argv[0]) > 0) {
> > +errno = 0;
> > jid = (int)strtol(argv[0], NULL, 10);
> > if (errno)
> > err(1, "Unable to parse jail ID.");
>
> Thanks - this certainly cures the effect.
>
> > But the broader problem is malloc. It's leaving errno set to
> > ENOENT when /etc/malloc.conf doesn't exist. This seems like
> > wrong behavior to me.
>
> Seems like a POLA violation to me,
No, this is how errno generally work, it is not changed if no error
happens.
pgpvsKMsQ5s3c.pgp
Description: PGP signature
Re: regression with jexec?
On Sun, 26 Jul 2009, Kostik Belousov wrote:
On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Gritton wrote:
Michael Butler wrote:
i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory
The symptom in jexec can be fixed by this little patch:
Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c(revision 195879)
+++ usr.sbin/jexec/jexec.c(working copy)
@@ -248,6 +248,7 @@
if (argc < 2)
usage();
if (strlen(argv[0]) > 0) {
+errno = 0;
jid = (int)strtol(argv[0], NULL, 10);
if (errno)
err(1, "Unable to parse jail ID.");
Thanks - this certainly cures the effect.
But the broader problem is malloc. It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist. This seems like
wrong behavior to me.
Seems like a POLA violation to me,
No, this is how errno generally work, it is not changed if no error
happens.
I haven't really understood which part, when and why would set the errno in
first place so that it would still be there? Is it something in jexec
that gets the errno in first place or is it something internal to
malloc that sets it returns successfully and doesn't clear it?
--
Bjoern A. Zeeb The greatest risk is not taking one.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: regression with jexec?
Bjoern A. Zeeb wrote:
On Sun, 26 Jul 2009, Kostik Belousov wrote:
On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Gritton wrote:
Michael Butler wrote:
i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory
The symptom in jexec can be fixed by this little patch:
Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c(revision 195879)
+++ usr.sbin/jexec/jexec.c(working copy)
@@ -248,6 +248,7 @@
if (argc < 2)
usage();
if (strlen(argv[0]) > 0) {
+errno = 0;
jid = (int)strtol(argv[0], NULL, 10);
if (errno)
err(1, "Unable to parse jail ID.");
Thanks - this certainly cures the effect.
But the broader problem is malloc. It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist. This seems like
wrong behavior to me.
Seems like a POLA violation to me,
No, this is how errno generally work, it is not changed if no error
happens.
I haven't really understood which part, when and why would set the errno in
first place so that it would still be there? Is it something in jexec
that gets the errno in first place or is it something internal to
malloc that sets it returns successfully and doesn't clear it?
The POLA violation is in malloc - it sets errno even when there was no
error. The allocation succeeded and a pointer was returned, yet errno
was set to ENOENT (not even an error malloc should be able to return).
The fact that malloc looks for an optional config file and doesn't find
one shouldn't be relayed back to the caller in errno. If
/etc/malloc.conf doesn't exist, it should either clear errno after that,
or perhaps restore its previous value. There's also a
getenv("MALLOC_OPTIONS") that can similarly set errno.
Perhaps this has all been gone over before and I missed it (this is from
code that's been stable since 2006), so I wouldn't want to just rush in
and fix malloc. Maybe this general principle has already been discussed
and my viewpoint lost. But if not, it's my opinion that malloc is
acting badly and needs a change.
In the meantime, I have no problem with errno not being cleared in
strtol, and the patch to jexec is correct (though strictly speaking it
shouldn't be necessary since we "know" errno has not yet been set).
- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kern/134584: [panic] spin lock held too long
2009/7/26 barbara : > It happened again, on shutdown. > As the previous time, it happened after a high (for a desktop) uptime and, if > it could matter, after running net-p2p/transmission-gtk2 for several hours. > I don't know if it's related, but often quitting transmission, doesn't > terminate the process. Sometimes it end after several minutes the gui exited, > sometimes it's still running after hours. > I've noticed it as the destination folder is on a manually mounted device and > I can't umount it as fstat reports the device used by a transmission process. > So I often have to kill it. > This happened both the time I had this kind of panic. Can you try to reproduce it with WITNESS and *without* WITNESS_SKIPSPIN? I would need to look at "show alllocks" and possibily "ps" because it seems that the lock owner is preempted but it should not happen while holding a spinlock (unless the acquired spinlock is the one in the preempting path, in this case thought it should drop inside sched_switch() and we can try to understand why that doesn't happen). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: regression with jexec?
On Sun, Jul 26, 2009 at 08:28:05AM -0600, Jamie Gritton wrote:
> Bjoern A. Zeeb wrote:
> >On Sun, 26 Jul 2009, Kostik Belousov wrote:
> >
> >>On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:
> >>>-BEGIN PGP SIGNED MESSAGE-
> >>>Hash: SHA1
> >>>
> >>>Jamie Gritton wrote:
> Michael Butler wrote:
> >i...@aaron:/home/imb> sudo jexec 5 tcsh
> >jexec: Unable to parse jail ID.: No such file or directory
> >>>
>
> The symptom in jexec can be fixed by this little patch:
>
> Index: usr.sbin/jexec/jexec.c
> ===
> --- usr.sbin/jexec/jexec.c(revision 195879)
> +++ usr.sbin/jexec/jexec.c(working copy)
> @@ -248,6 +248,7 @@
> if (argc < 2)
> usage();
> if (strlen(argv[0]) > 0) {
> +errno = 0;
> jid = (int)strtol(argv[0], NULL, 10);
> if (errno)
> err(1, "Unable to parse jail ID.");
> >>>
> >>>Thanks - this certainly cures the effect.
> >>>
> But the broader problem is malloc. It's leaving errno set to
> ENOENT when /etc/malloc.conf doesn't exist. This seems like
> wrong behavior to me.
> >>>
> >>>Seems like a POLA violation to me,
> >>
> >>No, this is how errno generally work, it is not changed if no error
> >>happens.
> >
> >I haven't really understood which part, when and why would set the errno in
> >first place so that it would still be there? Is it something in jexec
> >that gets the errno in first place or is it something internal to
> >malloc that sets it returns successfully and doesn't clear it?
>
> The POLA violation is in malloc - it sets errno even when there was no
> error. The allocation succeeded and a pointer was returned, yet errno
> was set to ENOENT (not even an error malloc should be able to return).
> The fact that malloc looks for an optional config file and doesn't find
> one shouldn't be relayed back to the caller in errno. If
> /etc/malloc.conf doesn't exist, it should either clear errno after that,
> or perhaps restore its previous value. There's also a
> getenv("MALLOC_OPTIONS") that can similarly set errno.
>
> Perhaps this has all been gone over before and I missed it (this is from
> code that's been stable since 2006), so I wouldn't want to just rush in
> and fix malloc. Maybe this general principle has already been discussed
> and my viewpoint lost. But if not, it's my opinion that malloc is
> acting badly and needs a change.
>
> In the meantime, I have no problem with errno not being cleared in
> strtol, and the patch to jexec is correct (though strictly speaking it
> shouldn't be necessary since we "know" errno has not yet been set).
Let me restate that errno is never cleared when no error occured.
It is only set when error took place.
E.g., for syscalls, you should look into errno only if syscall returned
-1, in most cases.
For non-syscall libc functions, you need to clear errno before the call,
then check for the error return (for strtoul that would be ULONG_MAX
or 0), that seems to be missed from your patch, and only then look for
errno.
See RETURN VALUES section of the strtoul(3).
pgpPrL4OtCjEk.pgp
Description: PGP signature
Re: regression with jexec?
Kostik Belousov wrote:
On Sun, Jul 26, 2009 at 08:28:05AM -0600, Jamie Gritton wrote:
Bjoern A. Zeeb wrote:
On Sun, 26 Jul 2009, Kostik Belousov wrote:
On Sat, Jul 25, 2009 at 09:06:34PM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Gritton wrote:
Michael Butler wrote:
i...@aaron:/home/imb> sudo jexec 5 tcsh
jexec: Unable to parse jail ID.: No such file or directory
The symptom in jexec can be fixed by this little patch:
Index: usr.sbin/jexec/jexec.c
===
--- usr.sbin/jexec/jexec.c(revision 195879)
+++ usr.sbin/jexec/jexec.c(working copy)
@@ -248,6 +248,7 @@
if (argc < 2)
usage();
if (strlen(argv[0]) > 0) {
+errno = 0;
jid = (int)strtol(argv[0], NULL, 10);
if (errno)
err(1, "Unable to parse jail ID.");
Thanks - this certainly cures the effect.
But the broader problem is malloc. It's leaving errno set to
ENOENT when /etc/malloc.conf doesn't exist. This seems like
wrong behavior to me.
Seems like a POLA violation to me,
No, this is how errno generally work, it is not changed if no error
happens.
I haven't really understood which part, when and why would set the errno in
first place so that it would still be there? Is it something in jexec
that gets the errno in first place or is it something internal to
malloc that sets it returns successfully and doesn't clear it?
The POLA violation is in malloc - it sets errno even when there was no
error. The allocation succeeded and a pointer was returned, yet errno
was set to ENOENT (not even an error malloc should be able to return).
The fact that malloc looks for an optional config file and doesn't find
one shouldn't be relayed back to the caller in errno. If
/etc/malloc.conf doesn't exist, it should either clear errno after that,
or perhaps restore its previous value. There's also a
getenv("MALLOC_OPTIONS") that can similarly set errno.
Perhaps this has all been gone over before and I missed it (this is from
code that's been stable since 2006), so I wouldn't want to just rush in
and fix malloc. Maybe this general principle has already been discussed
and my viewpoint lost. But if not, it's my opinion that malloc is
acting badly and needs a change.
In the meantime, I have no problem with errno not being cleared in
strtol, and the patch to jexec is correct (though strictly speaking it
shouldn't be necessary since we "know" errno has not yet been set).
Let me restate that errno is never cleared when no error occured.
It is only set when error took place.
E.g., for syscalls, you should look into errno only if syscall returned
-1, in most cases.
For non-syscall libc functions, you need to clear errno before the call,
then check for the error return (for strtoul that would be ULONG_MAX
or 0), that seems to be missed from your patch, and only then look for
errno.
See RETURN VALUES section of the strtoul(3).
All true - and I'll add the check you mention to my patch.
But what about the malloc case? Is it equally valid to say that errno
should not be set when no error occurred? Or are non-syscall libc
functions generally given free reign to overwrite errno in non-error
situations?
- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: regression with jexec?
On Sun, Jul 26, 2009 at 08:50:15AM -0600, Jamie Gritton wrote: > All true - and I'll add the check you mention to my patch. > > But what about the malloc case? Is it equally valid to say that errno > should not be set when no error occurred? Or are non-syscall libc > functions generally given free reign to overwrite errno in non-error > situations? Yes, they have a blanket to override errno when no error is returned to the caller. Malloc is good example. Errno is defined only after error. pgpPibMH5cX84.pgp Description: PGP signature
Re: status of flash9/flash10 support in RELENG_7 ?
On Sun, 2009-07-26 at 10:32 +0200, Marc Fonvieille wrote: > On Sun, Jul 26, 2009 at 08:20:09AM +0200, barbara wrote: > > > > > > An example of the URLs that is giving me problems is the following > > > > > > http://tv.repubblica.it/copertina/massa-colpito-da-un-detrito/35446?video > > > > > > (basically all videos from that site cause the same problem). I would be > > > grateful if you cold check it. > > > > > > > > > The video looks fine here, even if I'm getting a warning about the flash > > version. > > http://img24.imageshack.us/img24/2741/screenshotmassacolpitod.png > > > > I've found that on 7, the better combination for me is > > linux-flashplugin9, linux_base-fc4 and compat.linux.osrelease=2.4.2. > > Same here: the video plays fine on 7.2-S with linux_base-fc4 and > linux-flashplugin9 > > > On CURRENT, using linux_base-f10, I get much more stuck process, while > > on 7 it barely happens. > > On 8-BETA2 with linux_base-f10 and linux-f10-flashplugin10 that video > makes npviewer "coredumping". > This video played on my 8-BETA2 (r195818, SMP, i386) with linux_base-f10 and linux-f10-flashplugin10 without dumping core. Was your BETA2 before or after library version bump and, if latter, did you rebuild all your ports? -- Alexandre Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of flash9/flash10 support in RELENG_7 ?
> On Sun, 2009-07-26 at 10:32 +0200, Marc Fonvieille wrote: > > On Sun, Jul 26, 2009 at 08:20:09AM +0200, barbara wrote: > > > > > > > > An example of the URLs that is giving me problems is the following > > > > > > > > http://tv.repubblica.it/copertina/massa-colpito-da-un-detrito/35446?video > > > > > > > > (basically all videos from that site cause the same problem). I would be > > > > grateful if you cold check it. > > > > > > > > > > > > > The video looks fine here, even if I'm getting a warning about the flash > > > version. > > > http://img24.imageshack.us/img24/2741/screenshotmassacolpitod.png > > > > > > I've found that on 7, the better combination for me is > > > linux-flashplugin9, linux_base-fc4 and compat.linux.osrelease=2.4.2. > > > > Same here: the video plays fine on 7.2-S with linux_base-fc4 and > > linux-flashplugin9 > > > > > On CURRENT, using linux_base-f10, I get much more stuck process, while > > > on 7 it barely happens. > > > > On 8-BETA2 with linux_base-f10 and linux-f10-flashplugin10 that video > > makes npviewer "coredumping". > > > This video played on my 8-BETA2 (r195818, SMP, i386) with linux_base-f10 > and linux-f10-flashplugin10 without dumping core. Was your BETA2 before > or after library version bump and, if latter, did you rebuild all your > ports? > I've cvsupped and rebuilt my system on Jul. 23 and rebuilt all my ports. linux-f10-flashplugin10 is dumping core or not working for me too. BTW, why nspluginwrapper doesn't find the plugin? Barbara ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: regression with jexec?
Kostik Belousov wrote: On Sun, Jul 26, 2009 at 08:50:15AM -0600, Jamie Gritton wrote: All true - and I'll add the check you mention to my patch. But what about the malloc case? Is it equally valid to say that errno should not be set when no error occurred? Or are non-syscall libc functions generally given free reign to overwrite errno in non-error situations? Yes, they have a blanket to override errno when no error is returned to the caller. Malloc is good example. Errno is defined only after error. OK then, patching jexec is all that needs doing; I'll get that in. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of flash9/flash10 support in RELENG_7 ?
On Sun, 2009-07-26 at 18:15 +0200, barbara wrote: > > On Sun, 2009-07-26 at 10:32 +0200, Marc Fonvieille wrote: > > > On Sun, Jul 26, 2009 at 08:20:09AM +0200, barbara wrote: > > > > > > > > > > An example of the URLs that is giving me problems is the following > > > > > > > > > > http://tv.repubblica.it/copertina/massa-colpito-da-un-detrito/35446?video > > > > > > > > > > (basically all videos from that site cause the same problem). I would > > > > > be > > > > > grateful if you cold check it. > > > > > > > > > > > > > > > > > The video looks fine here, even if I'm getting a warning about the > > > > flash version. > > > > http://img24.imageshack.us/img24/2741/screenshotmassacolpitod.png > > > > > > > > I've found that on 7, the better combination for me is > > > > linux-flashplugin9, linux_base-fc4 and compat.linux.osrelease=2.4.2. > > > > > > Same here: the video plays fine on 7.2-S with linux_base-fc4 and > > > linux-flashplugin9 > > > > > > > On CURRENT, using linux_base-f10, I get much more stuck process, while > > > > on 7 it barely happens. > > > > > > On 8-BETA2 with linux_base-f10 and linux-f10-flashplugin10 that video > > > makes npviewer "coredumping". > > > > > This video played on my 8-BETA2 (r195818, SMP, i386) with linux_base-f10 > > and linux-f10-flashplugin10 without dumping core. Was your BETA2 before > > or after library version bump and, if latter, did you rebuild all your > > ports? > > > > I've cvsupped and rebuilt my system on Jul. 23 and rebuilt all my ports. > linux-f10-flashplugin10 is dumping core or not working for me too. > BTW, why nspluginwrapper doesn't find the plugin? sunny:RabbitsDen>nspluginwrapper -l /home/sunny/.mozilla/plugins/npwrapper.nppdf.so Original plugin: /usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Browser/intellinux/nppdf.so Wrapper version string: 1.2.2 /home/sunny/.mozilla/plugins/npwrapper.libflashplayer.so Original plugin: /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so Wrapper version string: 1.2.2 sunny:RabbitsDen> Given that wrapped plugins are local to your home directory, maybe you need to re-wrap them? -- Alexandre Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: status of flash9/flash10 support in RELENG_7 ?
On Sun, Jul 26, 2009 at 06:15:22PM +0200, barbara wrote: > > On Sun, 2009-07-26 at 10:32 +0200, Marc Fonvieille wrote: > > > On Sun, Jul 26, 2009 at 08:20:09AM +0200, barbara wrote: > > > > > > > > > > An example of the URLs that is giving me problems is the following > > > > > > > > > > http://tv.repubblica.it/copertina/massa-colpito-da-un-detrito/35446?video > > > > > > > > > > (basically all videos from that site cause the same problem). I would > > > > > be > > > > > grateful if you cold check it. > > > > > > > > > > > > > > > > > The video looks fine here, even if I'm getting a warning about the > > > > flash version. > > > > http://img24.imageshack.us/img24/2741/screenshotmassacolpitod.png > > > > > > > > I've found that on 7, the better combination for me is > > > > linux-flashplugin9, linux_base-fc4 and compat.linux.osrelease=2.4.2. > > > > > > Same here: the video plays fine on 7.2-S with linux_base-fc4 and > > > linux-flashplugin9 > > > > > > > On CURRENT, using linux_base-f10, I get much more stuck process, while > > > > on 7 it barely happens. > > > > > > On 8-BETA2 with linux_base-f10 and linux-f10-flashplugin10 that video > > > makes npviewer "coredumping". > > > > > This video played on my 8-BETA2 (r195818, SMP, i386) with linux_base-f10 > > and linux-f10-flashplugin10 without dumping core. Was your BETA2 before > > or after library version bump and, if latter, did you rebuild all your > > ports? > > > > I've cvsupped and rebuilt my system on Jul. 23 and rebuilt all my ports. > linux-f10-flashplugin10 is dumping core or not working for me too. > BTW, why nspluginwrapper doesn't find the plugin? > I assume it's cause nothing is installed under /usr/local/lib/browser_plugins/ so you need to do a ln -s /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so \ /usr/local/lib/browser_plugins/ just before the nspluginwrapper -v -a -i as I mentioned it in the Handbook. Regarding my BETA2, I mostly use the 'current' packages and some may come from before the bump, but firefox was built on friday. I should try to rebuild everything... however this box is really slow... -- Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-STABLE ZFS: mv: set flags (was: 00000000): Invalid argument - O_EXCL
I believe this issue was supposed to have been resolved with a path a couple weeks ago - (O_EXCL) I had thought it was solved for myself as well (except for my vi on 4.8 oddity), but it is not. :( Quoting "Peter Much" : Hi ZFS gurus! After upgrading my system from 7.2-PRERELEASE to 7.2-STABLE (as of last week), and accordingly upgrading my Pools from Version 6 to Version 13, I get this error when moving arbitrary files between different ZFS filesystems. While this seems not to do much harm (mv returns with 0), it is annoying. Does anybody know an explanation or fix, or is there some work in progress? rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Weird portmaster behaviour -- everything fails to install
Hi all, I've spent the weekend doing a ports catch-up: there seems to have been a lot of activity recently! It's taking a long time at least partly because portmaster doesn't seem to be "doing the right thing" all of a sudden: it will happily trace the dependencies and build the first superceded port, but fails to re-install it. On every occsaion this weekend, it gets to ===> Installing for foo-0.123_2 ===> Generating temporary packing list ===> Checking if graphics/foo already installed ===> foo-0.123_2 is already installed You may wish to "make deinstall" and blah, blah, blah... Of course it's installed, that's why I'm running portmaster! So I go into the directory, run make deinstall reinstall clean, and that goes without a hitch. Restart portmaster -uBd -a and half an hour later it will fail in the same way, and I'll have to do the same dance. It's most likely something dumb that I've got misconfigured: can anyone suggest to me where I should look? (I don't normally run with the -B switch. I put that in recently to stop it from trying to build backup packages, because it had previously been failing dismally at that stage, because most of the installed files didn't match their md5 hashes for some reason. I'm not too concerned with that: packing lists often get mixed up, in my experience.) Cheers, -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
