Re: [new] sysutils/obsdpkgup - tools for creating and using a package index
> On 2021/01/06 12:03, Stuart Henderson wrote: > Looking at this it's better than I thought it would be, there are some > problems though - > Hey thanks! > - The version number comparison using mcuadros/go-version is wrong, > it doesn't match packages-specs(5). > I took the time to learn some perl yesterday, and holy moly my version comparison code was *very* wrong. Thanks for taking the time to point that out. As a result, I went through and mirrored the perl code as closely as I could to ensure that it matches what OpenBSD does. > - There doesn't seem to be a way to validate that index.pkgup.gz is done > against the current available package build. For this I would suggest > recording the timestamp of the @digital-signature on the quirks package > in the index, and verifying when the update is run. (grep out of > "PKG_DBDIR=/var/empty PKG_PATH=$whatever pkg_info -f quirks" will do > the trick). > Added. I'm parsing the signify block in pure Go (instead of shelling out to pkg_info) because I want to be able to use the index generation code on any Go-supported platform. My own mirror (and from what I understand, some of OpenBSD's own mirrors) aren't necessarily running OpenBSD. > Between those two it could cause problems because the user may try to > update a too-small subset of packages. The first problem is obvious. > The second problem, if a library is bumped after the index is generated, > the required updates won't show up. For both if people use it and then > run into problems it's likely the bug reports will end up with openbsd > rather than pkgup. This makes me not want to add it to packages yet > (adding it could easily be seen as an endorsement of using it). > This would be less of a problem if it at least tries to detect outdated > caches and prints a clear warning. > I hope that my above two fixes rectify this situation in your mind. > Less important but I'd be happier if it used the signature from pkg_info > -qS rather than its own version using grep on +CONTENTS, to guard > against possible future changes to things that pkg_add considers when > deciding whether to update (also I think it would make sense to include > the whole string rather than a hash of the signature, there's no need to > hide that), as long as the full url/filename is used pkg_add will fetch > the file directly without grabbing the index first. i.e. > PKG_DBDIR=/var/empty pkg_info -qS > http://mirror/pub/OpenBSD/snapshots/packages/amd64/moo-1.5p0.tgz > I would like this as well. The problem is that pkg_info -qS is slow. It takes orders of magnitude more time to run than my current signature generation code. I can currently build a complete index from a remote mirror in less than ten minutes. If I switched to using pkg_info, it would take several hours by my math. In addition, I would like to keep genpkgup able to be run on any OS that Go supports instead of only OpenBSD machines. I went ahead and sorta-implemented your suggestion though by matching OpenBSD's current signature format. No more hashes. I was torn on this before, but I actually like your approach better because A: it's easier to debug when things go wrong and B: it's much less CPU-intensive not having to do sha256 stuff. So again, thank you for the recommendation. If the signature format changes in the future, I will gladly update my code to match, or revisit the problem if necessary. Again, thank you for taking the time to look at my tool!
Re: Bug in pkgtools version parsing logic?
On Wed, Jan 6, 2021, at 17:16, Jeremy O'Brien wrote:
> Hi there,
>
> I'm looking through the pkgtools code to determine how the version
> comparison logic works, and I came across this block of code at
> /usr/libdata/perl5/OpenBSD/PackageName.pm:385:
>
> sub from_string
> {
> my ($class, $string) = @_;
> my $o = bless { deweys => [ split(/\./o, $string) ],
> suffix => '', suffix_value => 0}, $class;
> if ($o->{deweys}->[-1] =~ m/^(\d+)(rc|alpha|beta|pre|pl)(\d*)$/) {
> $o->{deweys}->[-1] = $1;
> $o->{suffix} = $2;
> $o->{suffix_value} = $3;
> }
> return $o;
> }
>
> From what I understand, this is looking for one of OpenBSD "special"
> suffixes for a given version part of a package version. This code seems
> to only match cases where the "special" portion (rc, alpha, beta etc)
> of the version sits between a required decimal on the left and an
> optional decimal on the right. Looking through the current package
> listing, I found this one:
>
> clementine-1.4.0rc1p0.tgz
>
> Given the above regex, the rc1 portion of the package name will not be
> pulled into the suffix, and I believe that (given a comparison where
> the 1.4.0 portion of the version doesn't change) a future version
> comparison with this package version will potentially be done
> alphabetically?
>
> Is this intentional? Or perhaps I'm missing something here or elsewhere
> with this code.
>
> Thank you,
> Jeremy
>
>
Nevermind; I found where the hole in my logic was:
OpenBSD::PackageName::version handles the p/v cases. Sorry for the noise!
Bug in pkgtools version parsing logic?
Hi there,
I'm looking through the pkgtools code to determine how the version comparison
logic works, and I came across this block of code at
/usr/libdata/perl5/OpenBSD/PackageName.pm:385:
sub from_string
{
my ($class, $string) = @_;
my $o = bless { deweys => [ split(/\./o, $string) ],
suffix => '', suffix_value => 0}, $class;
if ($o->{deweys}->[-1] =~ m/^(\d+)(rc|alpha|beta|pre|pl)(\d*)$/) {
$o->{deweys}->[-1] = $1;
$o->{suffix} = $2;
$o->{suffix_value} = $3;
}
return $o;
}
>From what I understand, this is looking for one of OpenBSD "special" suffixes
>for a given version part of a package version. This code seems to only match
>cases where the "special" portion (rc, alpha, beta etc) of the version sits
>between a required decimal on the left and an optional decimal on the right.
>Looking through the current package listing, I found this one:
clementine-1.4.0rc1p0.tgz
Given the above regex, the rc1 portion of the package name will not be pulled
into the suffix, and I believe that (given a comparison where the 1.4.0 portion
of the version doesn't change) a future version comparison with this package
version will potentially be done alphabetically?
Is this intentional? Or perhaps I'm missing something here or elsewhere with
this code.
Thank you,
Jeremy
Re: Conditions that can trigger a package upgrade?
On Thu, Nov 5, 2020, at 03:38, Stuart Henderson wrote: > The current package on mirrors has changed since your downloaded file > (at least glib2 was updated) so maybe it's just because you're looking > at an old file. > Sigh. I double-checked my /etc/installurl. Apparently it’s set to cdn.openbsd.org (and not ftp3 like I could’ve sworn it was...), so your theory seems the most likely (that the package I manually grabbed was older than the one that pkg_add was looking at). Thank you for your succinct and useful help as always. I’m gonna call this one solved.
Re: Conditions that can trigger a package upgrade?
On Wed, Nov 4, 2020, at 11:37, Chris Bennett wrote: > > You haven't supplied any information for answering this question well. > Are you running -current and updating to a new snapshot? > I upgraded to a new snapshot. > Easy answer. System libraries that these packages were built with have > changed. Package is the same except for being rebuilt with newer > libraries. > This demonstrates that I don’t understand the mechanism by which these upgrade decisions are made then. How can pkg_add determine that a given package was built against newer libraries if there is nothing in the package header (+CONTENTS) indicating such? I assumed this would manifest itself in the package signature in some way, since pkg_add is clearly making an upgrade decision here. Or there is of course the possibility that there *is* some information there that I’m overlooking. > Are you upgrading to a newer stable/release? > Same answer. > > Are you getting this problem running pkg_add -u multiple times on the > same system without changing to a newer version or snapshot? > > Then something is wrong. (Assumimg you are actually running the actual > pkg_add -u) > Check to make sure that you do not have any packages that have been > since dropped. gettext caused me problems a good while back > > Please supply a little more info. That helps people to decide whether > they want to answer or not. Most likely you don't have any problem. > Have you read all of the relevant man pages? pkg_* > Multiple times. My problem is that the documentation appears to be written for a user of OpenBSD, not necessarily someone trying to fully grok the inner workings of exactly how the pkg_* tools work. I’ve tried reading the perl directly, but I haven’t found anything that seemed like a smoking gun. I guess what I want to know is, what *exactly* is pkg_add doing/comparing to determine that an upgrade is needed? > What is your PKG_PATH (if using). unset PKG_PATH is a quickie, temp fix > if it's wrong. > Have you changed /etc/installurl? > No PKG_PATH. /etc/installurl is ftp3. Unchanged since my install ~8 months ago. > Look for relevant threads previously on the ports@ mailing list > especially. > I will search, thank you :) > Enjoy! > Chris Bennett >
Conditions that can trigger a package upgrade?
Hey misc, I'm trying to understand the various scenarios that can trigger a package update in 'pkg_add -u'. I thought package updates were triggered only through explicit version bumps, or signature changes. I'm seeing that that isn't always the case however, as shown here: x1$ pkg_info -S colord ../colord/colord-1.3.5p2.tgz Information for inst:colord-1.3.5p2 Signature: colord-1.3.5p2,6,@consolekit2-1.2.1p9,@dbus-daemon-launch-helper-1.12.20,@dconf-0.36.0p0,@glib2-2.64.6,@lcms2-2.9p0,@polkit-0.118,@sqlite3-3.31.1p0,c.96.0,ffi.1.2,gio-2.0.4200.11,glib-2.0.4201.4,gmodule-2.0.4200.11,gobject-2.0.4200.11,gthread-2.0.4200.11,iconv.7.0,intl.7.0,lcms2.1.2,m.10.1,pcre.3.0,polkit-gobject-1.2.0,pthread.26.1,sqlite3.37.10,z.5.0 Information for file:../colord/colord-1.3.5p2.tgz Signature: colord-1.3.5p2,6,@consolekit2-1.2.1p9,@dbus-daemon-launch-helper-1.12.20,@dconf-0.36.0p0,@glib2-2.64.6,@lcms2-2.9p0,@polkit-0.118,@sqlite3-3.31.1p0,c.96.0,ffi.1.2,gio-2.0.4200.11,glib-2.0.4201.4,gmodule-2.0.4200.11,gobject-2.0.4200.11,gthread-2.0.4200.11,iconv.7.0,intl.7.0,lcms2.1.2,m.10.1,pcre.3.0,polkit-gobject-1.2.0,pthread.26.1,sqlite3.37.10,z.5.0 x1$ pkg_add -un colord quirks-3.471 signed on 2020-10-31T22:51:51Z colord-1.3.5p2->1.3.5p2: ok Running tags: ok --- -colord-1.3.5p2 --- You should also run rm -f /var/db/colord/mapping.db You should also run rm -f /var/db/colord/storage.db In the above example, I've downloaded the colord tarball from my chosen mirror, and compared its signature to my currently installed version. The signatures and version match exactly, however pkg_add still updates the package. Does anyone know what scenario is triggering this update? Thanks, Jeremy
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 13:45, Janne Johansson wrote: > Do think of what you call "the index file" in terms of "I check/replace some > 100+G of snapshots and packages every 24h", at which point do you replace > that single file, before, under or after none,most,all packages for your arch > are replaced? Will it be synced when the copying passes "i" for "index.txt" > in that packages folder? My gut is it doesn't matter when the file is sync'd. The file would only be used to prevent pkg_add from checking *every* installed package file *every* time. The effect would be basically the same as how my tool works, which is, it gives you a subset of installed packages to update, except with the added benefit of also detecting same-version rebuilds. pkg_add would still go through its normal recursive dependency checking, just with a (presumably) *much* shorter package list. > What happens if a sync gets cut off, restarted and/or if two syncs suddenly > run into eachother and replace files as they go? > > What if a new batch of amd64/i386 files appears while one of the ongoing > syncs run, do you restart over and hope yet another new one doesn't appear > while that one is running? Is this something that actually happens?
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 13:45, Janne Johansson wrote: > > Now if someone invents a decent piece of code to use http connection pooling, > quic/http3/rsync or whatever to speed up getting the required info, I'm sure > we mirror admins would be happy to add/edit our server programs to serve it. > Welp, I got a nice taste of what taking advantage of http-keepalives can do, and it is indeed quite a bit faster. Here's all I did (a bit overkill, but a neat proof-of-concept): # pkg_add squid # rcctl start squid # export http_server=http://localhost:3128/ # pkg_add -u squid by default uses keepalives on both the client and server connections. It seems that the server closes our connections several times during the transfers anyway (I assume either a max request limit or keepalive timeout), but it's much better than starting a new connection every time. I'd be really interested to see what something like quic can do.
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 08:47, Marc Espie wrote: > On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote: > > On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > > > > > The concept you need to understand is snapshot shearing. > > > > > > A full package snapshot is large enough that it's hard to guarantee that > > > you will have a full snapshot on a mirror at any point in time. > > > > > > In fact, you will sometimes encounter a mix of two snapshots (not that > > > often, > > > recently, but still) > > > > > > Hence, the decision to not have a central index for all packages, but to > > > keep (and trust) the actual meta-info within the packages proper. > > > > > > > Sorry, I guess I should've responded to this as well. Isn't snapshot > > shearing going to be a problem regardless of the existence of a single > > central-index? For instance, pkg_add notices a chromium update, which > > requires a newer version of a dependency that hasn't been propagated to the > > mirror yet. > > > That's not a big problem, it just stops before updating... at least > your installation doesn't get hosed. > Sorry if I'm being dense here. I'm just trying to understand this completely. In the current implementation, does pkg_add recursively verify every dependency of a package before installing *any* of them? Or does it install dependency updates as it finds them? Because if it's the latter, I can still envision scenarios that break a given package, such as: Package A depends on B and C. B is sync'd, C is not yet. pkg_add installs the update to B, then encounters the missing C update, and bails the upgrade of A. Now you have A installed which doesn't work with the new version of B. Is this something that can currently happen? I'm just trying to understand how the index causes the possibility of *more* breakage when compared to the current system. Even with snapshot shearing though, having this index file could provide a substantial speed upgrade. Instead of having to check *all* installed package's header for updates, you could use the index to know the subset of packages that you expect to have actually changed, and only download *those* packages' headers. If the expected "combined" sha of a given package doesn't match the index's version, then the mirror is clearly out of sync and we could abort an update as usual.
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > The concept you need to understand is snapshot shearing. > > A full package snapshot is large enough that it's hard to guarantee that > you will have a full snapshot on a mirror at any point in time. > > In fact, you will sometimes encounter a mix of two snapshots (not that often, > recently, but still) > > Hence, the decision to not have a central index for all packages, but to > keep (and trust) the actual meta-info within the packages proper. > Sorry, I guess I should've responded to this as well. Isn't snapshot shearing going to be a problem regardless of the existence of a single central-index? For instance, pkg_add notices a chromium update, which requires a newer version of a dependency that hasn't been propagated to the mirror yet.
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > The concept you need to understand is snapshot shearing. > > A full package snapshot is large enough that it's hard to guarantee that > you will have a full snapshot on a mirror at any point in time. > > In fact, you will sometimes encounter a mix of two snapshots (not that often, > recently, but still) > > Hence, the decision to not have a central index for all packages, but to > keep (and trust) the actual meta-info within the packages proper. > > The only way to avoid that would be to have specific tools for mirroring, > and to ask mirror sites to set aside twice as much room so that they > can rotate snapshots. > > Now, each package has all dependency information in the packing-list... > which allows pkg_add to know whether to update or not. We do a somewhat > strict check, we have tried to relax the check at some point in the past, > but this was causing more trouble than it was worth. > > The amount of data transmitted during pkg_add -u mostly depends on signify: > you have to grab at least a full signed block, which is slightly over 64KB. > > On most modern systems, the bandwidth is not an issue, the number of RTT > is more problematic. The way to speed pkg_add -u up would be to keep the > connection alive, which means ditching ftp(1) and switching to specific code > that talks modern http together with byte-ranges. > Thank you for this information. It was very helpful! So currently with my 433 packages installed, I need to transfer ~28MB of data and make the associated RTTs every time I want to know if I have updates. Multiply this by the number of people using OpenBSD that also check for package updates periodically (a completely unknown number to me), and it seems like there could be benefits to both the mirror providers and the users to optimize this a bit :) I'm spit-balling ideas to optimize this in my head, and I came up with something that seems simple and feasible to me. Please let me know if I'm way off-base here with my proposal, as I may be making false assumptions here. I noticed that there doesn't seem to be one "master" sha that hashes *all* of the files of a given package, but rather one sha per file that the package installs. I'm assuming that this is what causes us to have to download the +CONTENTS file from every installed package. Here is my proposal: maintain a single separate file in the mirrors (similar to the index.txt) where each line looks like this: got-0.36.tgzN9IEajlcv8snEv9clqcnsZZodggAR8VnFwCdu8I19WY= where the package name is business as usual, but the hash is actually a reduction of all the existing hashes from the +CONTENTS into a single hash (through concatenation, xor, probably doesn't matter that much; just pick something). Then, 'pkg_add -u' only downloads this single file as the source of truth for the current package state. The file can of course be signed + compressed as well. Does this idea seem to have any basis in reality?
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 17:19, Daniel Jakots wrote: > I think if I wanted to compare packages between a machine of mine and a > mirror, I would compare the quirks package signature timestamps. On > your machine you can find it with > $ grep digital-signature /var/db/pkg/quirks*/+CONTENTS > and on the mirror, you need to fetch the quirks-XXX.tgz (I guess you > can find the XXX with the index.txt) and then look for the +CONTENTS > file. > > Cheers, > Daniel > I'm not sure I'm following. What helpful information does this convey, exactly? It's my understanding that the quirks package specifies mainly package obsolescence and stem-changes.
New tool to (quickly) check for available package upgrades
Hey misc@, I wrote a quick little tool here: https://github.com/neutralinsomniac/obsdpkgup in Go to show available package upgrades from your configured mirror. It takes no more than a few seconds (the time it takes to download index.txt from the package repo) to show you all packages that have received a version bump. This tool *won't* show same-version package-rebuild upgrades, so it shouldn't be used as a complete replacement to running 'pkg_add -u', but rather as a companion to show when actual newer versions of packages are released. I just noticed that in my 99% case, I was waiting anywhere from 5-10 minutes for 'pkg_add -u' to complete checking all ~400 of my installed packages, and it uses a considerable amount of bandwidth while doing so. As I understand it, the pkgtools detect same-version rebuilds by downloading enough of every installed package tgz to check the metadata contained within to determine if an upgrade is needed. If anyone knows of an alternative way to determine when a same-version package install is required, I would love to know of it. In the meantime, I hope someone else can make use of this tool as well. Thanks! Jeremy
Re: Criteria for errata
On Fri, May 10, 2019, at 16:40, Jeremy O'Brien wrote: > On Fri, May 10, 2019, at 13:29, Sebastian Benoit wrote: > > Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400: > > > On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > > > > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > > > > Jeremy O'Brien wrote: > > > > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that > > > > > > above fix, and installed it on my system which has made X > > > > > > rock-stable for me. This is totally fine for me personally, but I > > > > > > was curious if other people have run into this issue on their 6.5 > > > > > > installs, and if so, is this something worth pushing a reliability > > > > > > errata out for? I'm unfamiliar with how the process traditionally > > > > > > works so please excuse me if the question is outlandish. > > > > > > > > > > security issues and major reliability issues. but we try not to spend > > > > > all our > > > > > time making errata. that fix may be a contender. depends on how widely > > > > > reported it is. > > > > > > > > > > > > > vga arbiter is only used with multiple cards which isn't the common case > > > > > > > > > > That's how I understood the bug too, but when I enabled a debug build of > > > xenocara and examined the core dump after a crash, I had the same > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > report. > > > > I dont know much about xenocara, but i think that including dmesg and > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > I already have a bug report sent to bugs@ > > https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2 > > Gah sorry. I confused myself. The report I linked has nothing to do with the (already fixed in -current) VGAarbiterSpriteMoveCursor issue.
Re: Criteria for errata
On Fri, May 10, 2019, at 17:33, Joe M wrote: > > > > That's how I understood the bug too, but when I enabled a debug build > > > > of xenocara and examined the core dump after a crash, I had the same > > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > > report. > > > > > > I dont know much about xenocara, but i think that including dmesg and > > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > > > > I already have a bug report sent to bugs@ > > > > https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2 > > > > A few weeks ago, I was told that this fix was added to -current. I > cannot find the email now though. > Yeah it is. I've had hard lockups on -current which is keeping me on stable for now.
Re: Criteria for errata
On Fri, May 10, 2019, at 13:29, Sebastian Benoit wrote: > Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400: > > On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > > > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > > > Jeremy O'Brien wrote: > > > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above > > > > > fix, and installed it on my system which has made X rock-stable for > > > > > me. This is totally fine for me personally, but I was curious if > > > > > other people have run into this issue on their 6.5 installs, and if > > > > > so, is this something worth pushing a reliability errata out for? I'm > > > > > unfamiliar with how the process traditionally works so please excuse > > > > > me if the question is outlandish. > > > > > > > > security issues and major reliability issues. but we try not to spend > > > > all our > > > > time making errata. that fix may be a contender. depends on how widely > > > > reported it is. > > > > > > > > > > vga arbiter is only used with multiple cards which isn't the common case > > > > > > > That's how I understood the bug too, but when I enabled a debug build of > > xenocara and examined the core dump after a crash, I had the same > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > report. > > I dont know much about xenocara, but i think that including dmesg and > maybe /var/log/Xorg.0.log output in your mail can't hurt. > I already have a bug report sent to bugs@ https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2
Re: Criteria for errata
On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > Jeremy O'Brien wrote: > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above > > > fix, and installed it on my system which has made X rock-stable for me. > > > This is totally fine for me personally, but I was curious if other people > > > have run into this issue on their 6.5 installs, and if so, is this > > > something worth pushing a reliability errata out for? I'm unfamiliar with > > > how the process traditionally works so please excuse me if the question > > > is outlandish. > > > > security issues and major reliability issues. but we try not to spend all > > our > > time making errata. that fix may be a contender. depends on how widely > > reported it is. > > > > vga arbiter is only used with multiple cards which isn't the common case > That's how I understood the bug too, but when I enabled a debug build of xenocara and examined the core dump after a crash, I had the same "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug report.
Criteria for errata
Hey misc@, I'm running 6.5 stable on a thinkpad x1 carbon 6th gen. Everything works beautifully, *except* I'm plagued by this issue: http://openbsd-archive.7691.n7.nabble.com/Xorg-crash-every-few-days-td357384.html which is fixed by this revision: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/common/xf86VGAarbiterPriv.h.diff?r1=1.8&r2=1.9 I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, and installed it on my system which has made X rock-stable for me. This is totally fine for me personally, but I was curious if other people have run into this issue on their 6.5 installs, and if so, is this something worth pushing a reliability errata out for? I'm unfamiliar with how the process traditionally works so please excuse me if the question is outlandish. Thanks, Jeremy
Re: X hangs again while on integrated
On Wed, May 8, 2019, at 03:59, Gregory Edigarov wrote: > > On 07.05.19 11:39, Gregory Edigarov wrote: > > I've got some more info on this. > > > > tried to run X with tiling wms: spectrwm (my main wm), dwm, i3 - all > > hang absolutely the same way. (see my last mail with X backtraced) > > > > then I've tried fvwm - works > > > > cwm - works > > > > kde & gnome - both work flawlessly. > > > > i.e. there is some trouble in the newest versions of Xenocara, making > > it impossible to run with tiling window manager at least on i915. > sorry, > > yesterday fvwm and cwm were both hanging the same way spectrwm does. > > if somebody want to look into the issue - what else information beside > dmesg and backtrace do you need? > > didn't test with kde & gnome ( and anyway I removed them as I don't use > them) > > Thanks. > > > > > > > On 23.04.19 11:43, Gregory Edigarov wrote: > >> Hello misc@ > >> > >> it happens with no traces in logs. > >> > >> most of the time while in chromium, but in firefox too. (with firefox > >> it just needs more time) > >> > >> thought it is memory, but memtest reveal nothing. the same is the > >> video memory tests. it happens only on > >> > >> intel i915. no hangs on radeon(non integrated). > >> > >> when this happen i am always able to login via ssh too the box and > >> kill X. > >> > >> killing chrome or firefox dfwiw, I also have X hangs on -current, though > >> I'm not able to ssh + reboot. My system completely locks up. I have an Intel UHD Graphics 620 card. I've submitted a bug report here: oesn't help. > >> > >> also noticed that with recent build as of Apr 21, kernel is loosing > >> the changes made by config, but still works when i make changes > >> during the boot in UKC. > >> > >> > >> > >> > >> dmesg: > >> fwiw, I also have X hangs on -current, though I'm not able to ssh + reboot. My system completely locks up. I have an Intel UHD Graphics 620 card. I've submitted a bug report here: https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2
Re: sound short stops in mpv when doing firefox stuff
On Fri, Feb 1, 2019, at 05:45, Mihai Popescu wrote: > Hello, > > I use mpv with a network stream (radio) and in the same time I use > firefox for browsing. There is some audible sound short stop each time > I open a new tab in firefox and sometimes when in change tabs. > This it doesn't happen if I listen to that stream in the firefox > browser, no matter how many tabs I open. > I use the most recent snapshot/amd64. I tried to adjust cache for mpv > but it does not matter. Vlc is playing fine, as cvlc terminal app. > > I want to stick with mpv for the moment, so if anyone is an expert in > fine tuning it, please drop here a hint. Even if it cannot be fixed > for the moment, > > Thank you. > Try changing the mpv audio backend to sndio. Solved it for me.
Re: undeadly
On Wed, Apr 25, 2012 at 01:21:06PM +0200, Gilles Chehade wrote: > On Wed, Apr 25, 2012 at 07:10:32AM -0400, Jeremy O'Brien wrote: > > On Wed, Apr 25, 2012 at 12:04:27PM +0200, mxb wrote: > > > On 04/25/2012 11:52 AM, Mihai Popescu wrote: > > > > > > > Hi, > > > > > > > > Nice article about Paris. Can someone point out what text editors are > > > > open in that picture? > > > > I don't want to start the old war about editors, I'm just interested > > > > what other options are ... > > > > Thanks. > > > > > > > > > > > > > I think it is Window Manager and grouping. > > > Forgot the name of this minimalistic WM. Anyone to point this out? > > > > > > P.S. > > > I see at least two WM in use on those photos. One is from the base. > > > > > > //maxim > > > > > > > Let's try that again without top-posting... O_o > > > > First laptop looks like either wmii or i3 based on the dynamic tiling > > (tab layouts within tiled layout) and colorscheme, though xmonad could > > also be coaxed into providing a layout like that. Second laptop looks > > like fvwm to me based on the fact that the windows have titlebars. cwm > > doesn't have titlebars. Just my observation. > > > > First laptop has ion3, editor is emacs with custom emacs.conf: > > https://www.poolp.org/~gilles/emacs/emacs.conf > > Also, how I managed to appear on a picture while only attending 3/4 hours > is an achievement in itself ;-p > I thought ion3, but i3 came out instead because that's what _I_ use. Thanks for the input. I'm also very nosy when it comes to the (windowing/editing) environments that people work/code in. Always looking for new ideas.
Re: undeadly
On Wed, Apr 25, 2012 at 12:04:27PM +0200, mxb wrote: > On 04/25/2012 11:52 AM, Mihai Popescu wrote: > > > Hi, > > > > Nice article about Paris. Can someone point out what text editors are > > open in that picture? > > I don't want to start the old war about editors, I'm just interested > > what other options are ... > > Thanks. > > > > > I think it is Window Manager and grouping. > Forgot the name of this minimalistic WM. Anyone to point this out? > > P.S. > I see at least two WM in use on those photos. One is from the base. > > //maxim > Let's try that again without top-posting... O_o First laptop looks like either wmii or i3 based on the dynamic tiling (tab layouts within tiled layout) and colorscheme, though xmonad could also be coaxed into providing a layout like that. Second laptop looks like fvwm to me based on the fact that the windows have titlebars. cwm doesn't have titlebars. Just my observation.
Re: undeadly
First laptop looks like either wmii or i3 based on the dynamic tiling (tab layouts within tiled layout) and colorscheme, though xmonad could also be coaxed into providing a layout like that. Second laptop looks like fvwm to me based on the fact that the windows have titlebars. cwm doesn't have titlebars. Just my observation. On Wed, Apr 25, 2012 at 12:04:27PM +0200, mxb wrote: > On 04/25/2012 11:52 AM, Mihai Popescu wrote: > > > Hi, > > > > Nice article about Paris. Can someone point out what text editors are > > open in that picture? > > I don't want to start the old war about editors, I'm just interested > > what other options are ... > > Thanks. > > > > > I think it is Window Manager and grouping. > Forgot the name of this minimalistic WM. Anyone to point this out? > > P.S. > I see at least two WM in use on those photos. One is from the base. > > //maxim
Re: Latest ThinkPad model fully compatible with OpenBSD out of the box?
On Thu, Sep 22, 2011 at 09:12:11AM -0700, James Hozier wrote: > What's the latest ThinkPad that OpenBSD can be installed on, and have > everything functional without having to tweak any special settings within > OpenBSD? > I just bought an X60s for cheap, and it's the first laptop I've used OpenBSD on that has literally ZERO problems. Graphics, wifi, suspend, sound, everything I've tried works beautifully and in some cases even better than I expected. I know this is an old post. I'm just catching up and had to use this thread to vent my excitement at finally having my perfect OpenBSD machine :)
Re: locate weirdness
On Wed, Jan 11, 2012 at 14:47, L. V. Lammert wrote: > At 01:30 PM 1/11/2012, Jeremy O'Brien wrote: > >> 4.3 was released May 1, 2008. That's almost 4 years old software. What >> are you expecting here? Someone to check out the code from that >> version and deeply inspect what may be causing your problem, that is >> more than likely already fixed in a later version? > > > Another typical reply - the question was "has anyone ever seen anything like > this", .. or, perhaps, "what could be causing it". No need for the off-topic > diatribes - a simple no would more than suffice. > OK then. I have used OpenBSD since 4.0, and I have not seen this behavior. I recommend seeing if an upgrade fixes your problem. ;)
Re: locate weirdness
On Wed, Jan 11, 2012 at 14:17, L. V. Lammert wrote: > At 01:04 PM 1/11/2012, Barry Grumbine wrote: >> >> Bite the bullet, upgrade, life is better at 5.0 > > > Sorry, but *UPGRADING* isn't the question - the question is why locate is > not working properly. If nobody has ever seen such a problem, it would be > quite more forthright to just admit that than spout the normal crap this > list promulgates. But, then, I should have expected multiple replies that > are off topic, of no help, and not worth the time to read. Sorry, I had > momentarily forgotten the definition of OBSD Misc - my bad. > > If nobody can answer the question, that's is not a problem, just say so! > >Lee > 4.3 was released May 1, 2008. That's almost 4 years old software. What are you expecting here? Someone to check out the code from that version and deeply inspect what may be causing your problem, that is more than likely already fixed in a later version? The replies were perfectly valid and helpful. In the software world, you're using an antique.
Re: X41 resume trouble
On Sat, Jan 22, 2011 at 09:48:33PM -0500, Jeremy O'Brien wrote: > Hello misc! > > So I installed OpenBSD 4.8 on my thinkpad X41, and everything seems to work > perfectly, except resume. If I suspend the laptop by closing the lid, and wake > it up quickly after, it seems to resume every time. If I leave the laptop in a > suspended state for say, a minute or longer however, my machine shows the > following message when I open it: > > http://hostthenpost.com/uploads/c30b89e9ce8e05b7c51820fcb723c7b5.jpg > > and I can do one of two things. I can either try to ctrl-c X, which > produces the output in the image, and then the machine freezes. Or I can > try to manually switch to X by hitting ctrl-f5, after which nothing > happens and the machine also freezes. Oh, and the uhci2 message seems to > appear on successful resumes as well. I'm not sure where to begin to > look for the problem. Following is all the information I can think you > guys might need. Thank you for any input. Seems as though upgrading to -current fixed the issue for me. It also made my uhci2 related message go away. Not sure what was causing the issue, but I will assume it was usb related unless told otherwise. In either case, no more problems to report here!
Re: insecure scheduler in OpenBSD 4.7
On Tue, Oct 12, 2010 at 01:57:20PM +0200, Alexandre Ratchov wrote: > On Tue, Oct 12, 2010 at 12:41:04AM +0400, Dmitry-T wrote: > > Try to recover ballance: > > renice 20 -p 30996 > > renice -20 -p 21919 25914 754 > ^ > > If you run any cpu bound process with priority -20, you will give all > the cpu to that process, without giving any chance to other processes > to run, so your box will hang until it terminates. This requires root > privileges. > > > > > It is not secure. One user script or program may load CPU and > > database or another servers lost speed in disk operations. > > This is hole for DOS attacks in OpenBSD design. > > Yeah, this is an attack root can do by renicing a cpu bound process, > but ``rm -rf /'' is much easier, isn't it? I was curious why no one brought this up earlier. A normal user _can't_ nice processes to anything below 0. Therefore this point is moot.
Re: thinkpad sl500: iwn0: radio is disabled by hardware switch
On Sat, May 22, 2010 at 12:29:28PM +0200, Peter N. M. Hansteen wrote: > Gregory Edigarov writes: > > > Where is that 'hardware switch'? > > on my SL500 it's a little slider switch on the front, to the left and > down from where you fumble your trackpad > On my X31, radio is permanently disabled due to lack of driver.
Re: Campus internet connection
Do we really need specialized hardware for 802.1X? I was under the impression that 802.1X is purely done in software, and only the WPA2 portion was done in hardware. Correct me if I'm wrong. On Nov 22, 2010 7:01 AM, "Iqigo Ortiz de Urbina" < inigoortizdeurb...@gmail.com> wrote: > If it really is, maybe donating some hardware would encourage some > developers to jump into this. Im not so sure about whether its a > priority or not atm, but it sure is something nice to have in the base > system. > > As for the hw donation, maybe we can start a pot so other ppl chips in > > On 11/22/10, Jeremy O'Brien wrote: >> Do you know if there are any plans in the works for implementing 802.1X in >> the future? My campus also insists on using it, and it is very frustrating. >> On Nov 17, 2010 10:53 AM, "David Coppa" wrote: >>> On Wed, Nov 17, 2010 at 4:38 PM, Tomas Vavrys wrote: >>>> Hello, >>>> >>>> I would like to use OpenBSD at school, but current documentation is >>>> only for Windows, Linux. Could you please guide me what is different >>>> and what man pages should I read? >>>> What bothers me is WPA supplicant. PF should not be a problem. >>>> >>>> Link to translated documentation, I know it is not perfect but I >>>> actually read it and it's fine to get the fundamental meaning. >>>> >> http://translate.google.cz/translate?hl=cs&sl=auto&tl=en&u=http://www.kolej.m ff.cuni.cz/faq/connect_linux.html%23mac >>> >>> Sorry, no way. >>> 802.1X authentication is currently unsupported on OpenBSD. >>> >>> ciao, >>> david
Re: Campus internet connection
Do you know if there are any plans in the works for implementing 802.1X in the future? My campus also insists on using it, and it is very frustrating. On Nov 17, 2010 10:53 AM, "David Coppa" wrote: > On Wed, Nov 17, 2010 at 4:38 PM, Tomas Vavrys wrote: >> Hello, >> >> I would like to use OpenBSD at school, but current documentation is >> only for Windows, Linux. Could you please guide me what is different >> and what man pages should I read? >> What bothers me is WPA supplicant. PF should not be a problem. >> >> Link to translated documentation, I know it is not perfect but I >> actually read it and it's fine to get the fundamental meaning. >> http://translate.google.cz/translate?hl=cs&sl=auto&tl=en&u=http://www.kolej.mff.cuni.cz/faq/connect_linux.html%23mac > > Sorry, no way. > 802.1X authentication is currently unsupported on OpenBSD. > > ciao, > david
Re: An OpenBSD smartphone
I was just thinking today about how cool it would be to have an OpenBSD phone, and then I saw your post. How bizarre. Anyway, the closest thing I have found to a "pocket computer phone" is the android line of phones. I've had an original Droid, and now I have a Droid Incredible, and I absolutely love them. They have multitasking, ssh (ConnectBot), email, full web browsers, and my favorite feature: the ability to connect to a bluetooth keyboard. Sometimes I forget I'm using a phone at all. I don't see many comparable "open" phones coming any time soon, so in the meantime, this is the best I've found out there. Good luck on your phone search. On Nov 17, 2010 3:02 AM, "Jan Stary" wrote: > My twelve years old cell phone needs to get replaced, > most probably with one of these newer smartphones. > > Beside other things, I want it to be as "open" as possible: > a freely-available OS, a class-compliant USB storage, a documented > wifi hardware, etc. So, in this regard: has someone managed > to install obsd on some of these newer phones? > > I understand that most of these have an OS that is basically > a modified linux; does anyone know about a varinat that would > have an OS based on BSD? > > Thanks > > Jan
Re: What does your environment look like?
On Sat, Jan 02, 2010 at 09:08:38PM -0500, Brynet wrote: > Hi, > > I know not everyone uses OpenBSD for a desktop OS, but I have been for > nearly 5 years and I'm quite curious about some of your opinions? do you > embrace minimalism or pure aesthetics? are the two mutually exclusive? > > When I started using OpenBSD (..around 3.7) I was frequently switching > between window managers, tweaking.. but for 2 years now I've been using > fluxbox and I believe I'm comfortable with it. > > * Do you use one of the bundled window managers like > cwm(1)/twm(1)/fvwm(1) or something else? xmonad after spending a lot of time getting ghc 6.10 set up. > * What other utilities do you find useful, any "dockapps" or similar > applets? personal customizations? -xmobar with CPU, battery, and fuzzy clock for statusbar -mutt -git for config syncing -firefox -tmux -irssi -mpd/pms > * Do you try to keep things uniform across other desktops? > * What does your environment look like? anyone willing to post > screenshots or actual workspace photos? I always use the same programs, and the configs are generally the same with machine-specific customizations tracked in my various git branches. Typical screenshot: http://pohl.ececs.uc.edu/~jeremy/obsd-screen.png > > I realize none of this may be relevant or even useful, but I figured it > was worth asking here anyway. > > Anyone feel like humouring me? :-) > > Thanks. > -Bryan.
Re: newfs_msdos alters disklabel?
On Tue, Jun 09, 2009 at 02:18:59PM +0300, Jussi Peltola wrote: > > S skip-quoted skip beyond quoted text > > > T toggle-quoted toggle display of quoted text > > Just use a MUA that doesn't suck too much :) > Holy crap. I had no idea mutt could do that! Thanks for the tip! -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc
Re: Wireless Freeze
On Sun, Apr 26, 2009 at 03:18:04PM -0300, Giancarlo Razzolini wrote: > Hi Guys, > >I finally got rid of my old access point and bought an internal pci > wireless card to put on my openbsd firewall. But i've been having some > weird "freezes". It simply stop sending packets for some seconds, and > then get back transmitting then, like nothing have happened. There ain't > no log on openbsd of any kind of errors, neither on my linux notebook. I > captured packets on both sides and didn't see any errors either. The > chipset i'm using is the RT2561S. I'm using it with 11g mode and i'm > using wpa1 with wpa-psk. Anyone had problems with this chipset? > Could be an entirely unrelated issue, but I have an Atheros AR5213 PCMCIA wireless card that exhibits the same behavior. I get random, varying periods of time where my card can receive traffic just fine but won't transmit worth a damn. I notice it most over ssh sessions. It's very aggravating. I hope it gets resolved. -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc
Re: Cardbus stops working after repeated card insertions
As a note, this is running on a Thinkpad X31.
Cardbus stops working after repeated card insertions
ion 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached ath0 at cardbus0 dev 0 function 0 "Atheros AR5212" rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf2112a 4.6, FCC1A, address 00:13:46:21:4f:9f ath0 detached -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc
Re: Can someone please suggest a replacement for xterm for me?
Paul de Weerd wrote: > Cheers, > > Paul 'WEiRD' de Weerd > > -- > >[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ I'm happy to see brainf*ck is still alive and well :)
Re: Can someone please suggest a replacement for xterm for me?
Shagbag OpenBSD wrote: > I'm currently using Openbox with xterm but the latter doesn't allow 'cut and > paste'. Can someone please suggest to me a small footprint alternative? > Kind regards Do you mean copy and paste? Because nearly all X11 apps have copy and paste by hilighting and middleclicking. I personally use rxvt-unicode (urxvt), and have no problems with it.
