Re: [flashrom] Porting flashrom to OpenBSD
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs. PCI config space writes (usually only to the PCI-LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years. flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip). I understand very well what you are trying to do. But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode. Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a hole for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working. Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix. Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD. I don't buy any of that stuff. By the time this has happened, you're already hosed.
Re: Porting flashrom to OpenBSD
Stuart Henderson wrote: Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile). You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at http://spacehopper.org/flashrom.txt Hi sthen, I've reported this to the lists and elsewhere before, libpci writes appear broken on at least i386/amd64, and have been for some time.. it always returns error on writes, setpci from pciutils also fails. I suspect the problem is in the kernel, not libpci.. but I haven't been able to figure it out yet. I believe once libpci/pci(4) writes are fixed, flashrom should work as intended. I would say that, as a general principle -- if you can't find this and fix it yourself, you probably are unable to evaluate the risk from bypassing the kernel and talking direct to the hardware.
Re: GCC4: To bump or not to bump?
Everytime an architecture switches to GCC4, there are dependency changes for all ports that use MODULES=gcc4 and C++ on that arch. Normally, this would require a PKGNAME bump. On the other hand, the gcc4 switch is something of a flag day for that arch anyway. So... ... to bump or not to bump? When we are un-cautious about this, I would like to request a second approach: Gaurantee a crank before the next release happens.
Re: mandoc errors in ports
I would tend to disagree. Please consider adding section names in national
languages. makewhatis already does so, it's completely harmless.
Formated.pm:if
(m/^(?:NAME|NAMES|NAMN|NOMBRE|NOME|Name|\xbe|\xcc\xbe\xbe\xce|\xcc\xbe\xc1\xb0)\s*$/)
{
I intensely dislike this since it simply doesn't scale. Luckily
we only have a few non-English man pages in the tree and these are
handled very haphazardly. But for perspective: LC_MESSAGES come
in, what, fifty languages? A hundred?
The bigger picture is that it would be incompatible with the 20 year
mandoc language.
mandoc(1) should do what doc-nroff does.
Re: mandoc errors in ports
On Sun, Apr 04, 2010 at 05:05:40PM +, Christian Weisgerber wrote:
Marc Espie es...@nerim.net wrote:
I would tend to disagree. Please consider adding section names in national
languages. makewhatis already does so, it's completely harmless.
Formated.pm:if
(m/^(?:NAME|NAMES|NAMN|NOMBRE|NOME|Name|\xbe|\xcc\xbe\xbe\xce|\xcc\xbe\xc1\xb0)\s*$/)
{
I intensely dislike this since it simply doesn't scale. Luckily
we only have a few non-English man pages in the tree and these are
handled very haphazardly. But for perspective: LC_MESSAGES come
in, what, fifty languages? A hundred?
It's practical. I want it to work on every manpage in the ports tree, not
every possible thing we would have to worry about 20 years in the future.
Too bad it is incompatible.
Re: pftop - cannot access rules in 4.6-release
I got the following error while moving through the screens in pftop: Error Reading Anchor / (DIOCGETRULES): Permission denied Anybody else getting this error? This was from packages. Non-root cannot read that. It is security sensitive. Isn't that obvious?
Re: update blows up
i dont see how this is stupid... Don't worry. Most of us see your name and at that moment delete the mail. This reply is an exception.
Re: update blows up
2009/10/8 Stuart Henderson st...@openbsd.org: If you want something better, download SHA256 and check the hashes. I know this has been discussed before, but other free OS solve this problem (among others) by signing their packages. Feel free to flame me. Solve the problem that all the packages are exported via a only a T1 because people don't fund the project enough and we can take the next steps.
Re: update blows up
Mirrors pull from other mirrors, with this method some mirrors will do their own lock handling, others will just rsync the lock files from their upstream and you'll end up with a broken mirror that looks valid. Or something may go wrong and a transfer only goes halfway while indicating success, etc. It's not robust. If you want something better, download SHA256 and check the hashes. Stuart, I think we are missing an opportunity to recruit this person to manage the 50+ mirrors that the project runs, which are of course many many steps removed from the build process... Oh oops. I forgot. We don't trust this specific loser we are discussing, since he spends all his time making uneducated complaints on the mailing lists. Sorry, forget the idea.
Re: NetBSD ports
Probably I am going to ask a stupid question but it is very interesting for me. Because I would like to help BSD projects. Why OpenBSD does not use pkgsrc of NetBSD project as default ports? I guess work can be faster in case port system is shared between BSD projects including FreeBSD. NetBSD ports are ported to many Oses so I would prefer these port system. Just like all the countries in the world should get together for a central governemnt and there would be more love, right?
Re: NetBSD ports
I am sorry. Really, I don't want to have support here. I just would like to know relationship between pkgsrc and original OpenBSD port system. A lot of English is spoken in India because the British used to be there a long time ago. How does it change anything if you know the relationship?
Re: NetBSD ports
Probably I am going to ask a stupid question but it is very interesting for me. Because I would like to help BSD projects. Why OpenBSD does not use pkgsrc of NetBSD project as default ports? I guess work can be faster in case port system is shared between BSD projects including FreeBSD. NetBSD ports are ported to many Oses so I would prefer these port system. Just like all the countries in the world should get together for a central governemnt and there would be more love, right? Yes. Like that - BSD community. I do not think it is Utopia. I think at first there is a need to discussed some general aims and rules which helps to resolve difference opinions. Then do common work together. For example (below just alphabetically sort BSD systems), - FreeBSD would like to be fastest under i386. FreeBSD team can do packages/ports related to i386. - NetBSD would like to be ported under many platforms. This BSD can do all rest work. - OpenBSD would like to be very secure and stable. Blowfish team can implement packages system to build them for N-platform using pkgsrc. I guess cooperation of BSD teams can save time to concentrate for different aims, but not common. BSD community is the power . Unfortunately, I can see divisions like DragonflyBSD. I guess it is bad way. It is just my opinion. What you suggest is absolute rubbish. It is just talk -- not action -- but furthermore you don't have a clue what you are talking about.
4.6 packages
What architectures are getting packages for the 4.6 release?
Re: opera 10 beta with unite
It would take a lot more than change of license for Opera to be available on CD. It has to be Open Source project. Where does it say that the packages on CD must only be open-source? I say so. Is that enough?
Re: user and syslog question for pptp client
On Mon, Jun 01, 2009 at 11:20:19PM -0600, Theo de Raadt wrote: Hmm.. kinda feels like a waste to create a new user/group. The app doesn't write to any files nor does it have any config files (ATM). How about I stick with nobody? How about everyone just share the root account? What are you afraid of, that we'll run out of users and groups? There are very good documented reasons why we have all daemons use different uids. Much security is failed from seperation. OK. I was just trying to use an available non-privileged account. I had not realized nobody was special in that it is being used for NFS. Every account that exists is being used for something. The point isn't just about nobody; it is about using the uid space for seperation. If you share, you don't have seperation.
Re: user and syslog question for pptp client
Hmm.. kinda feels like a waste to create a new user/group. The app doesn't write to any files nor does it have any config files (ATM). How about I stick with nobody? How about everyone just share the root account? What are you afraid of, that we'll run out of users and groups? There are very good documented reasons why we have all daemons use different uids. Much security is failed from seperation.
Re: python now requires X11 installed
I used to run all my OpenBSD servers with no X11. Now, to build nmap, you seem to need python. There are no FLAVORS and so no obvious way to prevent it from requiring python. And to build python, you need X11R6 installed. There are no FLAVORS as there used to be, to compile without tkinter to avoid requiring X11R6. Is it possible to install these without installing X11R6? Maybe I just don't understand the way ports work well enough. And, why the change? Would you prefer to live in a world with 500 flavors? Perhaps. Would you prefer if the ports developers spent all their time building and testing flavors, instead of bringing new code into the ports tree? That is the choice. So sometimes changes like that come direct from the upstream. Supporting flavors (which are mostly restrictions on what gets used) always requires more testing. Sometimes there is no choice but to accept the upstream.
Re: fyi port for graphics/png does not like MANPS=1
ppruett-lists writes: I happened to put in my /etc/mk.conf MANPS=1 ... And lol, I got a install error, for the package graphics/png I would not expect MANPS to work. The problem is probably more than only one package. 'man 7 ports' says this: BUGS Use of the MANPS and MANZ variables is not supported. Those variables are for the src tree. Not everything in OpenBSD is useable by everything. This is not just an OpenBSD issue. All systems of any kind have special features like that which are not universally useable.
Re: msttcorefonts fontconfig workaround
On Mon, 04 May 2009 07:31:39 +0200, Matthew Szudzik wrote: One of the xenocara font configuration files is interfering with the /x11/msttcorefonts port. See http://marc.info/?l=openbsd-miscm=124141462930332 Perhaps the port should be updated, so that the configuration file is disabled when the port is installed. I think it would be even better to have 31-nonmst.conf removed altogether. This issue clearly shows that the file hardly makes any sense. Its contents are better off in someone's personal ~/.fonts.conf than in a system-wide configuration file. Wow, your process stinks. Sure, we'll do that. Then you can only print in Mozilla if you have the Microsoft fonts installed. We'll get right on that, since you were carefully judged the situation. Always happy to get advice from the exports!
Re: msttcorefonts fontconfig workaround
hmm, on Mon, May 04, 2009 at 05:29:02PM +0200, Marc Espie said that They assume you will always have the microsoft core fonts installed, even though these basically ARE NOT open source. if i am not mistaken generic names like times, helvetica, courier, etc are used by more foundries, not only microsoft... so perhaps there was no such assumption from their side and simply the prehistoric bitmap fonts are used because, well, they are prehistoric and have been here forever.. on the other hand i am not sure an unconditional system-wide override should be the way to go, are we now supposed to fight with config files when we add arbitrary font packages? i am quite interested why was this change promoted from a personal fontconfig setting to a system-wide one. wouldn't it be enough to have this change for people who want it in their personal fontconfig overrides? perhaps you are right. the people who want mozilla to be able to print should configure it so. by default, people should end up with broken ps and pdf files. you had me going for a moment..
Re: msttcorefonts fontconfig workaround
well, i dont have even have firefox installed. why should i care? I did not realize we were developing OpenBSD just for you. now i will have to override an override to get the expected behaviour. since when is openbsd firefox's bitch? Your attitude is not very nice.
Re: msttcorefonts fontconfig workaround
hmm, on Mon, May 04, 2009 at 05:29:02PM +0200, Marc Espie said that You want the msttcorefonts ? install them... True, adding a fonts.conf snippet when you install them so they get used would make sense. if anything, openbsd should package a fonts.conf with the firefox package instead. and still only suggest it and not override stuff on a whim. You just plain don't understand the problem. Firefox was just an example.
Re: msttcorefonts fontconfig workaround
hmm, on Mon, May 04, 2009 at 12:26:35PM -0600, Theo de Raadt said that well, i dont have even have firefox installed. why should i care? I did not realize we were developing OpenBSD just for you. i did not realize openbsd was developed for firefox. what i was trying to say, why should i care that firefox cannot print to file unless massaged with a custom fonts.conf? you say it was only an example. ok, can you give me some other examples how by default, people should end up with broken ps and pdf files. ? I won't, because you are being hostile. i regularly produce files in X using a boatload of applications from gimp to tex and have never come accross the problem you are trying to solve. contrarywise, now the system messes with my font configuration for no good apparent reason. It does not -- it actually offers vector fonts that are installed to applications instead of only offering them bitmap fonts.
Re: msttcorefonts fontconfig workaround
hmm, on Mon, May 04, 2009 at 10:18:59PM +0200, Claudio Jeker said that Sorry you blame the wrong people. Get us free helvetica, times, and all i am not blaming anyone. but the whole system is being changed because one application is misbehaving. it is not making a whole class of problems go away (so far noone presented any examples how this was a problem besides firefox), it creates new ones. you are wrong. this is inconsistent with what i became accustomed to both in terms of openbsd philosophy and that of ports@ bummer. so go run something else. if an application is broken, fix it or make a cludge in the package. this is the ports approach. where's the diffs? i wouldnt be surprised if someone in the thread called me now a whiner because i have already written 4 mails because of this and i am not a developer and i dont get the problem anyway and i should go and run linux. but sometimes people need to be reminded to keep going in the direction they have created even if that means they will call you a whiner. your sense of self-importance just makes other people not even want to try. and of course in any case i can deal with it on my own. but just like everyone else i like to be as close to the released system as possible. bummer. anyway, i presented my case, and also rest it. i just felt necessary to voice my opinion for what it's worth. thank you for your attention. i could not give a rats ass what you say.
Re: msttcorefonts fontconfig workaround
hmm, on Mon, May 04, 2009 at 07:58:54PM -0600, Theo de Raadt said that if an application is broken, fix it or make a cludge in the package. this is the ports approach. where's the diffs? the diffs in the tree, only in the wrong directory. just put it in your home or install the (omg) msttcorefonts package, it's easy, Marc did a terrific job with pkg tools you know. that approach is broken. your sense of self-importance just makes other people not even want to try. yes, i am the light you should all follow. bleh. you know, instead of firing off theo-mails at me, you failed to bring up any good reasons, I don't have to bring up any good reasons for some random person on the mailing lists feels entitled. for the sake of archives and all the future discussions about this issue when it will bite people in the ass, just why was this was a good idea besides making firefox print pretty. (ok, thunderbird too) I don't care. there is not a thread where a valid technical reason won't shut me up, i am not ashamed to be proved wrong. because i am not here for the cozy friendship of yours either, that ship has sailed. but you failed to bring up any, because i think you dont have any. I don't care. anyway, i presented my case, and also rest it. i just felt necessary to voice my opinion for what it's worth. thank you for your attention. i could not give a rats ass what you say. very nice encouragement for future patches. I don't give a shit. i can't help but wonder how this very same discussion would have gone about this issue if actually we had been long-time friends and i had commit access. i assume you'd have tried to convince me with some technical arguments. why not do it here? i am not your enemy, i want a good system as bad as you do. bsd would be nowhere if people agreed on everything, it's a pre-condition of development. if i doubt your reasons you have to come up with justification, but you just take it all so personally, it actually scares away the good ideas as well, not just the bad. I don't care. i must admit, you never dissappoint. but consistency is a quality i admire. I really don't give a shit what you admire or not. You are a whiny snively jerk, and every time you open your mouth I go work on something else.
Re: no-arch directory
The $PACKAGE_REPOSITORY directory, typically /usr/ports/packages/, will normally contain subdirectories for arch, as well as, further subdirectories for desired\allowed redistribution (cdrom, ftp, ...). No, we don't do that. /usr/ports/packages/i386/ /usr/ports/packages/i386/all /usr/ports/packages/i386/ftp /usr/ports/packages/i386/cdrom The /usr/ports/packages/no-arch/ directory does not contain further subdirectories for desired\allowed redistribution? If something with problematic redistribution like Java 1.5 was broken into multi-packages (main, docs, ...), and the docs were properly put in the no-arch directory, then we now have a redistribution problem. Is the no-arch redistribution subdirs a problem worth fixing? Nope.
Re: pfstat gives errors on -current
On Thu, Mar 26, 2009 at 01:36:00PM +0100, Daniel Hartmeier wrote: On Thu, Mar 26, 2009 at 01:11:49PM +0100, Markus Lude wrote: Hello, after updating to the recent snapshot from march 24th I now get errors when running pfstat: ioctl: DIOCIGETIFACES: Operation not supported by device pf_query: query_ifaces() failed Probably something changed in the pf code. That just means the pfstat binary doesn't match the newer kernel, and needs to be rebuilt. But the rebuild of pfstat depends on the headers in /usr/include, so you may have to update those first. Which probably means you fetch -current sources, rebuild (or at least make include), and then rebuild pfstat. In the meantime I rebuild pfstat, but still the same error message. The newer header files were installed while upgrading to a newer snapshot. pfstat sources themselves don't need any changes, afaik. Sucks, eh? Tell the guy who broke pf ioctl API, mcbride@ most likely ;) As I'm not familiar with the pf code, could someone point out what the changes of the pf ioctl API were? have you considered using the built-in command systat pf 1 and then use the right and left cursors to see additional interesting views.
Re: keeping makewhatis happy wrt/ pod (Was: Re: UPD: devel/p5-Moose)
On Sun, Mar 22, 2009 at 12:47:28AM -0600, Theo de Raadt wrote: Another way to solve this is a rewrite of pod2man .. which will then generate mandoc instead. That also benefits the other manual page project. hum... so let's trade 10 lines of makewhatis to a complete new back-end to pod2man ? I'm not saying this would not be a good idea, but: - we will always need to parse some nroff stuff. Converting all manpages in all 3rd party ports is not realistic. Huh? Converting all pods to mandoc, and getting the prettiness for fre, isn't worth it? It has no downside.
Re: keeping makewhatis happy wrt/ pod (Was: Re: UPD: devel/p5-Moose)
Another way to solve this is a rewrite of pod2man .. which will then
generate mandoc instead.
That also benefits the other manual page project.
Actually, this is more complex than it looks, because recent pod converters
make a lot of use of
.ie n
.el
constructions, and that throws makewhatis completely off-base, especially
wrt Moose.
I have some quick hacks which allow it to proceed, and I'm still wondering
whether I should actually teach makewhatis how to parse .ie constructs.
the
.ie n
.el
lines are rather simple, I'm ways more worried about multiline tests, like
.ie n \{
.br \}
.el \{
.br \}
which promises to be a nightmare...
Re: pkg_info message display [Re: cups-enable]
.It Fl M Show the install-message file (if any) for each package. +If any step not documented in the manual must be taken before a package +can be used, this file will often mention it. That is an attempt to entirely push the problem under the table. The default message should be relevant. Noone will use special options to go look for relevant information. As an option, it would be much more realistic if -M did not EXIST. The basics + by-hand-setup information for most things is 2 lines long, because it points at a file. That is what should be printed everytime. Making people go dig for the important information they need is retarded. Documenting that they need to do such a ridiculous process is not right.
Re: new: geo/gypsy
On Mon, Dec 1, 2008 at 12:21 PM, Marc Balmer [EMAIL PROTECTED] wrote: * Ian Darwin wrote: Gypsy was designed to fix the numerous design flaws found in GPSD. These are compiled at http://gypsy.freedesktop.org/why-not-gpsd.html. So how does this compare to gpsd for real applications? I am asking since the main gpsd developer is also an OpenBSD developer, and maybe there are ways to fix the problems in gpsd? Oh, and I find this rude. DBUS is more crap I don't need or want on my machines, the regular gpsd serves my needs very well. I'm sure I could write a why-not-dbus-gypsy.html page, but I can't be arsed. I'm surprised that I'm even taking the time to reply to this. If it works, let them co-exist. GPSD does have some kind of DBUS support... but I have no use for it so I can't say how well it works. What are you saying? I want to understand this very clearly. Are you two saying no to a new package? Or what is this fight about? Or do the little words twist your panties?
Re: new: geo/gypsy
So how does this compare to gpsd for real applications? I am asking since the main gpsd developer is also an OpenBSD developer, and maybe there are ways to fix the problems in gpsd? Oh, and I find this rude. DBUS is more crap I don't need or want on my machines, the regular gpsd serves my needs very well. I'm sure I could write a why-not-dbus-gypsy.html page, but I can't be arsed. I'm surprised that I'm even taking the time to reply to this. If it works, let them co-exist. GPSD does have some kind of DBUS support... but I have no use for it so I can't say how well it works. What are you saying? I want to understand this very clearly. Are you two saying no to a new package? Or what is this fight about? I can only speak for myself: I am in no way objecting to this to go in. I was only commenting. Users should make the choice which GPS package they use, not us, not me. Then why does it make a difference if you think it is rude? Can you not see that adds zero value, except that it might convince people working on ports that they should not continue because someone might think it is 'rude'? Nevertheless I think it is ok to post comments. Sure, talk all you want. But so can the authors of that original source. At least they were detailed in their explanation.
Re: 4.4-beta shared libs
Can I safely assume that 4.4-beta binaries will be compatible with 4.4-release? That is, no shared libraries major number will be bumped. You can assume nothing until release.
Re: only days left to ports lock (4.4 release)
Theo wrote: Yes, and sometimes tough love is required. Perhaps whoever the maintainer is will merge this in time. Perhaps not. Let me pose a question: Would you rather have a good release that has good quality integration between packages or One that has the latest python? Let me pose a counter question: Who needs working ports or a good quality integration between packages f.e. for python if each kid from ghana could crash your webapplication or whatever you build with python. Some of us do have internet Theo... You can't always have both. You are right but we could try? You've had 5 months to try. Fine, I can postpone the 4.4 release to next year. Thanks for talking.
Re: only days left to ports lock (4.4 release)
On Mon, 28.07.2008 at 17:24:01 -0700, Peter Valchev [EMAIL PROTECTED] wrote: We are in release mode, with 4.4 just around the corner. This means that from now, no more commits to ports unless they are VERY urgent - such as fixing a broken dependency, high impact security issue, etc, I'd like to point at some problems in Python 2.5.2, which I became aware of just two days ago: CVE-2007-2052 CVE-2007-4965 CVE-2008-1679 CVE-2008-1721 CVE-2008-1887 The latter two are claimed to result in the execution of arbitrary code. Yes, and sometimes tough love is required. Perhaps whoever the maintainer is will merge this in time. Perhaps not. Let me pose a question: Would you rather have a good release that has good quality integration between packages or One that has the latest python? You can't always have both.
Re: Ports with possible 64-bit problems
Arnaud Bergeron [EMAIL PROTECTED] writes:
mt-daapd suffers from a case I've named 0.5:
pointer - int
and then the int is used as a truth value. So this is not a bug.
Not a bug? Really?
$ cat foo.c
int
main()
{
int true;
void *nonnull = (void *)0x7000;
true = nonnull;
printf(true ? true\n : false\n);
true = !!nonnull;
printf(true ? true\n : false\n);
}
$ make foo
cc -O2 -pipe-o foo foo.c
foo.c: In function `main':
foo.c:7: warning: assignment makes integer from pointer without a cast
$ ./foo
false
true
$
//art
I'll admit I didn't think about this. So I'll have to fix it. It
helps that most uses of the pointers look like that:
And think about the big-endian 64 bit machines too. If the cast is
in the right place, and you ensure that all memory is allocated below
4GB... guess what happens.
Re: DRM in xpdf
2008/4/25 Theo de Raadt [EMAIL PROTECTED]: Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. While it's always nice to blame Adobe, please first discuss those patches upstream (i.e. with Derek and/or the poppler guys). And then consider forking an OpenXPDF. At least make sure the original author never gets bug reports from your Frankenstein-XPDF. We don't have to do that. And if you don't like what our ports people do, you are more than welcome to not use their work. But you are NOT welcome to tell them what they should do.
Re: DRM in xpdf
2008/4/25 Deanna Phillips [EMAIL PROTECTED]: You mean this part? For those who would argue that important content might get irretrievably locked away in PDF format, I'll remind you that Xpdf is open source, and can be modified by end users (the GPL even allows this). While an XPDF port with these patches is technically not distributed but compiled by the user installing the port, any package of this patched XPDF will be a modified version of XPDF and as such has to follow the restrictions on distributing modified programs as specified in section 2 of the GPL. Or you stop distributing XPDF packages. My god you have an utterly twisted view on what free means. Why don't you just get lost. You are completely wrong.
Re: DRM in xpdf
On Thu, Apr 24, 2008 at 9:05 PM, Chris Kuethe [EMAIL PROTECTED] wrot= e: On Thu, Apr 24, 2008 at 4:46 PM, Andr=E9s [EMAIL PROTECTED] wrote: Why? Because ports is about getting things done, and code that gets in the way of you getting things done must die. Apply your patches locally, fork it, whatever; just don't make the port tree a place to get your favorite patches in. It is for _installing_ stuff. Thank you very much for your opinion, but it is clear you come with an agenda. The OpenBSD project people do not follow the bend to Adobe agenda that some xpdf people follow. Bye bye.
Re: Ion3 port is obsolete
Please immediately take this to your own list, instead of spamming this list further. On 2007-11-17 22:10 +0530, Siju George wrote: See it is not the OpenBSD people who tarnishes you. It is your own license restrictions that are working against you. The extra terms in the license are there for a reason, you know. Distros far bigger than OpenBSD fucking with you by distributing Xft-modified versions and ancient development snapshots for years. -- Tuomo
Re: Ion3 port is obsolete
On 2007-11-16, Stuart Henderson [EMAIL PROTECTED] wrote: The version in tree is before the license change; the additional restrictions on the newer code are a problem. They are not a problem for reasonable distributors that care to pay a bit of respect towards the author's time and work. Of course, reason, literacy, and respect towards authors and persoanl choice are something seldom seen among the FOSS herd, rather replacing them with blind ideology and monocultures. It is a popular myth that you have to provide the new release within 28 days, and although I encourage that, it is not true and what the license says. Alternatively, you must after those 28 days prominently notify the user installing the software that the release is likely to be antiquated, not representative of the project's present state, and the author will not provide support for it. Not much asked, in my opinion. You could even base this notification on a dead-man switch, which would be quite nice even generally, considering package maintainers often going MIA. Boy, that's a lot of must's in that paragraph. Sure sounds free. It's free, but you MUST list of things What's great about me jumping into this conversation is that you talking about respect of the author is so interesting. I don't use your software, but I am sure you use OpenSSH. And now you are telling me what I (who distribute OpenBSD with all the things) must do. You say Not much asked, in my opinion. But you did not ask. You demanded, and everyone can see that.
Re: Maintainer Update: net/pptp
Stefan Sperling [EMAIL PROTECTED] wrote: This patch has been sitting on the list for a month now. Can someone please commit this? Theo has requested that pptp should not set net.inet.gre.allow=1 when the package is installed, but only when the program is run, i.e., add corresponding sysctl(3) calls to pptp proper. This same idea should apply to other packages. When you install a package on a machine, it should not open a gaping hole in the machine. Once you configure it, or run it, then it can do what it needs. But doing a pkg_add *.tgz should not generate a less secure configuration of a machine. That is just clearly wrong.
Re: Maintainer Update: net/pptp
But if we don't want to allow 'pkg_add pptp' to enable an insecure protocol, why do we want to allow executing pptp to do so? Isn't the idea to have the user _manually_ turn a knob if that knob makes the system more insecure? This is rather simple to break apart. installing a package does not mean you are going to use it. adding another knob that people don't know on another system makes it more difficult to use openbsd. there is an obvious middle ground. starting an application means you want to use it, so THAT is the moment when the permission should be changed. it is not like it is securelevel locked or some such thing.
Re: Tor 1.2.16 - Security hole
I agree with you on this -current/-stable thingy. This ports tree soft locking shit *how we care about -stable users* is bullshit, when outdated/security vulnerable stuff is even in -current and it takes ages to backport and make packages of needed security updates... I see there no logic, since developers are on -current anyway and they don't care about stable users really... There are likely going to be some changes soon as to how -stable is treated. However, I think you will not like the changes. Many people are quite overworked, unable to proceed forward because they are being pecked to death by whiny users, and are quite sick and tired of these people who whine. The solution will likely comprise some set of: promise less, give less, and listen less.
Re: gettext and expat
* Todd T. Fries [2007-05-10]: There is an expat in src/. What are the plans for that? Would solve a lot of `must install xbase in order to get expat' complaints. The counter is that one already installs xbase to get libs. My understanding is, that it won't be activated until it's audited, which has not happened for about 1.5 years now. Someone just has to start gnawing away at it.
Re: Remove x11/ion
On Mon, Apr 30, 2007 at 10:20:37AM -0500, Travers Buda wrote: Point is, the unencumbered port works, no point in removing it over spite. http://article.gmane.org/gmane.comp.window-managers.ion.general/7694 The author believes the license change to be retroactive (even though that's clearly not possible). Consequentially, there is no way we can keep the port without either starting a fight with him (something I honestly don't have the time or patience to endure) or 'violating' his restrictions. I think a better fight against such balony is to keep his code in the ports tree under the existing (previous) license, and let it rot at that level, if need be. Once you release something under a copyright, there is no retroactive right. That's just not how it works. Leaving stuff available in some way for people to do forks is a good idea, of course.
Re: Remove x11/ion
On Mon, Apr 30, 2007 at 06:25:21PM +0200, Marc Balmer wrote: The ports tree is here for our users convenience. If a port has a strange license, you can always set the PERMIT_xy fields. Many users use ion, so why should we harrass them? It was not a simple question of removing the port because we didn't like the license. It was a question of conformance, at least towards what the author believes the rules now are. Actually, it is not a matter of conformance against what the author believes. Authors believe the most retarded things from time to time. The same thing happened with qmail before. djb thought we could have his code in the ports tree, but since he specifically does not copyright his code visibly, no rights are granted, so we could not include it, and had to delete it. It's more about conformance with the laws, than about whatever fantasy the author has.
Re: FIX: net/snort
And be super careful about this in anything else which interfaces
to bpf or pcap. The pcap people were super uncareful using a
machine-dependent structure.
This diff fixes unified logging/alerting on 64-bit platforms.
http://secure.lv/~nikns/stuff/ports/snort-2.6.0.2p1.diff
...
+--- src/snort_packet_header.h.orig Thu Jan 19 19:09:12 2006
src/snort_packet_header.h Tue Nov 7 20:28:12 2006
+@@ -16,12 +16,20 @@
+ #include sys/types.h
+
+
++/* we must use fixed size of 32 bits, because on-disk
++ * format of savefiles uses 32-bit tv_sec (and tv_usec)
++ */
++struct pcap_timeval {
++u_int32_t tv_sec; /* seconds */
++u_int32_t tv_usec; /* microseconds */
++};
++
Use bpf_timeval (see net/bpf.h) which is defined the same way,
don't define your own struct...
Re: OpenOffice source - Humppa.hu not avaiable
On Thu, 26 Oct 2006, [EMAIL PROTECTED] wrote: Then it`s sad that the port was marked for 4.0... Your ignorance continues to astound, *it isn't* marked for 4.0. Sometimes it is easier to work on something in-tree. -d Damien, briefly.. you`re talking junk. No, Damien is tell the TRUTH. THE CVS TREE IS NOT FOR OUR USERS. It is for our DEVELOPERS. it is OUR tree. We put in it what WE WANT, when WE WANT. You are lucky you get it at all. You don't get to tell ANYONE WHO IS A DEVELOPER what they may or may not put in the tree, and when, and when not to do so. You are a user. You will always just be a user. Your opinion counts does not count at all. What did I do? I tried a Port of OpenBSD 4.0 on the only avaiable architecture. So what are you talking about? Poor little Sebastian! If you love to have it in tree even if it`s brocken the Port itself could get marked as brocken (there some of those Ports) so that nobody on any architecture simply tries to build it. Or you even could have take care that the port gets NOT tagged for 4.0 (but then it still remains in the Ports-tree for current, clever, or?). So who`s ignorant here? You are the ignorant asshole, that's clear to everyone. Why don't you just PLEASE LEAVE and find a project that will listen to you. NOONE here will ever do anything that you want, because there is a fundamental LACK OF RESPECT for ANYTHING YOU SAY. EVERYTHING you say is just whiney whiney shit, shit, and shit.
Re: Ports folder...
Why? A little consistency never hurts (src.tar.gz and srcsys.tar.gz too). ports have so many disadvantages. Yeah, sure. If OpenBSD would start to ship incomplete ports, I hope people who want control back start using the MirPorts Framework. Ok, I've had enough. I have to speak up. Thorsten, will you stop self-advertising yourself (and your one-man shit show) on our mailing lists? PLEASE GO AWAY As an OpenBSD developer, I am continually offended by your presence here, and it makes me not want to do development, so I urge the community to solve the problem of him showing up here. Quite frankly, we are sick of him. If you want to self-advertise yourself, go do it on your own stupid mailing lists.
Re: Java ports: source vs. binary?
How about using the source if it's available and using the binary when it's not? Right. And in 5 years, how much source will you have? Don't forget, having the source also means being able to patch it as well. Duh. The point of Christian's mail was is that we all understand how these things work. If you keep accepting non-source components, eventually noone ever makes source available. Using source if it is available is not enough of a policy to ENCOURAGE SOURCE AVAILABILITY.
Re: Java ports: source vs. binary?
Leave installing the source as an option to the user, and install binaries as a default. And in 5 years noone will make source available.
Re: Java ports: source vs. binary?
P.S. Good time to re-read Ken's paper Reflections on Trusting Trust (online at http://www.acm.org/classics/sep95/), before you decide where to put your foot down. Wow, that is totally off-topic. The discussion is about how we can use some of our clout to encourage source availability in the long term (versus giving no pressure at all) while not hurting our users by not giving them what they need. Right from the start, the discussion is about where to draw the line, in a field of grey, instead of choosing black versus white position. THAT is the problem we always face. A way to balance them. When I run software that is in ports, I have absolutely no doubt that there are security risks, and quite frankly, I don't care. If you care, you must work to fix it, and in reverse too -- if you don't work to fix it, then you must not care enough to fix it. And that is NOT what this is about. When binaries have holes, or risk factors due to distribution problems, well DUH, so does source code. ANY SOURCE CODE has just as much risk. Which of you even bloody read what you download. It is the standard balony of If it is signed it must be risk-free or If it is signed at least it has fewer risks. It is still balony. This discussion is not about security. It is about trying to encourage suppliers of code to stick to the open source way of doing things. If we accept binary files all the time, how are we sending the right message? But if we only accept source, we are hurting our users. THERE ARE MANY MIDDLE GROUNDS where we don't hurt our users too much, yet we send a message to people who don't supply source. Even with blobs, we have middle grounds, because while some of them are huge traps, some of them (like firmwares) just require redistribution rights, but too few people actually study the situation well enough and then (stupidly) they choose either black or white positions. Again, this discussion has ZERO TO DO WITH SECURITY.
Re: Java ports: source vs. binary?
It's pervert to have a STOP BLOB release theme and then importing exactly BLOBS in the ports tree. There is absolutely no need to do so, nothing suffers from going throught the source, besides, maybe these ports are a little bit harder to do. Please do not misuse the term BLOB like this. This issue is not what we use the word for. We call it a blob when there is no source, and when there is no license to use it. These are not real blobs.
Re: gvim crashes over ssh -X tunnel
Except that is not a fix. It indicates the application (or some library it is using) is violating the X security extension. Meaning that if someone can misuse/fool such an application, it cannot just render into it's window, but totally take over your X server from remote. Lovely. The gtk libraries are one of the worst offenders. And one day someone will use this flaw, to significant effect. Several people pointed out to use -Y instead and that works. Sorry for the noise. Chris Kuethe wrote: On 5/14/06, Marco Peereboom [EMAIL PROTECTED] wrote: gvim 7 crashes after clicking any menu option whenever launched over an ssh tunnel. Any clues? My X-Fu is nonexistent, but I am unable to reproduce this on my i386 machine. CK
Re: Fix for /usr/ports/devel/startup-notification/patches/patch-libsn_sn-util_c
- strcpy (s, str); Yes, the old code is totally wrong for using strcpy. + strncpy (s, str, sizeof(s)); And whoever tried to fix it, made it even worse. Now it only copies either 4 bytes, 8 bytes, or the size of the destination buffer if it is not a pointer (and it is a pointer, isn't it). Heck, they might as well have put a value 1 in there, for all that diff is worth. + strncpy (s, str, strlen (str) + 1); Ah, but this diff is 100% the same as the original strcpy(). Think about it. If that is the best anyone can do, amateurish buffer overflow fixing which makes it worse or doesn't fix it, then they should not change the code. There is an alternative. Some people should instead try the alternative: Don't try to fix it, but yell at the authors about the problem repeatedly. That's something even amateurs can do. If you can spot it, you can always get it fixed correctly that way. But don't rely on even OpenBSD developers (or ports contributers) to get this this right all the time. The responsibility always lies with the official maintainer...
Re: UPDATE: expat-2.0.0
I still wish someone would properly audit libexpat. I looked at it, and I was totally terrified. Poeple actually use software that uses something written this poorly?
Re: strcmp vs strncmp question
Wel. had you looked at the second hit (really near the top, so boredom should not have set in yet) searching for why it was a hit you would have seen several instances of str*** func calls being replaced by strn*** func when the str ones were unsafe. Seeing that it was all about a CERT vulnerability report one would have assumed that a student of the topic would have gotten some insight into why these changes were made. Well too bad you are wrong Rod, but then you had to go insult him as well, didn't you. The head tells you that buffer overflows were an issue as they often are when str funcs are used unsafely. Not in this case. He found a real mistake. What exactly was your contribution to this? OH right. You were insulting with any cause. I'm sure that a good STFA would have found some insights from Theo and others and you really should have donee your homework there before asking about such a frequent topic. Mailing list netiquette. PEOPLE LIKE YOU, jumping on people who actually find real bugs, are the REAL problem with our mailing lists. He found a real bug. You just yelled and yelled and are an ass for it.
Re: strcmp vs strncmp question
Rod.. Whitworth wrote: /* Made up example of course */ - if (!strcmp(buf,n/a)) + if (!strncmp(buf,n/a,3)) you would have seen several instances of str*** func calls being replaced by strn*** func when the str ones were unsafe. Seeing that it The one has little to do with the other. What if buf, in the made-up example, contains n/abc? strcmp() says it's not the same, while the strncmp() line above does. Either function requires a valid, NUL-terminated C string, and both need to be smart enough to not read past that NUL (and they are.) I highly doubt that a str?cmp() fix ever went in like that, unless the different behavior was desired. It would be nice if Patrick could mention what he specifically means, because such a patch would most likely be wrong if it went in as an errenous safe string function replacement attempt. I grepped the ports tree patches. There are at least 10 of these bad patches. Someone should go delete them.
Re: brokenish /emulators/redhat/base
I was trying to build www/opera on my 3.8 (from CD) box emulators/redhat/base hung up with some error message like: xargs: unknown option -- r To fix it I installed and symlinked GNU xargs. I don't know if there is possibly a better fix that should be implemented into the port itself, just thought I'd post this in case someone else has a similar problem and needed a solution. By the way, although the install was from CD, the ports tree was downloaded from snapshots a couple of nights ago. No kidding. You are mixing a release and -current. No wonder it won't work for you. DON'T DO THAT!
Ports PRs still open
The following PR numbers appear to still be open. Perhaps ports people have not noticed. 4473 bugs portsopen serious medium netgnome-panel freeze and quits on OpenBSD 3.8 current i386 4474 bugs portsopen serious medium netXChat quits in: preferences and browsing background image And perhaps others too.
Re: qemu propolice problem?
I believe using -fno-stack-protector is correct in this case. Note that this is in Makefile.target, which is used to compile 'opcodes' for the emulated processor. And propolice interferes with that (even if it works, it would slow the emulation by doing its checks for every 'instruction') The rest of the qemu is compiled with propolice. Propolice only instruments functions which contain what it thinks look like strings. (A variety of issues make it a bit more complicated than being able to say just strings).
Re: gtk+2 emacs mode and mozilla
Now that mozilla has been switched to gtk+2 a lot of people will get bitten by the fact that for some bizarre reason the emacs mode is no longer default in the gtk+2 settings as someone pointed out on this list a few weeks ago. This means that the standard ^U, ^A, ^E etc. emacs commands will no longer work - I mean, those even work on IE on a windows box!! I think this should definitely be made default. It is important to understand that this affects *all* applications that use GTK2. The basic impact is that where ^x used to directly call an action, now if the focus is in an input field it will intercept most ^x keystrokes (and interpret them as editing commands). This shouldn't break any applications, but it is a change in behavior. People running lots of GTK2 apps, maybe a GNOME desktop, should check whether they are comfortable with this--assuming they didn't already set this behavior in ~/.gtkrc-2.0. If it is so important that you LEFT THIS ALONE until just before we head into a release? Who's not paying attention to making a quality release?
Re: mp3 players
The problem is that our mixers don't provide a smooth range 0..255 (scaled to 0..100 by the OSS emulation) but will ratchet up to the next supported value. The details may vary with the sound hardware, on my laptops (clcs, auich) the step size is 8. mp3blaster tries to adjust the volume by +/- 2 on the OSS scale, which doesn't work. BTW, this is a problem is several ports. If anybody can think of a generic solution... How about a kernel solution. Instead of always rounding up, we can make the code round to farthest thing. So that n+1 would round to n+8, and n-1 would round to n-8. Would that help?
