Re: Re : Equivalent of /etc/libmap.conf on OpenBSD
On Thu, Feb 09, 2012 at 07:17:10AM +, Mik J wrote: Thank you Theo, But what would be the workaround to get a similar result ? - Mail original - @ : Mik J mikyde...@yahoo.fr I have not found how to get an equivalent of /etc/libmap.conf on OpenBSD I'm following a documentation written for FreeBSD and they say echo libpthread.so libthr.so /etc/libmap.conf Do you know how can I get this done on OpenBSD ? What's 'this'? I don't know what libmap.conf is. If you do not explain what problem you are trying to solve, we cannot help you. -Otto De : Theo de Raadt dera...@cvs.openbsd.org We don't have that, and we won't ever.
Re: Re : Equivalent of /etc/libmap.conf on OpenBSD
On Wed, Feb 8, 2012 at 11:17 PM, Mik J mikyde...@yahoo.fr wrote: But what would be the workaround to get a similar result ? You don't actually state what your *real* problem is, so I'll go with rebuild the involved software against the correct library. Philip Guenther
AD有票开要的电⒔⒌⒍04⒊2⒐0⒊王
hg3;QQo714524894,ADf g%(ehgg5f f :bb b 04b 2b0b
Thinkpad X220 4286-CTO display does not wake up after suspend
Hi all, Display does not wake up after suspend on Thinkpad X220. Other equipment works ok - I can log in using SSH and continue my work. I am trying to fix this issue, but with no result yet. Any feedback is welcome. (Especially on how to log what happens there and how to reinitialize display.) Full bug report is here: http://marc.info/?l=openbsd-bugsm=132878348108463w=2 Thanks, Alex dmesg: OpenBSD 5.1 (GENERIC) #2: Thu Feb 9 21:03:21 NZDT 2012 r...@p2.extensibl.com:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz (GenuineIntel 686-class) 2.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,D \ S,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,T \ M2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,LAHF real mem = \ 3667050496 (3497MB) avail mem = 3596984320 (3430MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 07/07/11, BIOS32 rev. 0 @ 0xfc200, SMBIOS rev. \ 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version 8DET50WW (1.20 ) date 07/07/2011 bios0: LENOVO 4286CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT \ SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) \ HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4940 serial 13527 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0x1! cpu0: Enhanced SpeedStep 2592 MHz: speeds: 2601, 2600, 2400, 2200, 2000, 1800, 1600, \ 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel GT2+ Video rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 drm0 at inteldrm0 Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured Intel 6 Series KT rev 0x04 at pci0 dev 22 function 3 not configured em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address \ f0:de:f1:80:a7:a5 ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x04: apic \ 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x04: msi azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb4: apic 2 int 16 pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 6 Series PCIE rev 0xb4: apic 2 int 17 pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO \ 2T2R, MoW, address a0:88:b4:db:8f:44 ppb2 at pci0 dev 28 function 3 Intel 6 Series \ PCIE rev 0xb4: apic 2 int 19 pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 function 4 Intel 6 Series PCIE rev 0xb4: apic 2 int 16 pci4 at ppb3 bus 13 sdhc0 at pci4 dev 0 function 0 Ricoh 5U823 SD/MMC rev 0x04: apic 2 int 16 sdmmc0 at sdhc0 ehci1 at pci0 dev 29 function 0 Intel 6 Series USB rev 0x04: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 Intel QM67 LPC rev 0x04 pciide0 at pci0 dev 31 function 2 Intel 6 Series SATA rev 0x04: DMA, channel 0 \ configured to native-PCI, channel 1 configured to native-PCI pciide0: using apic 2 int 19 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: Hitachi HTS545050A7E380 wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 ichiic0 at pci0 dev 31 function 3 Intel 6 Series SMBus rev 0x04: apic 2 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600 SO-DIMM pciide1 at pci0 dev 31 function 5 Intel 6
Re: Long delay updating xenocara source tree?
Otto Moerbeek wrote [2012-02-03 12:47+0100]: I like to say that long delays I have seen when using cvs had to do with multiple different values of CVS/Root files in my local tree. Otto, could you please elaborate? How does this slow down a cvs update? Is it really due to the fact that there are multiple different *values* stored in the CVS/Root files? So that cvs needs to consult multiple cvs servers, and *that* is what gets slow? I just checked, and I have three different servers mentioned in my CVS/Root files; a cvs update is slow, but when I have just one server mentioned in the CVS/Root files, it is not faster. Also, specifying 'cvs -d mirror' explicitly should get rid of this problem then (right?), and speed things up, which it doesn't. Or is the slowdown possibly due to the sheer *number* of CVS/Root files that are consulted? Would that be remedied by cvs -d too? Actually, cvs(1) says: -d CVS_root_directory Use CVS_root_directory as the root directory pathname of the master source repository. Overrides the setting of the CVSROOT environment variable. This value should be specified as an absolute pathname. CVS/Root Pathname to the repository ( CVSROOT ) location at the time of checkout. This file is used instead of the CVSROOT environment variable if the environment variable is not set. A warning message will be issued when the contents of this file and the CVSROOT environment variable differ. The file may be over- ridden by the presence of the CVS_IGNORE_REMOTE_ROOT environment variable. It doesn't state explicitly whether 'cvs -d' makes the CVS/Root files ignored. Does it? Also, the wording for 'CVS/Root' doesn't seem to be entirely correct: If I untar, say, sys.tar.gz, then my local tree contains no CVS/Root files, and if I later do a 'cvs -d mirror up -Pd', the tree gets populated with CVS/Root files (mentioning mirror) -- that's not a time of checkout, that's an update. Also, having CVS_IGNORE_REMOTE_ROOT doesn't override CVS/Root, it just makes it ignored, right? Those different entries can be created when doing a cvs up -d that creates a new dir. Not only. A 'cvs -d mirror up -d' of a freshly untared sys.tar.gz creates CVS/Root files all over the place, *not* just in the new directories (that got created due to the 'up -d'). For example it creates ./sys/arch/i386/CVS/Root, while the directory /sys/arch/i386/ definitely was there before (so it didn't get created with 'up -d'). If a cvs -d option is used at the same time, the CVS/Root entry for tht dir wil be different than the other's. Yes, but it will also change the content of CVS/Root in directories that existed before. The exact cause of the slowdown is not known to me. But when you are switch repositories once in a while it's easy to get this case. I repair this by find . -name Root | xargs rm and using a explicit cvs root. So, using an explicit cvs root does not ignore the CVS/Root files? Because if it does, then the 'find | xargs rm' should make no difference, right? Now this is really another important issue of scattered information, is it, and it's not noted in anoncvs.html! I've slightly modified your command, i think my version is more secure for use on a webpage. -Otto --steffen Index: anoncvs.html === RCS file: /cvs/www/anoncvs.html,v retrieving revision 1.363 diff -a -p -u -r1.363 anoncvs.html --- anoncvs.html 24 Jan 2012 09:57:35 - 1.363 +++ anoncvs.html 3 Feb 2012 13:33:28 - @@ -542,6 +542,15 @@ add the em-d anon...@anoncvs.ca.openbs # strongcd /usr/src/strong # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong /pre + +p And because cvs(1) stores the name of the server which is in use once +a directory gets created in the file CVS/Root inside this new directory, ^^^ (not only) +it maybe wise to issue a command sequence like the following: +pre + # strongcd /usr/src/strong + # strongfind . -path '*CVS/Root' | xargs rm/strong + # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong +/pre /ul I think this is blind typing without understanding what is going on (not that I know), contrary to the ways of our brilliant FAQ. Let's understand it first. Can someone with internal knowledge of cvs shed some light on this please? Thank you for your time Jan
Re: Long delay updating xenocara source tree?
On Thu, Feb 09, 2012 at 01:16:10PM +0100, Jan Stary wrote: +it maybe wise to issue a command sequence like the following: +pre + # strongcd /usr/src/strong + # strongfind . -path '*CVS/Root' | xargs rm/strong + # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong +/pre /ul Never ever! For example if we would talk about ports tree, 'mystuff' could get taken from different cvs repo. CVS works like this, you can have multiple cvs repos inside the tree, it is by design. Instead of this silly command above, better to tell people to start learning cvs :) jirib
Re: NDOutils 1.5 on OpenBSD 5.0
On 2012-02-09, Alvaro Mantilla Gimenez alv...@alvaromantilla.com wrote: Hi Stuart, El 08/02/12 20:09, Stuart Henderson escribis: On 2012-02-08, Alvaro Mantilla Gimenez alv...@alvaromantilla.com wrote: Hi, I am trying to install NDOutils 1.5 on OpenBSD 5.0 amd64. I am having a weird error during compilation. Not really weird, your include search path is wrong. Look at where gcc is searching and compare to where the files are. Are we talking about this error? /usr/bin/ld: /tmp//ccdrJBOI.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /tmp//ccdrJBOI.o: could not read symbols: Bad value collect2: ld returned 1 exit status Oh I didn't get that far down; that error message from the linker is pretty clear though.. I am not sure if this is something autogenerated by configure command or it is something I should change...somewhere...or just a GCC issue related with the platform (amd64). Yes you'll need to change the compiler flags to use -fPIC Also, I research about this and it seems it is related with amd64 only...other 64 bits platforms seems not have any issues like this. I would like to know if somebody on this list has NDOutils 1.5 running with Nagios (from ports). No but icinga + idoutils is in ports/packages and should work ok. (the core program and classic aka nagios-style-but-nicer cgi web interface work well; idoutils has seen a bit less testing but should also work, the icinga-web port isn't quite finished yet but my uncommitted diffs are not far off). Thanks for the tip about icinga + idoutils. I will test those too. Personally I'm not going to spend much time on nagios problems but am a bit more interested in any problems with running icinga on OpenBSD. btw, I find that upstream icinga developers are usually quite responsive too.
Rescan SCSI bus
Hi anyone knows how to get a scsi bus rescan after adding a disk, without rebooting? Right now I have plugged a new disk, but it appears not configured: # disklabel sd1 disklabel: /dev/rsd1c: Device not configured Thanks Pierre
Re: Long delay updating xenocara source tree?
On Thu, Feb 09, 2012 at 01:16:10PM +0100, Jan Stary wrote: Otto Moerbeek wrote [2012-02-03 12:47+0100]: I like to say that long delays I have seen when using cvs had to do with multiple different values of CVS/Root files in my local tree. Otto, could you please elaborate? How does this slow down a cvs update? Is it really due to the fact that there are multiple different *values* stored in the CVS/Root files? So that cvs needs to consult multiple cvs servers, and *that* is what gets slow? I just checked, and I have three different servers mentioned in my CVS/Root files; a cvs update is slow, but when I have just one server mentioned in the CVS/Root files, it is not faster. Also, specifying 'cvs -d mirror' explicitly should get rid of this problem then (right?), and speed things up, which it doesn't. Or is the slowdown possibly due to the sheer *number* of CVS/Root files that are consulted? Would that be remedied by cvs -d too? I have no idea, I just observerd the slowdown multiple times. -Otto Actually, cvs(1) says: -d CVS_root_directory Use CVS_root_directory as the root directory pathname of the master source repository. Overrides the setting of the CVSROOT environment variable. This value should be specified as an absolute pathname. CVS/Root Pathname to the repository ( CVSROOT ) location at the time of checkout. This file is used instead of the CVSROOT environment variable if the environment variable is not set. A warning message will be issued when the contents of this file and the CVSROOT environment variable differ. The file may be over- ridden by the presence of the CVS_IGNORE_REMOTE_ROOT environment variable. It doesn't state explicitly whether 'cvs -d' makes the CVS/Root files ignored. Does it? Also, the wording for 'CVS/Root' doesn't seem to be entirely correct: If I untar, say, sys.tar.gz, then my local tree contains no CVS/Root files, and if I later do a 'cvs -d mirror up -Pd', the tree gets populated with CVS/Root files (mentioning mirror) -- that's not a time of checkout, that's an update. Also, having CVS_IGNORE_REMOTE_ROOT doesn't override CVS/Root, it just makes it ignored, right? Those different entries can be created when doing a cvs up -d that creates a new dir. Not only. A 'cvs -d mirror up -d' of a freshly untared sys.tar.gz creates CVS/Root files all over the place, *not* just in the new directories (that got created due to the 'up -d'). For example it creates ./sys/arch/i386/CVS/Root, while the directory /sys/arch/i386/ definitely was there before (so it didn't get created with 'up -d'). If a cvs -d option is used at the same time, the CVS/Root entry for tht dir wil be different than the other's. Yes, but it will also change the content of CVS/Root in directories that existed before. The exact cause of the slowdown is not known to me. But when you are switch repositories once in a while it's easy to get this case. I repair this by find . -name Root | xargs rm and using a explicit cvs root. So, using an explicit cvs root does not ignore the CVS/Root files? Because if it does, then the 'find | xargs rm' should make no difference, right? Now this is really another important issue of scattered information, is it, and it's not noted in anoncvs.html! I've slightly modified your command, i think my version is more secure for use on a webpage. -Otto --steffen Index: anoncvs.html === RCS file: /cvs/www/anoncvs.html,v retrieving revision 1.363 diff -a -p -u -r1.363 anoncvs.html --- anoncvs.html24 Jan 2012 09:57:35 - 1.363 +++ anoncvs.html3 Feb 2012 13:33:28 - @@ -542,6 +542,15 @@ add the em-d anon...@anoncvs.ca.openbs # strongcd /usr/src/strong # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong /pre + +p And because cvs(1) stores the name of the server which is in use once +a directory gets created in the file CVS/Root inside this new directory, ^^^ (not only) +it maybe wise to issue a command sequence like the following: +pre + # strongcd /usr/src/strong + # strongfind . -path '*CVS/Root' | xargs rm/strong + # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong +/pre /ul I think this is blind typing without understanding what is going on (not that I know), contrary to the ways of our brilliant FAQ. Let's understand it first. Can someone with internal knowledge of cvs shed some light on this please? Thank you for your time Jan
Re: Long delay updating xenocara source tree?
On Thu, Feb 09, 2012 at 07:52:44AM -0500, Jiri B wrote: On Thu, Feb 09, 2012 at 01:16:10PM +0100, Jan Stary wrote: +it maybe wise to issue a command sequence like the following: +pre + # strongcd /usr/src/strong + # strongfind . -path '*CVS/Root' | xargs rm/strong + # strongcvs -d anon...@anoncvs.ca.openbsd.org:/cvs -q up -Pd/strong +/pre /ul Never ever! For example if we would talk about ports tree, 'mystuff' could get taken from different cvs repo. CVS works like this, you can have multiple cvs repos inside the tree, it is by design. Instead of this silly command above, better to tell people to start learning cvs :) jirib Still the observation stands. -Otto
Re: Long delay updating xenocara source tree?
1. On the long run cvs(1) will die, and be replaced by Schily SCCS (oh god, why does v6 not have any branch name info, too??), which will rule the world. Without having the need to use GNU autoconf at all, so that software will compile with make(1) not gmake(1). Make bootstrapping easy. Freedom! Peace!! Love!!! Yup. 2. I like my patch. And my daily dose of Hypericum; highly recommendet. Jan Stary wrote [2012-02-09 13:16+0100]: [.] Actually, cvs(1) says: [.] This is not true for cvs(1) on MacOS X (Snow Leopard), btw. And heaven knows if a Linux system does have any manpages at all! Right?? (TinyCore definitely has none.) Yes, but it will also change the content of CVS/Root in directories that existed before. Huh? But that's right, push the people to it! The current FAQ does not massage CVS/Root related brain cells! I think this is blind typing without understanding I quote myself (quotes removed from sites though, so it may not be remembered 100 percent correctly): I use version control daily, but i don't want to think about it. (It was due to our massive internal hg(1)/git(1) war, and my favorite hg(1) - the user interface is so much better and easier to understand - 'lost due to .. Python and the .. backend.) That is to say: i agree with you. I am psychologically experienced. Can someone with internal knowledge of cvs shed some light on this please? Thank you for your time Jan --steffen
Re: Rescan SCSI bus
* Pierre Berthier pierre.berth...@ini.phys.ethz.ch [2012-02-09 14:21]: anyone knows how to get a scsi bus rescan after adding a disk, without rebooting? you can't really right now. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Long delay updating xenocara source tree?
there aren't all that many repositories the size of ours out there. My upload-traffic problem never occurred with binutils, which is also an *incredible* large repository, especially if you up -d. 10% there and my monthly traffic would exhaust, and no begging would help. I have no idea, I just observerd the slowdown multiple times. --steffen
Re: NDOutils 1.5 on OpenBSD 5.0
On 02/09/12 13:14, Stuart Henderson wrote: On 2012-02-09, Alvaro Mantilla Gimenez alv...@alvaromantilla.com wrote: Hi Stuart, El 08/02/12 20:09, Stuart Henderson escribis: On 2012-02-08, Alvaro Mantilla Gimenez alv...@alvaromantilla.com wrote: Hi, I am trying to install NDOutils 1.5 on OpenBSD 5.0 amd64. I am having a weird error during compilation. Not really weird, your include search path is wrong. Look at where gcc is searching and compare to where the files are. Are we talking about this error? /usr/bin/ld: /tmp//ccdrJBOI.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /tmp//ccdrJBOI.o: could not read symbols: Bad value collect2: ld returned 1 exit status Oh I didn't get that far down; that error message from the linker is pretty clear though.. I am not sure if this is something autogenerated by configure command or it is something I should change...somewhere...or just a GCC issue related with the platform (amd64). Yes you'll need to change the compiler flags to use -fPIC Also, I research about this and it seems it is related with amd64 only...other 64 bits platforms seems not have any issues like this. I would like to know if somebody on this list has NDOutils 1.5 running with Nagios (from ports). No but icinga + idoutils is in ports/packages and should work ok. (the core program and classic aka nagios-style-but-nicer cgi web interface work well; idoutils has seen a bit less testing but should also work, the icinga-web port isn't quite finished yet but my uncommitted diffs are not far off). Thanks for the tip about icinga + idoutils. I will test those too. Personally I'm not going to spend much time on nagios problems but am a bit more interested in any problems with running icinga on OpenBSD. btw, I find that upstream icinga developers are usually quite responsive too. If you search there are patches to get a 1.4 version working... http://www.kernel-panic.it/openbsd/nagios/nagios5.html#nagios-5.3.1 You need to patch at least include/config.h.in /usr/local/bin/mysql_config --include returns the include path, it's no longer a configure option... $ mysql_config --include -I/usr/local/include/mysql $ That path is correct so the config.h generated from config.h.in is wrong, you can get around this, combined with the previous patches. env CFLAGS=-g -O2 -I/usr/local/include -fPIC ./configure --disable-pgsql --enable-mysql make
Ghost Domain Names: Revoked Yet Still Resolvable
Dear all, It said due to design issues in the DNS protocol. So, indirectly and probably this will affect OpenBSD BIND too? Ghost Domain Names: Revoked Yet Still Resolvable https://www.isc.org/software/bind/advisories/cve-2012-1033 -- Thank you. Zamri Besar
Re: /etc/daily bug? altroot vs DUIDs
On Wed, 8 Feb 2012, Dave Anderson wrote:
On Tue, 7 Feb 2012, Kenneth R Westerback wrote:
On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote:
I've got a system running amd64/mp -current (latest source update on
February 1st) and have noticed (for quite a while, actually) that the
nightly backup of / to /altroot wasn't working. I finally got around to
looking into this and discovered that the /etc/daily script was
explicitly checking for /dev/whatever in the /altroot fstab entry -- but
I've been using DUIDs (as set up by the installer).
Shouldn't the daily script be updated to handle DUIDs as well as
explicit devices in /etc/fstab?
Dave
Does this diff work for you? Test with duid and without would be
nice. :-)
And don't be bashful. Anybody can test!
Ken
That works for me, both ways.
Thanks,
Dave
Aaargh! Not quite, it turns out. This superficially appears to work,
and does seem to work in the non-DUID case, but I evidently didn't look
at the results carefully enough. In the DUID case, rather than copying
/ to the altroot partition it copies it to /dev/rduid.partition!
My bad. Apologies to all.
I remember seeing a commit which sounds like it might tweak some
low-level functions to translate DUIDs into devices; I'll upgrade to a
current -current and see if this problem goes away.
Dave
Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.72
diff -u -p -r1.72 daily
--- daily 6 Dec 2011 21:02:39 - 1.72
+++ daily 7 Feb 2012 20:14:26 -
@@ -90,20 +90,20 @@ if [ -f /var/account/acct ]; then
fi
# If ROOTBACKUP is set to 1 in the environment, and
-# if filesystem named /altroot is type ffs, on /dev/* and mounted xx,
+# if filesystem named /altroot is type ffs and mounted xx,
# use it as a backup root filesystem to be updated daily.
next_part Backing up root filesystem:
while [ X$ROOTBACKUP = X1 ]; do
- rootbak=`awk '$2 == /altroot $1 ~ /^\/dev\// $3 == ffs \
- $4 ~ /xx/ \
- { print substr($1, 6) }' /etc/fstab`
+ rootbak=`awk '$2 == /altroot $3 == ffs $4 ~ /xx/ \
+ { print $1 }' /etc/fstab`
if [ -z $rootbak ]; then
echo No xx ffs /altroot device found in the fstab(5).
break
fi
- bakdisk=${rootbak%[a-p]}
+ rootbak=${rootbak#/dev/}
+ bakdisk=${rootbak%%?(.)[a-p]}
sysctl -n hw.disknames | grep -Fqw $bakdisk || break
- bakpart=${rootbak#$bakdisk}
+ bakpart=${rootbak##$bakdisk?(.)}
baksize=`disklabel $bakdisk 2/dev/null | \
awk -v part=$bakpart: '$1 == part { print $2 }'`
rootdev=`mount | awk '$3 == / $1 ~ /^\/dev\// $5 == ffs \
--
Dave Anderson
d...@daveanderson.com
leyes fiscales 2012
POR MEDIO DE LA PRESENTE LE MANDO UN CORDIAL SALUDO Y A LA VEZ, LA LISTA DE PRECIOS DE LAS LEYES FISCALES 2012 Breviario Fiscal con Correlaciones 2012 935.00 Csdigo Fiscal de la Federacisn Correlacionado 2012 1,799.00 INFONAVIT Correlacionado 2012 970.00 Ley Aduanera y de Comercio Exterior Correlacionadas 2012 1,799.00 Ley del ISR y del IETU Correlacionados 2012 1,799.00 Ley del IVA y del IEPS Correlacionados 2012 1,245.00 Leyes Fiscales con Correlaciones 2012 1,660.00 Leyes Fiscales del Distrito Federal 2012 1,660.00 Mexican Laws 2012 6,609.00 Porta Themis Fiscal con Correlaciones 2012 385.00 SAR Correlacionado 2012 1,799.00 Seguro Social Correlacionado 2012 1,799.00 Sumario Civil del Distrito Federal 2012 1,660.00 Sumario Civil Federal 2012 1,029.00 Sumario Financiero 2012 1,660.00 Sumario Fiscal Actualizable 2012 con Correlaciones. Incluye actualizacisn (cuatro envmos) 3,410.00 Sumario Fiscal con Correlaciones 2012 2,260.00 Sumario Laboral con Correlaciones 2012 2,059.00 Sumario Mercantil 2012 1,910.00 Sumario Penal del Distrito Federal 2012 1,010.00 Sumario Penal Federal 2012 1,269.00 Sumario Procesal 2012 1,110.00 Resoluciones Fiscales impresa con suscripcisn anual 2012 4,645.00 PAQUETES THEMIS 2012 PAQUETE FISCAL 1 Sumario Fiscal Actualizable. Incluye actualizacisn (cuatro envmos) Porta Themis Fiscal con Correlaciones Resoluciones Fiscales (Actualizacisn mensual impresa) 6,329.00 PAQUETE FISCAL 2 Sumario Fiscal Actualizable. Incluye actualizacisn (cuatro envmos) Porta Themis Fiscal con Correlaciones 3,605.00 PAQUETE FISCAL 3 Leyes Fiscales con Correlaciones Resoluciones Fiscales (Actualizacisn mensual impresa) 4,730.00 PAQUETE FISCAL 4 Sumario Fiscal con Correlaciones Sumario Laboral con Correlaciones Resoluciones Fiscales (Actualizacisn mensual impresa) 6,725.00 PAQUETE 1 LEYES FISCALES CORRELACIONADAS Ley del ISR y del IMPAC Correlacionadas Ley del IVA y del IEPS Correlacionadas Csdigo Fiscal de la Federacisn Correlacionado Ley Aduanera y de Comercio Exterior Correlacionadas 4,980.00 PAQUETE 2 LEYES FISCALES CORRELACIONADAS Ley del ISR y del IMPAC Correlacionadas Ley del IVA y del IEPS Correlacionadas Csdigo Fiscal de la Federacisn Correlacionado 3,635.00 PAQUETE SEGURIDAD SOCIAL Seguro Social Correlacionado INFONAVIT Correlacionado SAR Correlacionado Sumario Laboral 4,970.00 PAQUETE 1 SUMARIOS JURIDICOS Sumario Civil del Distrito Federal Sumario Civil Federal Sumario Financiero Sumario Laboral Sumario Mercantil Sumario Procesal Sumario Penal del Distrito Federal Sumario Penal Federal 8,789.00 PAQUETE 2 SUMARIOS JURIDICOS Sumario Civil Federal Sumario Financiero Sumario Laboral Sumario Mercantil Sumario Procesal Sumario Penal Federal 6,780.00 LEYES PARA PROFESIONALES 2012 / ACTUALIZACION ELECTRONICA Csdigo Fiscal de la Federacisn Correlacionado 2012 2,198.00 INFONAVIT Correlacionado 2012 1,369.00 Ley Aduanera y de Comercio Exterior Correlacionadas 2012 2,198.00 Ley del ISR y del IETU Correlacionados 2012 2,198.00 Ley del IVA y del IEPS Correlacionados 2012 1,646.00 Leyes Fiscales con Correlaciones 2012 2,062.00 Leyes Fiscales del Distrito Federal 2012 2,062.00 SAR Correlacionado 2012 2,198.00 Seguro Social Correlacionado 2012 2,198.00 Sumario Civil del Distrito Federal 2012 2,062.00 Sumario Civil Federal 2012 1,428.00 Sumario Financiero 2012 2,062.00 Sumario Fiscal con Correlaciones 2012 2,661.00 Sumario Laboral con Correlaciones 2012 2,458.00 Sumario Mercantil 2012 2,312.00 Sumario Penal del Distrito Federal 2012 1,407.00 Sumario Penal Federal 2012 1,669.00 Sumario Procesal 2012 1,511.00 SISTHEMIS POR MATERIA PLUS (INTEGRAL) 7,860.00 FISCAL NACIONAL Y DE SEGURIDAD SOCIAL 3,589.00 FISCAL INTERNACIONAL 4,990.00 ADMINISTRATIVO / MERCANTIL / CIVIL 1,975.00 COMERCIO EXTERIOR Y ADUANAS 1,975.00 LABORAL 1,975.00 PENAL 1,975.00 CONSTITUCIONAL / PROCESAL / ITERNACIONAL Y DERECHOS HUMANOS 1,975.00 BANCARIO / BURSATIL / SEGUROS Y FIANZAS 1,975.00 LEYES EN INGLES 4,990.00 SUSCRIPCION PLUS (INTEGRAL) 7,860.00 SUSCRIPCION FISCAL NACIONAL Y DE SEGURIDAD SOCIAL 3,589.00 SUSCRIPCION FISCAL INTERNACIONAL 4,990.00 SUSCRIPCION ADMINISTRATIVO / MERCANTIL / CIVIL 1,975.00 SUSCRIPCION COMERCIO EXTERIOR Y ADUANAS 1,975.00 SUSCRIPCION LABORAL 1,975.00 SUSCRIPCION PENAL 1,975.00 SUSCRIPCION CONSTITUCIONAL / PROCESAL / ITERNACIONAL Y DERECHOS HUMANOS 1,975.00 SUSCRIPCION BANCARIO / BURSATIL / SEGUROS Y FIANZAS 1,975.00 SUSCRIPCION LEYES EN INGLES 4,990.00 COLECCISN FORO DE LA BARRA Homenaje a Fernando Vazquez Pando305.00 Reformas al Sistema de Seguridad Social199.00 Las Nuevas Tecnologmas y la Proteccisn del Derecho de Autor229.00
nat-to source-hash strangeness
Hi,
source-hash gives me different IP when used on different rules
pass out quick log on $ext_if proto tcp from 10.0.0.1 to 203.0.113.1
port 80 nat-to 192.0.2.0/24 source-hash
pass out quick log on $ext_if proto tcp from 10.0.0.1 to 203.0.113.1
port 443 nat-to 192.0.2.0/24 source-hash
With this I get:
Feb 09 17:32:29.467431 rule 133/(match) pass out on vlanxxx:
192.0.2.1.64386 203.0.113.1.80: S 2151338718:2151338718(0) win 14600
mss 1440,sackOK,timestamp 883937025 0,nop,wscale 9
Feb 09 17:32:33.464448 rule 134/(match) pass out on vlanxxx:
192.0.2.2.57614 203.0.113.1.443: S 2121037714:2121037714(0) win 14600
mss 1440,sackOK,timestamp 883941022 0,nop,wscale 9
If I change the firewall rule to:
pass out quick log on $ext_if proto tcp from 10.0.0.1 to 203.0.113.1
port {80, 443} nat-to 192.0.2.0/24 source-hash
although this is evaluated in 2 rules (at least in pfctl -sr) I always
get the same IP 192.0.2.1
Is this normal?
thanks,
Giannis
Re: Long delay updating xenocara source tree?
Replying to myself,
On Feb 09 13:16:10, Jan Stary wrote:
Also, specifying 'cvs -d mirror' explicitly should get rid of this
problem then (right?), and speed things up, which it doesn't.
it does; see below.
Or is the slowdown possibly due to the sheer *number* of CVS/Root
files that are consulted? Would that be remedied by cvs -d too?
Actually, cvs(1) says:
-d CVS_root_directory
Use CVS_root_directory as the root directory pathname of
the master source repository. Overrides the setting of the
CVSROOT environment variable. This value should be specified
as an absolute pathname.
CVS/Root
Pathname to the repository ( CVSROOT ) location at the
time of checkout. This file is used instead of the CVSROOT
environment variable if the environment variable is not
set. A warning message will be issued when the contents
of this file and the CVSROOT environment variable differ.
The file may be over- ridden by the presence of the
CVS_IGNORE_REMOTE_ROOT environment variable.
It doesn't state explicitly whether 'cvs -d'
makes the CVS/Root files ignored. Does it?
I think it does: I tested with ktrace.
Without the explicit -d cvsroot, the kdump of 'ktrace cvs -q up -Pd'
contains a lot of sequences like this (ommiting sigprocmask and mprotect):
27461 cvs CALL stat(0x8a0af780,0xcfbf3da8)
27461 cvs NAMI CVS
27461 cvs STRU struct stat {dev=1028, ino=27355, mode=drwxr-xr-x ,
nlink=2, uid=0, gid=0, rdev=117141, atime=1313508893,
stime=1328714573.403561510, ctime=1328714573.403561510, size=512, blocks=4,
blksize=16384, flags=0x0, gen=0x7c8f81d }
27461 cvs RET stat 0
27461 cvs CALL access(0x8a0aff10,0x4R_OK)
27461 cvs NAMI CVS/Root
27461 cvs RET access 0
27461 cvs CALL open(0x8a0aff10,0O_RDONLY,unused0x1b6)
27461 cvs NAMI CVS/Root
27461 cvs RET open 3
27461 cvs CALL fstat(0x3,0xcfbf3cd0)
27461 cvs STRU struct stat {dev=1028, ino=28235, mode=-rw-r--r-- ,
nlink=1, uid=0, gid=0, rdev=113711, atime=1328714573.403561510,
stime=1328714573.403561510, ctime=1328714573.403561510, size=21, blocks=4,
blksize=16384, flags=0x0, gen=0xbde86d5b }
27461 cvs RET fstat 0
27461 cvs CALL read(0x3,0x85d34000,0x4000)
27461 cvs GIO fd 3 read 21 bytes
/home/cvsync/openbsd
27461 cvs RET read 21/0x15
I haven't looked at the cvs source code, but this is
undoubtedly cvs checking if there is a readable CVS/Root,
opening it, and reading it (indeed, /home/cvsync/openbsd
is my locally cvsync'd cvsroot).
Now, with the explicit cvs -d cvsroot, a kdump of
'ktrace cvs -q -d /home/cvsync/openbsd up -Pd' says
3670 cvs CALL access(0x3c00f315,0F_OK)
3670 cvs NAMI CVS/Root
3670 cvs RET access 0
which is just a check whether the file exists.
It is never opened, read from, or written to.
So it seems that 'cvs -d mirror up -d' creates the CVS/Root file
(and writes mirror into it) if the file doesn't exist; if it does
exist, it is ignored.
The exact cause of the slowdown is not known to me. But when you are
switch repositories once in a while it's easy to get this case.
I repair this by find . -name Root | xargs rm and using a explicit cvs
root.
So, using an explicit cvs root does not ignore the CVS/Root files?
Because if it does, then the 'find | xargs rm' should make no difference,
right?
Given the above, doing
find . -name Root | xargs rm
cvs -d mirror up -Pd
actually means *more* work, as it creates and writes all the CVS/Root files.
If they are left there (skip the find | xargs rm), it is only checked that
they exist and left intact -- which is less work, right?
(Then again, I am just reading a kdump. I don't know what CVS really does.)
Here are the tests I did on /usr/src, in the simplest case
of having a local cvsroot, uniform for all files in the tree:
With the CVS/Root files present, all containing /home/cvsync/openbsd:
time cvs -q up -Pd
4m44.15s real 0m4.64s user 0m8.49s system
4m43.67s real 0m4.25s user 0m8.84s system
4m11.57s real 0m4.36s user 0m8.77s system
4m20.84s real 0m4.55s user 0m8.46s system
4m24.09s real 0m4.43s user 0m8.82s system
4m52.91s real 0m4.32s user 0m8.40s system
4m42.52s real 0m4.53s user 0m8.36s system
4m33.40s real 0m4.64s user 0m8.35s system
4m55.80s real 0m4.43s user 0m8.51s system
time cvs -q -d /home/cvsync/openbsd up -Pd
4m24.48s real 0m4.28s user 0m8.35s system
4m21.63s real 0m4.27s user 0m8.43s system
4m14.73s real 0m4.44s user 0m8.43s system
4m13.98s real 0m4.26s user 0m7.93s system
4m17.07s real 0m4.38s user 0m7.90s system
4m18.60s real 0m4.35s user 0m8.77s system
Re: Long delay updating xenocara source tree?
On Thu, Feb 09, 2012 at 06:15:50PM +0100, Jan Stary wrote: Replying to myself, [snip] Things might change if (1) the cvsroot is remote (2) it is not the same for all files. I will try that next. Jan That last case (remote repo's and different Roots) is the actual case I have observerd multipe times. There might be playing other facts though, but I'm curious what that test case shows. BTW, AFAIK, cvs -d up does not write Root files. -Otto
[SOLVED] NDOutils 1.5 on OpenBSD 5.0
El 09/02/12 08:42, Nigel Taylor escribis: env CFLAGS=-g -O2 -I/usr/local/include -fPIC ./configure --disable-pgsql --enable-mysql That worked great!!! Thanks so much!! Alvaro
Re: Long delay updating xenocara source tree?
On Feb 09 18:54:45, Otto Moerbeek wrote: BTW, AFAIK, cvs -d up does not write Root files. It does: cd /usr/src ftp -o - ftp://MIRROR/pub/OpenBSD/5.0/sys.tar.gz | tar xzpf cd sys find . -name Root cvs -q -d MIRROR up find . -name Root Jan
Re: Long delay updating xenocara source tree?
On Feb 09 20:10:11, Jan Stary wrote: On Feb 09 18:54:45, Otto Moerbeek wrote: BTW, AFAIK, cvs -d up does not write Root files. It does: cd /usr/src ftp -o - ftp://MIRROR/pub/OpenBSD/5.0/sys.tar.gz | tar xzpf cd sys find . -name Root cvs -q -d MIRROR up find . -name Root Ah, you mean 'write' as opposed to 'create'? What I showed above is that 'cvs -d MIRROR up' _creates_ the CVS/Root in the directories where they did not exist. But you are right, running 'cvs -d OTHERMIRROR up' does _not_ rewrite those CVS/Root files that already exist. Jan
Re: Long delay updating xenocara source tree?
On Thu, Feb 09, 2012 at 08:16:25PM +0100, Jan Stary wrote: On Feb 09 20:10:11, Jan Stary wrote: On Feb 09 18:54:45, Otto Moerbeek wrote: BTW, AFAIK, cvs -d up does not write Root files. It does: cd /usr/src ftp -o - ftp://MIRROR/pub/OpenBSD/5.0/sys.tar.gz | tar xzpf cd sys find . -name Root cvs -q -d MIRROR up find . -name Root Ah, you mean 'write' as opposed to 'create'? What I showed above is that 'cvs -d MIRROR up' _creates_ the CVS/Root in the directories where they did not exist. But you are right, running 'cvs -d OTHERMIRROR up' does _not_ rewrite those CVS/Root files that already exist. Jan I meant 'create' but a test clearly shows that it does create missing Root files. Sorry for the confusion, I must be mixing this up with some other weird cvs behaviour I've seen in the past. -Otto
Re: the aucat recording studio - stereo panning
You'll face other problems preventing you from doing everything with aucat. First, there's no reverb, which is necessary to create the spacial feel, volume changes are too abrupt (cause small clicks) and not real-time. Implementing pan, effects and smooth parameter changes would bloat aucat/sndiod. IMO the way to go is to handle processing in small programs (with a simple record-process-play loop) and keep sndiod only for routing the signal to the hardware or other programs. Currently that's the way I handle some effects, I write small programs that apply effects on the record stream to send the result in real-time on the play stream. Then I use -mmon to record the result in a file. Not very flexible, but good enough to test the concept. If I understand what you are doing, perhaps you have another way. Noatun doesn't make the deal ? You play audio file with it and add the filter Arts::Synth_FREEVERB. It has the essential control knobs for reverb. Kaffeine has other filters for audio. Noatun Kaffeine work well with filters, parameters can be adjusted in real-time. And it should be possible to record the audio output in a file. And perhaps you will want to write new filters for them ;).
Re: the aucat recording studio - stereo panning
On 02/09/2012 06:05 PM, Alexandre H wrote: You'll face other problems preventing you from doing everything with aucat. First, there's no reverb, which is necessary to create the spacial feel, volume changes are too abrupt (cause small clicks) and not real-time. Implementing pan, effects and smooth parameter changes would bloat aucat/sndiod. IMO the way to go is to handle processing in small programs (with a simple record-process-play loop) and keep sndiod only for routing the signal to the hardware or other programs. Currently that's the way I handle some effects, I write small programs that apply effects on the record stream to send the result in real-time on the play stream. Then I use -mmon to record the result in a file. Not very flexible, but good enough to test the concept. If I understand what you are doing, perhaps you have another way. Noatun doesn't make the deal ? You play audio file with it and add the filter Arts::Synth_FREEVERB. It has the essential control knobs for reverb. Kaffeine has other filters for audio. Noatun Kaffeine work well with filters, parameters can be adjusted in real-time. And it should be possible to record the audio output in a file. And perhaps you will want to write new filters for them ;). Has 'sox' been mentioned in this context? For many simple filters, source-sox-aucat works well for me. Command line only.
Re: Long delay updating xenocara source tree?
On 2012-02-09, Steffen Daode Nurpmeso sdao...@googlemail.com wrote: On the long run cvs(1) will die, and be replaced by Schily SCCS oh please don't, even as a joke. anyway they are still releasing new versions of CVS. (they have to, they add new features with security holes...) I like my patch. And my daily dose of Hypericum; highly recommendet. we will need a bulk order if we have to use SCCS ;)
Does cvsync let ancient patches escape from the attic?
Hi, Yesterday I updated to current and rebuilt the ports I use. All went well except building mupdf, which stalled at file to patch:: # cd textproc/mupdf/ # make install === Checking files for mupdf-0.9 `/usr/ports/distfiles/mupdf-0.9-source.tar.gz' is up to date. (SHA256) mupdf-0.9-source.tar.gz: OK . === Extracting for mupdf-0.9 === Patching for mupdf-0.9 File to patch: Looking in /usr/ports/textproc/mupdf/patches/ $ ls CVS patch-apps_unix_ximage_c patch-debian_mupdf_pc patch-Makerules patch-debian_mupdf_desktop Somehow patch-apps_unix_ximage_c has gotten in there, even though (according to http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/ ) it was moved to the attic over 2 years ago. To use cvsync I do: $ su - cvsyncuser $ cvsync -4 -c /home/cvsyncuser/cvsync-config and then to update my source to build from: # cd /usr/ports (and src xenocara) # cvs -d /usr/cvsync up -Pd The only thing I can think that I have done out-of-the-ordinary is # chown -R cvsyncuser /usr/cvsync repository when I stopped cvsync'ing as root (but it seems unlikely chown would cause a file to move directories). Has anyone seen this happen before? Have I done something to mess this up? Brett.
Re: Does cvsync let ancient patches escape from the attic?
On Thu, Feb 9, 2012 at 4:43 PM, Brett brett.ma...@gmx.com wrote: Hi, Yesterday I updated to current and rebuilt the ports I use. All went well except building mupdf, which stalled at file to patch:: # cd textproc/mupdf/ # make install === Checking files for mupdf-0.9 `/usr/ports/distfiles/mupdf-0.9-source.tar.gz' is up to date. (SHA256) mupdf-0.9-source.tar.gz: OK . === Extracting for mupdf-0.9 === Patching for mupdf-0.9 File to patch: Looking in /usr/ports/textproc/mupdf/patches/ $ ls CVS patch-apps_unix_ximage_c patch-debian_mupdf_pc patch-Makerules patch-debian_mupdf_desktop Somehow patch-apps_unix_ximage_c has gotten in there, even though (according to http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/ ) it was moved to the attic over 2 years ago. $ cvs status patch-apps_unix_ximage_c see if there is sticky tag there. If so, then do: $ cvs up -dPA --patrick
Re: Does cvsync let ancient patches escape from the attic?
Somehow patch-apps_unix_ximage_c has gotten in there, even though (according to http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/ ) it was moved to the attic over 2 years ago. $ cvs status patch-apps_unix_ximage_c see if there is sticky tag there. If so, then do: $ cvs up -dPA --patrick # cvs -d/usr/cvsync status /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c === File: patch-apps_unix_ximage_c Status: Up-to-date Working revision:1.1 Fri Feb 10 00:17:20 2012 Repository revision: 1.1 /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not return to the attic. The hostname in my cvsync config file is cvsync.allbsd.org if that would make any difference. Brett.
Re: Long delay updating xenocara source tree?
On 02/09/12 12:54, Otto Moerbeek wrote: On Thu, Feb 09, 2012 at 06:15:50PM +0100, Jan Stary wrote: Replying to myself, [snip] Things might change if (1) the cvsroot is remote (2) it is not the same for all files. I will try that next. Jan That last case (remote repo's and different Roots) is the actual case I have observerd multipe times. There might be playing other facts though, but I'm curious what that test case shows. ... cvs does some weird s**t from time to time. I've had the chance to watch it on a public server..it only gets weirder when you watch it there. SOMETIMES -- and I do not know why -- it builds a tree in the cvs server's tmp dir (which is probably something like /repo/anoncvs/tmp in a good mirror), which is as almost as big as the repo it is serving -- I've seen 600+M in size for a single user. That's a lot of disk thrashing, 'specially if it is on the same disk with a few other people doing checkouts or updates, and maybe serving install, too. Yeah, I was able to throw massive amounts of disk I/O and a MFS tmp dir at it, but not all mirrors have that kind of throughput under those circumstances. (keep in mind, on i386, MFS can be no bigger than a hair under 1GB, and 600MB is a non-trivial chunk of that. And if a CVS process disconnects prematurely, the tmp file never gets purged by cvs). I do not know why it does those 600M temp dirs...sometimes (usually?), it does just a few MB. Combine a few people having a nasty update (with the 600MB tmp dirs), slow disk I/O on the server and a lot of disk thrashing...well, uh...no, I STILL can't explain a nine (plus!) hour update, but I do think a large chunk of the problem may be on the server's side. and possibly, if you have multiple servers in different parts of the tree, maybe multiple servers. But no, I'm NOT going to advise people to blow away all their CVS/Root files routinely, for the most part, I find them more useful than harm, but there are a FEW times when it would be appropriate to do so, so a FAQ entry will be coming on this. As trouble resolving thing...great. I've thought about CHANGING all my Root files (as I'm going to have to change my mirror soon...and I'm hoping, soon again after that), simply deleting them and having them recreate is quite nifty, wish I had thought of that. :) Nick.
Re: Does cvsync let ancient patches escape from the attic?
On Thu, Feb 9, 2012 at 6:26 PM, Brett brett.ma...@gmx.com wrote: Somehow patch-apps_unix_ximage_c has gotten in there, even though (according to http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/ ) it was moved to the attic over 2 years ago. $ cvs status patch-apps_unix_ximage_c see if there is sticky tag there. If so, then do: $ cvs up -dPA --patrick # cvs -d/usr/cvsync status /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c === File: patch-apps_unix_ximage_c Status: Up-to-date Working revision:1.1 Fri Feb 10 00:17:20 2012 Repository revision: 1.1 /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not return to the attic. The hostname in my cvsync config file is cvsync.allbsd.org if that would make any difference. I would try another cvsync host and see if the issue gets resolved. --patrick
Re: Does cvsync let ancient patches escape from the attic?
On 09/02/2012, Brett brett.ma...@gmx.com wrote: Somehow patch-apps_unix_ximage_c has gotten in there, even though (according to http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/ ) it was moved to the attic over 2 years ago. $ cvs status patch-apps_unix_ximage_c see if there is sticky tag there. If so, then do: $ cvs up -dPA --patrick # cvs -d/usr/cvsync status /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c === File: patch-apps_unix_ximage_c Status: Up-to-date Working revision:1.1 Fri Feb 10 00:17:20 2012 Repository revision: 1.1 /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not return to the attic. The hostname in my cvsync config file is cvsync.allbsd.org if that would make any difference. Brett. Looks like cvsync.allbsd.org is in trouble -- patch-apps_unix_ximage_c is present both outside Attic at rev1.1, and within Attic at rev1.2. http://cvsweb.allbsd.org/cvsweb.cgi/ports/textproc/mupdf/patches/?cvsroot=openbsd http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/ Perhaps Hiroki can clarify how this could have happened. C.
Re: /etc/daily bug? altroot vs DUIDs
On Thu, Feb 09, 2012 at 10:25:45AM -0500, Dave Anderson wrote: On Wed, 8 Feb 2012, Dave Anderson wrote: On Tue, 7 Feb 2012, Kenneth R Westerback wrote: On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote: I've got a system running amd64/mp -current (latest source update on February 1st) and have noticed (for quite a while, actually) that the nightly backup of / to /altroot wasn't working. I finally got around to looking into this and discovered that the /etc/daily script was explicitly checking for /dev/whatever in the /altroot fstab entry -- but I've been using DUIDs (as set up by the installer). Shouldn't the daily script be updated to handle DUIDs as well as explicit devices in /etc/fstab? Dave Does this diff work for you? Test with duid and without would be nice. :-) And don't be bashful. Anybody can test! Ken That works for me, both ways. Thanks, Dave Aaargh! Not quite, it turns out. This superficially appears to work, and does seem to work in the non-DUID case, but I evidently didn't look at the results carefully enough. In the DUID case, rather than copying / to the altroot partition it copies it to /dev/rduid.partition! My bad. Apologies to all. I remember seeing a commit which sounds like it might tweak some low-level functions to translate DUIDs into devices; I'll upgrade to a current -current and see if this problem goes away. I tried latest -current (from sources), and the same problem is there as well. I think this change should be reverted, because having a copy of root partition sitting as world readable in /dev is not cool: 08:35 je@iso:~$ ls -l /dev/rec6572ba6b33d733.a -rw-r--r-- 1 root wheel 143M Feb 10 08:23 /dev/rec6572ba6b33d733.a Juha
Taller Práctico de Finanzas NO Financieros 29 de Febrero
[IMAGE] Pms de Mixico prestigiada firma de Capacitacisn presenta: Taller de Finanzas para NO Financieros 29 de Febrero en la ciudad de Mixico. Capacitacisn personalizada por el experto en la materia. Este entrenamiento tiene valor curricular y garantma de satisfaccisn. Obtenga las herramientas necesarias para alcanzar un sptimo desempeqo en su funcisn. !Reciba la informacisn completa y Revise la agenda! Por favor responda este e-mail con los datos siguientes Empresa Nombre Telifono Email Nzmero de Interesados En breve recibira temario, reseqa de expositor y tarifas. Pms Capacitacisn Efectiva de Mixico es una empresa Registrada ante la STPS Trabajamos con expertos en la materia para poder brindar herramientas tacticas, vanguardistas y de facil aplicacisn. Si lo prefiere comunmquese a los telifonos donde con gusto uno de nuestros ejecutivos le atendera. Telifonos: (0133) 8851-2365, (0133) 8851-2741 con mas de 10 lmneas. Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Copyright (C) 2011, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. E-Mail MARKETING SERVICE POWERED BY MEDIAMKTOOLS. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. ALTO, si en esta ocasisn la informacisn recibida no fue de su interis pero desea recibir informacisn personalizada en relacisn a otros temas favor de indicarlo. Si usted ha recibido este mensaje por error, haga caso omiso de el y de antemano una sincera disculpa por la molestia, reporte su cuenta respondiendo este correo con el subject BAJAFINANZAS Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAFINANZAS Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia para nosotros y no es intencisn de la empresa la inconformidad del receptor, nuestra intencisn es promover herramientas de utilidad para el [demime 1.01d removed an attachment of type image/jpeg which had a name of image003.jpg]
