HomeSort by: relevance | last modified time | path
    Searched hist:1.969 (Results 1 - 18 of 18) sorted by relevancy

  /src/distrib/sets/lists/xdebug/
shl.mi 1.68.2.1 Tue Sep 05 17:26:24 UTC 2023 martin Pull up following revision(s) (requested by riastradh in ticket #348):

distrib/sets/lists/xbase/shl.mi: revision 1.103 (patch)
distrib/sets/lists/debug/shl.mi: revision 1.329 (patch)
distrib/sets/lists/xdebug/shl.mi: revision 1.69 (patch)
distrib/sets/lists/base/shl.mi: revision 1.969 (patch)

lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.

These must stay around so applications linked against them will still
work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
or libfoo.so.N.(M+1).

Exceptions:
- I'm willing to believe the rump modules have a different story so I
left those obsolete entries alone.
- libuv.so was never supposed to be exposed publicly anyway and never
went out in a release. (Maybe this information should be recorded
somewhere?)
- Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
history. Maybe libg2c.so too, no idea what that is.
- libisns.so was moved from /usr/lib to /lib, so it's legitimate for
the debug data to live there too now. (XXX Maybe we should have a
separate marker for this.)
- Libraries under /usr/tests are not used by normal applications, so
they can safely be deleted when obsoleted.

Note: The libfoo.so symlink for a library that has been deleted
altogether, not just upgraded, can be obsoleted. Loadable modules
that applications aren't linked against can be obsoleted, even if
some of them like npf ext_*.so or pam_*.so are formally versioned
(for reasons unclear to me).

Note: This means that incremental builds may complain about these
.so.N and .so.N.M files in destdir (PR misc/57581), but it's much
worse for an upgrade to break working applications.

  /src/distrib/sets/lists/xbase/
shl.mi 1.102.2.1 Tue Sep 05 17:26:24 UTC 2023 martin Pull up following revision(s) (requested by riastradh in ticket #348):

distrib/sets/lists/xbase/shl.mi: revision 1.103 (patch)
distrib/sets/lists/debug/shl.mi: revision 1.329 (patch)
distrib/sets/lists/xdebug/shl.mi: revision 1.69 (patch)
distrib/sets/lists/base/shl.mi: revision 1.969 (patch)

lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.

These must stay around so applications linked against them will still
work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
or libfoo.so.N.(M+1).

Exceptions:
- I'm willing to believe the rump modules have a different story so I
left those obsolete entries alone.
- libuv.so was never supposed to be exposed publicly anyway and never
went out in a release. (Maybe this information should be recorded
somewhere?)
- Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
history. Maybe libg2c.so too, no idea what that is.
- libisns.so was moved from /usr/lib to /lib, so it's legitimate for
the debug data to live there too now. (XXX Maybe we should have a
separate marker for this.)
- Libraries under /usr/tests are not used by normal applications, so
they can safely be deleted when obsoleted.

Note: The libfoo.so symlink for a library that has been deleted
altogether, not just upgraded, can be obsoleted. Loadable modules
that applications aren't linked against can be obsoleted, even if
some of them like npf ext_*.so or pam_*.so are formally versioned
(for reasons unclear to me).

Note: This means that incremental builds may complain about these
.so.N and .so.N.M files in destdir (PR misc/57581), but it's much
worse for an upgrade to break working applications.
  /src/sys/dev/pci/
viaide.c 1.57.4.4 Sun Jan 20 00:19:07 UTC 2013 bouyer Apply patch, requested by msaitoh in ticket #1842:
sys/dev/pci/pcidevs 1.969 via patch
sys/dev/pci/viaide.c 1.58

Add VT8237S Integrated SATA Controller support.
PR#47452.
pcidevs 1.969 Sun Dec 21 16:23:53 UTC 2008 nonaka Add VIA VT8237S Integrated SATA Controller ID.
1.962.4.17 Sun Jan 20 00:19:06 UTC 2013 bouyer Apply patch, requested by msaitoh in ticket #1842:
sys/dev/pci/pcidevs 1.969 via patch
sys/dev/pci/viaide.c 1.58

Add VT8237S Integrated SATA Controller support.
PR#47452.
pcidevs.h 1.969 Sat Nov 29 23:48:58 UTC 2008 christos regen
pcidevs_data.h 1.969 Tue Dec 16 19:55:22 UTC 2008 christos regen
  /src/usr.bin/make/
var.c 1.969 Thu Dec 09 20:13:10 UTC 2021 rillig make: remove period from end of error messages and warnings

The majority of the existing error messages and warnings does not
include a period at the end. Follow this style consistently.
  /src/distrib/sets/lists/base/
mi 1.969 Sat Oct 15 13:00:59 UTC 2011 mbalmer branches: 1.969.2;
Install, and add to the set lists, example code to illustrate Lua module use.
Sat Oct 15 13:00:59 UTC 2011 mbalmer branches: 1.969.2;
Install, and add to the set lists, example code to illustrate Lua module use.
1.969.2.7 Thu May 22 00:01:32 UTC 2014 yamt sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
1.969.2.6 Wed Jan 23 00:04:10 UTC 2013 yamt sync with head
1.969.2.5 Wed Jan 16 05:26:03 UTC 2013 yamt sync with (a bit old) head
1.969.2.4 Tue Oct 30 18:48:38 UTC 2012 yamt sync with head
1.969.2.3 Wed May 23 10:07:10 UTC 2012 yamt sync with head.
1.969.2.2 Tue Apr 17 00:02:38 UTC 2012 yamt sync with head
1.969.2.1 Thu Nov 10 14:31:11 UTC 2011 yamt sync with head
shl.mi 1.969 Mon Sep 04 19:07:58 UTC 2023 riastradh lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.

These must stay around so applications linked against them will still
work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
or libfoo.so.N.(M+1).

Exceptions:

- I'm willing to believe the rump modules have a different story so I
left those obsolete entries alone.

- libuv.so was never supposed to be exposed publicly anyway and never
went out in a release. (Maybe this information should be recorded
somewhere?)

- Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
history. Maybe libg2c.so too, no idea what that is.

- libisns.so was moved from /usr/lib to /lib, so it's legitimate for
the debug data to live there too now. (XXX Maybe we should have a
separate marker for this.)

- Libraries under /usr/tests are not used by normal applications, so
they can safely be deleted when obsoleted.

Note: The libfoo.so symlink for a library that has been deleted
altogether, not just upgraded, can be obsoleted. Loadable modules
that applications aren't linked against can be obsoleted, even if
some of them like npf ext_*.so or pam_*.so are formally versioned
(for reasons unclear to me).

Note: This means that incremental builds may complain about these
.so.N and .so.N.M files in destdir (PR misc/57581), but it's much
worse for an upgrade to break working applications.
1.942.2.9 Tue Sep 05 17:26:24 UTC 2023 martin Pull up following revision(s) (requested by riastradh in ticket #348):

distrib/sets/lists/xbase/shl.mi: revision 1.103 (patch)
distrib/sets/lists/debug/shl.mi: revision 1.329 (patch)
distrib/sets/lists/xdebug/shl.mi: revision 1.69 (patch)
distrib/sets/lists/base/shl.mi: revision 1.969 (patch)

lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.

These must stay around so applications linked against them will still
work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
or libfoo.so.N.(M+1).

Exceptions:
- I'm willing to believe the rump modules have a different story so I
left those obsolete entries alone.
- libuv.so was never supposed to be exposed publicly anyway and never
went out in a release. (Maybe this information should be recorded
somewhere?)
- Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
history. Maybe libg2c.so too, no idea what that is.
- libisns.so was moved from /usr/lib to /lib, so it's legitimate for
the debug data to live there too now. (XXX Maybe we should have a
separate marker for this.)
- Libraries under /usr/tests are not used by normal applications, so
they can safely be deleted when obsoleted.

Note: The libfoo.so symlink for a library that has been deleted
altogether, not just upgraded, can be obsoleted. Loadable modules
that applications aren't linked against can be obsoleted, even if
some of them like npf ext_*.so or pam_*.so are formally versioned
(for reasons unclear to me).

Note: This means that incremental builds may complain about these
.so.N and .so.N.M files in destdir (PR misc/57581), but it's much
worse for an upgrade to break working applications.
  /src/sys/arch/i386/conf/
GENERIC 1.969 Sun Feb 21 05:16:29 UTC 2010 cnst New wbsio(4) driver for Winbond Super I/O attachment of lm(4) on any port.

http://mail-index.netbsd.org/tech-kern/2010/02/17/msg007338.html

Reviewed by <pgoyette>, <tech-kern>.
  /src/sys/conf/
files 1.969 Tue Jan 19 16:24:44 UTC 2010 pooka Specify bpf_filter attribute only when the device uses the filter engine.
  /src/doc/
CHANGES 1.969 Thu Dec 27 15:19:05 UTC 2007 elad Mention security(8) for ASLR, requested by hubertf@.
3RDPARTY 1.969 Fri Sep 21 08:15:08 UTC 2012 wiz Mention that gcc-4.5.4 was imported and that 4.7.2 is out.

  /src/distrib/sets/lists/tests/
mi 1.969 Sat Nov 14 15:35:20 UTC 2020 rillig make(1): add test for the -t option in jobs mode
  /src/share/mk/
bsd.own.mk 1.969 Wed Oct 12 16:44:31 UTC 2016 christos switch to gdb.old
  /src/distrib/sets/lists/man/
mi 1.969 Sat Jan 20 18:44:26 UTC 2007 xtraeme Updated viaenv(4) driver:

* Support for the VIA VT8231 Hardware monitor.
* Power Management Timer available for timecounters in both
VT86C686A and VT8231 (code simplified thanks to dev/ic/acpipmtimer).
* Remove viapm(4) code and manpage (which was a link to viaenv.4 anyway).

From OpenBSD, tested by some users.
  /src/distrib/sets/lists/debug/
shl.mi 1.298.2.10 Tue Sep 05 17:26:24 UTC 2023 martin Pull up following revision(s) (requested by riastradh in ticket #348):

distrib/sets/lists/xbase/shl.mi: revision 1.103 (patch)
distrib/sets/lists/debug/shl.mi: revision 1.329 (patch)
distrib/sets/lists/xdebug/shl.mi: revision 1.69 (patch)
distrib/sets/lists/base/shl.mi: revision 1.969 (patch)

lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.

These must stay around so applications linked against them will still
work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
or libfoo.so.N.(M+1).

Exceptions:
- I'm willing to believe the rump modules have a different story so I
left those obsolete entries alone.
- libuv.so was never supposed to be exposed publicly anyway and never
went out in a release. (Maybe this information should be recorded
somewhere?)
- Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
history. Maybe libg2c.so too, no idea what that is.
- libisns.so was moved from /usr/lib to /lib, so it's legitimate for
the debug data to live there too now. (XXX Maybe we should have a
separate marker for this.)
- Libraries under /usr/tests are not used by normal applications, so
they can safely be deleted when obsoleted.

Note: The libfoo.so symlink for a library that has been deleted
altogether, not just upgraded, can be obsoleted. Loadable modules
that applications aren't linked against can be obsoleted, even if
some of them like npf ext_*.so or pam_*.so are formally versioned
(for reasons unclear to me).

Note: This means that incremental builds may complain about these
.so.N and .so.N.M files in destdir (PR misc/57581), but it's much
worse for an upgrade to break working applications.
  /src/distrib/sets/lists/comp/
mi 1.969 Fri Nov 10 19:43:02 UTC 2006 christos add more ssp library files.

Completed in 2759 milliseconds