Re: [oi-dev] Memory use with Firefox
On Thu, Jan 04, 2024 at 11:36:05AM -0800, Joshua M. Clulow via oi-dev wrote: > > You can ask Firefox for more information about the processes it has > started by entering "about:processes" and "about:memory" into the URL > bar. I believe the process ID is in parentheses on each line in the > list that represents a process. My "about:memory" display looks like this: 1,085.17 MB (100.0%) -- explicit ├599.16 MB (55.21%) -- gfx │├──597.14 MB (55.03%) -- webrender ││ ├──580.42 MB (53.49%) ── swgl ││ └───16.72 MB (01.54%) ++ (10 tiny) │└2.02 MB (00.19%) ++ (8 tiny) ├198.31 MB (18.27%) ── heap-unclassified ├─82.74 MB (07.63%) -- js-non-window I assume that "swgl' means "software GL", probably as a result of my Radeon HD 7450 video card not doing hardware GL. There goes 580 megs anyway. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 11, 2024 at 05:17:37AM -0600, Matthew R. Trower wrote: > > Seriously, though, I imagine it's going to be related to the kinds of sites > you visit, what kind of assets they're sucking down, what kind of monster > javascript frontends they want to run clientside, etc... Firefox basically > has Operating System status these days. I've seen individual tabs run > anywhere from 32MB to 500MB+ each. That sounds like cnn.com to me. > Just like with an OS, you need a process manager to answer these questions. > Unfortunately, you said that yours (about:process) wasn't working --- did > you ever figure that out? Yes, the problem seems to be with the version of firefox that was included with the OS. I'll have to do an upgrade to get that feature working. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 11, 2024 at 09:09:27AM -0800, Alan Coopersmith wrote: > Xorg maps VRAM from your video card, so you need to use pmap on the process > to see how much is heap allocation (regular ram) vs. memory mappings. Here's the processes today: $ prstat -c -s size Please wait... PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 941 mills2558M 2532M sleep 590 58:09:13 0.1% Xorg/3 1129 mills2066M 899M sleep 490 6:15:59 0.8% firefox/177 ... Indeed, Xorg is using more memory than the main firefox process. Perhaps my Radeon video card is responsible for that. Here's how memory allocation looks in more detail: root@ryzen># pmap 941 941:/usr/bin/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten 0040 2976K r-x-- /usr/bin/Xorg 006F8000 72K rw--- /usr/bin/Xorg 0070A0002572040K rw---[ heap ] 7FFFAAA0 16384K rw-s- 7FFFABA4204K r-x-- /usr/lib/xorg/modules/amd64/libint10.so 7FFFABA83000 8K rw--- /usr/lib/xorg/modules/amd64/libint10.so ... The largest portion of it seems to be in heap allocation. At least, the size seems to stabilize pretty quickly. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 04, 2024 at 05:26:30PM -0500, Gordon Ross wrote: > Aren't those LWPs being shown? (not processes) No, those are individual processes, with the number of threads for each process also shown. The first one is the main firefox process. It has about 200 threads. Most of the others correspond to tabs. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 04, 2024 at 11:36:05AM -0800, Joshua M. Clulow via oi-dev wrote: > > Firefox increasingly uses multiple processes as a measure of isolation > between different fault and security domains; if there is a > vulnerability or a bug in some code, it need not impact all the other > tabs necessarily. > > You can ask Firefox for more information about the processes it has > started by entering "about:processes" and "about:memory" into the URL > bar. I believe the process ID is in parentheses on each line in the > list that represents a process. The "about:processes" URL seems not to work in my version of firefox. All I see is the title bar. "about:memory" does work, but the amount of memory used seems quite small: There are no gigabytes of memory shown. I wonder if all memory is displayed there. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 04, 2024 at 10:38:00AM -0800, Bill Sommerfeld via oi-dev wrote: > > swap reports on used, reserved, and available swap space for virtual memory; > it doesn't report on free physical memory. ZFS operates largely below > the virtual memory system and manages physical memory. I was assuming that available swap space included both physical memory and disk device space. I was further assuming that disk space was used last. > Two ways to look at free physical memory are with the "vmstat" command's > "free" column, and with "top"; "top" also displays ZFS ARC statistics. I'll try top. I used an mdb macro to determine the size of the ZFS ARC. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, Jan 04, 2024 at 12:11:49PM -0600, John Howard wrote: > Pattern is 14 processes after 14 days. New process per day. That's not my experience. The number of processes quickly reaches a maximum. > Script to close the app at the end of each day and restart the app > for a new day. Then see what happens. That's a solved problem, one that produces a system that stays up without restarting any application. You have to limit the ZFS ARC. > BTW, you have a monster system. In what sense? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Memory use with Firefox
I have a system that I mostly use for web brousing. It has an AMD Ryzen 7 2700 Eight-Core Processor, and runs a recent version of OI, from 2023-11-07. It has 48 gigs of memory with an 8-gig swap partition. Using Firefox 119.0.1, I noticed that Firefox became sluggish only a few days after boot. I have five permanent tabs in Firefox, along with several temporary tabs, using the "Open in new tab" option. I assumed that ZFS and firefox were fighting over memory. Indeed, the ZFS ARC was using 32 gigs of memory. To fix this problem, I put the following into a file in /etc/system.d and rebooted: set zfs:zfs_arc_max = 0x2E000 This change limited the ARC to 12 gigs, and seems to have corrected the problem. Firefox scrolling was quick and smooth, and continued to be so for the next two weeks. After the reboot, the swap space looked like this: $ swap -sh total: 940.79M allocated + 536.90M reserved = 1.44G used, 44.81G available After 14 days, it was like this: $ swap -sh total: 4.98G allocated + 2.00G reserved = 6.98G used, 25.91G available The free memory seems to have stabilized at about 26 gigs. I assume that ZFS allocates memory from this free space. I still have questions about the memory usage of firefox. Here's how memory size looked after 14 days: $ prstat -c -s size Please wait... PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 1598 mills2850M 1481M sleep 490 26:56:22 0.7% firefox/198 941 mills2558M 2532M sleep 590 27:14:03 0.2% Xorg/3 1978 mills 578M 272M sleep 590 0:03:10 0.0% firefox/25 18154 mills 569M 261M sleep 440 0:15:33 0.1% firefox/26 1868 mills 558M 254M sleep 590 0:14:22 0.0% firefox/28 1867 mills 414M 158M sleep 590 0:10:04 0.0% firefox/24 1601 mills 411M 151M sleep 590 0:01:01 0.0% firefox/24 1602 mills 384M 147M sleep 590 0:00:32 0.0% firefox/24 1866 mills 360M 124M sleep 590 0:09:19 0.0% firefox/24 18878 mills 340M 108M sleep 490 0:00:01 0.0% firefox/25 19646 mills 310M 68M sleep 490 0:00:00 0.0% firefox/12 19639 mills 310M 69M sleep 590 0:00:00 0.0% firefox/12 19642 mills 310M 68M sleep 490 0:00:00 0.0% firefox/12 1604 mills 227M 45M sleep 590 0:00:03 0.0% firefox/3 1600 mills 227M 44M sleep 590 0:00:00 0.0% firefox/4 Total: 133 processes, 1323 lwps, load averages: 0.22, 0.23, 0.21 Why are there so many firefox processes? I was expecting one process per tab. Clearly there are many more. Why do some of the processes have so many threads? How much memory does firefox want? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] newbie help needed build errors pkg nut
On Fri, Nov 10, 2023 at 09:10:06AM +0100, Stephan Althaus wrote: > > I get an error: > > . pkg install: The following packages all deliver driver actions to ugen: > . > . > pkg://openindiana.org/system/management/nut/drivers/usb@2.8.1,5.11-2023.0.0.0:20231109T161519Z > . > pkg://openindiana.org/driver/usb/ugen@0.5.11,5.11-2023.0.0.21867:20231110T011306Z > . > . These packages cannot be installed together. Any non-conflicting subset > . of the above packages can be installed. You don't need nut's ugen driver if the illumos ugen driver will do. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Emacs has a bad font
On Wed, Nov 08, 2023 at 05:44:42PM +0100, Andreas Wacknitz wrote: > If you are using the gtk variant of emacs That's the one I'm using. > then it relies on pango for > font rendering and layout which in case has dropped support for older > font types a couple of months ago. > So your problem might be that you are trying to use an unsupported (by > pango) font type and thus rendering results look ugly. > You might solve this be choosing a font of a supported font type, eg. a > truetype font. There's no indication of truetype in the list of fonts that emacs displays. In fact, emacs will often tell me that a font does not exist when I select that font from its list. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Emacs has a bad font
On Wed, Nov 08, 2023 at 11:28:33AM -0500, Gordon Ross wrote: > I saw the same after I upgraded, back in July. > See subject: Emacs font problem in 28.2 Where are you finding this? I can't seem to find it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Emacs has a bad font
On Wed, Nov 08, 2023 at 06:07:54PM +0200, Toomas Soome via oi-dev wrote: > sounds like the original font got substituted. If you start emacs from > command line, does it tell about fonts being replaced? No, it completely silent. However, when I use the Options menu to select the system font, my check mark has disappeared the next time I start emacs. It acts like there is no such thing as a system font. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Emacs has a bad font
I recently did an OI upgrade, on one of my systems, from 20220928 to 20231107 (more than a year). Everthing worked normally afterwards except for emacs. It has a peculiar font, compared to MATE-terminal. The font appears to be too thin. I'm using the same font size as before, 10 point. What could the matter be? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Fri, Mar 10, 2023 at 05:27:46PM +0100, Udo Grabowski (IMK) wrote: > > The quick fix is just to comment that line. > I don't think we need any more quick fixes to the python script. I've just filed an OI bug report on the invoking ksh script. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Fri, Mar 10, 2023 at 08:49:25AM +0100, Klaus Ziegler wrote: > this is wired, because the patch: > oi-userland/components/desktop/desktop-cache/patches/01-python.patch > which Alan mentions in his mail has already been changed with PR: 10803 > on Feb 02 2023 to use python3.9, and my dev system (updated just now) > shows this for the find_newer script: > root@x4200:~# head -1 /usr/share/desktop-cache/find_newer > #!/usr/bin/python3.9 Yes, it is 3.9 on my system that had the problem. I reviewed the python script on an older system where it was indeed 3.5 . I assumed they were the same. That was my mistake. Nevertheless, the hidden python error message was produced on that system that had the problem. The invocation of the find_newer script would have returned with a non-zero return code, which is ignored by the method script. It also would have returned nothing on standard output, which is also ignored. I repeat the python3.9 error message here: Traceback (most recent call last): File "/usr/share/desktop-cache/find_newer", line 149, in sys.exit(main()) File "/usr/share/desktop-cache/find_newer", line 123, in main os.stat_float_times (True) AttributeError: module 'os' has no attribute 'stat_float_times' The best solution is still to eliminate the use of find_newer entirely. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Wed, Mar 08, 2023 at 04:21:17PM +0100, Till Wegmüller wrote: > Sounds like an actuator did not run correctly: You were right. > We have a couple SMF services that need to be restarted after updates one of > the needs to be restarted after glib-2.0 files got updated. [...] > The FMRI I suspect has an issue is > svc:/application/desktop-cache/gconf-cache:default and or That's the one. > svc:/application/desktop-cache/dconf-update:default > > The Patterns ins the Transforms is a standard python regex match of the file > actions in the manifest. `pkg contents -m` The method script, /lib/svc/method/gconf-cache, seems correct. It, however, invokes a python3.5 script, /usr/share/desktop-cache/find_newer, that fails on newly-installed systems. The error message that I got, normally not seen, is: Traceback (most recent call last): File "/usr/share/desktop-cache/find_newer", line 149, in sys.exit(main()) File "/usr/share/desktop-cache/find_newer", line 123, in main os.stat_float_times (True) AttributeError: module 'os' has no attribute 'stat_float_times' This script should, as a minimum, be converted to use a modern version of python. I better fix would be to modify the method script so that it never needed to invoke the python script. Both scripts are part of illumos, I assume. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Wed, Mar 08, 2023 at 01:47:25PM -0600, Tim Mooney via oi-dev wrote: > That's generated by glib-compile-schemas(1). From my understanding, it's > basically just a binary cache of all of the XML schemas in that directory. > > The Gsettings classes in glib can read that binary blob. I'm not sure if > there's a "decompile" tool, but I kind of doubt it. > > You could try move that file aside and then regenerate it with > glib-compile-schemas and see if you get an identical file. Ah, I did that, and the gschemas.compiled file got larger by 1759 bytes. The "gsettings get" commands worked. That result looks promising. # gsettings get org.mate.panel.menubar max-recent-items 10 # gsettings get org.mate.accessibility-keyboard capslock-beep-enable false I've never seen that before on this system, only on other systems. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Wed, Mar 08, 2023 at 11:57:36PM -0600, Tim Mooney via oi-dev wrote: > That would be my first guess. That a faulty theme is the cause now seems unlikely to me. I looked at some Mate themes on github: all of them contain keys related to geometry and colour, but nothing related to the number of items displayed or to the keyboard. > will show you a lot of your general desktop environment settings. In > particular, in there you'll see one for "theme": > > $ gsettings list-recursively org.mate.Marco | egrep theme > org.mate.Marco.general theme 'nimbus' That's exactly what I get. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Wed, Mar 08, 2023 at 01:47:25PM -0600, Tim Mooney via oi-dev wrote: > > I believe what the error message is saying is that your current theme is > not supplying a value for max-recent-items, but the gschema says there > should be one. So, the cause could be a faulty theme. I assume I'm using the default theme, whatever that is. I certainly have not changed any settings. > You could try move that file aside and then regenerate it with > glib-compile-schemas and see if you get an identical file. Yes, the gsettings tool only reads the gschemas.compiled file, not the original XML files. I verified that with "truss". > At one point I understood the theme support better, but it has been > so long since I looked at it that I don't recall how it all works. If > you do figure out where the theme you're using is lacking settings, please > do report back to the list. I know nothing at all about themes. Is there a way to find out which theme I'm using? It would have to be in a CLI session, since the graphic login never completes. Alternatively, is there a way to disable mate-panel, as that application seems to be the one that fails repeatedly? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Wed, Mar 08, 2023 at 04:21:17PM +0100, Till Wegmüller wrote: > Sounds like an actuator did not run correctly: > > We have a couple SMF services that need to be restarted after updates one of > the needs to be restarted after glib-2.0 files got updated. That seems to have happened correctly. > Check out the sources here for reference > https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/transforms/actuators#L46-L79 > > The FMRI I suspect has an issue is > svc:/application/desktop-cache/gconf-cache:default and or > svc:/application/desktop-cache/dconf-update:default Those seem to be caches that do not affect my problem. It's caches for mate-panel and mate-settings-daemon that concern me. > The Patterns ins the Transforms is a standard python regex match of the file > actions in the manifest. `pkg contents -m` > > You may also want to check if the package has the actuator set properly. pkg > contents .m should output restart_fmri > svc:/application/desktop-cache/gconf-cache:default as part of the file > action. That seems okay too. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Mon, Mar 06, 2023 at 05:19:34PM -0600, Gary Mills wrote: > On Mon, Mar 06, 2023 at 02:27:31PM -0600, Tim Mooney via oi-dev wrote: > > > > What does: > > > > gsettings get org.mate.panel.menubar max-recent-items > > > > report? > > $ gsettings get org.mate.panel.menubar max-recent-items > No such key “max-recent-items” The problem seems to be that two keys are missing from the schema. It seems simple at first, but the XML files in /usr/share/glib-2.0/schemas do contain the apparently missing keys. There are other locations searched, though. One is /usr/share/glib-2.0/schemas/gschemas.compiled . I have not figured how examine that file. It may well be correct. There is also a ".cache" directory in my home directory. I suppose I can remove or rename it, and it will be rebuilt. I haven't tried that yet. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Mon, Mar 06, 2023 at 02:27:31PM -0600, Tim Mooney via oi-dev wrote: > > What does: > > gsettings get org.mate.panel.menubar max-recent-items > > report? $ gsettings get org.mate.panel.menubar max-recent-items No such key “max-recent-items” > If you temporarily rename ~/.config (better if you can do this from a > non-graphical session, but OK to do even if not) and then log in, A graphical log in never completes, with the error. I have to shut the system down to recover. The message "X connection to :0 broken" must be caused by the shutdown. > does the > error go away? You can move .config back after the test, to get most of > your settings back. No, I get the same icon jumping behavior. It does rebuild .config . mate-panel dumps core. The .xsession-errors file is also different. This the beginning of one of the cycles: (mate-settings-daemon:2314): GLib-GIO-ERROR **: 16:47:00.121: Settings schema 'org.mate.accessibility-keyboard' does not contain a key named 'capslock-beep-enable' (mate-panel:2315): GLib-GIO-ERROR **: 16:47:00.219: Settings schema 'org.mate.panel.menubar' does not contain a key named 'max-recent-items' (mate-settings-daemon:2320): MateDesktop-WARNING **: 16:47:00.367: Call to screen_info_new is too frequent, skipping... (mate-settings-daemon:2320): MateDesktop-WARNING **: 16:47:00.368: Call to screen_info_new is too frequent, skipping... (mate-settings-daemon:2320): MateDesktop-WARNING **: 16:47:00.369: Call to screen_info_new is too frequent, skipping... ** (mate-settings-daemon:2320): WARNING **: 16:47:00.370: There was a problem when setting QT_FONT_DPI=96: GDBus.Error:org.gnome.SessionManager.NotInInitialization: Setenv interface is only available during the Initialization phase ** (mate-settings-daemon:2320): WARNING **: 16:47:00.370: There was a problem when setting QT_SCALE_FACTOR=1: GDBus.Error:org.gnome.SessionManager.NotInInitialization: Setenv interface is only available during the Initialization phase (mate-volume-control-status-icon:1893): Gtk-WARNING **: 16:47:00.387: Theme parsing error: gtk-widgets.css:6:28: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version (mate-volume-control-status-icon:1893): Gtk-WARNING **: 16:47:00.387: Theme parsing error: gtk-widgets.css:7:28: The style property GtkRange:stepper-size is deprecated and shouldn't be used anymore. It will be removed in a future version (time-slider-notify:1881): Gtk-WARNING **: 16:47:00.387: Theme parsing error: gtk-widgets.css:6:28: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version > Are you using the default theme? I'm using only the defaults. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Mon, Mar 06, 2023 at 07:15:10PM +0100, Klaus Ziegler wrote: > > I've just updated from: illumos-58b0c75051 to: illumos-806838751b which > includes #PR 11279 and can't find the error message from pulseaudio > in .xsessions-errors any more. I just updated the system I installed two days ago, and all the pulseaudio errors seem to be gone. However, mate-settings-daemon still dumps core. The messages in .xsession-errors that show ERROR or CRITICAL are these: (mate-panel:2259): GLib-GIO-ERROR **: 13:09:07.569: Settings schema 'org.mate.panel.menubar' does not contain a key named 'max-recent-items' (mate-settings-daemon:2258): GLib-GIO-ERROR **: 13:09:07.578: Settings schema 'org.mate.accessibility-keyboard' does not contain a key named 'capslock-beep-enable' Window manager warning: Log level 8: g_main_loop_is_running: assertion 'loop != NULL' failed (tracker-miner-fs:1614): GLib-GIO-CRITICAL **: 13:09:07.725: Error while sending AddMatch() message: The connection is closed (tracker-miner-fs:1614): GLib-GIO-CRITICAL **: 13:09:07.725: Error while sending AddMatch() message: The connection is closed (tracker-miner-fs:1614): GLib-GIO-CRITICAL **: 13:09:07.725: Error while sending AddMatch() message: The connection is closed X connection to :0 broken (explicit kill or server shutdown). X connection to :0 broken (explicit kill or server shutdown). -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libpulsecore error
On Mon, Mar 06, 2023 at 11:29:52AM +0100, Udo Grabowski (IMK) wrote: > > A symbolic in /usr/lib/amd64/ with the old name temporarily fixes > this problem. Even with that workaround, I still have trouble with mate. I get these messages in .xsession-errors: (mate-power-manager:3042): PowerManager-WARNING **: 09:49:52.908: failed to send session response: Connection was disconnected before a reply was received X connection to :0 broken (explicit kill or server shutdown). X connection to :0 broken (explicit kill or server shutdown). mate-settings-daemon dumps core. Here's the traceback from mdb: > ::stack libglib-2.0.so.0.7400.6`g_log_structured_array+0x127() libglib-2.0.so.0.7400.6`g_log_default_handler+0xb9() libglib-2.0.so.0.7400.6`g_logv+0x23c() libglib-2.0.so.0.7400.6`g_log+0x7d() libgio-2.0.so.0.7400.6`g_settings_schema_get_value+0x91() libgio-2.0.so.0.7400.6`g_settings_schema_key_init+0x52() libgio-2.0.so.0.7400.6`g_settings_get_value+0x66() libgio-2.0.so.0.7400.6`g_settings_get_boolean+0xd() liba11y-keyboard.so`start_a11y_keyboard_idle_cb+0x60() libglib-2.0.so.0.7400.6`g_main_context_dispatch+0x140() libglib-2.0.so.0.7400.6`g_main_context_iterate.constprop.0+0x1c8() libglib-2.0.so.0.7400.6`g_main_loop_run+0x83() libgtk-3.so.0.2404.30`gtk_main+0x7d() main+0x56a() _start_crt+0x87() _start+0x18() -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Needed two reboots after OI upgrade
Yesterday, I upgraded a system on my private network from
hipster-20220226 to hipster-20220915 . (The last component of the BE
name is the date of OI). After the reboot, the network did not work,
although the system's network card did get the correct IP address via
DHCP.
When I did a second reboot, the network worked normally, along with
everything else. I noticed from the messages log that fmd reported an
error after the first reboot. Specifically, fmd reported that the
svc:/network/ipfilter:default SMF service had failed and been placed
in the maintenance state. That's a curious thing because that service
is normally disabled. It stayed disabled on the second reboot.
Here's the SMF log from that first session, showing essentially the
same thing:
[ Sep 15 19:33:43 Method "start" exited with status 0. ]
[ Sep 15 19:33:54 Rereading configuration. ]
[ Sep 15 19:33:54 Executing refresh method ("/lib/svc/method/ipfilter
reload"). ]
[ Sep 15 19:35:55 Method or service exit timed out. Killing contract 112. ]
[ Sep 15 19:35:55 Leaving maintenance because disable requested. ]
[ Sep 15 19:35:55 Disabled. ]
I don't know if this is an OI bug or an illumos bug, but I thought I'd
start here.
--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI package build process
On Fri, Jul 22, 2022 at 03:04:50PM -0600, n...@snapcon.com wrote: > > It has been a few years since I built userland, but there were a few > components that downloaded, unpacked and patched multiple archives prior to > building I know that when I was with Sun/Oracle, we discouraged things > downloading required bits during the "build" phase. We wanted to be sure > that we were able to cache the source that we downloaded to have a copy of > it for a variety of reasons. Downloading into a cache was more community > friendly, provided some stability that was worthwhile, and more. The > archive hashes also provide some guarantees. > > GCC is an example of something that downloads, unpacks and patches multiple > archives. It downloads gcc, mpfr, mpc, and gmp prior to building. > > "build" depends on "prep", which depends on "download", "unpack", and > "patch". "patch" depends on "unpack". "unpack" depends on "download" and > "download" depends on each downloaded archive. There are intermediate > targets and variations on this, but that is the high level. By the time > that you hit the "build" phase, the expectation was that you had the full > component source and that it was ready to build. The reality is that the > "download" target was/is expected to download all of the source that you > need. > > I don't know if it is a goal of oi-userland, but there was a time when the > Solaris userland build was expected to and did work disconnected from the > internet. I used to run "gmake download", prior to travel and update the > cache on my laptop so that I could work disconnected on the plane. Yes, that is how it is supposed to work. GO applications, like zrepl are the exception. OI has some of them already. The GO compiler resolves references by downloading GO modules. In the case of zrepl, it downloads 46 modules from a variety of Internet sites. It does this based on files in the zrepl source tree. The GO compiler knows how to parse these files, and how to do the downloads. By default, all of this happens during the "build" target. My questions are two. First of all, will this work reliably for OI? Secondly, is there any advantage to moving the download to an earlier target? Regardless, 46 modules will still be downloaded, still without any cache. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] OI package build process
I need a bit more information about the process that the OI build server uses. I know, of course, that the "download" target is intended to download a source archive into a cache, the "unpack" target is intended to unpack the archive into a directory within the component directory, and that the "build" target is intended to compile the source files. I'm attempting to develop a package for zrepl, another backup system for ZFS. Zrepl is written in the GO language. Like other GO applications, the "build" target downloads a large number of source files (aka GO modules) from various Internet sites before it does the actual compile. This is how GO resolves references to other GO modules. Is this behavior likely to be a problem for the OI build process? I may be able to move GO's download to the "unpack" target. It will still downoad many files. There still isn't a cache. Will this change offer any improvement to the OI build process? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Packaging a GO application for OI
I'm engaged in creating an OI package for the backup system "zrepl". It's somewhat hostile to the normal packaging procedure. For example, during the "build" step, it downloads 46 GO modules to $(SOURCE_DIR)/gopath . Is there a way to prevent this download? If not, I may be able to move the download to the "unpack" step. Would doing that be an improvement? Is there any other way? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
On Fri, Jun 24, 2022 at 10:39:00AM -0700, Alan Coopersmith wrote: > What that's telling you is that it can't find which IPS package to list > for the dependency on libLLVM-13.so - most commonly this means a missing > entry in the REQUIRED_PACKAGES list in the Userland Makefile - which the > first command should have resolved, but it seems to have failed for a > reason I don't recognize. (It looks like it's missing the path to the > script to run, and I don't know why that would happen.) Ah, there are two clang-13 packages now: $ pkg list '*clang-13*' NAME (PUBLISHER) VERSIONIFO developer/clang-13 (openindiana.org) 13.0.1-2022.0.0.0 i-- runtime/clang-13 (openindiana.org)13.0.1-2022.0.0.0 i-- -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
On Fri, Jun 24, 2022 at 06:23:18PM +0200, Friedrich Kink via oi-dev wrote: > Oh forgot just for the sake of completeness and the brave who want test on > the own here my current Makefile: I'll bet you have a $HOME/.cargo directory. > # Put the bits cargo downloads in a private directory. This could be cached > # somewhere more permanent, but it's important to make sure that a person's > # $HOME/.cargo isn't used. > RUST_VERSION= $(COMPONENT_VERSION) > RUSTUP_HOME= $(BUILD_DIR)/$(MACH64) > CARGO_HOME= $(BUILD_DIR)/$(MACH64) > COMPONENT_BUILD_ENV+= CARGO_HOME=$(CARGO_HOME) > COMPONENT_INSTALL_ENV+= CARGO_HOME=$(CARGO_HOME) > COMPONENT_TEST_ENV+= CARGO_HOME=$(CARGO_HOME) > COMPONENT_BUILD_ENV+= RUSTUP_HOME=$(RUSTUP_HOME) > COMPONENT_INSTALL_ENV+= RUSTUP_HOME=$(RUSTUP_HOME) > COMPONENT_TEST_ENV+= RUSTUP_HOME=$(RUSTUP_HOME) > # Cleanup standard environment! > COMPONENT_BUILD_ENV = > COMPONENT_BUILD_ENV += OPENSSL_DIR=$(OPENSSL_PREFIX) > COMPONENT_BUILD_ENV += OPENSSL_LIB_DIR=$(OPENSSL_PREFIX)/lib/amd64 > COMPONENT_BUILD_ENV += OPENSSL_INCLUDE_DIR=$(OPENSSL_PREFIX)/include > COMPONENT_BUILD_ENV += OPENSSL_STATIC=0 > COMPONENT_BUILD_ENV += CC=$(CC) > COMPONENT_BUILD_ENV += CFLAGS="$(CFLAGS)" > #COMPONENT_BUILD_ENV += LDFLAGS="-L$(OPENSSL_PREFIX)/lib/$(MACH64) -lssl > -lcrypto" > COMPONENT_BUILD_ENV += CXX=$(CXX) > #COMPONENT_BUILD_ENV += CPPFLAGS="-I$(OPENSSL_PREFIX)/include" > COMPONENT_BUILD_ENV += CXXFLAGS="$(CXXFLAGS)" > COMPONENT_BUILD_ENV += AR=$(GNUAR) > COMPONENT_BUILD_ENV += RUSTC=$(CARGO_HOME)/bin/rustc > # Enforce linker consistency > COMPONENT_BUILD_ENV += RUSTFLAGS="-C linker=$(CC)" > COMPONENT_BUILD_ENV += RUST_BACKTRACE=1 > # Cleanup standard environment > COMPONENT_INSTALL_ENV = > COMPONENT_INSTALL_ENV += $(COMPONENT_BUILD_ENV) > # Set install path > COMPONENT_INSTALL_ENV += DESTDIR=$(PROTO_DIR) -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
> thanks a lot again, this helped to successfully build and install the rust > package. Nevertheless the original issue still persists: [...] > /usr/bin/python3.9 RESOLVE_DEPS= > /usr/src/myoi-userland/components/developer/rust/build/.resolved-i386 > /usr/bin/python3.9: can't open file > '/usr/share/src/myoi-userland/components/developer/rust/RESOLVE_DEPS=': > [Errno 2] No such file or directory > make: *** [/usr/share/src/myoi-userland/make-rules/ips.mk:516: > REQUIRED_PACKAGES] Error 2 My guess is that the rust bootstrap files should be in a separate OI package, one that only needs to be pkg-installed by rust developers. This new package would become a build dependancy of rust, of course. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
On Mon, Jun 20, 2022 at 09:21:58PM +0200, Andreas Wacknitz wrote: > We already had another guy trying to build a newer rust failing with the > same problem. > He found out that this is a known problem and there should already be a > fix (as far as I understood) but it hadn't been integrated in the release. > It looks like the situation didn't change in the last weeks. Who is the other guy? That makes three of us. I had the same problem. The solution is to copy the files in the Makefile, instead of using symlinks or hard links: # Workaround the symlink name length 100 problem, but hope it is not neccessary # but also with patch src_tools_rust-installer_src_generator.rs.patch COMPONENT_PRE_CONFIGURE_ACTION = $(CP) -r $(SOURCE_DIR)/* $(@D)/ -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
On Sun, Jun 19, 2022 at 11:05:48AM +0200, Friedrich Kink wrote:
> Thanks a lot for your response. Let me give some more information. This
> patch helped me to over come your issue:
>
> --- rustc-1.61.0-src/src/bootstrap/builder.rs 2022-05-18
> 03:29:36.0 +
> +++ rustc-1.61.0-src/src/bootstrap/builder.rs.new 2022-06-06
> 21:25:45.179276851 +
> @@ -1304,7 +1304,7 @@
> Some("-Wl,-rpath,@loader_path/../lib")
> } else if !target.contains("windows") {
> rustflags.arg("-Clink-args=-Wl,-z,origin");
> - Some("-Wl,-rpath,$ORIGIN/../lib")
> + Some("-Wl,-rpath,/usr/clang/13.0/lib")
> } else {
> None
> };
I'm already using that patch, so that can't be the cause of my
problem.
> Also I already use rustup (as suggested by Joshua, too) and this is my
> current Makefile (as metioned it gets compiled and installed but make
> REQUIRED_PACKAGES|publish stops immediately):
My Makefile is somewhat different. I'll attach it. Notice that I am
using the bootstrap files from Joyent, instead of using rustup. Also
notice that the build environment is different, but seems to work.
The original Makefile seems to set part of the build environment, and
then assign it to null, and then set more of it. That's peculiar.
--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the "License").
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets "[]" replaced with your own identifying
# information: Portions Copyright [] [name of copyright owner]
#
# CDDL HEADER END
#
#
# Copyright 2018, cgrze...@opencsw.org
# Copyright 2018, Aurelien Larcher
# Copyright 2018, Michal Nowak
# Copyright 2021, Carsten Grzemba
# Copyright 2022 Gary Mills
#
PREFERRED_BITS= 64
include ../../../make-rules/shared-macros.mk
COMPONENT_NAME= rustc
COMPONENT_VERSION= 1.60.0
# COMPONENT_REVISION= 0
COMPONENT_FMRI= developer/lang/rustc
COMPONENT_SUMMARY= Rust - Safe, concurrent, practical language
COMPONENT_CLASSIFICATION= Development/Other Languages
COMPONENT_PROJECT_URL= https://www.rust-lang.org
COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION)-src
COMPONENT_ARCHIVE= $(COMPONENT_SRC).tar.gz
COMPONENT_ARCHIVE_HASH=
sha256:20ca826d1cf674daf8e22c4f8c4b9743af07973211c839b85839742314c838b7
COMPONENT_ARCHIVE_URL= https://static.rust-lang.org/dist/$(COMPONENT_ARCHIVE)
COMPONENT_LICENSE= MIT or Apache-2.0
RUST_STAGE0_VER=1.60.0
RUST_ARCH:= x86_64-unknown-illumos
COMPONENT_NAME_1= rust
COMPONENT_VERSION_1=$(RUST_STAGE0_VER)
COMPONENT_SRC_1=$(COMPONENT_NAME_1)-$(COMPONENT_VERSION_1)-$(RUST_ARCH)
COMPONENT_ARCHIVE_1=$(COMPONENT_SRC_1).tar.gz
COMPONENT_ARCHIVE_HASH_1=
sha256:866259dc82f142606ced875532cb32c9f24301f27e2ab0087afb6fda01af6658
COMPONENT_ARCHIVE_URL_1=
https://us-east.manta.joyent.com/pkgsrc/public/pkg-bootstraps/$(COMPONENT_ARCHIVE_1)
SOURCE_DIR_1= $(COMPONENT_DIR)/$(COMPONENT_SRC_1)
RUST_BOOTSTRAP_PATH=$(SOURCE_DIR_1)
include $(WS_MAKE_RULES)/prep.mk
include $(WS_MAKE_RULES)/configure.mk
include $(WS_MAKE_RULES)/ips.mk
PATH=$(GCC_BINDIR):$(PATH.gnu)
# Need some help to pick the correct ar binary
GNUAR=$(GNUBIN)/ar
# getpwuid_r failure
CXXFLAGS += -D_POSIX_PTHREAD_SEMANTICS
CFLAGS += -D_POSIX_PTHREAD_SEMANTICS
# Add arch triplet to pkg macros
PKG_MACROS+= RUST_ARCH="$(RUST_ARCH)"
# Workaround the symlink name length 100 problem, but hope it is not neccessary
# but also with patch src_tools_rust-installer_src_generator.rs.patch
COMPONENT_PRE_CONFIGURE_ACTION = $(CP) -r $(SOURCE_DIR)/* $(@D)/
# Ignore the previous environment
COMPONENT_BUILD_ENV = -i
# Put the bits cargo downloads in a private directory. This could be cached
# somewhere more permanent, but it's important to make sure that a person's
# $HOME/.cargo isn't used.
COMPONENT_BUILD_ENV += CARGO_HOME=$(BUILD_DIR)/.cargo
# Rust expects the library path to be /usr/lib and is broken otherwise
RUSTC_LIBDIR= $(USRLIBDIR)
CLANG_ROOT= /usr/clang/13.0
CONFIGURE_OPTIONS = --prefix=$(CONFIGURE_PREFIX)
CONFIGURE_OPTIONS += --mandir=$(CONFIGURE_MANDIR)
CONFIGURE_OPTIONS +
Re: [oi-dev] problems publishing rust
On Sat, Jun 18, 2022 at 03:49:33PM +0200, Friedrich Kink via oi-dev wrote: > > I try to prepare new rustc package with current version 1.61.0. So far > building and installing is already working. But publishing respectively make > REQUIRED_PACKAGES immediately bails out with the following error message: [...] > truss shows that make REQUIRED_PACKAGE really tries to open the file > /usr/share/src/myoi-userland/components/developer/rust/RESOLVE_DEPS= Any > idea what goes wrong here? To simplify things I just used sample manifest > p5m file to exclude home made errors. First of all, I'm pleased that somebody else is working on rust: I thought I was the only one. I anticipated that the upgrade would be difficult, but it's essential to upgrade any packages that still use clang-90 . Rust is one of these. Consequently, I did the upgrade by stages. The first stage was to build and publish the original rust package with no change. I found I had to make one change: COMPONENT_PRE_CONFIGURE_ACTION had to copy files, instead of creating symlinks or hard links. Then, build and publish were successful Subsequent stages were to upgrade clang, to upgrade python, and to convert the Makefile to the new style. I'm still stuck in the second stage. You clearly have gotten further. I found many things that did not work, but nothing successful. The original rust version (1.44.1) is too old to build with clang-13. I chose 1.60.0, since it had a bootstrap archive available from Joyent. I also found that this version will not build with the clang compilers. I had to revert to gcc for these. Still, my builds terminated with this error: libLLVM-14-rust-1.60.0-stable.so is missing I don't know how to get past that error. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-dev Digest, Vol 141, Issue 7
On Sun, May 29, 2022 at 05:14:30PM +0100, Peter Tribble wrote: > >Just run: >� /usr/sbin/svccfg delete svc:/system/metainit:default >Easiest before the update, but if you've updated already just run that >and reboot to clear it. >The metainit service hasn't actually existed for years, but SMF still >has a >record of it, and it's injecting false dependencies. Thanks for the information. I had to do exactly that when I updated OI today. The command and a reboot fixed it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] What to do with clang-90?
I'm investigating clang-90 with a view to removing python 3.5 from OI. The version is already the latest of 9.0 that is available, making a version upgrade impossible. We already clang-13, a recent version of the clang compiler. I'm left with only two options. Should I obsolete clang-90, or should I leave it part of OI, but attempt to upgrade the version of python that it uses? If I obsolete clang-90, is clang-13 already adequate in OI? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Removal of python 3.5 from OI
I've attached a file of affected directories to this message. It's a list of directories with a Makefile that contain "runtime/python-35". Note that it's not a list of packages. All that it implies is that the directory contains at least one package that requires python 3.5 . Some Makefiles iterate over python versions to create "-35" packages, along with other packages. In that case, it's usually only necessary to obsolete the "-35" package and to remove all references to python 3.5 . Other Makefiles specify only a single python version. If that is so, the software can usually be upgraded to python 3.7 or 3.9 . The trick is to obsolete packages in such a way as to avoid affecting users. Packages using python 3.5 that are not required by other packages can be obsoleted at any time. In the case of python 3.5 scripts, the easiest thing is to upgrade first, to a newer python version, and work down the dependency tree from there. Note that there has been no official announcement of the removal of python 3.5 from OI yet. However, python 2.7 has already mostly been eliminated from OI. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- cluster/crmsh cluster/pacemaker desktop/desktop-cache desktop/openbox desktop/pidgin developer/clang-90 developer/coccinelle developer/glade inputmethod/ibus-anthy inputmethod/imf-selector library/brltty library/glib library/gtk+ library/libpeas library/py3c library/speech-dispatcher multimedia/youtube-dl network/avahi network/bind openindiana/ddu openindiana/illumos-gate openindiana/openindiana-welcome openindiana/time-slider print/hplip print/system-config-printer python/argcomplete python/argh python/asn1crypto python/atomicwrites python/attrs python/automat python/backports.entry_points_selectable python/bcrypt-legacy python/ccsm python/cffi python/chardet python/charset-normalizer python/cheroot python/cherrypy python/compizconfig-python python/constantly python/coverage python/cryptography python/cssutils python/cython python/dbus-python python/decorator python/distlib python/dulwich python/geoip python/hamcrest python/hyperlink python/hypothesis python/idna python/import-profiler python/importlib-metadata python/incremental python/iniconfig python/ipython_genutils python/ipython python/jinja2-legacy python/jsonrpclib python/jsonschema python/kafka-python python/mako python/markdown python/markupsafe-legacy python/mock python/more-itertools python/netaddr python/nose python/packaging python/paramiko python/pathlib2 python/pexpect python/pickleshare python/pillow python/pip python/pipdeptree python/pluggy python/ply python/prettytable python/prompt-toolkit python/psutil python/ptyprocess python/py-cpuinfo python/py python/pyatspi python/pybonjour python/pycairo python/pycodestyle python/pycparser python/pycups python/pycurl python/pygments python/pygobject-3-legacy python/pylxml python/pymongo python/pynacl python/pyopenssl python/pyparsing python/pyro4 python/pyrsistent python/pytest-benchmark python/pytest-legacy python/pytest-reporter python/python-certifi python/python-dateutil python/python-memcached python/python-rapidjson-35 python/pytz python/pyxdg python/pyyaml python/pyzmq python/rbtools python/redis-py python/requests-legacy python/scandir python/serpent python/setuptools_scm python/setuptools-35 python/simplegeneric python/simplejson python/singledispatch python/six python/sortedcontainers python/sqlalchemy python/tempora python/texttable python/toml python/tornado python/traitlets python/twisted python/typing_extensions python/urllib3 python/virtualenv python/wcwidth python/zc.lockfile python/zipp python/zope-interface text/texinfo x11/redshift desktop/gnome3/orca desktop/mate/mozo web/apache2-modules/mod_wsgi ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error building a zrepl package for OI
On Tue, Apr 26, 2022 at 09:06:32PM +0300, Toomas Soome via oi-dev wrote: > > Old pool *may* contribute to trigger the issue, but such crash is > program error. That was my assumption. I've submitted the entire error message to the zrepl developers. While I'm waiting for a response, I'll move on to something else in OI. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error building a zrepl package for OI
On Fri, Apr 15, 2022 at 07:16:02PM +0100, Peter Tribble wrote: >The common pattern in oi-userland (see eg >components/sysutils/chezmoi/Makefile) >is >COMPONENT_BUILD_ENV += GOPATH="$(SOURCE_DIR)/gopath" >COMPONENT_INSTALL_ENV += GOPATH="$(SOURCE_DIR)/gopath" Thanks. That got me much further in building a package. However, in my first test, the daemon terminated with a segmentation fault. I'm building zrepl-0.5.0, which I assume is the current version. Here's part of the error message: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0xaea33e] This was followed by a traceback, but I didn't see anything that revealed the origin of the error. Could an old zpool be part of the problem? This is part of the output: $ zpool status dpool pool: dpool state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error building a zrepl package for OI
On Fri, Apr 15, 2022 at 07:16:02PM +0100, Peter Tribble wrote: > >The environment variable GOPATH is set to the root of the zrepl source. >Any other value will work. If unset, then ~/go, but that's not always >ideal. Thanks. I assumed it had to exist. It's the opposite: it had to not exist, because that's where go will download packages. >The common pattern in oi-userland (see eg >components/sysutils/chezmoi/Makefile) That is my model. Obviously a good choice. >is >COMPONENT_BUILD_ENV += GOPATH="$(SOURCE_DIR)/gopath" >COMPONENT_INSTALL_ENV += GOPATH="$(SOURCE_DIR)/gopath" Yes, that worked for me. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Error building a zrepl package for OI
I'm attempting to build a "zrepl" package for OI. Zrepl is a "go" application. It it even possible to package go applications for OI? On build, I'm getting this error: make[1]: Entering directory '.../oi-userland-gh/components/sysutils/zrepl/build/amd64' $GOPATH/go.mod exists but should not ... $GOPATH/go.mod exists but should not GO111MODULE=on go build -mod=readonly -ldflags \ "-X github.com/zrepl/zrepl/version.zreplVersion=oi-20200504-2370-gd402c2588" \ -o "artifacts/zrepl-illumos-" $GOPATH/go.mod exists but should not make[1]: *** [Makefile:228: zrepl-bin] Error 1 make[1]: Leaving directory '.../oi-userland-gh/components/sysutils/zrepl/build/amd64' What causes this error, and how can I prevent it? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Fri, Apr 08, 2022 at 06:41:24PM -0500, Gary Mills wrote: > > I can confirm that the line ending is "\n\0", something that is not > documented as correct. That's the same hal bug that I suggested was > possible. I also suggested an easy solution. My suggestion is part of: https://www.illumos.org/issues/14227 It only would take a simple patch to hald to eliminate the trailing NUL byte. The first change is just before the write() to the pipe by reducing the byte count by one. That's the same thing that strlen() would return. The second change is just before the sscanf() that parses the output from the pipe. It restores the terminating NUL by overwriting the last byte of the string, which will be the newline byte. As far as I can tell, the NUL byte is needed by sscanf(). -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Fri, Apr 08, 2022 at 04:27:27PM -0700, Alan Coopersmith wrote: > Something that one of our engineers has recently discovered while > looking into a different HAL issue (problems with the power button > signalling) is that HAL appears to include a NULL byte at the end > of the messages it sends, I can confirm that the line ending is "\n\0", something that is not documented as correct. That's the same hal bug that I suggested was possible. I also suggested an easy solution. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Tue, Apr 05, 2022 at 05:12:41PM +0200, s...@pandora.be wrote: > I think the most difficult thing is to setup a development system > (build system) to further test this issue (which is now fortunately > solved - for the moment - by the rollback of the glib2 version to > 2.62). Not for me, it's not. I have half-a-dozen OI systems running on bare hardware: no virtualization here. The rollback is a temporary solution, until this bug is found. > I am not very familiar with dbus and hal but a good overview is at : > > https://iks.cs.ovgu.de/~elkner/s11/rmmount.html Yes, that web page looks useful. I haven't looked at it in detail yet. > On my OpenIndiana system, if I insert a USB device and monitor it with : > >$ dbus-monitor --session --profile | grep RemoteVolumeMonitor > > I see events on the dbus-monitor output like : > >1. DriveConnected >2. DriveChanged >3. VolumeAdded >4. VolumeMount >5. VolumeChanged >6. MountAdded > If a build system with glib2 and debug info is setup by someone > then perhaps it is possible to figure out where the "DriveConnected" > is happening when the USB removable drive is added. I haven't looked at "--session" output for some time, although I have looked at "--system" output. Running a BE where the USB automount fails, there is virtually no output from "dbus-monitor". -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Sun, Apr 03, 2022 at 07:13:45PM -0500, Gary Mills wrote: > [...] > Here's the result with a BE where the USB automount did not work. > Notice that there are two signals about 60 microseconds apart, and > nothing more. Notice also that the columns do not align with the > header: > > Script started on April 3, 2022 at 03:05:42 PM CDT > # dbus-monitor --system --profile > #type timestamp serial sender destination pathinterface > member > # in_reply_to > sig 1649016387.639814 2 org.freedesktop.DBus:1.60 > /org/freedesktop/DBus org.freedesktop.DBusNameAcquired > sig 1649016387.639882 4 org.freedesktop.DBus:1.60 > /org/freedesktop/DBus org.freedesktop.DBusNameLost I suppose the original message contained too much information for anyone to digest. Consider this instead: The output for a BE where the USB automount succeeded began with a signal message: sig 1648934895.356888 306 :1.2 /org/freedesktop/Hal/Managerorg.freedesktop.Hal.Manager DeviceAdded This is not an actual signal, but a bus message derived from the signal. Note that the "DeviceAdded" message is entirely absent in the output from the BE where USB automount did not work. I wonder if a missing signal is responsible for the failure. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
101 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusNameOwnerChanged mc 1648934895.827629 146 :1.16 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.827719 147 org.freedesktop.DBus:1.16 146 mc 1648934895.827862 147 :1.16 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.827920 148 org.freedesktop.DBus:1.16 147 mc 1648934895.886880 148 :1.16 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.886974 149 org.freedesktop.DBus:1.16 148 mc 1648934895.887121 149 :1.16 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.887205 150 org.freedesktop.DBus:1.16 149 mc 1648934895.927018 40 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.927108 41 org.freedesktop.DBus:1.18 40 mc 1648934895.927260 41 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.927272 42 org.freedesktop.DBus:1.18 41 mc 1648934895.928897 42 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.928966 43 org.freedesktop.DBus:1.18 42 mc 1648934895.929223 43 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.929235 44 org.freedesktop.DBus:1.18 43 mc 1648934895.930718 44 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.930796 45 org.freedesktop.DBus:1.18 44 mc 1648934895.931051 45 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.931063 46 org.freedesktop.DBus:1.18 45 mc 1648934895.933708 46 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.933780 47 org.freedesktop.DBus:1.18 46 mc 1648934895.934018 47 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.934030 48 org.freedesktop.DBus:1.18 47 mc 1648934895.936044 48 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.936147 49 org.freedesktop.DBus:1.18 48 mc 1648934895.936682 49 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.936695 50 org.freedesktop.DBus:1.18 49 mc 1648934895.937130 50 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.937232 51 org.freedesktop.DBus:1.18 50 mc 1648934895.937384 51 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.937501 52 org.freedesktop.DBus:1.18 51 mc 1648934895.937750 52 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.937893 53 org.freedesktop.DBus:1.18 52 mc 1648934895.938053 53 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.938065 54 org.freedesktop.DBus:1.18 53 mc 1648934895.945624 54 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.945639 55 org.freedesktop.DBus:1.18 54 mc 1648934895.945704 55 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.945715 56 org.freedesktop.DBus:1.18 55 mc 1648934895.948386 56 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusAddMatch mr 1648934895.948399 57 org.freedesktop.DBus:1.18 56 mc 1648934895.948632 57 :1.18 org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBusRemoveMatch mr 1648934895.948644 58 org.freedesktop.DBus:1.18 57 Notice that everything happened within the same second, including the mount request. There is a dramatic difference between the two BEs. I don't know if it's only a symptom of the real problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing li
Re: [oi-dev] What changed between glib versions?
On Thu, Mar 31, 2022 at 04:48:04PM -0500, Gary Mills wrote: > Ah, that behavior makes it much more difficult to diagnose the > problem. Intermittent operation is not something I even considered. > Could there be a critical timing someplace? I don't know how you > would even answer that question. The only thing I can think of that occurs at a random time is signals. Linux signal handling is quite different from illumos signal handling. Both OSes can lose repeated signals. The other pecularity, although not entirely random, is that hal writes UTF strings to a pipe, and reads them back from the same pipe. Pipes also are quite different between Linux and illumos. In particular, illumos pipes use streams, and require a context switch before the packet can move along the pipe. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Thu, Mar 31, 2022 at 08:34:44PM +0200, Andreas Wacknitz wrote: > In my experience this is not fully accurate. I have USB devices > (Logitech mouse and data sticks) that work sometimes. > Funnily, another keyboard/mouse combo from Logitech works reliably with > glib-2.62.6, but another mouse (Performance MX) can even be lost without > unplugging it by > just plugging in another USB device (data stick). My two sticks > sometimes work and sometimes not. This seems to be a timing problem. > > My USB devices worked with glib-2.70.0 with illumos-gate from about > three or four days ago but with the latest versions they don't seem to > work anymore. > So, this might also be a subtle timing problem. Ah, that behavior makes it much more difficult to diagnose the problem. Intermittent operation is not something I even considered. Could there be a critical timing someplace? I don't know how you would even answer that question. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] What changed between glib versions?
We now know which glib versions allow USB automounts and which fail to do so. The question is: what has changed between these versions? The bug itself is probably not in glib at all, but knowing what code has changed would at least put us on the right track. In the process of doing an automount, hal calls the function g_io_channel_read_line() within glib. That function in turn calls the function g_io_channel_read_line_backend() to do the actual work. The function g_io_channel_read_line_backend() in turn calls the function g_io_channel_fill_buffer(). Any change in any of these functions is suspect. As far as I can tell by reading the code, these functions are behaving as documented. However, they may no longer be compatible with the operation expected by hal. The compiler, or optimizer, may also be responsible. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] The end of python-27
On Thu, Mar 24, 2022 at 09:02:36AM -0700, Alan Coopersmith wrote: > > Since gnome-doc-utils is not used with GNOME 3 or later, upstream has > ended development and archived the project: > https://gitlab.gnome.org/Archive/gnome-doc-utils > so no amount of waiting will ever get it ported to Python 3 by them. Thanks for the information. Product developers may provide an alternative. It may have to be selected at build time. Python-2 might still disappear. > Does mate still need these tools or have they moved on to something else? There aren't very many products. Some of them are gnome-2 applications that OI runs under Mate. Mate itself may not need the tools, but I really don't know. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] The end of python-27
On Thu, Mar 24, 2022 at 07:19:36PM +0100, Marcel Telka wrote: > > You cannot obsolete gnome-doc-utils right now because the following > components lists it in REQUIRED_PACKAGES: > > multimedia/totem > desktop/gparted > desktop/gnome2/zenity > desktop/stardict Only four packages. That's actually pretty good. Fortunately also, it's only a build-time dependency, not a run-time dependancy. Only developers will need to install the gnome-doc-utils package. That's still a step in the right direction. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] The end of python-27
On Thu, Mar 24, 2022 at 03:58:59PM +, Peter Tribble wrote: > >For gimp, can you not simply build with --disable-python? That's certainly worth a try. However, I understand that a python-3 version is coming soon. >In Tribblix, I've largely eliminated python2. I suspect OI will become the same way. >But there are still one >or two things >that need it (gnome-doc-utils being one, older Node.JS which will >eventually go >away, but also Pale Moon requires it for build). So I'm actually >keeping a python2.7 >package, but it only exists to meet a handful of build dependencies so >doesn't >get installed in the normal course of events, and I'm expecting to keep >it that >way for a while. If it's only a build-time dependency, but not a run-time dependency, that's still pretty good. Only developers will install it in that case. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] The end of python-27
As some of you may know, Nona and I have been working through a list of packages that depend on python-27 . The list was originally published by Aurlien Larcher, with a view to the removal of python-27 from OI. With the integration of PR #7942, there are only two remaining packages: developer/gnome/gnome-doc-utils image/editor/gimp In both of these cases, python-2 is deeply embedded in the product, and the upstream developers have not completed the conversion to python-3 . Unless the conversion happens very soon, we have little choice but to obsolete these two packages, and revive them later when the conversion is ready. If anyone has a better alternative, please let us know. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Mount of USB stick now succeeds
On Wed, Mar 23, 2022 at 07:55:29AM -0700, Alan Coopersmith wrote: > > I don't remember what issue you're discussing here, but we did apply a > simple fix to Solaris HAL to make hal-storage-mount work with newer glib > releases a while back: > > https://gitlab.freedesktop.org/alanc/hal/-/commit/8953bfd08e6119368152ded0aa4d355a7609de93 > > But it looks like that was needed for glib 2.55.0 and later, so may be > a different issue than you're hitting now. Hal belongs to illumos, not OI. However, that may well be the problem. In any case, the patch won't hurt anything. The illumos developers certainly could fix that bug. > The only other USB device mounting bug I see us fixing in hal since then > was to workaround an issue in the Studio 12.6 compiler, which you wouldn't > be using: > > https://gitlab.freedesktop.org/alanc/hal/-/commit/a3e3d718f64be8f9477019d48267001c7b91a4cd That's exactly the problem, but I would not expect the gcc optimizer to have exactly the same bug. > but you can look through the list of our changes at > https://gitlab.freedesktop.org/alanc/hal/-/commits/solaris > to see if there's something I didn't notice that would help you. Thanks. Nothing else seems relevant to me. Others may spot something. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Mount of USB stick now succeeds
On Wed, Mar 23, 2022 at 11:48:25AM +0100, Andreas Wacknitz wrote: > Solaris-userland is > at glib-2.70 so they seem to have fixed either hal or glib. I wonder what they fixed. It would be done with a patch, most likely. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Mount of USB stick now succeeds
I'm pleased to report that automount of a USB stick now succeeds under OI on one of my systems. I upgraded from hipster-20210514 to hipster-20220322, and after the reboot it started working. I assume it was the backport of glib that fixed the problem, although I still believe the bug is actually in hal . My guess is that the the version of hal in illumos is not compatible with the current version of glib. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Where to put the history file?
On Sun, Feb 13, 2022 at 05:14:05PM +0100, Andreas Wacknitz wrote: > components/meta-packages/history/history is our global history file. > You'll need to merge the contents of the local history files into it. Is there a sort command that maintains the order of the global history file? Actually, does the order matter? I ask because I have ten lines to add to that file. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Where to put the history file?
I have four packages that I'd like to obsolete: library/python/logilab-astng library/python/logilab-astng-27 library/python/logilab-common library/python/logilab-common-27 These packages were formerly dependents of pylint, but are now unused. I'd also like to remove the containing directories, which are: components/python/logilab-astng components/python/logilab-common Both of these directories contain a history file. Where do I put them now? Where do I put the four new lines? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems dependency checks
On Thu, Dec 30, 2021 at 09:08:31PM +0100, Friedrich Kink via oi-dev wrote: > >I've some packages (clamav update to latest version and dovecot) I'd >like to commit but dependency check fails: > [...] >mav-clamdtop.depend has unresolved dependency ' >depend type=require fmri=__TBD pkg.debug.depend.file=libclamav.so.9 >\ >pkg.debug.depend.reason=usr/bin/clamdtop >pkg.debug.depend.type=elf \ >pkg.debug.depend.path=lib \ >pkg.debug.depend.path=usr/gcc/7/lib \ >pkg.debug.depend.path=usr/lib'. This error implies that libclamav.so.9 could not be found. It's looking in /lib, /usr/gcc/7/lib, and /usr/lib for the SO file. The first and last are default locations for the runtime linker. The middle one is unlikely. Where is that SO file? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some packages did not build anymore in userland
On Wed, Dec 22, 2021 at 08:27:49PM -0300, Till Wegmueller wrote: > > Can we have that Patch? I don't have a patch for ninja. I meant that it would be easy to develop a patch for ninja. All you have to do is to search the source for _FILE_OFFSET_BITS and write a patch to delete that line. What I actually did for glib was to write a shell wrapper that deleted that operand and value from the compiler command-line, and then invoked the compiler. That allowed me to build glib. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Some packages did not build anymore in userland
On Wed, Dec 22, 2021 at 08:58:12PM +0100, Alexander Jung wrote: > > i build the whole oi-userland from time to time, but in the last time there > are many packages they did not build anymore. I tried a fresh install and > fresh sync of oi-userland but it is the same. > > For example glib stops with this message ... [...] > /usr/gcc/9/bin/gcc -Igio/gresource.p -Igio -I../../glib-2.66.8/gio -Igmodule > -I../../glib-2.66.8/gmodule -I. -I../../glib-2.66.8 -Iglib > -I../../glib-2.66.8/glib -Igobject -I../../glib-2.66.8/gobject > -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch > -std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS > -Wduplicated-branches -Wimplicit-fallthrough -Wmisleading-indentation > -Wstrict-prototypes -Wunused -Wno-unused-parameter -Wno-bad-function-cast > -Wno-cast-function-type -Wno-pedantic -Wno-format-zero-length > -Werror=declaration-after-statement -Werror=format=2 > -Werror=implicit-function-declaration -Werror=init-self > -Werror=missing-include-dirs -Werror=missing-prototypes > -Werror=pointer-arith -m32 -O3 -Wno-error=format-nonliteral > -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -MD -MQ > gio/gresource.p/gresource-tool.c.o -MF gio/gresource.p/gresource-tool.c.o.d > -o gio/gresource.p/gresource-tool.c.o -c > ../../glib-2.66.8/gio/gresource-tool.c I've seen that behavior too. It's a bug in ninja, but the developer refuses to accept complaints about it. Ninja unconditionally defines _FILE_OFFSET_BITS=64 . The bug affects only 32-bit builds, but sometimes you need a 32-bit build. It's easily fixed on OI, by a patch that removes the offending statement. There's almost no way to fix it when building with ninja, other than building some other way. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] How to combine two source archives into one OI package?
I'm working on upgrading the pycairo package to the latest version, but I've run into a conflict with the existing version. Specifically, the conflict is with usr/include/pycairo/py3cairo.h and usr/lib/pkgconfig/py3cairo.pc, both of which are created by both versions. The existing version only supports python 3.5. The latest version supports only 3.7 and 3.9. The latter are required by many other packages. I could solve the conflict by obsoleting the existing pycairo package. Is this possible? Do I need to retain it? If I have to retain it, I'll need the Makefile to publish packages for python 3.5, 3.7, and 3.9, using both the existing and latest versions of the source. How do I do that? Is it even possible? I haven't seen any examples of doing that. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How to handle an unresolved dependency?
On Wed, Nov 24, 2021 at 04:07:46PM +0100, Andreas Wacknitz wrote: > > In many cases it's just needed to update the dependencies by running > "gmake REQUIRED_PACKAGES". > This will update the Makefile and you can check the new entries against > the old ones. That was exactly what I was trying to do. > If Python is involved you sometime also need to > - either add new packages (typically we don't want that) > - or add a bypass-generate entry in the manifest Yes, python was involved. The magical addition to the manifest turned out to be: pkg.depend.bypass-generate=.*six.* -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] How to handle an unresolved dependency?
I'm working on the upgrade of an OI package called "fio". Here's part of an error message I got: $ gmake REQUIRED_PACKAGES ... .../components/sysutils/fio/build/manifest-i386-fio.depend has unresolved dependency ' depend type=require fmri=__TBD pkg.debug.depend.file=six/__init__.py \ pkg.debug.depend.reason=usr/bin/fio2gnuplot \ pkg.debug.depend.type=python \ pkg.debug.depend.path=usr/bin \ pkg.debug.depend.path=usr/lib/python3.9 \ pkg.debug.depend.path=usr/lib/python3.9/lib-dynload \ pkg.debug.depend.path=usr/lib/python3.9/site-packages \ pkg.debug.depend.path=usr/lib/python3.9/vendor-packages \ pkg.debug.depend.path=usr/lib/python39.zip'. Indeed, the file usr/lib/python3.9/vendor-packages/six/__init__.py does not exist. That's because the entire python module is contained in the file usr/lib/python3.9/vendor-packages/six.py . How do I fix the manifest so that this dependency is accepted? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Does OI use gtk+ or gtk+3, or both?
On Sun, Nov 07, 2021 at 06:19:27PM -0800, Alan Coopersmith wrote: > On 11/7/21 3:43 PM, Gary Mills wrote: > > > Now, I've come to "nmap". That package indeed depends on python 2.7 > > That's an upstream limitation: > https://github.com/nmap/nmap/issues/1176 > https://github.com/nmap/nmap/pulls?q=is%3Apr+python3+is%3Aopen Well, that solves that problem. OI must remove nmap at the same time as it obsoletes python 2.7 . Nmap can return once it's able to be built with python 3.7 or 3.9 . -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Does OI use gtk+ or gtk+3, or both?
I've been working my way through Aurlien Larcher's list of all OI packages that are dependent on Python 2.7, upgrading as I went. Apparently Python 3.5 is to be deprecated as well. Now, I've come to "nmap". That package indeed depends on python 2.7 but also on two other python libraries: pygobject-27 and pygtk2-27 . Both of those libraries do not have python 3.7 or 3.9 versions. In fact, the web page for the new version of "pygtk2" says "For GTK+ 3 or Python 3 use PyGObject instead". I see that the OI source has two names for this package: pygobject and pygobject-3 . Both packages are obsolete, according to Aurlien's criteria above. The latest version of pygobject will require yet another new name, at least for the short term. What should this be? Note that the version major number is still 3, but that number has already been used. As far as I can tell, OI uses both gtk+ and gtk+3 libraries. Is this correct? As well, OI has two sets of python bindings: pygtk2 for gtk+, and pygobject for gtk+3 . Am I correct here too? I notice that only pygobject-27 is installed on my system now. Will we switch to a a new binding sometime? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gstreamer1 and OpenGL/EGL
On Tue, Oct 26, 2021 at 02:44:25PM -0500, Tim Mooney via oi-dev wrote: > > I'm working my way through updating the gstreamer1 components to the > latest version (1.16.2 -> 1.18.5). They've switched from autoconf to > meson, so the biggest hurdle has been converting the Makefile to use > the new configuration options. Meson is somewhat broken, except when Unix=Linux. It also does not work well for 32 and 64-bit builds. One solution is to omit the 32-bit build. If it's really needed, you must find another solution. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] More on USB failure to automount
On Sun, Oct 10, 2021 at 10:33:07AM +0200, Andreas Wacknitz wrote: > > Hi, are there any news about this bug and its fix? That patch didn't work. Neither did the next dozen or so. However, I did learn a great deal about glib. I know what the cause is. I just don't have the solution yet. One of the causes is the nature of the EAGAIN error. In the context of hald and glib on OI, the read() system call within glib produces this error when the pipe is empty, but the other end of the pipe is still open for write. Every subsequent read() will produce the same error until the process at the other end actually writes something to the pipe. This error is converted to G_IO_STATUS_AGAIN by glib. hald only processes lines when the status returned by g_io_channel_read_line() is G_IO_STATUS_NORMAL . It ignores any others, including G_IO_STATUS_AGAIN . The other cause is that lines written by hald (with the write() system call) to the pipe all end with "\n\0". Yes, the trailing null is written to and read back from the pipe. However, hald does not set the line terminator as glib expects, instead relying on glib's automatic line ending determination. In this case, that appears not to work. Instead, glib does a second read, which always sets the status to G_IO_STATUS_AGAIN . Once set, this status replaces any previous status. As you can see, hald writes lines to the pipe with write() but reads them back with g_io_channel_read_line(). That design may be a third cause. I'm going to do a bit more testing with hald and glib, and then return to what I was doing with OI. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] More on USB failure to automount
On Thu, Sep 02, 2021 at 09:32:16PM +0200, s...@pandora.be wrote: > > First of all it seems there are again OpenIndiana packages being updated; > thanks a lot for the work on this. [...] > Unfortunately the USB problem is still there and it got worse for me. I'm testing a patch for glib that might fix the USB problem on OI. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] More on USB failure to automount
Joshua M. Clulow has identified the location of the error: In particular, on my system, I see three write(2) calls that look like this: EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2 EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0 EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0 /dev/rdsk/c4t0d0 0 This seems about right. These writes are into a self-pipe (i.e., both ends of the pipe are held open within this single hald process) that is established in the sysevent_init() routine, and stored in the "sysevent_pipe_fds" global where I was able to confirm with pfiles that the pipe is still open. Where things appear to fall down is once we get into the glib area. ... Though we do enter sysevent_iochannel_data() on schedule for each sysevent, it seems like the call to g_io_channel_read_line() always returns a value of 3 on my system -- which seems like an EOF? Because the value is not G_IO_STATUS_NORMAL, we don't even try to call sscanf() to parse the lines we wrote above. This means we never call into sysevent_dev_add() and thus we never pass the hotplug event on to the rest of HAL. I've managed to add a few details using truss. Here's the command I used to examine the top hald process: # truss -f -o /tmp/NNN.truss -t read -u \ libglib-2.0::g_io_channel_read_line -p PID On a system where USB automount still worked, with a BE dated 2020-11-27, I got the following output: 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1: read(12, " E C _ d e v f s E S C".., 1024)= 80 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1: read(12, " E C _ d e v f s E S C".., 1024)= 89 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1: read(12, 0x08341480, 1024) Err#11 EAGAIN 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 3 1994/1@1: -> libglib-2.0:g_io_channel_read_line(0x8279938, 0x8046200, 0x8046204, 0x0) 1994/1: read(12, " E C _ d e v _ a d d d".., 1024)= 98 1994/1@1: <- libglib-2.0:g_io_channel_read_line() = 1 It shows the entry and return of g_io_channel_read_line() as well as the underlying read() system call that occurs between the two. Note that all three lines in the pipe were read back by hald. In this case, the return value from g_io_channel_read_line() is 1. Note also that one read system call raised the EAGAIN errno. This means that there is data in the pipe but that it is not yet ready to read. The code should try again later to read the data. In this case, the return value from g_io_channel_read_line() is 3. The hald process retries the read() and is successful. On a system where USB automount failed, running a BE dated 2021-05-14, I got this output from a similar truss command: 318/1@1:-> libglib-2.0:g_io_channel_read_line(0x8281920, 0x8046200, 0x8046204, 0x0) 318/1: read(12, " E C _ d e v f s E S C".., 1024)= 64 318/1@1:<- libglib-2.0:g_io_channel_read_line() = 1 318/1@1:-> libglib-2.0:g_io_channel_read_line(0x8281920, 0x8046200, 0x8046204, 0x0) 318/1: read(12, " E C _ d e v f s E S C".., 1024)= 73 318/1: read(12, 0x08292292, 1024) Err#11 EAGAIN 318/1@1:<- libglib-2.0:g_io_channel_read_line() = 3 318/1@1:-> libglib-2.0:g_io_channel_read_line(0x8281920, 0x8046200, 0x8046204, 0x0) 318/1: read(12, " E C _ d e v _ a d d d".., 1024)= 82 318/1: read(12, 0x082922E4, 1024) Err#11 EAGAIN 318/1@1:<- libglib-2.0:g_io_channel_read_line() = 3 The first call to g_io_channel_read_line() was successful. Subsequent calls to that glib function failed with return code 3. Note that there are now two read() system calls within the glib function, and the the second one always gets EAGAIN. That is the bug. All three lines were read, but the data are discarded because of the return code from g_io_channel_read_line(). What we need is a robust handling of EAGAIN after read() in glib. To give the p
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: > > OK, so I have looked into this a little bit. It seems like there is a > bug in the HAL code we ship, or in the glib that OI is now using, or > somewhere inbetween. [...] > This seems about right. These writes are into a self-pipe (i.e., both > ends of the pipe are held open within this single hald process) that > is established in the sysevent_init() routine, and stored in the > "sysevent_pipe_fds" global where I was able to confirm with pfiles > that the pipe is still open. > > Where things appear to fall down is once we get into the glib area. > The strings that are written into one end of the pipe by the sysevent > consumer, as described above, are meant to then be read through a glib > GIOChannel object in sysevent_iochannel_data(): [...] > I have run out of steam on this for now, but I hope this is enough for > someone to keep digging. As far as I can tell, nobody has taken up the chase from here. I'd like to do that myself, but I don't know enough dtrace to do it. This does look like a job for dtrace. In particular, I'd like to find out what glib is doing after that function call. There should be a read() system call at the bottom of it all. I'd like to see what's returned from that system call. Pipes on illumos are completely different internally from pipes on Linux, and certainly could behave differently. Self-pipes on illumos are even more likely to misbehave. Would it be possible for you to suggest some dtrace code that will reveal what I need from that glib function? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What to do with python module dependancies?
On Sun, Jul 18, 2021 at 03:08:38PM +0100, Peter Tribble wrote: > >I've also noticed the setup.py builds quite happily whether >dependencies >are present or not. >All I do is look at the requires.txt file. Usually present in the >.egg-info >directory, which may be present in the source or in the build tree. >(Some modules are smart enough to handle the fact that dependencies >vary between python versions, too.) Thanks for the information; it was quite helpful. I found the file that you mentioned. It lists the two modules that I've already discovered, and two others conditionally. Do I need to create the IPS dependancies myself, or does this happen automatically? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] What to do with python module dependancies?
I'm working on a python package that imports many other python modules. So far I've discovered two python modules that don't have corresponding packages in OI. There should be dependancies on these two packages, but the automatic mechanism seems not to add them. How can I add them myself? Do I do it directly in the P5M file? The original package builds and installs with the setup.py method. It doesn't check for dependancies at all. I don't notice missing dependancies until I test the module and get an error message when an "import" fails. I'd like to be able to build a package that does not have this problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error after pkg install
On Tue, Jul 13, 2021 at 08:20:43PM +0200, s...@pandora.be wrote: > > I installed some software (pkg install squeak) today and had no problems; > E_COULDNT_RESOLVE_HOST (6) reason: Could not resolve host: > pkg.openindiana.org > I've seen this error quite a few times when there is DNS resolving > problem, for example when /etc/nsswitch.conf has an issue. It certainly was transient. Both "host" and "getent" could resolve the hostname to an IP address immediately afterward. I also did not get the error message a few minutes ago when I did an install. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Error after pkg install
Twice recently, after a successful package install, I found this message in my terminal window: WARNING: Errors were encountered when attempting to retrieve package catalog information. Packages added to the affected publisher repositories since the last retrieval may not be available. Errors were encountered when attempting to contact repository for publisher 'openindiana.org'. Unable to contact valid package repository: http://pkg.openindiana.org/hipster/ Encountered the following error(s): Framework error: code: E_COULDNT_RESOLVE_HOST (6) reason: Could not resolve host: pkg.openindiana.org URL: 'http://pkg.openindiana.org/hipster' (happened 4 times) What does this mean? I've never seen it before. What's going on? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Something wrong with dependancies
I'm trying to build a library that uses only python-3.9 . For its tests, it requires pytest-3.9 . I noticed that OI has the pytest-39 package, and it includes that executable. However, when I tried to install that package, I got 30 packages. What's going on? Something must be broken with dependancies to get that many packages. Here's a transcript of what I got: # pkg install -nv library/python/pytest-39 Packages to install: 30 Estimated space available:7.38 GB Estimated space to be consumed: 1012.63 MB Create boot environment: No Create backup boot environment: No Rebuild boot archive: No Changed packages: openindiana.org library/python/attrs-37 None -> 20.3.0-2020.0.1.0 library/python/attrs-39 None -> 20.3.0-2020.0.1.0 library/python/importlib-metadata-35 None -> 1.5.2-2020.0.1.1 library/python/iniconfig-35 None -> 1.1.1-2020.0.1.0 library/python/iniconfig-37 None -> 1.1.1-2020.0.1.0 library/python/iniconfig-39 None -> 1.1.1-2020.0.1.0 library/python/packaging-35 None -> 20.8-2020.0.1.0 library/python/packaging-37 None -> 20.8-2020.0.1.0 library/python/packaging-39 None -> 20.8-2020.0.1.0 library/python/pathlib2-35 None -> 2.3.5-2020.0.1.1 library/python/pluggy-35 None -> 0.13.1-2020.0.1.0 library/python/pluggy-37 None -> 0.13.1-2020.0.1.0 library/python/pluggy-39 None -> 0.13.1-2020.0.1.0 library/python/py None -> 1.8.2-2020.0.1.0 library/python/py-27 None -> 1.8.2-2020.0.1.0 library/python/py-35 None -> 1.8.2-2020.0.1.0 library/python/py-37 None -> 1.8.2-2020.0.1.0 library/python/py-39 None -> 1.8.2-2020.0.1.0 library/python/pytest None -> 6.1.2-2020.0.1.1 library/python/pytest-35 None -> 6.1.2-2020.0.1.1 library/python/pytest-37 None -> 6.1.2-2020.0.1.1 library/python/pytest-39 None -> 6.1.2-2020.0.1.1 library/python/scandir None -> 1.10.0-2020.0.1.0 library/python/scandir-27 None -> 1.10.0-2020.0.1.0 library/python/scandir-35 None -> 1.10.0-2020.0.1.0 library/python/scandir-37 None -> 1.10.0-2020.0.1.0 library/python/toml-35 None -> 0.10.2-2020.0.1.0 library/python/toml-37 None -> 0.10.2-2020.0.1.0 library/python/toml-39 None -> 0.10.2-2020.0.1.0 library/python/zipp-35 None -> 1.2.0-2020.0.1.0 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] I've given up on gnome-doc-utils
In an attempt to eliminate dependancies on python-27, I came eventually to the gnome-doc-utils package. Reluctantly, I had to give up my attempt. The product was last updated in 2012 and has no python-3 support. Most of the work is conversion of the python code from 2 to 3, using the python bindings for libxml2. Somebody who knows more about python than I do may be able to accomplish this. The alternative is to abandon the package and perhaps any packages that require this one. I'm moving on to other packages. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] atge driver issue
On Fri, Jul 02, 2021 at 03:47:25PM +0200, Carsten Grzemba wrote:
>
>It seems the fix is simple:
I'm pleased to hear that.
>--- a/usr/src/uts/common/io/atge/atge_main.c
>+++ b/usr/src/uts/common/io/atge/atge_main.c
>@@ -256,7 +256,7 @@ static� � � � � mii_ops_t atge_l1c_mii_ops = {
>� � � � � � � atge_l1c_mii_read,
>� � � � � � � atge_l1c_mii_write,
>� � � � � � � atge_mii_notify,
>-� � � � � � NULL
>+� � � � � � atge_l1c_mii_reset
>� };
>�
>the function atge_l1c_mii_reset exist already but is not registered�
>in the mii_ops table.
I haven't looked at the source for a long time. I don't know why
that function is missing from that table. Is it called from another
place, or is it just floating? You might need the NULL line if the
table is ever searched.
>With this the "atge0: L1C chip detected a fatal error, interrupt
>status: 2200" did not occur again on cable disconnect.
>
>The interface is working if the cable is connected again.
Since you found the bug and the solution, you are welcome to file
an illumos bug report and PR for the driver.
--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] atge driver issue
On Thu, Jul 01, 2021 at 06:27:55PM +0200, Carsten Grzemba via oi-dev wrote: > >I use the atge driver on my laptop with AR8151V2 chip. There I have the >problem if the cable disconnects 10 sec later I get a L1C error and as >a result it seems that the upper layer assumes that the link is up with >10MB half duplex. [...] >But it seems there is very less similarity of the illumos driver with >the BSD or Linux driver. > >So I am wondering which source was the blue print for the Illumos atge >driver? I started with the Freebsd alc driver, and wound up with a new version of the illumos atge driver. This was in 2010. Much has changed since then. At the time, I tested the AR8132 on my ASUS laptop. Masayuki Murayama tested the AR8131 on his laptop. This was my first driver. I had a great deal of help from other people. There was one report in 2012 of a driver failure with AR8151 v2.0 hardware. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Mon, Jun 28, 2021 at 02:55:21PM -0700, Alan Coopersmith wrote: > On 6/28/21 12:52 PM, Gary Mills wrote: > > I don't know yet if the glib developers have > > dropped support for solaris or illumos. > > I've not seen any such moves by them, and have gotten Solaris-specific > pull requests accepted in recent years. Okay thanks. I'll drop that idea from my list of known unknowns, and look elsewhere. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Mon, Jun 28, 2021 at 06:53:33PM +0200, s...@pandora.be wrote: > > It's good that you reported the issue and of course USB automount > is useful. > > Andreas Wacknitz also confirmed this, and is trying to help as much > as possible. I didn't know this. In fact, I generally don't know when somebody else is working on something. We should be collaborating, rather than duplicating effort. I'm assuming the problem is in glib. I have several snapshots of the OI source, including the current one of course. I don't know yet if a patch disappeared. I don't know yet if the glib developers have dropped support for solaris or illumos. Going through the layers, I've gotten as far as: status = channel->funcs->io_read (channel, channel->read_buf->str + cur_len, channel->buf_size, _size, err); I'm assuming that OS-specific versions of "io_read" exist in glib, but I haven't found them yet. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: > > OK, so I have looked into this a little bit. It seems like there is a > bug in the HAL code we ship, or in the glib that OI is now using, or > somewhere inbetween. You've gone much farther than I have. With some help from you, I've determined, with a current OI BE, that: Something failed to notify hald of new USB devices. Hald failed to notify the process spawner: hald-runner. The mount was never done. In general, we agree. > With DTrace, I am able to see (in the "hald --daemon=yes" process at > the top of the HAL process tree) that it receives the appropriate > sysevents from the kernel when a USB disk is plugged in or removed. It's good to know that that bit of IPC works as intended. [...] > Where things appear to fall down is once we get into the glib area. > The strings that are written into one end of the pipe by the sysevent > consumer, as described above, are meant to then be read through a glib > GIOChannel object in sysevent_iochannel_data(): > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272 > > Though we do enter sysevent_iochannel_data() on schedule for each > sysevent, it seems like the call to g_io_channel_read_line() always > returns a value of 3 on my system -- which seems like an EOF? Because > the value is not G_IO_STATUS_NORMAL, we don't even try to call > sscanf() to parse the lines we wrote above. This means we never call > into sysevent_dev_add() and thus we never pass the hotplug event on to > the rest of HAL. That sounds like the "temporarily unavailable" or the "interrupted system call" errors for the read() system call in glib. > I have run out of steam on this for now, but I hope this is enough for > someone to keep digging. In particular, it seems like it is worth > investigating whether glib has been updated in OI at some point > between when this was last working and now. Perhaps there is a build > issue or a bug there. It doesn't seem like there has been a lot of > change in the HAL daemon itself (which is in the gate, as linked > above). The hal package is rebuilt for OI. There have been many changes, with different revision numbers. For example, in the BE from 2020-11-27 where mounts work, the package is service/hal@0.5.11-2020.0.1.20171 . In the BE from 2021-05-14 where mounts do not work, the package is service/hal@0.5.11-2020.0.1.20514 . I assume the revision numbers do not indicate actual changes. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 11:50:31AM +0200, s...@pandora.be wrote: > I like the 2021.04 release of OI, this is a great piece of work, > and this release works well on my PC (thanks for the work on it). I like it too, especially the new Firefox. So far, I've only found one anomaly with it, and I have a workaround. It does work with web pages where previous versions would not. > Regarding the USB automount, I can personally live with the > workaround of manual mount. Automount would be nice so if it gets > fixed all the better. I use it periodically to transfer files from my main Unix system to another system that runs Windows 10. I know there are alternatives to USB sticks, but they are convenient. USB automount is useful to me. In both cases, it has taken me some time to notice problems with OI. Automated testing would not help much, because you have to know what a problem is, before you can design a test for it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sat, Jun 26, 2021 at 07:56:41AM +0200, s...@pandora.be wrote: > > Shouldn't 'eject' be listing those removable disks (they currently > do not for me). You can't eject USB sticks because there is no eject mechanism. Only CD and DVD drives have the mechanism. You have to remove USB sticks from the connector yourself. The best you can do is un-mount them first. That's adequate. > I'd expect something like > > # eject -l > /dev/dsk/c12t0d0p0:1 rmdisk,rmdisk0,USBSLACK,/media/USBSLACK > /dev/dsk/c1t0d0s2cdrom,cdrom0,cd,cd0,sr,sr0 Perhaps you are thinking of "rmumount -l"? You can also un-mount them from the desktop icon. > and > > # eject rmdisk > rmdisk /dev/dsk/c12t0d0p0:1 unmounted Notice that it un-mounted the device but didn't eject it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:
>
> It seems like it would be good to figure out, on the systems that _do_
> work, what exactly is performing the mount. Then we can work
> backwards to why that is no longer happening.
Good idea. I have a system running an older BE where the automount
does work. I did exactly what you suggested.
> I would probably do something like...
>
>
> $ pfexec dtrace -w -n '
> syscall::*mount*:entry {
> raise(SIGSTOP);
> system("pargs %d; ptree %d; prun %d", pid, pid, pid);
> }'
Here's the result. Probably because I ran it as root, the result was
a bit different from usual, but the mount did succeed.
# dtrace -w -n '
> syscall::*mount*:entry {
> raise(SIGSTOP);
> system("pargs %d; ptree %d; prun %d", pid, pid, pid);
> }'
dtrace: description '
syscall::*mount*:entry ' matched 2 probes
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
10 8968umount2:entry 3951:
/usr/lib/hal/hald-addon-storage
argv[0]: /usr/lib/hal/hald-addon-storage
1994 /usr/lib/hal/hald --daemon=yes
1995 hald-runner
3951 /usr/lib/hal/hald-addon-storage
11 8532 mount:entry 3955: mount -o nosuid
/dev/dsk/c4t0d0p0:1 /media/STORE N GO
argv[0]: pcfs_mount
argv[1]: -o
argv[2]: nosuid
argv[3]: /dev/dsk/c4t0d0p0:1
argv[4]: /media/STORE N GO
1994 /usr/lib/hal/hald --daemon=yes
1995 hald-runner
3954 /usr/lib/hal/hal-storage-mount
3955 mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
2 8532 mount:entry 3951:
/usr/lib/hal/hald-addon-storage
argv[0]: /usr/lib/hal/hald-addon-storage
1994 /usr/lib/hal/hald --daemon=yes
1995 hald-runner
3951 /usr/lib/hal/hald-addon-storage
^?
I pressed the interupt key at that point.
--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 25, 2021 at 08:45:10PM +0200, s...@pandora.be wrote: > > I can reproduce the problem; Knowing that helps a lot: I thought for a while that I was the only one. > When I plugin a USB key on my OI 2021.04 latest update system it > does not automount the volume; Yes, that's the same problem > cdrecord -scanbus shows the USB key controller.target.disk 5.0.0 so > from there it is also possible to deduce > root@wapper:~# mount -F pcfs /dev/dsk/c5t0d0p1 /mnt > > that works I used "fstyp" to find the right device name. > This is USB 2 key in a USB 3.2 port for me > > root@wapper:~# modinfo | grep xhci > 103 f7cef000 e8f0 251 1 xhci (USB xHCI Driver) I tried that too, also this: # mdb -ke '::prtusb' INDEX DRIVER INST NODE GEN VID.PID PRODUCT 1 xhci0 pci1043,8694 3.0 . No Product String 2 hid 3 mouse 1.1 045e.0040 Microsoft Wheel Mouse Optical� 3 usb_mid 1 device1.1 046d.c31c USB Keyboard 4 scsa2usb0 storage 2.0 13fe.3423 STORE N GO > There are also 2 USB 2 ports on my computer but that doesn't help > for automount either. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 06, 2021 at 09:49:58PM +0200, Andreas Wacknitz wrote: > > service/hal is delivered by illumos-gate Well, hal seemed to be a good lead, but turned out to be another dead end. Curiously, there seem to be many versions of the hal package in OI. The range is enormous. I wonder why there are so many? The ones in my recent BEs are service/hal@0.5.11-2020.0.1.20171 and service/hal@0.5.11-2020.0.1.20514 . At the moment, I've run out of leads. All that I know is that a BE dated 2021-05-15 has this problem but a BE dated 2020-11-27 does not have it. Of course, if you don't use USB sticks, and don't disconnect your USB mouse or keyboard, you will never experience the problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 06, 2021 at 11:06:06AM -0700, Alan Coopersmith wrote: > > hal monitors the devices and uses dbus to send messages to other programs > on certain events - like notifying the GNOME/Mate file manager when a new > removable media device is inserted or removed so they can show/hide it. So, I got it backwards. dbus is only a message bus or a rendevous point. It's hal that's likely responsible for ignoring changes to USB devices. I've already got ideas how to debug this problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 03:11:32PM -0500, Gary Mills wrote: > > Ah, I tried the first command on an OI system running the 2020-11-27 > BE and did get some output while I inserted and removed a USB stick: > > # lshal --monitor > > Start monitoring devicelist: > - > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.mount_point = '/media/STORE N GO' > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted_read_only = false (new) > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted = true > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.mount_point = '' > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted = false > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > removed > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 > removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 > removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed > I also tried "dbus-monitor --system" on the same system as I inserted and removed a USB stick. I got too much output to capture, but this is part of it: method call time=1622910378.194372 sender=:1.39 -> destination=org.freedesktop.Hal serial=555 path=/org/freedesktop/Hal/devices/pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1; interface=org.freedesktop.Hal.Device; member=GetAllProperties method return time=1622910378.194409 sender=:1.2 -> destination=:1.39 serial=867 reply_serial=555 array [ ... dict entry( string "org.freedesktop.Hal.Device.Volume.method_execpaths" variant array [ string "hal-storage-mount" string "hal-storage-unmount" string "hal-storage-eject" ] ) ... dict entry( string "volume.label" variant string "STORE N GO" ) ... dict entry( string "block.solaris.raw_device" variant string "/dev/rdsk/c4t0d0p0:1" ) dict entry( string "block.device" variant string "/dev/dsk/c4t0d0p0:1" ) ... Note that the "lshal" output shows the mount point as '/media/STORE N GO', but the "dbus" output only shows the device name. "/media" is the mount point used by the "rmvolmgr" daemon and the "rmmount" command. Something must have mounted the USB stick between those two services. I'm not familiar with this area of OI; I only know what I saw in the output cited above. However, something must have convinced "dbus" to send those messages when the USB stick was inserted. I don't know what is missing or changed in the current OI BE so that it seems to ignore USB devices. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 01:16:38PM -0500, Gary Mills wrote: > I tried both of those commands, and got no output. That was "lshal --monitor" and "dbus-monitor --system" on a recent BE. Both of those commands produced no output. I know they work because I tried both of them on another system that was booted back to an older BE. There, both of them produced copious output, just as the support document showed. > The insertion and > removal does appear in /var/adm/messages, but goes no further. Here's what I saw on insertion of a USB stick: Jun 5 16:52:03 z400 usba: [ID 912658 kern.info] USB 2.0 device (usb951,160b) operating at hi speed (USB 2.x) on USB 2.0 root hub: storage@6, scsa2usb3 at bus address 3 Jun 5 16:52:03 z400 usba: [ID 349649 kern.info] Kingston DataTraveler2.0 0805050224383 Jun 5 16:52:03 z400 genunix: [ID 936769 kern.info] scsa2usb3 is /pci@0,0/pci103c,1309@1a,7/storage@6 Jun 5 16:52:03 z400 genunix: [ID 408114 kern.info] /pci@0,0/pci103c,1309@1a,7/storage@6 (scsa2usb3) online Jun 5 16:52:03 z400 scsi: [ID 583861 kern.info] sd9 at scsa2usb3: target 0 lun 0 Jun 5 16:52:03 z400 genunix: [ID 936769 kern.info] sd9 is /pci@0,0/pci103c,1309@1a,7/storage@6/disk@0,0 Jun 5 16:52:03 z400 genunix: [ID 408114 kern.info] /pci@0,0/pci103c,1309@1a,7/storage@6/disk@0,0 (sd9) online Jun 5 16:52:03 z400 genunix: [ID 127566 kern.info] device pciclass,03@0(display#0) keeps up device sd@0,0(disk#9), but the former is not power managed Note that the messages show only "sd9" as the disk device name. This is the old-style name, one that is no longer used. /dev/sd9 does not exist. The "rmformat" command show the device name as: /dev/rdsk/c8t0d0p0 . It does exist, as does the block device: /dev/dsk/c8t0d0p0 . As far as I can tell, "dbus" sends messages to "hal" about the state of devices on the system. However, for insertion of USB sticks, this does not happen. I don't know why it doesn't happen. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: > I found a document that might help. It describes: > > lshal --monitor > dbus-monitor --system Ah, I tried the first command on an OI system running the 2020-11-27 BE and did get some output while I inserted and removed a USB stick: # lshal --monitor Start monitoring devicelist: - pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '/media/STORE N GO' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted_read_only = false (new) pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = true pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = false pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed This system did automount the USB stick and did pop up a window showing the contents of the stick. Now we are getting somewhere. Something is wrong with the OS upgrade. All that's left is to figure out what is missing or what is ignoring USB events. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: > I found a document that might help. It describes: > > lshal --monitor > dbus-monitor --system I tried both of those commands, and got no output. The insertion and removal does appear in /var/adm/messages, but goes no further. Is it possible that dbus is ignoring the USB messages? > which seem to be both clients. The document is at: > > https://www.suse.com/support/kb/doc/?id=16652 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Thu, Jun 03, 2021 at 01:30:43PM -0300, Till Wegmueller wrote: > > To understand which service might be affected by the problem, could you > check if one either hal or rmvolmgr produce informative output? I found a document that might help. It describes: lshal --monitor dbus-monitor --system which seem to be both clients. The document is at: https://www.suse.com/support/kb/doc/?id=16652 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Thu, Jun 03, 2021 at 01:30:43PM -0300, Till Wegmueller wrote: > > To understand which service might be affected by the problem, could you > check if one either hal or rmvolmgr produce informative output? How would I do that? I'm not familiar with either of those subsystems. I assume that the output would come from a client of those daemons. > Also another thing that might have changed is behaviour in the Mate > components in the UI that control the mounting. What do the GUI tools say > about mounting? Nothing, as far as I can tell. Are they supposed to? What tool or tools do you suggest? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] OI no longer automounts USB sticks
A couple of weeks ago, I upgraded my OI systems to the current version of OI. Everything seemed to work, although I didn't test everything. Yesterday, I inserted a USB stick into one of the systems, and was surprised that it didn't mount. It used to work. This event start me on an investigation. All of my USB sticks use a FAT32 filesystem and one FDISK partition. They all automount on Windows 10 and show no errors. On my test OI system, running the 2021-05-15 version of OI, they do not automount. A reboot did not help. The "fstyp" command for the :1 device shows a "pcfs" filesystem. I am able to mount and umount the device as root. It shows the correct content. When I booted the 2020-11-27 BE on that same system, the USB stick did automount. A window popped up showing the contents of the device. It also showed up in "mount | grep media". Another USB stick also automounted the same way. I conclude that something happened between those two versions of OI to prevent USB sticks from mounting. I don't know what changed or what is missing. Has anyone else seen the same problem? Automounting is complicated. These are three services that have to be operating properly for USB sticks to be automounted: $ svcs hal dbus rmvolmgr STATE STIMEFMRI online 20:54:09 svc:/system/dbus:default online 20:54:11 svc:/system/hal:default online 20:54:11 svc:/system/filesystem/rmvolmgr:default All three of them are online on all of my OI systems. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Upgrade of gdb to 8.0 and python 3.7
This message is just to inform the OI developers that I'm working on gdb now. It will be a version upgrade from 7.10.1 to 8.0 and a python upgrade from 2.7 to 3.7 . Gdb version 8.0 is the Oracle Solaris freeware version, used in the current Solaris. I know that the current gdb version is 10.2, but 8.0 comes with a set of patches that are known to work with Solaris, and will likely work with OI. Note that the gdb presently included with OI has 63 patches. I'm not about to review all of those. Version 8.0 has only eight patches. All of them seem to work. All I have to do before creating a PR is to do a bit of testing with the new gdb. The important thing is to remove the current dependancy on python-2, so we can get rid of that version of python. I also intend to try some more recent versions of gdb to see if they also work with the Solaris patches. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Moving on with postgresql
On Sat, Apr 17, 2021 at 04:46:06PM -0500, Gary Mills wrote: > OI currently has postgresql versions: 95 96 10 11 12 . The OI > default, in shared-macros.mk, is 95 . However, the postgresql > developers report that 95 is unsupported, but 13 is available and > supported. Something has to change in OI to move forward with > postgresql. Thanks to all who responded to my original message. Most people wanted to use modern versions of postgres, including 13, which is not packaged on OI. Nobody wanted to use 95, which is an unsupported version. Unfortunately, 95 is still needed by many OI packages, and cannot immediately be obsoleted. Given these wishes and constraints, here is my proposal for postgres packages in OI. I will change the default to 10 or 11, and upgrade 95 and 96 to new minor versions, and to python-3. After all, removing python-2 is the whole reason for the current round of package upgrades. The result of this proposal is that package database/postgres-95/library still exists, and that OI packages that require these libraries will still work. Because the postgres default has changed, some packages may no longer build. A short term fix for these is to add this statement to Makefile: PG_VERSION= 9.5 The proposal above is only the first step, but will get OI past the python version update. The next step for postgres will be to obsolete 95 and 96, and to add 13. People upgrading postgres will need to dump tables from the old version and load them in the new version, as suggested in the postgres manuals. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Moving on with postgresql
OI currently has postgresql versions: 95 96 10 11 12 . The OI default, in shared-macros.mk, is 95 . However, the postgresql developers report that 95 is unsupported, but 13 is available and supported. Something has to change in OI to move forward with postgresql. Here are some actions that could be taken with OI. We could change the default version to 10. I, myself, would prefer 11. We could obsolete 95. I'd prefer obsoleting 95 and 96. We could add version 13, but only after 96 is obsoleted. We should limit the number of postgresql versions in OI, after all. Finally, we could make no obsoletions or additions, retaining even the unsupported 95. Which would you prefer? I have not investigated two questions. Perhaps you can tell me? What are the consequences of obsoleting 95? What are the consequences of the default change? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Variable PATH in Makefile (tornado)
On Wed, Apr 14, 2021 at 12:40:17PM +0200, Nona Hansel wrote: > >I'm having some problems updating tornado. Currently, the PATH variable >in Makefile is defined in the older mode like this: > >PATH=/usr/bin:/usr/gnu/bin:/usr/sbin > >Like this, tornado builds, installs and publishes fine. > >When I change it to the newer mode: > >PATH=$(PATH.gnu) >It builds fine, but fails during gmake install with this message: The order of directories in the search path only matters if the commands have the same name, because the first one is found. `sed' does exist in both /usr/bin and /usr/gnu/bin, for example. `gsed', however, only exists in /usr/bin . Of course, a missing directory in the path will matter, because the command will not be found. Some Makefiles use `env -i', which deletes all environment variables, including useful ones like PATH . In that case, you need to reinstate PATH . -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Nvidia warning at reboot
Yesterday, I did an OI update on my development server to get /bin/ksh in a separate package. The update was successful as was the subsequent reboot. During the reboot, I got these console messages: /kernel/drv/amd64/nvidia_modeset: undefined symbol 'nvidia_get_rm_ops' WARNING: mod_load: cannot load module 'nvidia_modeset' WARNING: nvidia_modeset: unable to resolve dependency, module 'nvidia' not found Are these warnings now normal? The server does no have an nvidia video card. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
