Re: svn - but smaller?
I think that this keys shouldn't be included into binary.
svnup --ports
svnup --stable
svnup --security (or --release)
I'm proposing create somewhere, like in
/usr/share/svnup/aliases
with
portsTABsvn://svn.freebsd.org/blabla/
stableTABsvn://svn.freebsd.org/blabla/ {uname-arch}/{uname-version}/
etc.
So we will have some freedom to enhance and tweak it's behhavior while at
least in alpha stage.
--
Regards,
Alexander Yerenkow
___
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: svn - but smaller?
On 13 Mar 2013, at 06:29, Ian Smith smi...@nimnet.asn.au wrote:
On Tue, 12 Mar 2013 18:32:28 -0500, John Mehr wrote:
On Tue, 12 Mar 2013 02:20:37 +0100
Michael Ross g...@ross.cx wrote:
On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr j...@visi.com wrote:
[..]
Hello,
I'm currently in the process of adding http/https support to svnup and
once I've got that working, the command line interface will be changing
to be more like the traditional svn client to make it easier for people
to adopt the tool [...]
What'd you think about a syntax extension along the lines of
svnup --bsd-base
svnup --bsd-ports
svnup --bsd-all
with automagic host selection, default to uname's major version stable
branch and default target dirs?
Hello,
This sounds good to me, and as long as there's some sort of a consensus that
we're not breaking the principle of least surprise, I'm all for it. The one
default that may be unexpected is the defaulting to the stable branch --
people who track the security branches will be left out. So maybe something
like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
Hi John,
I have a few ..
Firstly, this is a great advance for I suspect many people who aren't
developers as such, but want to simply update sources for some or all of
the reasons Ike spells out on his wiki page. The sooner this hits the
tree the better in my view, but adding more features won't speed that.
I have a small test system on which I'd installed (two instances of) 9.1
so a couple of days ago I fetched ports with portsnap, installed svnup,
and ran it using the (just what I needed) example command in svnup(1).
I get about 700KB/s here, and svnup took about 15 minutes to update 9.1
sources to 9-stable. This is fine. Last night I ran it again, but it
took 12:42 to make no changes. This seemed puzzling, as you'd said only
a few minutes for subsequent updates, but the reason appears to be that
in both cases, I ran it in script(1), and the default verbosity of 1
includes a listing of every directory and file examined, followed by
CR then erase to eol codes. Even in less -r (raw) mode it still has
to display and skip through all the (now invisible) lines; bit messy.
Even the second do-nothing run made a 2MB script file, the original with
all 9.1 to -stable updates being 3.4MB. So I'd love the option to only
list the changes (- and +) and simply ignore unchanged dirs/files
without any display for use in script(1). Apart from that, I'm happy.
As is, it more or less follows csup(1) type arguments, and I think that
as a c{,v}sup replacement that's appropriate. Making its arguments more
like svn's may actually be confusing, if it leads people to think of it
as svn light when it really isn't, especially with no .svn directory.
As we have portsnap, which updates INDEX-* and checks integrity, I'm not
sure that using svnup for ports is worthwhile considering. It would
save (here) 135MB in var/db/portsnap, but that's pretty light in view of
the 700MB-odd of /usr/ports/.svn in the ports distributed with 9.1-R
I beg to differ, if I can only use the tool to upgrade my base sources but not
the ports, thus still needing vanilla SVN, then I for one won't have any use
for said tool whatsoever.
Just my take on it.
I'm totally not into portsnap.
As for stable, release or security branches (of which major release?) I
think specifying base/stable/9 or whatever is good; it helps people with
10 or more years of 9-STABLE or 9.1-RELEASE etc syntax adapt to the svn
reality but remains explicit enough to put in a script and know just
what's being fetched, without regard to the fetching machine's uname.
Not to go as far as emulating supfiles, but a few things (host, branch
and target dir) would be useful in a small .conf file that could be
specified on command line, as a supfile is to csup, perhaps?
And svnup(1) really should mention that any files in the target tree not
in the repository will be deleted, which was (explicitly) not the case
with c{,v}sup. I only lost a few acpi patches that I think have likely
made it to stable/9 anyway, and it's a test system, but I was surprised.
All the best John; as a first contribution I think this is fabulous!
cheers, Ian
___
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
Re: carp on stable/9: is there a way to keep jumbo?
(moving to more appropriate mailing list) On Mon, 11 Mar 2013, Dmitry Morozovsky wrote: yes, I know glebius@ overhauled carp in -current, but I'm a bit nervous to deploy bleeding edge system on a NAS/SAN ;) So, my question is about current state of carp in stable/9: building HA pair I found that carp interfaces lose jumbo capabilities: I made a patch for 9.1-RELEASE, it is totally based on glebius@ work, or partially :). I'm using it nowadays and it just works pretty fine for me. I didn't test with JUMBO frame, but you can give a try and let us know if it works or not. PATCH: http://people.freebsd.org/~araujo/carpdev/ I'vr managed to apply this finally :) It seems your path is sometimes spammed with $FreeBSD$ changes, which leads to 4 .rej's for me (nothing except ./sys/netinet/ip_carp.c.rej are sighnificany, but they may produce problem in future merging) Only buildworld tests are finished for me yet; more to test later and/or tomorrow. I booted my carp pair and it at least boot properly, ``ifconfig lagg0 vhid 1 state master'' works, and tcpdump to carp address show jumbo frames receiving and sending. Time to set up takeover and test istgt Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
amdtemp does not find my CPU.
Hi! Im running FreeBSD 9.1 on a AMD APU machine: CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU) FreeBSD 9.1-RELEASE-p1 #0 r243379M: Fri Mar 8 23:16:44 CET 2013 r...@pean.org:/usr/obj/usr/src/sys/GENERIC I try to use amdtemp(4) to read the temperature of this CPU but it doesnt seem to detect the CPU. The manual states that it should support K8-class. The amdtemp.c isnt huge so maybe it is very simple to make it work? Best Regards Peter Ankerstål. ___ 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: amdtemp does not find my CPU.
On Wed, 13 Mar 2013 10:17:51 +0100 Peter Ankerstål pe...@pean.org wrote: Hi! Im running FreeBSD 9.1 on a AMD APU machine: CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU) FreeBSD 9.1-RELEASE-p1 #0 r243379M: Fri Mar 8 23:16:44 CET 2013 r...@pean.org:/usr/obj/usr/src/sys/GENERIC I try to use amdtemp(4) to read the temperature of this CPU but it doesnt seem to detect the CPU. The manual states that it should support K8-class. The amdtemp.c isnt huge so maybe it is very simple to make it work? Best Regards Peter Ankerstål. Hi, you need to try amdtemp.c from CURRENT aka HEAD. I did it for both E-350 and C-60 CPU and it works for me. If you need something more to test it, I can help, but it is really easy. Regards, Milan ___ 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: amdtemp does not find my CPU.
On Wed, Mar 13, 2013 at 10:17:51AM +0100, Peter Ankerst?l wrote: Hi! Im running FreeBSD 9.1 on a AMD APU machine: CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU) FreeBSD 9.1-RELEASE-p1 #0 r243379M: Fri Mar 8 23:16:44 CET 2013 r...@pean.org:/usr/obj/usr/src/sys/GENERIC I try to use amdtemp(4) to read the temperature of this CPU but it doesnt seem to detect the CPU. The manual states that it should support K8-class. The amdtemp.c isnt huge so maybe it is very simple to make it work? A similar discussion happened last month about FreeBSD 8.x and the amdtemp(4) driver and what models it supports. See thread and my comments: Thread: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/thread.html#72340 First post: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072340.html Points I'm trying to get across, as someone who has no familiarity with the amdtemp(4) driver/code, but does have quite a lot of familiarity with H/W monitoring chipsets: 1. Do not assume it will be simple to make it work simply because the driver you see is ~13KBytes -- the size has no bearing on technical complexities. 2. Support for different CPUs have to be added gradually and carefully, as hardware vendors change methods/models behaviour of the DTSes and surrounding bits more often than you might think. Consider what would happen if support was added which in turn broke/caused issues for other CPU models (either newer or older); the end result consists of end-users screaming about the breakage, and people having to rush to provide a fix. You might want to look at the Core Temp utility for Windows, for example, where it has to be updated periodically to add support for some models of CPUs; be sure to note all the Fix: items too. http://www.alcpu.com/CoreTemp/history.html 3. Low-level technical documentation of behaviour per CPU model is sometimes not made available publicly by the vendor until after N number of years. This requires the person adding support to reverse-engineer existing programs out there (ex. Linux, etc.) that provide such. This takes time, and can often be more error-prone than real documentation. And don't forget about CPU bugs/errata too. 4. Do not forget amdtemp(4) is kernel-land: the last thing you want to do is screw it up (think panic). Userland is often more forgiving, depending what all you're interfacing with on the kernel side (ex. a badly-formed ioctl from userland could cause a panic too). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: amdtemp does not find my CPU.
On 03/13/2013 11:16 AM, Milan Obuch wrote: you need to try amdtemp.c from CURRENT aka HEAD. I did it for both E-350 and C-60 CPU and it works for me. If you need something more to test it, I can help, but it is really easy. Regards, Milan Thanks! That worked nicely! Regards, Peter ___ 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: amdtemp does not find my CPU.
On Wed, 13 Mar 2013 11:45:15 +0100 Peter Ankerstål pe...@pean.org wrote: On 03/13/2013 11:16 AM, Milan Obuch wrote: you need to try amdtemp.c from CURRENT aka HEAD. I did it for both E-350 and C-60 CPU and it works for me. If you need something more to test it, I can help, but it is really easy. Regards, Milan Thanks! That worked nicely! Regards, Peter Glad it helps :) Just one small thing I encountered - temperature read via sysctl from amdtemp module was ~ 7 degrees higher than those reported via BIOS setup screen. As it was some months already, maybe these vaules are now in line, but it would be good to test it for yourself. Regards, Milan ___ 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: amdtemp does not find my CPU.
On 03/13/2013 12:00 PM, Milan Obuch wrote: Glad it helps :) Just one small thing I encountered - temperature read via sysctl from amdtemp module was ~ 7 degrees higher than those reported via BIOS setup screen. As it was some months already, maybe these vaules are now in line, but it would be good to test it for yourself. Regards, Milan Ah, good to know, I will check it out. /Peter. ___ 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: svn - but smaller?
On Wed, 13 Mar 2013 09:08:21 +0100, Damien Fleuriot wrote: On 13 Mar 2013, at 06:29, Ian Smith smi...@nimnet.asn.au wrote: Damien, please permit me to trim to the point you responded to: As we have portsnap, which updates INDEX-* and checks integrity, I'm not sure that using svnup for ports is worthwhile considering. It would save (here) 135MB in var/db/portsnap, but that's pretty light in view of the 700MB-odd of /usr/ports/.svn in the ports distributed with 9.1-R I beg to differ, if I can only use the tool to upgrade my base sources but not the ports, thus still needing vanilla SVN, then I for one won't have any use for said tool whatsoever. Just my take on it. I'm totally not into portsnap. Allow me to rephrase that: I'm not sure that using svnup for ports is worthwhile considering as an option for me, here :) I'm happy using portsnap, not having had any problem with it .. but to each their own! For one thing, I'm still getting ~13 minute svnup runs, even using -v0 (silent), to update once 5 and later 1 file in stable/9, whereas running portsnap fetch portsnap update totalled ~50 seconds for 5 new ports and 82 patches. Has anyone tried svnup with -b ports/base yet? It seems that you could use svnup to download any part of the repository that the server will let you have. I used '-b base/stable/9' but could apparently? get base/head or base/releng/4.11 - or ports/head, doc/head or perhaps even csrg for a 4.4BSD snapshot! - any corrections welcome. cheers, Ian ___ 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: problem compiling openjdk6
You can ask this on freebsd-j...@freebsd.org also. Ronald. On Sat, 09 Mar 2013 15:59:22 +0100, Filippo Moretti filippom...@yahoo.com wrote: I get the following compile error when attempting to build openjdk6 on FreeBSD STING.teletu.it 9.1-STABLE FreeBSD 9.1-STABLE #0: Sun Mar 3 00:09:06 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 va/openjdk6/work/hotspot/src/share/vm/adlc/adlparse.cpp /usr/ports/java/openjdk6/work/hotspot/src/share/vm/adlc/adlparse.cpp:1: sorry, unimplemented: 64-bit mode not compiled in gmake[6]: *** [../generated/adfiles/adlparse.o] Error 1 gmake[6]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir/bsd_amd64_compiler2/product' gmake[5]: *** [ad_stuff] Error 2 gmake[5]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir/bsd_amd64_compiler2/product' gmake[4]: *** [product] Error 2 gmake[4]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir' gmake[3]: *** [generic_build2] Error 2 gmake[3]: Leaving directory `/usr/ports/java/openjdk6/work/hotspot/make' gmake[2]: *** [product] Error 2 gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/hotspot/make' gmake[1]: *** [hotspot-build] Error 2 gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work' gmake: *** [build_product_image] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/java/openjdk6. *** [install] Error code 1 Stop in /usr/ports/java/openjdk6. *** [build-depends] Error code 1 Stop in /usr/ports/java/icedtea-web. *** [install] Error code 1 Stop in /usr/ports/java/icedtea-web. sincerely Filippo ___ 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
Re: svn - but smaller?
On Tue, March 12, 2013 19:32, John Mehr wrote:
This sounds good to me, and as long as there's some sort
of a consensus that we're not breaking the principle of
least surprise, I'm all for it. The one default that may
be unexpected is the defaulting to the stable branch --
people who track the security branches will be left out.
So maybe something like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
If svnup will eventually going to be used to update a variety of
repositories, on a plethora of operating systems, then hard coding the
above may not be appropriate. Something akin to svnup --repo={ports,
stable, security, release} may be better, and then have a configuration
file with the settings.
___
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: amdtemp does not find my CPU.
On 13 March 2013 05:17, Peter Ankerstål pe...@pean.org wrote: Hi! Im running FreeBSD 9.1 on a AMD APU machine: CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU) FreeBSD 9.1-RELEASE-p1 #0 r243379M: Fri Mar 8 23:16:44 CET 2013 r...@pean.org:/usr/obj/usr/src/sys/GENERIC I try to use amdtemp(4) to read the temperature of this CPU but it doesnt seem to detect the CPU. The manual states that it should support K8-class. Just an aside (as I note you've got it nailed down), but AFIK the E-450 is a K-10 core not a K-8. It'd be nice if K-10 was a perfect superset of K-8, but I have my doubts. -- -- ___ 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: carp on stable/9: is there a way to keep jumbo?
2013/3/13 Dmitry Morozovsky ma...@rinet.ru (moving to more appropriate mailing list) On Mon, 11 Mar 2013, Dmitry Morozovsky wrote: yes, I know glebius@ overhauled carp in -current, but I'm a bit nervous to deploy bleeding edge system on a NAS/SAN ;) So, my question is about current state of carp in stable/9: building HA pair I found that carp interfaces lose jumbo capabilities: I made a patch for 9.1-RELEASE, it is totally based on glebius@ work, or partially :). I'm using it nowadays and it just works pretty fine for me. I didn't test with JUMBO frame, but you can give a try and let us know if it works or not. PATCH: http://people.freebsd.org/~araujo/carpdev/ I'vr managed to apply this finally :) It seems your path is sometimes spammed with $FreeBSD$ changes, which leads to 4 .rej's for me (nothing except ./sys/netinet/ip_carp.c.rej are sighnificany, but they may produce problem in future merging) Only buildworld tests are finished for me yet; more to test later and/or tomorrow. I booted my carp pair and it at least boot properly, ``ifconfig lagg0 vhid 1 state master'' works, and tcpdump to carp address show jumbo frames receiving and sending. Time to set up takeover and test istgt Thank you! Hello Dmitry, Nice know that it works well... let me know more info about the takeover and test istgt. Best Regards, -- Marcelo Araujo ara...@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
Re: svn - but smaller?
On Wed, 13 Mar 2013 16:29:45 +1100 (EST)
Ian Smith smi...@nimnet.asn.au wrote:
On Tue, 12 Mar 2013 18:32:28 -0500, John Mehr wrote:
On Tue, 12 Mar 2013 02:20:37 +0100
Michael Ross g...@ross.cx wrote:
On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr
j...@visi.com wrote:
[..]
Hello,
I'm currently in the process of adding http/https
support to svnup and
once I've got that working, the command line
interface will be changing
to be more like the traditional svn client to make
it easier for people
to adopt the tool [...]
What'd you think about a syntax extension along the
lines of
svnup --bsd-base
svnup --bsd-ports
svnup --bsd-all
with automagic host selection, default to uname's
major version stable
branch and default target dirs?
Hello,
This sounds good to me, and as long as there's some
sort of a consensus that
we're not breaking the principle of least surprise,
I'm all for it. The one
default that may be unexpected is the defaulting to
the stable branch --
people who track the security branches will be left
out. So maybe something
like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
Hi John,
I have a few ..
Firstly, this is a great advance for I suspect many
people who aren't
developers as such, but want to simply update sources
for some or all of
the reasons Ike spells out on his wiki page. The sooner
this hits the
tree the better in my view, but adding more features
won't speed that.
I have a small test system on which I'd installed (two
instances of) 9.1
so a couple of days ago I fetched ports with portsnap,
installed svnup,
and ran it using the (just what I needed) example
command in svnup(1).
I get about 700KB/s here, and svnup took about 15
minutes to update 9.1
sources to 9-stable. This is fine. Last night I ran it
again, but it
took 12:42 to make no changes. This seemed puzzling, as
you'd said only
a few minutes for subsequent updates, but the reason
appears to be that
in both cases, I ran it in script(1), and the default
verbosity of 1
includes a listing of every directory and file examined,
followed by
CR then erase to eol codes. Even in less -r (raw)
mode it still has
to display and skip through all the (now invisible)
lines; bit messy.
Even the second do-nothing run made a 2MB script file,
the original with
all 9.1 to -stable updates being 3.4MB. So I'd love the
option to only
list the changes (- and +) and simply ignore unchanged
dirs/files
without any display for use in script(1). Apart from
that, I'm happy.
Which mirror are you using? I ran several tests tonight
repeatedly fetching 9/stable from svn0.us-west (so they
would all be do-nothing runs) both inside and outside of a
script(1) capture and on both an old SSD and on a ZFS
mirrored array (to see if the target media made any
difference) and they all completed in 2 minutes, 43
seconds +/- 2 seconds on my 350 KB/s connection.
I'll definitely put in a verbosity level that does exactly
what you suggest. Sorry about that.
As is, it more or less follows csup(1) type arguments,
and I think that
as a c{,v}sup replacement that's appropriate. Making
its arguments more
like svn's may actually be confusing, if it leads people
to think of it
as svn light when it really isn't, especially with no
.svn directory.
This is an excellent point, and I agree 100%.
As we have portsnap, which updates INDEX-* and checks
integrity, I'm not
sure that using svnup for ports is worthwhile
considering. It would
save (here) 135MB in var/db/portsnap, but that's pretty
light in view of
the 700MB-odd of /usr/ports/.svn in the ports
distributed with 9.1-R
As for stable, release or security branches (of which
major release?) I
think specifying base/stable/9 or whatever is good; it
helps people with
10 or more years of 9-STABLE or 9.1-RELEASE etc syntax
adapt to the svn
reality but remains explicit enough to put in a script
and know just
what's being fetched, without regard to the fetching
machine's uname.
Not to go as far as emulating supfiles, but a few things
(host, branch
and target dir) would be useful in a small .conf file
that could be
specified on command line, as a supfile is to csup,
perhaps?
Actually, after reading both this message and Alexander
Yerenkow's excellent suggestion, I think implementing some
sort of supfile/.conf/aliases file (with command line
parameters overriding the settings in the
supfile/.conf/aliases) is the way to go.
And svnup(1) really should mention that any files in the
target tree not
in the repository will be deleted, which was
(explicitly) not the case
with c{,v}sup. I only lost a few acpi patches that I
think have likely
made it to stable/9 anyway, and it's a test system, but
I was surprised.
I always thought csup did delete files. I was looking at
csup's man page for things to put on the to-do
Re: svn - but smaller?
On Tue, 12 Mar 2013 19:57:13 -0600 (MDT) Warren Block wbl...@wonkity.com wrote: On Tue, 12 Mar 2013, John Mehr wrote: On Tue, 12 Mar 2013 02:20:37 +0100 Michael Ross g...@ross.cx wrote: What'd you think about a syntax extension along the lines of svnup --bsd-base svnup --bsd-ports svnup --bsd-all with automagic host selection, default to uname's major version stable branch and default target dirs? Hello, This sounds good to me, and as long as there's some sort of a consensus that we're not breaking the principle of least surprise, I'm all for it. The one default that may be unexpected is the defaulting to the stable branch -- people who track the security branches will be left out. So maybe something like: svnup --ports svnup --stable svnup --security (or --release) How would you select the mirror? There are two now, and likely more later. This is a good question. I was thinking it could be done the same way that freebsd-update selects its mirror via an SRV query but it looks like that's currently not an option. ___ 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: svn - but smaller?
On Wed, 13 Mar 2013 14:50:43 -0400
David Magda dma...@ee.ryerson.ca wrote:
On Tue, March 12, 2013 19:32, John Mehr wrote:
This sounds good to me, and as long as there's some sort
of a consensus that we're not breaking the principle of
least surprise, I'm all for it. The one default that
may
be unexpected is the defaulting to the stable branch --
people who track the security branches will be left
out.
So maybe something like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
If svnup will eventually going to be used to update a
variety of
repositories, on a plethora of operating systems, then
hard coding the
above may not be appropriate. Something akin to svnup
--repo={ports,
stable, security, release} may be better, and then have
a configuration
file with the settings.
Hello,
You're absolutely correct. It looks like someone has
already forked the code on github which seems like pretty
solid evidence for taking as flexible an approach as
possible and minimizing the amount of hard coded data.
___
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: amdtemp does not find my CPU.
On Wed, Mar 13, 2013 at 08:04:04PM -0400 I heard the voice of ill...@gmail.com, and lo! it spake thus: Just an aside (as I note you've got it nailed down), but AFIK the E-450 is a K-10 core not a K-8. None of the above. E-450 is a Bobcat. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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
