Re: [PATCH 17/20] x86/tdx: Convert VM_RD/VM_WR tdcalls to use new TDCALL macros

[Dave Hansen]

Let's say you're debugging tdg_vm_rd().  You suspect someone read the
spec wrong.  You pull up the spec:

https://sr71.net/~dave/intel/tdg.vm.rd.png

On 5/17/24 07:19, Kirill A. Shutemov wrote:
>  static inline u64 tdg_vm_rd(u64 field, u64 *value)
>  {
> - struct tdx_module_args args = {
> - .rdx = field,
> - };

RDX is assigned 'field'.  Makes sense based on the input operands.

> - u64 ret;
> -
> - ret = __tdcall_ret(TDG_VM_RD, )> - *value = args.r8;

'value' is set to r8.  Also matches the spec.  It's obvious that this is
a 'two return values' pattern.

> - return ret;

This is also obviously correct.

Compare that to:

> + return TDCALL_1(TDG_VM_RD, 0, field, 0, 0, value);
>  }

Where it's 100% opaque which registers thing to into or that 'value' is
an output, not an input.

So, yeah, this is fewer lines of C code.  But it's *WAY* less
self-documenting.  It's harder to audit.  It's harder to understand and
it's more opaque.

While the goals here are laudable, I'm not a big fan of the end result.

Re: [PATCH 16/20] x86/tdx: Convert VP_INFO tdcall to use new TDCALL_5() macro

[Dave Hansen]

On 5/17/24 07:19, Kirill A. Shutemov wrote:
> - /*
> -  * TDINFO TDX module call is used to get the TD execution environment
> -  * information like GPA width, number of available vcpus, debug mode
> -  * information, etc. More details about the ABI can be found in TDX
> -  * Guest-Host-Communication Interface (GHCI), section 2.4.2 TDCALL
> -  * [TDG.VP.INFO].
> -  */
> - tdcall(TDG_VP_INFO, );
> + tdg_vp_info(_width, _attr);

Why is the comment going away?

Re: [PATCH 03/20] x86/tdx: Convert port I/O handling to use new TDVMCALL macros

[Dave Hansen]

On 5/17/24 07:19, Kirill A. Shutemov wrote:
>  static inline void tdx_io_out(int size, u16 port, u32 value)
>  {
> - struct tdx_module_args args = {
> - .r10 = TDX_HYPERCALL_STANDARD,
> - .r11 = hcall_func(EXIT_REASON_IO_INSTRUCTION),
> - .r12 = size,
> - .r13 = 1,
> - .r14 = port,
> - .r15 = value,
> - };
> -
> - __tdx_hypercall();
> + TDVMCALL_0(hcall_func(EXIT_REASON_IO_INSTRUCTION),
> +size, TDX_PORT_WRITE, port, value);
>  }

I actually really like the self-documenting nature of the structures.  I
don't think it's a win if this is where the lines-of-code savings comes
from.

Re: [PATCH 01/20] x86/tdx: Introduce tdvmcall_trampoline()

[Dave Hansen]

On 5/17/24 07:19, Kirill A. Shutemov wrote:
> TDCALL calls are centralized into a few megawrappers that take the
> struct tdx_module_args as input. Most of the call sites only use a few
> arguments, but they have to zero out unused fields in the structure to
> avoid data leaks to the VMM. This leads to the compiler generating
> inefficient code: dozens of instructions per call site to clear unused
> fields of the structure.

I agree that this is what the silly compiler does in practice.  But my
first preference for fixing it would just be an out-of-line memset() or
a pretty bare REP;MOV.

In other words, I think this as the foundational justification for the
rest of the series leaves a little to be desired.

Re: [PATCH 00/20] x86/tdx: Rewrite TDCALL wrappers

[Dave Hansen]

On 5/17/24 07:19, Kirill A. Shutemov wrote:
>  arch/x86/boot/compressed/tdx.c|  32 +---
>  arch/x86/coco/tdx/tdcall.S| 145 ++-
>  arch/x86/coco/tdx/tdx-shared.c|  26 +--
>  arch/x86/coco/tdx/tdx.c   | 298 --
>  arch/x86/hyperv/ivm.c |  33 +---
>  arch/x86/include/asm/shared/tdx.h | 159 +++-
>  arch/x86/include/asm/tdx.h|   2 +
>  arch/x86/virt/vmx/tdx/tdxcall.S   |  29 +--
>  tools/objtool/noreturns.h |   2 +-
>  9 files changed, 322 insertions(+), 404 deletions(-)

I was going to grumble about this being a waste of time, but it looks
like this gives smaller binaries and less code.  Looks promising so far!

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Dave Eckhardt]

> I confirmed the model was trained on 9front resources, including
> git history.

I looked quickly at the document but didn't see a statement that
it was machine-generated text or what the inputs were.  Though
"LLM ethics" are far from settled, I think at this stage it would
be good to state clearly and prominently, up front, that this is
machine-generated text, and to somewhere include information about
which LLM was used, trained on what, and with what sort of prompt.

As a separate matter, though I am not presently a 9front user, as
I quickly skimmed the document it didn't seem clearly accurate.
Is accuracy a goal?  If so, how will it be determined whether or
not that goal has been achieved?

Dave Eckhardt

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me5cc575537394d7a0803f2c0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[Bug 2065051] Re: [SRU] Migrate Pi users to KMS

[Dave Jones]

Verified with upgrade of a Pi 4 on an SD card as described in the test
plan, only variant being to grab the noble tar-ball manually (as do-
release-upgrade won't allow --proposed with --devel). Worked happily,
KMS was present in the config.txt after the upgrade, and the HDMI audio
outputs appeared correctly when the card was subsequently booted on a Pi
5.

** Tags removed: verification-needed-noble
** Tags added: verification-done-noble

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065051

Title:
  [SRU] Migrate Pi users to KMS

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2065051/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #11, bug #55154 (group groff):

[comment #10 comment #10:]
> Bizarrely, while it accepts the second translation, it doesn't
> actually honor it.

It gets worse: even .char fails at this.

$ cat char-test
.char b \~
abc cba\p
$ nroff char-test | cat -s
a c   c a

$ 

I presume this is due to this explanation in the Texinfo manual:

 -- Request: .char c ['"'][contents]
 Every time C is to be output, CONTENTS is processed in a temporary
environment and the result encapsulated in a node.

The temporary environment being unaware of the rest of the line, it can only
turn \~ into a node that is the width of an ordinary unbreakable space.

This is frustrating, because it means there is no way within groff to work
around bug #62300 (fixed in 1.23.0) for UTF-8 documents that need to work
under earlier preconvs.  Another tool has to preprocess the file before
preconv gets to it.  While everything here appears to be working as designed,
I'm tempted to open a new bug report anyway, because the design thwarts such a
seemingly straightforward way to handle pre-1.23 preconv output for the input
character U+00A0.

Hopefully I'm wrong about something above, and someone wiser will set me
straight.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH 1/2] drm/buddy: stop using PAGE_SIZE

[Dave Airlie]

On Thu, 29 Feb 2024 at 23:48, Arnd Bergmann  wrote:
>
> On Thu, Feb 29, 2024, at 11:51, Matthew Auld wrote:
> > The drm_buddy minimum page-size requirements should be distinct from the
> > CPU PAGE_SIZE. Only restriction is that the minimum page-size is at
> > least 4K.
> >
> > Signed-off-by: Matthew Auld 
> > Cc: Arunpravin Paneer Selvam 
> > Cc: Christian König 
> > Cc: Arnd Bergmann 
>
> Acked-by: Arnd Bergmann 

Has this landed anywhere yet?

I'm been testing 6.9 on 64K pages and the buddy tests are exploding so
I wanted to pull this in.

Dave.

Re: [git pull] drm urgent for 6.10-rc1

[Dave Airlie]

> >>
> >> (And that kernel version of "6.9.0-08295-gfd39ab3b5289" that is quoted
> >> in the WARN isn't some official kernel, I have about ten private
> >> patches that I keep testing in my tree, so if you wondered what the
> >> heck that git version is, it's not going to match anything you see,
> >> but the ~ten patches also aren't relevant to this).
> >>
> >> Nothing unusual in the config, although this is clang-built. Shouldn't
> >> matter, never has before.
> > Arun is investigating and trying to repro it.  You still have a
> > polaris based GPU right?
> We haven't been able to reproduce it across variety of GPU's. Would it
> please be possible
> to send your dmesg logs and kernel config, I will check this on the same
> GPU you are using.

I just installed my RX480 polaris card in my AMD test machine, and
with current origin/master
I'm not seeing this at all.

Running an F40 GNOME desktop, doing firefox etc.

Linus, do you see it a boot straight away?

Dave.

Multiline @cindex entries misrender in groff Texinfo manual

[Dave Kemper]

In a few places, the groff Texinfo manual uses a line-ending @ to
continue a @cindex entry.  An example is:

  @DefreqList {tm, message}
  @DefreqItemx {tm1, [@code{"}]message}
  @DefreqListEndx {tmc, [@code{"}]message}
  @cindex print to the standard error stream (@code{tm}, @code{tm1},@
  @code{tmc})
  @cindex standard error stream, write to (@code{tm}, @code{tm1},@
  @code{tmc})
  @cindex stream, standard error, write to (@code{tm}, @code{tm1},@
  @code{tmc})
  Send @var{message}, which consumes the remainder of the input line and

My version of makeinfo (texi2any (GNU texinfo) 6.7) doesn't render
this as desired:

  -- Request: .tm message
  -- Request: .tm1 ['"']message
  -- Request: .tmc ['"']message
  'tmc') 'tmc') 'tmc') Send MESSAGE, which consumes the remainder of
  the input line and ...

That is, the continued @code{} tags are being put into the output
rather than considered part of the index entry.

I don't know enough about the Texinfo language to know whether this is
a bug in our manual or in makeinfo.  Does this render correctly in
newer makeinfo versions?  makeinfo 6.7 is fairly old, but the groff
manual appears to require only 5.0 (as of commit 986d2a5b2, Apr 2020
(http://git.savannah.gnu.org/cgit/groff.git/commit/?id=986d2a5b2)).

[Dailydave] What a failure of Secure by Design looks like: Web Browsers

[Dave Aitel via Dailydave]

I know it's in vogue to pick on enterprise hardware marketed to "Secure
your OT Environment" but actually written in crayon in a language made of
all sharp edges like C or PHP, with some modules in Cobol for spice. This
is the "Critical Infrastructure" risk du jour, on a thousand podcasts and
panels, with *Volt Typhoon* in the canary seat, where once only the
"sophisticated threat" Mirai had root permissions.

As embarrassing as having random Iranian teenagers learn how to do systems
administration on random water plants in New Jersey is, it's *more*
humiliating to have systemic vulnerabilities right in front of you, have a
huge amount of government brain matter devoted to solving them, and yet not
make the obvious choice to turn off features that are bleeding us out.

And when you talk about market failure in Security you can't help but talk
about Web Browsers, both mobile and desktop. Web Browsing technology is in
everything - and includes a host of technologies too complicated to go
into, but one of the most interesting has been Just in Time compiling,
which got very popular as an exploitation technique (let's say) in 2010
<http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf> but
since then - for over a decade! - has been a bubbling septic font of
constant systemic, untreated risk.

Proponents of having a JIT in your Javascript compiler say "Without this
kind of performance, you wouldn't be able to have GMail or Expedia!" Which
is not true on today's hardware (Turn on Edge Strict Security mode today
and you won't even notice it), and almost certainly not true on much older
hardware. The issue with JITs is visible to any hacker who has looked at
the code - whenever you have concepts like "Negative Zero
<https://googleprojectzero.blogspot.com/2020/09/jitsploitation-one.html>"
that have to be gotten perfectly every time or else the attacker gets full
control of your computer, you are in an indefensible space.

I would, in a perfect world, like us to be able to get ahead of systemic
problems. We have a rallying cry and a lot of signatories on a pledge, but
we need to turn it into clicky clicking on the configuration options that
turn these things off on a USG and Enterprise level, the same way we banned
Russian antivirus from having Ring0 in our enterprises, or suspiciously
cheap subsidized Chinese telecom boxes from serving all the phone companies
across the midwest.

The issue with web browsers is not limited to JITs. A Secure By Design
approach to web browsing would mean that most sites would not have access
to large parts of the web browsing specification. We don't need to be
tracked by every website. They don't all need access to Geolocation or
Video or Web Assembly or any number of other parts of the things our web
browsers give them, largely in order to allow the mass production of
targeted advertising.

If we've learned anything in the last decade, it is that the key phrase in
Targeted Advertising is "Targeted", and malware authors have known this for
as long as the ecosystem existed. The reason your browser is insecure by
default is to support a parasitic advertising ecology, enhancing
shareholder value, but leaving our society defenceless against anyone
schooled enough in the dark arts.

Google's current solution to vulnerabilities in the browser is Yet Another
Sandbox. These work for a while until they don't - over time, digital
sandboxes get dirty and filled with secrets just like the one in your
backyard gets filled with presents from the local feral cat community. I
know Project Zero's Samuel Groß is better at browser hacking than I am, and
he personally designed the sandbox, but I look out across the landscape of
the Chinese hacking community and see only hungry vorpal blades and I do
not think it is a winning strategy.

-dave

References:

   1. Microsoft's Strict mode turns the JIT off (kudos to Johnathan Norman)
   
https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d
   2. The Sandbox: https://v8.dev/blog/sandbox
___
Dailydave mailing list -- dailydave@lists.aitelfoundation.org
To unsubscribe send an email to dailydave-le...@lists.aitelfoundation.org

Re: vmm guest does not get IP after upgrade to 7.5

[Dave Voutila]

Florian Obser  writes:

> On 2024-05-16 09:42 -04, Dave Voutila  wrote:
>> Johan Huldtgren  writes:
>>
>>> hello,
>>>
>>> On 2024-05-16  8:14, Dave Voutila wrote:
>>>>
>>>> Johan Huldtgren  writes:
>>> $ doas cat /etc/hostname.vio0
>>> inet autoconf
>>>
>>> # /bin/sh /etc/netstart vio0
>>> ifconfig: autoconf not allowed for this AF
>>>
>>
>> I don't understand why you're getting that error. I can confidently say
>> that if you can't use "inet autoconf" in /etc/hostname.vio0 then
>> something else is wrong with your guest.
>
> It's because of this:
>
>>>> >> > dmesg (guest):
>>>> >> >
>>>> >> > OpenBSD 6.4-current (GENERIC) #707: Mon Feb 18 01:21:51 MST 2019
>>>> >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Oh, well, that explains it. I missed that!

Re: vmm guest does not get IP after upgrade to 7.5

[Dave Voutila]

Johan Huldtgren  writes:

> hello,
>
> On 2024-05-16  8:14, Dave Voutila wrote:
>>
>> Johan Huldtgren  writes:
>>
>> > hello,
>> >
>> > On 2024-05-15 17:31, Dave Voutila wrote:
>> >>
>> >> Johan Huldtgren  writes:
>> >>
>> >> >> Synopsis:  vmm guest does not get IP after upgrade to 7.5
>> >> >> Category:  vmd
>> >> >> Environment:
>> >> > System  : OpenBSD 7.5
>> >> > Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 
>> >> > MDT 2024
>> >> >  
>> >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> >> >
>> >> > Architecture: OpenBSD.amd64
>> >> > Machine : amd64
>> >> >> Description:
>> >> > I recently upgraded one of my machines from 7.4 to 7.5, and noticed
>> >> > that the vmm guest I run on there wasn't getting an IP. I did
>> >> > some rudimentary tcpdumping on each side but nothing jumped out, I
>> >> > saw the dhcp request go out on the guest and I saw it being received
>> >> > on the host but that was it. Configuring the guest with a static IP
>> >> > resolves the issue, so the issue seems to be directly related to dhcp.
>> >> >
>> >> > The guest I'm running is quite old and cannot be upgraded, however it's
>> >> > been working fine as a guest for a long time and hasn't been changed.
>> >> >
>> >> > For completness sake I did try creating a switch stanza for bridge0
>> >> > and directing interface tap0 to use that, but it made no discernable
>> >> > difference.
>> >> >
>> >> > Relevant configs:
>> >> >
>> >> > # host (OpenBSD 7.5 + syspatches)
>> >> >
>> >> > $ doas cat /etc/vm.conf
>> >> > vm "guest.vm" {
>> >> > disk "/home/vm/guest.img"
>> >> > owner johan
>> >> > memory 4G
>> >> > local interface tap0
>> >>
>> >> Why are you using "local interface tap0" and then putting tap0 in a
>> >> bridge(4) with a trunk(4)? I'm not an networking person but that seems
>> >> odd to me.
>> >
>> > Entierly possible I'm doing this wrong. This is the only setup I have
>> > where I tried using local interface, everywhere else I define the switch
>> > so I probably just carried that part of the config over. I modified it
>> > to normalize my config so it's similar to all my others.
>> >
>> > $ doas cat /etc/vm.conf
>> >
>> > switch "uplink" {
>> > interface bridge0
>> > }
>> >
>> > vm "guest.vm" {
>> > disk "/home/vm/gallery.img"
>> > owner johan
>> > memory 3.5G
>> > interface tap0 {
>> > switch "uplink"
>> > }
>> > }
>> >
>> >> The major change in 7.5 is the emulated virtio network device is now
>> >> multi-threaded. If removing tap0 from your bridge doesn't fix it, can
>> >> you run vmd with debug logging and check the output for that particular
>> >> guests's vionet process?
>> >>
>> >> It will potentially be pretty chatty, but you should see messages about
>> >> dhcp packet interception and reply injection.
>> >>
>> >> # rcctl stop vmd
>> >> # $(which vmd) -dvv
>> >>
>> >> You might need to tweak the guest memory to 3.5G to get around memory
>> >> limits when running vmd in the foreground.
>> >
>> > # $(which vmd) -dvv
>> > vmd: startup
>> > vmd: /etc/vm.conf:11: switch "uplink" registered



>> > vm/guest.vm/vionet0: read_pipe_main: resetting virtio network device 0
>> > vm/guest.vm: vcpu_process_com_lcr: set baudrate = 115200
>> > vm/guest.vm: vcpu_exit_i8253_misc: counter 2 clear, returning 0x0
>> > vm/guest.vm: vcpu_exit_i8253_misc: discarding data written to PIT misc port
>> > vm/guest.vm: vcpu_exit_i8253_misc: counter 2 clear, returning 0x0
>> > vm/guest.vm: vcpu_exit_i8253_misc: discarding data written to PIT misc port
>> > vm/guest.vm: vcpu_exit_i8253_misc: counter 2 clear, returning 0x0
>>

Re: vmm guest does not get IP after upgrade to 7.5

[Dave Voutila]

Johan Huldtgren  writes:

> hello,
>
> On 2024-05-15 17:31, Dave Voutila wrote:
>>
>> Johan Huldtgren  writes:
>>
>> >> Synopsis: vmm guest does not get IP after upgrade to 7.5
>> >> Category: vmd
>> >> Environment:
>> >System  : OpenBSD 7.5
>> >Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
>> > 
>> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> >
>> >Architecture: OpenBSD.amd64
>> >Machine : amd64
>> >> Description:
>> > I recently upgraded one of my machines from 7.4 to 7.5, and noticed
>> > that the vmm guest I run on there wasn't getting an IP. I did
>> > some rudimentary tcpdumping on each side but nothing jumped out, I
>> > saw the dhcp request go out on the guest and I saw it being received
>> > on the host but that was it. Configuring the guest with a static IP
>> > resolves the issue, so the issue seems to be directly related to dhcp.
>> >
>> > The guest I'm running is quite old and cannot be upgraded, however it's
>> > been working fine as a guest for a long time and hasn't been changed.
>> >
>> > For completness sake I did try creating a switch stanza for bridge0
>> > and directing interface tap0 to use that, but it made no discernable
>> > difference.
>> >
>> > Relevant configs:
>> >
>> > # host (OpenBSD 7.5 + syspatches)
>> >
>> > $ doas cat /etc/vm.conf
>> > vm "guest.vm" {
>> > disk "/home/vm/guest.img"
>> > owner johan
>> > memory 4G
>> > local interface tap0
>>
>> Why are you using "local interface tap0" and then putting tap0 in a
>> bridge(4) with a trunk(4)? I'm not an networking person but that seems
>> odd to me.
>
> Entierly possible I'm doing this wrong. This is the only setup I have
> where I tried using local interface, everywhere else I define the switch
> so I probably just carried that part of the config over. I modified it
> to normalize my config so it's similar to all my others.
>
> $ doas cat /etc/vm.conf
>
> switch "uplink" {
> interface bridge0
> }
>
> vm "guest.vm" {
> disk "/home/vm/gallery.img"
> owner johan
> memory 3.5G
> interface tap0 {
> switch "uplink"
> }
> }
>
>> The major change in 7.5 is the emulated virtio network device is now
>> multi-threaded. If removing tap0 from your bridge doesn't fix it, can
>> you run vmd with debug logging and check the output for that particular
>> guests's vionet process?
>>
>> It will potentially be pretty chatty, but you should see messages about
>> dhcp packet interception and reply injection.
>>
>> # rcctl stop vmd
>> # $(which vmd) -dvv
>>
>> You might need to tweak the guest memory to 3.5G to get around memory
>> limits when running vmd in the foreground.
>
> # $(which vmd) -dvv
> vmd: startup
> vmd: /etc/vm.conf:11: switch "uplink" registered
> vmd: vm_register: registering vm 1
> vmd: /etc/vm.conf:27: vm "guest.vm" registered (enabled)
> warning: macro 'sets' not used
> vmd: vm_priv_brconfig: interface bridge0 description switch1-uplink
> vmd: vmd_configure: setting staggered start configuration to parallelism: 4 
> and delay: 30
> vmd: vmd_configure: starting vms in staggered fashion
> vmd: start_vm_batch: starting batch of 4 vms
> vmd: vm_opentty: vm guest.vm tty /dev/ttyp0 uid 1000 gid 4 mode 620
> vmd: start_vm_batch: done starting vms
> vmm: config_getconfig: vmm retrieving config
> vmm: vm_register: registering vm 1
> priv: config_getconfig: priv retrieving config
> control: config_getconfig: control retrieving config
> agentx: config_getconfig: agentx retrieving config
> vmd: vm_priv_ifconfig: interface tap0 description vm1-if0-guest.vm
> vmd: vm_priv_ifconfig: switch "uplink" interface bridge0 add tap0
> vmd: started guest.vm (vm 1) successfully, tty /dev/ttyp0
> vm/guest.vm: loadfile_bios: loaded BIOS image
> vm/guest.vm: pic_set_elcr: setting level triggered mode for irq 3
> vm/guest.vm: pic_set_elcr: setting level triggered mode for irq 5
> vm/guest.vm: virtio_init: vm "guest.vm" vio0 lladdr fe:e1:bb:d1:ae:e3
> vm/guest.vm: pic_set_elcr: setting level triggered mode for irq 6
> vm/guest.vm: guest.vm: launching vioblk0
> vm/guest.vm: virtio_dev_launch: sending 'd' type device struct
> vm/guest.vm: virtio_dev_

Re: Regarding feature #6841

[Dave Page]

On Wed, 15 May 2024 at 12:33, Anil Sahoo 
wrote:

> Hi Team,
>
> I have implemented the Execute query feature and tested it with different
> kinds of test cases.
>
> FYI the PostgreSQL Do block does not work as a single statement when we
> put the cursor inside the block at different positions.
>
> The cursor position is mentioned using pipe('|') and underlined query is
> the active query that will run on click of Execute query button.
>
> I have attached some screenshots for reference.
>
> Please let me know if you have any questions.
>

That is exactly the sort of behaviour I was afraid of :-(. At least we have
safeguards in place to minimise the chances of the user running something
unexpected.

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
EDB: https://www.enterprisedb.com

[git pull] drm urgent for 6.10-rc1

[Dave Airlie]

Hi Linus,

Here is the buddy allocator fix I picked up from the list, please apply.

Dave.

drm-next-2024-05-16:
drm urgent for 6.10-rc1 merge:

buddy:
- fix breakage in buddy allocator.
The following changes since commit 275654c02f0ba09d409c36d71dc238e470741e30:

  Merge tag 'drm-xe-next-fixes-2024-05-09-1' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next (2024-05-10
12:41:34 +1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-05-16

for you to fetch changes up to 431c590c3ab0469dfedad3a832fe73556396ee52:

  drm/tests: Add a unit test for range bias allocation (2024-05-16
12:50:14 +1000)


drm urgent for 6.10-rc1 merge:

buddy:
- fix breakage in buddy allocator.


Arunpravin Paneer Selvam (2):
  drm/buddy: Fix the range bias clear memory allocation issue
  drm/tests: Add a unit test for range bias allocation

 drivers/gpu/drm/drm_buddy.c|  3 ++-
 drivers/gpu/drm/tests/drm_buddy_test.c | 36 +-
 2 files changed, 37 insertions(+), 2 deletions(-)

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 10:06, Dave Airlie  wrote:
>
> On Thu, 16 May 2024 at 09:50, Dave Airlie  wrote:
> >
> > On Thu, 16 May 2024 at 06:29, Linus Torvalds
> >  wrote:
> > >
> > > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> > >  wrote:
> > > >
> > > > I have to revert both
> > > >
> > > >   a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > > >   e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> > > >
> > > > to make things build cleanly. Next step: see if it boots and fixes the
> > > > problem for me.
> > >
> > > Well, perhaps not surprisingly, the WARN_ON() no longer triggers with
> > > this, and everything looks fine.
> > >
> > > Let's see if the machine ends up being stable now. It took several
> > > hours for the "scary messages" state to turn into the "hung machine"
> > > state, so they *could* have been independent issues, but it seems a
> > > bit unlikely.
> >
> > I think that should be fine to do for now.
> >
> > I think it is also fine to do like I've attached, but I'm not sure if
> > I'd take that chance.
>
> Scrap that idea, doesn't die, but it makes my system unhappy, like
> fbdev missing,
>
> so for quickest path forward, just make the two reverts seems best.
>
> I've reproduced it here, so I'll track it down,

https://lore.kernel.org/amd-gfx/20240514145636.16253-1-arunpravin.paneersel...@amd.com/T/#t

This patch seems to fix it for me, I might just pull it into my tree
and send it to you.

Dave.

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 09:50, Dave Airlie  wrote:
>
> On Thu, 16 May 2024 at 06:29, Linus Torvalds
>  wrote:
> >
> > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> >  wrote:
> > >
> > > I have to revert both
> > >
> > >   a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > >   e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> > >
> > > to make things build cleanly. Next step: see if it boots and fixes the
> > > problem for me.
> >
> > Well, perhaps not surprisingly, the WARN_ON() no longer triggers with
> > this, and everything looks fine.
> >
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> I think that should be fine to do for now.
>
> I think it is also fine to do like I've attached, but I'm not sure if
> I'd take that chance.

Scrap that idea, doesn't die, but it makes my system unhappy, like
fbdev missing,

so for quickest path forward, just make the two reverts seems best.

I've reproduced it here, so I'll track it down,

Dave.

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 06:29, Linus Torvalds
 wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
>  wrote:
> >
> > I have to revert both
> >
> >   a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> >   e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to make things build cleanly. Next step: see if it boots and fixes the
> > problem for me.
>
> Well, perhaps not surprisingly, the WARN_ON() no longer triggers with
> this, and everything looks fine.
>
> Let's see if the machine ends up being stable now. It took several
> hours for the "scary messages" state to turn into the "hung machine"
> state, so they *could* have been independent issues, but it seems a
> bit unlikely.

This worries me actually, it's possible this warn could cause a
problem, but I'm not convinced it should have machine ending
properties without some sort of different error at the end, so I'd
keep an eye open here.

Dave.

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 06:29, Linus Torvalds
 wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
>  wrote:
> >
> > I have to revert both
> >
> >   a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> >   e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to make things build cleanly. Next step: see if it boots and fixes the
> > problem for me.
>
> Well, perhaps not surprisingly, the WARN_ON() no longer triggers with
> this, and everything looks fine.
>
> Let's see if the machine ends up being stable now. It took several
> hours for the "scary messages" state to turn into the "hung machine"
> state, so they *could* have been independent issues, but it seems a
> bit unlikely.

I think that should be fine to do for now.

I think it is also fine to do like I've attached, but I'm not sure if
I'd take that chance.

Two questions for Arunpravin (and Alex):

Is this fix correct, and can we get a good explanation of it?

Where did this error sneak in? Is the problem in the amdgpu tree, or
was it a drm-next only problem? If so perhaps we need to discuss
moving amdgpu more into drm-tip to catch this sort of problem.

Dave.
From 085b89278f296c40e86f5d1e1bcc1017c39f4002 Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Thu, 16 May 2024 09:46:37 +1000
Subject: [PATCH] drm/buddy: convert WARN_ON to an if + continue

This WARN_ON triggers a lot, but I don't think the __force_merge
path always has to succeed, so just return a failure here instead
of warn on to let other paths handle the allocation.

(Not 100% sure on this patch - airlied).
---
 drivers/gpu/drm/drm_buddy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 284ebae71cc4..6b90ec6eefa8 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -195,8 +195,9 @@ static int __force_merge(struct drm_buddy *mm,
 			if (!drm_buddy_block_is_free(buddy))
 continue;
 
-			WARN_ON(drm_buddy_block_is_clear(block) ==
-drm_buddy_block_is_clear(buddy));
+			if (drm_buddy_block_is_clear(block) !=
+			drm_buddy_block_is_clear(buddy))
+continue;
 
 			/*
 			 * If the prev block is same as buddy, don't access the
-- 
2.44.0

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 08:56, Linus Torvalds
 wrote:
>
> On Wed, 15 May 2024 at 15:45, Dave Airlie  wrote:
> >
> >   The drm subsystem enables more warnings than the kernel default, 
> > so
> >   this config option is disabled by default.
>
> Irrelevant.
>
> If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
> sets CONFIG_DRM_WERROR or not. It's a no-op. It's pointless.
>
> And that means that it's also entirely pointless to ask. It's only annoying.
>
> > depends on DRM && EXPERT
> >
> > so we aren't throwing it at random users.
>
> Yes you are.
>
> Because - rightly or wrongly - distros enable EXPERT by default. At
> least Fedora does. So any user that starts from a distro config will
> have EXPERT enabled.
>
> > should we rename it CONFIG_DRM_WERROR_MORE or something?
>
> Renaming does nothing. If it's pointless, it's pointless even if it's renamed.
>
> It needs to have a
>
>depends on !WERROR
>
> because if WERROR is already true, then it's stupid and wrong to ask AGAIN.
>
> To summarize: if the main WERROR is enabled, then the DRM tree is
> *ALREADY* built with WERROR. Asking for DRM_WERROR is wrong.
>
> I keep harping on bad config variables because our kernel config thing
> is already much too messy and is by far the most difficult part of
> building your own kernel.
>
> Everything else is literally just "make" followed by "make
> modules_install" and "make install". Very straightforward.
>
> But doing a kernel config? Nasty. And made nastier by bad and
> nonsensical questions.

It's also possible it's just that hey there's a few others in the tree

KVM_WERROR not tied to it
PPC_WERROR (why does CXL uses this?)
AMDGPU, I915 and XE all have !COMPILE_TEST on their variants

We should probably add !WERROR to all of these at this point.

Adding Jani who was the initial author of

commit f89632a9e5fa6c4787c14458cd42a9ef42025434
Author: Jani Nikula 
Date:   Tue Mar 5 11:07:36 2024 +0200

drm: Add CONFIG_DRM_WERROR

where I see we actually removed the !COMPILE_TEST check in v2.

Dave.

[users@httpd] Redirecting based on IP

[Dave Wreski]

Hi,

Google insists that one of our staging sites needs to be indexed despite 
"disallow" in robots.txt and a half-dozen other methods for preventing 
Google from indexing it (including submitting it for removal from their 
index). The staging site is even protected with a RequireAll statement 
for the DocumentRoot based on the IP, which then results in a 404 and 
other errors in GSC. This impacts our SEO and also causes GSC to stop 
processing the rest of our site.


The next steps I'd like to do is to redirect anyone not in that 
RequireAll statement to be redirected to the production site. Is this 
possible? Perhaps a RewriteCond that depends upon certain IPs, then 
otherwise redirects to the production site?


Thanks,
Dave

Re: [git pull] drm for 6.10-rc1

[Dave Airlie]

On Thu, 16 May 2024 at 06:43, Linus Torvalds
 wrote:
>
> On Tue, 14 May 2024 at 23:21, Dave Airlie  wrote:
> >
> > This is the main pull request for the drm subsystems for 6.10.
>
> .. and now that I look more at this pull request, I find other things wrong.
>
> Why is the DRM code asking if I want to enable -Werror? I have Werror
> enabled *already*.
>
> I hate stupid config questions. They only confuse users.
>
> If the global WERROR config is enabled, then the DRM config certainly
> shouldn't ask whether you want even more -Werror. It does nothing but
> annoy people.
>
> And no, we are not going to have subsystems that can *weaken* the
> existing CONFIG_WERROR. Happily, that doesn't seem to be what the DRM
> code wants to do, it just wants to add -Werror, but as mentioned, its'
> crazy to do that when we already have it globally enabled.
>
> Now, it might make more sense to ask if you want -Wextra. A lot of
> those warnings are bogus.

The help says:

  The drm subsystem enables more warnings than the kernel default, so
  this config option is disabled by default.

It's also

depends on DRM && EXPERT

so we aren't throwing it at random users.

should we rename it CONFIG_DRM_WERROR_MORE or something?

Dave.

Re: [PATCH 0/8] drm/i915/pciids: PCI ID macro cleanups

[Dave Hansen]

On 5/15/24 07:25, Jani Nikula wrote:
> No reply from Bjorn, Cc: the x86 maintainers and list, could I get an
> ack from you please?

x86 is just a consumer of the drm/i915_pciids.h macros.  The name change
is perfectly fine with me.  No objections.  But I really don't think you
need our acks to move forward.

Either way:

Acked-by: Dave Hansen  # for x86

Re: vmm guest does not get IP after upgrade to 7.5

[Dave Voutila]

Johan Huldtgren  writes:

>> Synopsis:vmm guest does not get IP after upgrade to 7.5
>> Category:vmd
>> Environment:
>   System  : OpenBSD 7.5
>   Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>   Architecture: OpenBSD.amd64
>   Machine : amd64
>> Description:
> I recently upgraded one of my machines from 7.4 to 7.5, and noticed
> that the vmm guest I run on there wasn't getting an IP. I did
> some rudimentary tcpdumping on each side but nothing jumped out, I
> saw the dhcp request go out on the guest and I saw it being received
> on the host but that was it. Configuring the guest with a static IP
> resolves the issue, so the issue seems to be directly related to dhcp.
>
> The guest I'm running is quite old and cannot be upgraded, however it's
> been working fine as a guest for a long time and hasn't been changed.
>
> For completness sake I did try creating a switch stanza for bridge0
> and directing interface tap0 to use that, but it made no discernable
> difference.
>
> Relevant configs:
>
> # host (OpenBSD 7.5 + syspatches)
>
> $ doas cat /etc/vm.conf
> vm "guest.vm" {
> disk "/home/vm/guest.img"
> owner johan
> memory 4G
> local interface tap0

Why are you using "local interface tap0" and then putting tap0 in a
bridge(4) with a trunk(4)? I'm not an networking person but that seems
odd to me.

The major change in 7.5 is the emulated virtio network device is now
multi-threaded. If removing tap0 from your bridge doesn't fix it, can
you run vmd with debug logging and check the output for that particular
guests's vionet process?

It will potentially be pretty chatty, but you should see messages about
dhcp packet interception and reply injection.

# rcctl stop vmd
# $(which vmd) -dvv

You might need to tweak the guest memory to 3.5G to get around memory
limits when running vmd in the foreground.

> }
>
> $ doas cat /etc/hostname.tap0
> up
>
> $ doas cat /etc/hostname.bridge0
> add trunk0
> add tap0
>
> $ doas ifconfig tap0
> tap0: flags=8943 mtu 1500
> lladdr fe:e1:ba:d0:78:97
> description: vm1-if0-guest.vm
> index 6 priority 0 llprio 3
> groups: tap
> status: active
> inet 100.64.1.2 netmask 0xfffe
>
> $ doas ifconfig bridge0
> bridge0: flags=41 mtu 1500
> description: switch1-uplink
> index 5 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> designated: id 00:00:00:00:00:00 priority 0
> tap0 flags=3
> port 6 ifpriority 0 ifcost 0
> trunk0 flags=3
> port 8 ifpriority 0 ifcost 0
> Addresses (max cache: 100, timeout: 240):
> fe:e1:bb:d1:d2:bb tap0 1 flags=0<>
> 64:9e:f3:ec:fc:7f trunk0 1 flags=0<>
>
> # guest (OpenBSD 6.4)
>
> $ doas cat /etc/hostname.vio0
> dhcp
>
> $ doas ifconfig vio0
> vio0: flags=8b43 mtu 
> 1500
> lladdr fe:e1:bb:d1:7d:0d
> index 1 priority 0 llprio 3
> media: Ethernet autoselect
> status: active
>
> Example tcpdump on guest (limited it to the dhcp requests, there are also 
> lots of "icmp6:neighbor sol: who has" messages)
>
> May 14 18:37:51.132856 fe:e1:bb:d1:7d:0d ff:ff:ff:ff:ff:ff 0800 342: 
> 0.0.0.0.68 > 255.255.255.255.67:  xid:0x1f15c47d secs:14 vend-rfc1048 
> DHCP:DISCOVER HN:"guest" PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP 
> CID:1.254.225.187.209.125.13 [tos 0x10]
> May 14 18:38:17.202879 fe:e1:bb:d1:7d:0d ff:ff:ff:ff:ff:ff 0800 342: 
> 0.0.0.0.68 > 255.255.255.255.67:  xid:0x876492de vend-rfc1048 DHCP:DISCOVER 
> HN:"guest" PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP 
> CID:1.254.225.187.209.125.13 [tos 0x10]
> May 14 18:38:19.212820 fe:e1:bb:d1:7d:0d ff:ff:ff:ff:ff:ff 0800 342: 
> 0.0.0.0.68 > 255.255.255.255.67:  xid:0x876492de secs:2 vend-rfc1048 
> DHCP:DISCOVER HN:"guest" PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP 
> CID:1.254.225.187.209.125.13 [tos 0x10]
> May 14 18:38:21.222848 fe:e1:bb:d1:7d:0d ff:ff:ff:ff:ff:ff 0800 342: 
> 0.0.0.0.68 > 255.255.255.255.67:  xid:0x876492de secs:4 vend-rfc1048 
> DHCP:DISCOVER HN:"guest" PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP 
> CID:1.254.225.187.209.125.13 [tos 0x10]
> May 14 18:38:25.222831 fe:e1:bb:d1:7d:0d ff:ff:ff:ff:ff:ff 0800 342: 
> 0.0.0.0.68 > 255.255.255.255.67:  xid:0x876492de secs:8 vend-rfc1048 
> DHCP:DISCOVER HN:"guest" PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP 
> CID:1.254.225.187.209.125.13 [tos 0x10]
>
> On the host we see it received
>
> May 14 18:10:21.073328 rule 189/(match) pass out on trunk0: 0.0.0.0.68 > 
> 255.255.255.255.67:  xid:0x34bf962a secs:4 [|bootp] [tos 0x10]
> May 14 18:10:41.073407 rule 183/(match) pass in on tap0: 0.0.0.0.68 > 
> 255.255.255.255.67:  xid:0x34bf962a secs:24 [|bootp] [tos 0x10]
>
>> How-To-Repeat:
>   Try to get an IP with  dhcp on an 

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione updated 
https://github.com/llvm/llvm-project/pull/91868

>From 30a36018b9c96d7ddd969815ef850987d781338e Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 30 Apr 2024 10:45:10 -0700
Subject: [PATCH 1/4] [lldb] Support custom LLVM formatting for variables
 (#81196)

Adds support for applying LLVM formatting to variables.

The reason for this is to support cases such as the following.

Let's say you have two separate bytes that you want to print as a
combined hex value. Consider the following summary string:

```
${var.byte1%x}${var.byte2%x}
```

The output of this will be: `0x120x34`. That is, a `0x` prefix is
unconditionally applied to each byte. This is unlike printf formatting
where you must include the `0x` yourself.

Currently, there's no way to do this with summary strings, instead
you'll need a summary provider in python or c++.

This change introduces formatting support using LLVM's formatter system.
This allows users to achieve the desired custom formatting using:

```
${var.byte1:x-}${var.byte2:x-}
```

Here, each variable is suffixed with `:x-`. This is passed to the LLVM
formatter as `{0:x-}`. For integer values, `x` declares the output as
hex, and `-` declares that no `0x` prefix is to be used. Further, one
could write:

```
${var.byte1:x-2}${var.byte2:x-2}
```

Where the added `2` results in these bytes being written with a minimum
of 2 digits.

An alternative considered was to add a new format specifier that would
print hex values without the `0x` prefix. The reason that approach was
not taken is because in addition to forcing a `0x` prefix, hex values
are also forced to use leading zeros. This approach lets the user have
full control over formatting.
---
 lldb/docs/use/variable.rst|  9 +++
 lldb/source/Core/FormatEntity.cpp | 70 ---
 .../custom-printf-summary/Makefile|  2 +
 .../TestCustomSummaryLLVMFormat.py| 20 ++
 .../custom-printf-summary/main.c  | 13 
 5 files changed, 104 insertions(+), 10 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomSummaryLLVMFormat.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c

diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index 8eaed6405315b..e9175b25336ba 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -460,6 +460,15 @@ summary strings, regardless of the format they have 
applied to their types. To
 do that, you can use %format inside an expression path, as in ${var.x->x%u},
 which would display the value of x as an unsigned integer.
 
+Additionally, custom output can be achieved by using an LLVM format string,
+commencing with the ``:`` marker. To illustrate, compare ``${var.byte%x}`` and
+``${var.byte:x-}``. The former uses lldb's builtin hex formatting (``x``),
+which unconditionally inserts a ``0x`` prefix, and also zero pads the value to
+match the size of the type. The latter uses ``llvm::formatv`` formatting
+(``:x-``), and will print only the hex value, with no ``0x`` prefix, and no
+padding. This raw control is useful when composing multiple pieces into a
+larger whole.
+
 You can also use some other special format markers, not available for formats
 themselves, but which carry a special meaning when used in this context:
 
diff --git a/lldb/source/Core/FormatEntity.cpp 
b/lldb/source/Core/FormatEntity.cpp
index ba62e26252591..da5b1cfce74ac 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -57,6 +57,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/Regex.h"
 #include "llvm/TargetParser/Triple.h"
 
 #include 
@@ -658,6 +659,38 @@ static char ConvertValueObjectStyleToChar(
   return '\0';
 }
 
+static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d", 
llvm::Regex::IgnoreCase};
+
+static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
+ValueObject ) {
+  std::string formatted;
+  std::string llvm_format = ("{0:" + options + "}").str();
+
+  // Options supported by format_provider for integral arithmetic types.
+  // See table in FormatProviders.h.
+
+  auto type_info = valobj.GetTypeInfo();
+  if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {
+if (type_info & eTypeIsSigned) {
+  bool success = false;
+  int64_t integer = valobj.GetValueAsSigned(0, );
+  if (success)
+formatted = llvm::formatv(llvm_format.data(), integer);
+} else {
+  bool success = false;
+  uint64_t integer = valobj.GetValueAsUnsigned(0, );
+  if (success)
+formatted =

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione updated 
https://github.com/llvm/llvm-project/pull/91868

>From 30a36018b9c96d7ddd969815ef850987d781338e Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 30 Apr 2024 10:45:10 -0700
Subject: [PATCH 1/3] [lldb] Support custom LLVM formatting for variables
 (#81196)

Adds support for applying LLVM formatting to variables.

The reason for this is to support cases such as the following.

Let's say you have two separate bytes that you want to print as a
combined hex value. Consider the following summary string:

```
${var.byte1%x}${var.byte2%x}
```

The output of this will be: `0x120x34`. That is, a `0x` prefix is
unconditionally applied to each byte. This is unlike printf formatting
where you must include the `0x` yourself.

Currently, there's no way to do this with summary strings, instead
you'll need a summary provider in python or c++.

This change introduces formatting support using LLVM's formatter system.
This allows users to achieve the desired custom formatting using:

```
${var.byte1:x-}${var.byte2:x-}
```

Here, each variable is suffixed with `:x-`. This is passed to the LLVM
formatter as `{0:x-}`. For integer values, `x` declares the output as
hex, and `-` declares that no `0x` prefix is to be used. Further, one
could write:

```
${var.byte1:x-2}${var.byte2:x-2}
```

Where the added `2` results in these bytes being written with a minimum
of 2 digits.

An alternative considered was to add a new format specifier that would
print hex values without the `0x` prefix. The reason that approach was
not taken is because in addition to forcing a `0x` prefix, hex values
are also forced to use leading zeros. This approach lets the user have
full control over formatting.
---
 lldb/docs/use/variable.rst|  9 +++
 lldb/source/Core/FormatEntity.cpp | 70 ---
 .../custom-printf-summary/Makefile|  2 +
 .../TestCustomSummaryLLVMFormat.py| 20 ++
 .../custom-printf-summary/main.c  | 13 
 5 files changed, 104 insertions(+), 10 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomSummaryLLVMFormat.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c

diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index 8eaed6405315b..e9175b25336ba 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -460,6 +460,15 @@ summary strings, regardless of the format they have 
applied to their types. To
 do that, you can use %format inside an expression path, as in ${var.x->x%u},
 which would display the value of x as an unsigned integer.
 
+Additionally, custom output can be achieved by using an LLVM format string,
+commencing with the ``:`` marker. To illustrate, compare ``${var.byte%x}`` and
+``${var.byte:x-}``. The former uses lldb's builtin hex formatting (``x``),
+which unconditionally inserts a ``0x`` prefix, and also zero pads the value to
+match the size of the type. The latter uses ``llvm::formatv`` formatting
+(``:x-``), and will print only the hex value, with no ``0x`` prefix, and no
+padding. This raw control is useful when composing multiple pieces into a
+larger whole.
+
 You can also use some other special format markers, not available for formats
 themselves, but which carry a special meaning when used in this context:
 
diff --git a/lldb/source/Core/FormatEntity.cpp 
b/lldb/source/Core/FormatEntity.cpp
index ba62e26252591..da5b1cfce74ac 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -57,6 +57,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/Regex.h"
 #include "llvm/TargetParser/Triple.h"
 
 #include 
@@ -658,6 +659,38 @@ static char ConvertValueObjectStyleToChar(
   return '\0';
 }
 
+static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d", 
llvm::Regex::IgnoreCase};
+
+static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
+ValueObject ) {
+  std::string formatted;
+  std::string llvm_format = ("{0:" + options + "}").str();
+
+  // Options supported by format_provider for integral arithmetic types.
+  // See table in FormatProviders.h.
+
+  auto type_info = valobj.GetTypeInfo();
+  if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {
+if (type_info & eTypeIsSigned) {
+  bool success = false;
+  int64_t integer = valobj.GetValueAsSigned(0, );
+  if (success)
+formatted = llvm::formatv(llvm_format.data(), integer);
+} else {
+  bool success = false;
+  uint64_t integer = valobj.GetValueAsUnsigned(0, );
+  if (success)
+formatted =

Re: [QUESTION] KIE - NPM package names

[Dave Fisher]

Here’s my 2 cents.

Incubation is a journey, and if there are parts that are yet to be compliant 
that should be fine. In the end all will be squared away.

For the IPMC - should we have something like DISCLAIMER-WIP for binary 
convenience packaging?

Best,
Dave

> On May 15, 2024, at 1:13 PM, Tiago Bento  wrote:
> 
> Tison,
> 
> Thanks for the reply!
> 
> On Wed, May 15, 2024 at 1:43 PM tison  <mailto:wander4...@gmail.com>> wrote:
>> 
>> We have an official account on NPM [1] and the associated org [2] (cc @Mark
>> Thomas  IIRC who manages this account).
>> 
>> [1] https://www.npmjs.com/~theasf
>> [2] https://www.npmjs.com/org/apache
>> 
>> Both of these associations can improve the verification and brand for your
>> release, while you may use the @apache scope in your package's name to
>> replace the handy apache- prefix that isn't endorsed by NPM's mechanism.
>> 
>> For the name and branding topic, I would suggest (in priority):
>> 
>> 1. State your display name as Apache KIE™ (incubating) on the release page
>> (README).
> Ok.
> 
>> 2. Build an association with our official NPM organization, following NPM's
>> mechanism.
> How? Every package we ever published to NPM under KIE is owned by
> https://www.npmjs.com/~kie-tools-bot <https://www.npmjs.com/~kie-tools-bot> 
> now (some of them were
> removed/renamed). We can give control to the ~theasf user, no problem.
> 
>> 3. Change your package name (handle) to @apache/kie-xxx.
> This is what I'd like to avoid, as it's going to be major work on our
> side due to the number of packages we have, delaying our release even
> more... I see OpenDAL has some packages published under the `opendal`
> and `@opendal/*` names, which is kind of analogous to what we'd have
> without renaming. Of course we can move everything to @apache/kie-* or
> @apache-kie/* to comply with the guidelines and requirements, but if
> this could be postponed to the next release, it would be great.
>> 
>> As for the VS Code Extensions, I'm unfamiliar with this scope, but it seems
>> there are other names like "kogito". What are the relations between them
>> and KIE?
> Drools, jBPM, SonataFlow, OptaPlanner, Kogito, and Tools are all
> components inside KIE. All KIE VS Code Extensions are already
> published under these names I listed. Renaming it would mean
> essentially creating new extensions, without any relationship to the
> old ones whatsoever. Example:
> https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension
>  
> <https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension>
> 
>> 
>> As for the WebJar, I'm unfamiliar with this scope also. And I don't find an
>> entry called sonataflow-deployment-webapp on the page you linked.
> If you type "sonataflow" in the search input at the right-hand-side
> you'll see that a JAR was published based on the NPM package. See
> https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp
>  
> <https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp>
> 
>> 
>> The official name of an ASF project is always Apache Foo [3], and we should
>> use this name when possible.
> Ok.
> 
>> 
>> [3] https://www.apache.org/foundation/marks/guide
>> 
>> Best,
>> tison.
>> 
>> 
>> Tiago Bento  于2024年5月16日周四 00:43写道：
>> 
>>> Shawn,
>>> 
>>> Does that mean you didn't publish anything to NPM as part of your
>>> releases while in the incubator?
>>> 
>>> On Wed, May 15, 2024 at 12:31 PM Shawn Yang 
>>> wrote:
>>>> 
>>>> Hi Tiago,
>>>> 
>>>> From the current incubator release policy, you need to rename all npm
>>>> packages to apache-xxx before releasing. The packages released before
>>>> should be on to left intact.
>>>> 
>>>> I came across same issue when we release apache fury. In your case, most
>>>> packages starts with kie. Fury has similar rules which starts with
>>> furyjs.
>>>> Rename to apache-xxx has many works to do and breaks the compatibility
>>> with
>>>> downstreams. So fury just skipped release binary packages for fury
>>>> JavaScript.
>>>> 
>>>> I was wondering whether the incubator release policy remove such name
>>>> rules. It does introduce extra work and confusion to podlings. And It's
>>> not
>>>> idiomatic in npm. Similar confusion exists for Python wheels. In Python,
>>>> the nami

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #10, bug #55154 (group groff):

[comment #0 original submission:]
> .tr a 
> .tr b\~
> .tr c\ 
> .tr d\|
> .tr e\^
> .tr f\0
> 
> This attempts to translate six alphabetic characters to six
> different types of space characters.  What it does instead is
> accept the first two translations and reject the last four:

Bizarrely, while it accepts the second translation, it doesn't actually honor
it.

$ cat tr-test
.tr b\~
abc cba\p
$ nroff tr-test | cat -s
a c   c a

$ 

I'm not sure what to think of this.  On the one hand, comment #2 argues this
shouldn't work; even the texinfo manual says a .tr target should be a glyph,
which \~ isn't.  On the other hand, given that fact, the translation failing
outright (as the subsequent lines of the original submission do) would make
sense, whereas silently converting a stretchable space to an unstretchable one
surely does not.

The deprecation proposed in bug #64337 would make this moot.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

kastiglione wrote:

@adrian-prantl updated the description:

> Re-apply https://github.com/llvm/llvm-project/pull/81196, with a fix that 
> handles the absence of llvm formatting: 
> https://github.com/llvm/llvm-project/commit/3ba650e91eded3543764f37921dcce3bb47d425f

https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione edited 
https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione edited 
https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [libreoffice-users] Help for Libreoffice portable

[Dave Howorth]

On Wed, 15 May 2024 16:14:31 -0300
ady  wrote:

> > I would like to get help for LibreOffice
> > portable in Czech. Is it somewhere to download it, please? Best
> > regards  
> 
> For the (Windows) portable package, the offline help is available in
> English only.
> 
> In the LibreOffice download site, you could select to download a Help
> package to _install_, but I am not sure how it would work with your
> _portable_ version. I guess you really need to know what you are doing
> in order to mix these 2 packages. Generally speaking, I wouldn't
> recommend it.
> 
> Since you are using the portable package, I guess that the simplest
> way to read the help content in Czech would be to read it on-line:
> 
> For LO 7.6:
> 

FWIW that link is unusable for me. As are each of the others below. They
all take me to
https://help.libreoffice.org/latest/en-US/text/swriter/main.html

which sits there apparently constantly reloading the page. This is
using FF 115.11.0esr with the NoScript add-on that is set to disable
scripting on 'new' sites such as this one is to my browser.

wget appears to fetch and save the correct new_help.html but I haven't
investigated to see what FF finds so objectionable.

> For LO 24.2:
> 
> 
> For the "latest" version (a moving target):
> 
> 
> HTH,
> Ady.

-- 
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Re: New Release to get rid of CVE

[Dave Fisher]

Hi Stephan,

Two answers.

1) Please list the CVEs that would be fixed. It’s quite possible they have no 
impact on POI or XMLBeans.

2) Please consider submitting a PR to make the fix. We can always use more 
contributors and everyone here is a volunteer.

Best,
Dave

> On May 15, 2024, at 2:23 AM, Stefan Bischof  wrote:
> 
> hi,
> 
> could you please plan a new release to get rid of CVE  from 
> apache-commons-compress 1.25.0 -> 1.26.1
> 
> bests
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: [marxmail] [The Washington Post] Time is up for neoliberals

[Dave Lindorff]

It seems to me that the successful deindustrialization of the US economy
and the related undermining and weakening of industrial unionism, there
remains little power in the working class to compel a change for the better
in the lives of the American middle class or the lives of the poor. There
isn't even a militant movement for fixing Social Security. Instead we get
endless warnings that Social Security is facing a crisis in 2034, and then
the pathetic suggestion offered as a comfort to the masses, to the effect
that "there's no need to worry about Social Security going bankrupt --
there will still be enough FICA payroll tax money coming to fund 79% of
promised benefits into the next century."   And people seem to just nod
their heads and say, "Oh, well that's lucky."

There should be marches by millions of people demanding a fix that takes
the needed funds from the rich. Given the massive shift in wealth to the
upper 10% and upper 1% of the country, and the price gouging and excessive
profits of corporations, what should change should be and to the sanctified
50/50 split in FICA taxes between workers and employers, with employers
paying a higher percentage of payrolls -- something a number of European
countries have long-since done to make their pension systems better able to
support their elder populations over the long term and at a much more
generous level than the US Social Security system does.

On Wed, May 15, 2024 at 10:59 AM Michael Meeropol via groups.io  wrote:

> According to some versions of SSA theory, the period beginning with the
> New Deal (especially finalized after WW II) involved a ::"Capital-Labor
> Accord" whereupon the biggest capitalists acquiesced in union
> representation and rising real wages IN RETURN For unions recognizing
> "management prerogatives" which basically meant Management controlled the
> pace and intensity of work and "paid for it" with higher wages --- THen
> there was a "capital-citizen accord" which created the welfare-warfare
> state (with the expansion of social security and the culmination of the
> expansion of the social safety net with Medicare and Medicaid 
>
> THis "worked" --- income inequality lessened --- a very significant
> percentage of the population moved out of poverty.
>
> NOW --- could something similar happen with "GREEN" technology --- I think
> it could but of course the current beneficiaries of the fossil-fuel based
> economy have a lot of power to thwart those changes ---
>
>
>
> On Wed, May 15, 2024 at 9:16 AM Mark Baugher via groups.io  mbaugher@groups.io> wrote:
>
>>
>>
>> > On May 14, 2024, at 3:13 PM, Michael Meeropol via groups.io > gmail@groups.io> wrote:
>> >
>> >
>> > Could a new version of the post WW II SSA (which even Baran and Sweezy
>> admit [temporarily] banished the stagnation wolf from the door) arise that
>> would do al the great things that Siglitz wants ---
>>
>> I don't know how SSA compares with Mandel's Long Waves, or if either
>> improve on Kondratiev.  But I think the answer to your question is "no" to
>> the extent that the post WW II boom depended on WW II destruction of the
>> infrastructure of much of Europe, Eurasia, and Asia along with the
>> repression or destruction of working class organizations.
>>
>> And what would a new version of WWII and the post WW II economic boom do
>> to the planet's ecosystems?
>>
>> Mark
>>
>>
>> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30343): https://groups.io/g/marxmail/message/30343
Mute This Topic: https://groups.io/mt/106071997/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Problem reseting touch ID with stolen device protection on.

[Dave Carlson]

Paul,
Aren’t you supposed first to disable that protection feature before adding a 
fingerprint? And of course that protection needs to be turned off when you are 
at your home location.

Dave Carlson
Farfar, Oregonian, Engineer, Woodworker, Musician
dgcarlson0...@gmail.com




On May 15, 2024, at 8:22 AM, Paul Hopewell  wrote:

Hello,
I have a backup iPhone SE 2020 just updated to IOS 17.5. Touch ID no longer 
works so I need to reset it by adding a new fingerprint. I have stolen device 
protection set on which means that I have to do Touch ID to let me add a 
fingerprint!
This iPhone SE is my backup phone and has been in a desk drawer at home for 
ages and has not left home for weeks. I have just left it switched on for an 
hour or so in the hope that it would then let me add the new fingerprint, but 
no luck.
Any ideas on how to solve this problem?
Many thanks … Paul Hopewell

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/73ED08F0-3A8F-432C-B0E7-53F6315B3736%40hopewell.org.uk.

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/D8104921-0AAF-49AD-91AB-9183975EA852%40gmail.com.

Re: [RE-wrenches] Fortress Avalon

[Dave Angelini Offgrid Solar via RE-wrenches]

Hey Darryl,

I got involved with the Schneider Home all in one (same thing as 
Fortress Avalon) Before that I was involved with another Schneider HV 
all in one long before Solark. Omnia failed to get to market. I get the 
hee bee jeebies with that kind of voltage offgrid. The numerous various 
failures of the LG hi voltage batteries.


There is no way to replace the battery without waiting for Fortress to 
help. With 48v, I can go to Costco or Walmart and build a temporary 48v 
bank in 3 hours. Pretty simple requirement that I have. Especially in 
this world!


Dave Angelini Offgrid Solar
"we go where powerlines don't"
   [1]https://offgridsolar1.com/ [2]  [1]
e-mail  offgridso...@sti.net
text 209 813 0060

On 2024-05-14 6:33 pm, Darryl Thayer via RE-wrenches wrote:

I am looking at going high voltage as opposed to 48 volts. This is my 
largest battery system, I have a large distance between battery and 
inverter, 40 feet, the cost of wire, 50 kW, at 50 volts is 1000 amps.  
I am thinking this is too big for me.


On Tue, May 14, 2024, 7:29 PM Mac Lewis via RE-wrenches 
 wrote:



Hello Wrenches,

I am looking closely at offering the Fortress Avalon system.  I would 
like to hear from anyone that has installed, commissioned and seen 
them work in the field. Pros and cons, all of your thoughts are 
appreciated.


Thanks! ___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try 
the other:

https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org


___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try 
the other:

https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org



Links:
--
[1] http://members.sti.net/offgridsolar/
[2] https://offgridsolar1.com/___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try the other:
https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org

Re: [PATCH v2 1/2] x86/sgx: Resolve EAUG race where losing thread returns SIGBUS

[Dave Hansen]

On 5/15/24 06:54, Jarkko Sakkinen wrote:
> I'd cut out 90% of the description out and just make the argument of
> the wrong error code, and done. The sequence is great for showing
> how this could happen. The prose makes my head hurt tbh.

The changelog is too long, but not fatally so.  I'd much rather have a
super verbose description than something super sparse.

Would something like this make more sense to folks?

Imagine an mmap()'d file. Two threads touch the same address at
the same time and fault. Both allocate a physical page and race
to install a PTE for that page. Only one will win the race. The
loser frees its page, but still continues handling the fault as
a success and returns VM_FAULT_NOPAGE from the fault handler.

The same race can happen with SGX. But there's a bug: the loser
in the SGX steers into a failure path. The loser EREMOVE's the
winner's EPC page, then returns SIGBUS, likely killing the app.

Fix the SGX loser's behavior. Change the return code to
VM_FAULT_NOPAGE to avoid SIGBUS and call sgx_free_epc_page()
which avoids EREMOVE'ing the winner's page and only frees the
page that the loser allocated.

[Bug 2058970] Re: deepin-log-viewer 5.9.7+ds1-2build6 FTBFS on 32-bit time64 architectures

[Dave Jones]

** Changed in: deepin-log-viewer (Ubuntu Noble)
 Assignee: Shengjing Zhu (zhsj) => Dave Jones (waveform)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2058970

Title:
  deepin-log-viewer 5.9.7+ds1-2build6 FTBFS on 32-bit time64
  architectures

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/deepin-log-viewer/+bug/2058970/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH] nouveau: set placement to original placement on uvmm validate.

[Dave Airlie]

From: Dave Airlie 

When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.

I think this should be fine to use the initial domain from the
object creation, as least with VM_BIND this won't change after
init so this should be the correct answer.

Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Cc: Danilo Krummrich 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index ee02cd833c5e..84a36fe7c37d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1803,6 +1803,7 @@ nouveau_uvmm_bo_validate(struct drm_gpuvm_bo *vm_bo, 
struct drm_exec *exec)
 {
struct nouveau_bo *nvbo = nouveau_gem_object(vm_bo->obj);
 
+   nouveau_bo_placement_set(nvbo, nvbo->valid_domains, 0);
return nouveau_bo_validate(nvbo, true, false);
 }
 
-- 
2.45.0

[PATCH] nouveau: set placement to original placement on uvmm validate.

[Dave Airlie]

From: Dave Airlie 

When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.

I think this should be fine to use the initial domain from the
object creation, as least with VM_BIND this won't change after
init so this should be the correct answer.

Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Cc: Danilo Krummrich 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index ee02cd833c5e..84a36fe7c37d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1803,6 +1803,7 @@ nouveau_uvmm_bo_validate(struct drm_gpuvm_bo *vm_bo, 
struct drm_exec *exec)
 {
struct nouveau_bo *nvbo = nouveau_gem_object(vm_bo->obj);
 
+   nouveau_bo_placement_set(nvbo, nvbo->valid_domains, 0);
return nouveau_bo_validate(nvbo, true, false);
 }
 
-- 
2.45.0

Re: [RE-wrenches] Fortress Avalon

[Dave Angelini Offgrid Solar via RE-wrenches]

Huge mistake to me to use high voltage battery.  I am biased for 
offgrid.


Dave Angelini Offgrid Solar
"we go where powerlines don't"
   [1]https://offgridsolar1.com/ [2]  [1]
e-mail  offgridso...@sti.net
text 209 813 0060

On 2024-05-14 5:28 pm, Mac Lewis via RE-wrenches wrote:


Hello Wrenches,

I am looking closely at offering the Fortress Avalon system.  I would 
like to hear from anyone that has installed, commissioned and seen them 
work in the field. Pros and cons, all of your thoughts are appreciated.


Thanks!
___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try 
the other:

https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org



Links:
--
[1] http://members.sti.net/offgridsolar/
[2] https://offgridsolar1.com/___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try the other:
https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org

Re: /boot too small

[Dave Close]

Michal Schorm wrote:

>The best *trivial* setup and usage should be having everything on
>BTRFS (except EFI, as you said),
>and maintain some amount of snapshots you can revert to anytime in
>case of any issues.

I look forward to a complete set of instructions for this approach
in the Fedora documentation web site. I'm sure many of us will want
to adopt this approach.
-- 
Dave Close, Compata, Irvine CA  "'Always' and 'never' are two
d...@compata.com, +1 714 434 7359words you should always remember
dhcl...@alumni.caltech.edu   never to use." --Wendell Johnson

--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[bug #62916] list things to deprecate

[Dave]

Follow-up Comment #8, bug #62916 (group groff):

Related: bug #65724 seeks to deprecate EBCDIC.  However, if it goes through as
contemplated, it won't make it onto the list proposed by this ticket, because
there won't be a release where it's deprecated but still functional.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: ripping out EBCDIC (cp1047)/preparing for UTF-8 input

[Dave Kemper]

On Tue, May 14, 2024 at 8:53 AM G. Branden Robinson
 wrote:
> I aim to drop EBCDIC a.k.a.
> code page (CCSID) 1047 support from groff 1.24.

No objection to this.

> The idea is, for 1.24, to get everybody migrating to pure ASCII input
> documents (as might be generated by preconv(1)) by the time GNU troff
> sees them.

I don't strongly object, but I wonder about the advisability of
requiring preconv on a wide swath of documents that didn't previously
require it while Savannah #59442 (preconv vs soelim) and #65108
(handling encoding of filenames) are unresolved.

This set of intertwined problems doesn't go away even when groff
accepts UTF-8 natively: files included via .so still might use Latin-1
-- especially any files dating from before 2026 (or whenever 1.24
comes out), where that was the native input encoding -- and the
underlying file system might use a different encoding for filenames.

Are support for EBCDIC and for Latin-1 tightly enough coupled in the
code that it's unnecessarily complex to remove the former while
retaining the latter?

Re: [Emc-users] Beam Stiffening?

[Dave Engvall]

This is why I’m a chemist not an engineer. So how does it break out cost vs 
results, not exactly the same as weight. Even tho it is not an aircraft app 
working towards lightness may make sense. Thanks for the elucidation. Really 
happy it is not my problem. ;-)  A Boeing engineer once commented that 
non-aeronautical applications were SO easy to make strong/stiff!

> On May 13, 2024, at 4:02 PM, andy pugh  wrote:
> 
> On Mon, 13 May 2024 at 22:50, Chris Albertson 
> wrote:
> 
>> Adding anything inside is the worst place to add material.
> 
> 
> Yes, without a doubt, but it seems fair to assume that the ganry has slides
> and other components on the outside, but not on the inside.
> 
> The base beam has an Iyy (bending in the plane of the smaller dimension )
> of 22in^4
> Doubling it internally gives: 34.2in^4, so about 50% stiffer
> Doubling externally gives: 57in^4 so getting on for 3x as stiff.
> 
> I admit I was imagining a thinner wall thickness relative to the overall
> dimensions, where the difference would be smaller.
> 
> There is less to be gained than you might think from making the section
> solid. You can do the experiments here:
> https://amesweb.info/section/second-moment-of-area-calculator.aspx
> 
> If stiffness is the key, then add a stiff material.
> Aluminium is 68GPa (moving away from measuring in bananas)
> Steel is 200GPa (this is the same for all iron alloys, hardened or
> unhardened, including cast iron)
> Titanium is 114GPa, so good for light, not for stiff.
> Carbon fibre is 181Gpa for uindirectional fibres, but more typically around
> 50GPa.
> Tungsten carbide is 600GPa (which is why solid carbide boring bars exist)
> Beryllium is 287 but probably out of both budget and COSHH limits.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[NNagain] Fwd: Invitation to: Net Neutrality Zoominar - May 21st at 1PM Eastern

[Dave Taht via Nnagain]

Jeff pulver used to be pretty clued


-- Forwarded message -
From: Jeff Pulver 
Date: Tue, May 14, 2024, 11:01 AM
Subject: Invitation to: Net Neutrality Zoominar - May 21st at 1PM Eastern
To: Dave 


Dear Dave,


You are invited to join me for an insightful Zoominar on the *FCC’s 2024
Net Neutrality Order,* scheduled for May 21st at 1 PM Eastern / 10 AM
Pacific.


I will be hosting a conversation with *Glenn Richards*, Partner at
Dickinson Wright, and J*onathan Marashlian*, Managing Partner at The
CommLaw Group. We will delve into the implications of the FCC’s 2024 Net
Neutrality Order, discussing key aspects such as the restoration of Title
II classification, enhanced regulatory authority, commitment to an open
internet, and more.


To RSVP, please use this link: *RSVP Link
<https://jeffpulver.us8.list-manage.com/track/click?u=a7307a648951c3c7f9129dd41=3d7052a424=7bddd6f7b4>.*


There will be an opportunity to ask questions during the Zoominar, so feel
free to bring any queries you might have.

I hope to see you there!



Warm regards,

Jeff






This email was sent to dave.t...@gmail.com
*why did I get this?*
<https://jeffpulver.us8.list-manage.com/about?u=a7307a648951c3c7f9129dd41=e0690cd2b3=7bddd6f7b4=4a9d78e876>
unsubscribe from this list
<https://jeffpulver.us8.list-manage.com/unsubscribe?u=a7307a648951c3c7f9129dd41=e0690cd2b3=b=7bddd6f7b4=4a9d78e876>
update subscription preferences
<https://jeffpulver.us8.list-manage.com/profile?u=a7307a648951c3c7f9129dd41=e0690cd2b3=7bddd6f7b4=4a9d78e876>
pulver.com · PO Box 2594 · Manchester Center, VT 05255 · USA
___
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

[Starlink] Fwd: [Bloat] fq_codel Day - it's twelve years old!

[Dave Taht via Starlink]

I would never have imagined it would have taken this long for 300 lines of
code to propagate across the planet.

-- Forwarded message -
From: Rich Brown via Bloat 
Date: Tue, May 14, 2024, 8:15 AM
Subject: [Bloat] fq_codel Day - it's twelve years old!
To: bloat 


My calendar reminds me that fq_codel is TWELVE YEARS OLD today! Dave Täht
announced a testable version on the CeroWrt list at:
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html

Since then, fq_codel, CAKE, TX Queues, AQL, ATF, and cake-autorate have all
made their way into good products. (See
https://forum.openwrt.org/t/how-openwrt-vanquishes-bufferbloat/189381 for
details.)

Congratulations, everyone!

Rich
___
Bloat mailing list
bl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
___
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

[NNagain] Fwd: [Bloat] fq_codel Day - it's twelve years old!

[Dave Taht via Nnagain]

I would never have imagined it would have taken this long for 300 lines of
code to propagate across the planet.

-- Forwarded message -
From: Rich Brown via Bloat 
Date: Tue, May 14, 2024, 8:15 AM
Subject: [Bloat] fq_codel Day - it's twelve years old!
To: bloat 


My calendar reminds me that fq_codel is TWELVE YEARS OLD today! Dave Täht
announced a testable version on the CeroWrt list at:
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html

Since then, fq_codel, CAKE, TX Queues, AQL, ATF, and cake-autorate have all
made their way into good products. (See
https://forum.openwrt.org/t/how-openwrt-vanquishes-bufferbloat/189381 for
details.)

Congratulations, everyone!

Rich
___
Bloat mailing list
bl...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
___
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

Re: [Emc-users] Beam Stiffening?

[Dave Engvall]

Hi all, 
Since I’m cheap I’d prototype with a fiberglass tube and fill with urethane 
foam. How much does the modulus change between a rectangular tube and 
elliptical geometry?
Box with corner braces that are viscous damped. It all comes down to load and 
frequencies. 
I’m just the aging dummy in the corner. ;-)

> On May 13, 2024, at 2:36 PM, Chris Albertson  
> wrote:
> 
> 
> 
>> On May 13, 2024, at 1:45 PM, Todd Zuercher via Emc-users 
>> mailto:emc-users@lists.sourceforge.net>> 
>> wrote:
>> 
>> Anyone have any brilliant ideas to stiffen a woefully inadequate cross beam 
>> on a gantry router without adding too much mass?  What is there now is a 4" 
>> x 8" rectangular 3/8" walled extrusion that is 145" long.
>> 
>> Under normal jogging commands the two servos control the ends of this gantry 
>> reasonably well, but while the axis is homing the thing shakes and wobbles 
>> terribly bad.  Also If I put a dial indicator in the center of the bridge 
>> and hit the bridge forward or backward it will flex and wobble enough to 
>> displace the dial indicator +/-0.03 and it takes nearly a dozen wobbles to 
>> dampen it.  But on the ends the servo's only have a few thousandths of give.
>> 
>> I'm less concerned about the actual stiffness and more worried about 
>> dampening the wobble.
> 
> 
> What is the extrusion made of, I assume it is some kind of aluminum alloy.
> The simplest but expensive option is to replace it with a stronger/stiffer 
> material with the same dimensions.   Of course Titanium comes to mind but 
> that is maybe not in the budget.Carbon fiber could work and it is 
> possible to DIY carbon fiber beams with just hand tools.   I have made 4 
> meter long racing kayaks with carbon, using just a paint brush and scissors 
> in one weekend.   
> 
> The first class way is to make a female mold and polish it well so the part 
> looks nice.   The cheap way is to make one like they make surfboards.  You 
> start with a foam block, shape it then wrap it in fiber and resin.
> 
> The neat thing about carbon composite is that you are not limited to the 
> extrusion shape.   I would make the entire beam a compound curve with no flat 
> or straight or cylindrical sections,  Maybe like a very elongated American 
> football but with ovil cross section.
> 
> I like to use the car hood story.  A flat sheet of sheet steel is bendable by 
> hand.  But after they stamp it into the shape of a car hood it becomes rigid. 
>   So rather then a square tube, way not oval but with a larger diameter in 
> the center where all the bending force is?
> 
> The way you make it is to first make a full-size model out of wood and bondo. 
> Do a test-fit and give it an automotice grade paint finsh and then paste wax. 
>  Make a fiber glass mold, then from that your part.   Yes that is a lot of 
> work.  This is why you have an aluminum extrusion there now, because that was 
> easy and cheap.
> 
> 
> 
> 
> 
> 
>> 
>> Todd Zuercher
>> P. Graham Dunn Inc.
>> 630 Henry Street
>> Dalton, Ohio 44618
>> Phone:  (330)828-2105ext. 2031
>> 
>> 
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: Just downloaded the installer file

[Dave Caughey]

Most browsers also have a "Downloads" item in their main menu (typically
found at the right side of the main toolbar) that'll show you all of the
files you downloaded using the browser.


On Tue, 14 May 2024 at 12:36, Ray O'Donnell  wrote:

> On 14/05/2024 16:01, Jarod Steed wrote:
>
> I can’t tell where the program got saved to in my c drive, do you know
> what the default file path is for downloading the pgadmin-4-8.6-x64.exe?
>
>
>
>
> I'd imagine that depends on your browser websites don't have control
> over that sort of thing, to my knowledge. Look in your browser settings and
> see where it is set to save downloads.
>
> Ray..
>
>
> --
> Raymond O'Donnell // Galway // ireland...@rodonnell.ie
>
>

Re: [LibreQoS] [Starlink] It’s the Latency, FCC

[Dave Taht via LibreQoS]

I agree the number 3s are the most motivated. For example I think mediatek
is doing a massive come from behind win vs Broadcom and Qualcomm in the
wifi ap market




On Wed, May 1, 2024, 12:26 PM Eugene Y Chang  wrote:

> Pick up the glove?
> I can be part of a team. I am not as close as to the equipment as I used
> to be.
> I need help assembling a demo configuration that can engage the
> subscribers.
> Building a local team for this has been very slow going.
>
> I like helping a market #3 or #4 disrupt an incumbent. In most cases I
> have seen, the #2 already has a game plan for competing with #1. A distant
> #3 is usually the most hungry.
>
> Gene.
> --
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
> Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.ch...@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
> On Apr 30, 2024, at 9:27 PM, Frantisek Borsik 
> wrote:
>
> Basically, Eugene, the situation you are describing is calling for a
> competitor to disrupt them!
>
> This is such an old story - so many ISPs, especially WIPSs, started just
> because they either didn't have any option or all those options available
> were really terrible.
>
> Don't you want to pick up the glove? :P
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.bor...@gmail.com
>
>
> On Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang 
> wrote:
>
>> Frank,
>> Thank you. What you suggest makes sense if it was objective!
>>
>> In my neighborhood, the ISP’s organization will feel they have nothing to
>> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>> another organization. They just implement corporate standards. The local
>> managers are not motivated to deviate from their corporate marching orders.)
>>
>> A public promotion (campaign) of modern best practices is needed. Then I
>> need to have this campaign spill over to the subscriber community. The
>> business community needs to be educated that their productivity will
>> improve. The social leaders need to learn that their community will get
>> better service. Then, and only then, can I see the ISP feeling the need to
>> improve. It helps if the improvement is just open-source software on their
>> hardware investment.
>>
>>
>> Gene
>> --
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <
>> frantisek.bor...@gmail.com> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him
>> about us: https://libreqos.io
>>
>> He can take a look on it, join our support chat and get help if he won't
>> be able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to
>> deploy.
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.bor...@gmail.com
>>
>>
>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>> starl...@lists.bufferbloat.net> wrote:
>>
>>> OK. I need help teaching my ISPs that they can do this without
>>> threatening their business model.
>>> Who can help me?
>>>
>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>> adopted the lessons from the public demo, most of the latency issues would
>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>> practice? Am I crying over issues that are already fixed? Does this
>>> simplify the issues at the FCC?
>>>
>>> Gene
>>> --
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht  wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software 

Re: [Starlink] It’s the Latency, FCC

[Dave Taht via Starlink]

I agree the number 3s are the most motivated. For example I think mediatek
is doing a massive come from behind win vs Broadcom and Qualcomm in the
wifi ap market




On Wed, May 1, 2024, 12:26 PM Eugene Y Chang  wrote:

> Pick up the glove?
> I can be part of a team. I am not as close as to the equipment as I used
> to be.
> I need help assembling a demo configuration that can engage the
> subscribers.
> Building a local team for this has been very slow going.
>
> I like helping a market #3 or #4 disrupt an incumbent. In most cases I
> have seen, the #2 already has a game plan for competing with #1. A distant
> #3 is usually the most hungry.
>
> Gene.
> --
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
> Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.ch...@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
> On Apr 30, 2024, at 9:27 PM, Frantisek Borsik 
> wrote:
>
> Basically, Eugene, the situation you are describing is calling for a
> competitor to disrupt them!
>
> This is such an old story - so many ISPs, especially WIPSs, started just
> because they either didn't have any option or all those options available
> were really terrible.
>
> Don't you want to pick up the glove? :P
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.bor...@gmail.com
>
>
> On Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang 
> wrote:
>
>> Frank,
>> Thank you. What you suggest makes sense if it was objective!
>>
>> In my neighborhood, the ISP’s organization will feel they have nothing to
>> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>> another organization. They just implement corporate standards. The local
>> managers are not motivated to deviate from their corporate marching orders.)
>>
>> A public promotion (campaign) of modern best practices is needed. Then I
>> need to have this campaign spill over to the subscriber community. The
>> business community needs to be educated that their productivity will
>> improve. The social leaders need to learn that their community will get
>> better service. Then, and only then, can I see the ISP feeling the need to
>> improve. It helps if the improvement is just open-source software on their
>> hardware investment.
>>
>>
>> Gene
>> --
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <
>> frantisek.bor...@gmail.com> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him
>> about us: https://libreqos.io
>>
>> He can take a look on it, join our support chat and get help if he won't
>> be able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to
>> deploy.
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.bor...@gmail.com
>>
>>
>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> OK. I need help teaching my ISPs that they can do this without
>>> threatening their business model.
>>> Who can help me?
>>>
>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>> adopted the lessons from the public demo, most of the latency issues would
>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>> practice? Am I crying over issues that are already fixed? Does this
>>> simplify the issues at the FCC?
>>>
>>> Gene
>>> --
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht  wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software 

[Bug 1921914] Re: [SRU] package quickml 0.7-5.1 failed to install/upgrade: installed quickml package post-installation script subprocess returned error exit status 1

[Dave Jones]

I've re-sponsored updated debdiffs as requested

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921914

Title:
  [SRU] package quickml 0.7-5.1 failed to install/upgrade: installed
  quickml package post-installation script subprocess returned error
  exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/quickml/+bug/1921914/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[allura:tickets] #8558 user email changes not getting into solr

[Dave Brondsema]

- **status**: open --> closed
- **assigned_to**: Guillermo Cruz



---

**[tickets:#8558] user email changes not getting into solr**

**Status:** closed
**Milestone:** unreleased
**Created:** Thu Apr 25, 2024 04:58 PM UTC by Dave Brondsema
**Last Updated:** Thu Apr 25, 2024 04:58 PM UTC
**Owner:** Guillermo Cruz


For example, when a primary email address is deleted on a user, and one of 
their other emails becomes the primary, that doesn't get into solr.  So 
/nf/admin/search_users has old results

`IndexerSessionExtension` only indexes Users changes.  I think if an email 
address record is added or deleted, we probably want to trigger a user index 
then.

Also (and maybe even more importantly) the `user.set_pref('email_address', 
primary_addr)` call doesn't make `IndexerSessionExtension` do anything which is 
surprising since that is a field saved on the user record directly.  Need to 
figure out why.

minor, kinda related, I think this should be fixed:
```
--- Allura/allura/controllers/auth.py
+++ Allura/allura/controllers/auth.py
@@ -617,7 +617,7 @@ def _update_emails(self, user, admin=False, form_params={}):
 flash('You must provide your current password to delete an 
email', 'error')
 return
 if primary_addr == user.email_addresses[i]:
-if select_new_primary_addr(user, 
ignore_emails=primary_addr) is None \
+if select_new_primary_addr(user, 
ignore_emails=[primary_addr]) is None \
 and asbool(config.get('auth.require_email_addr', 
False)):
 flash('You must have at least one verified email 
address.', 'error')
 return
```




---

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed 
to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://forge-allura.apache.org/p/allura/admin/tickets/options.  Or, if this is 
a mailing list, you can unsubscribe from the mailing list.

[Bug 2060882] Re: [SRU] usrpctl fails to run

[Dave Jones]

Confirmed; fix looks minimal and reasonable, sponsoring, thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2060882

Title:
  [SRU] usrpctl fails to run

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/uhd/+bug/2060882/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

fossil 2.24 not updated

[Dave St.Germain]

I've updated fossil to version 2.24, but the binary still seems to be version 
2.23. 
I've tried removing and reinstalling, with a binary dated May 11th. Same result:

$ pkg_info -I fossil
fossil-2.24v0   simple distributed software configuration management

$ /usr/local/bin/fossil version
This is fossil version 2.23 [47362306a7] 2023-11-01 18:56:47 UTC

[jira] [Created] (CAMEL-20763) Rest template with underscore fails after Camel 4.2.0

[Dave Riseley (Jira)]

Dave Riseley created CAMEL-20763:


 Summary: Rest template with underscore fails after Camel 4.2.0
 Key: CAMEL-20763
 URL: https://issues.apache.org/jira/browse/CAMEL-20763
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 4.2.0
 Environment: Camel 4.2.0 or later
Reporter: Dave Riseley


We have a camel route, which in it's simplified form looks like this:
{code:java}
@Component
public class CamelRouteBuilder extends RouteBuilder{

@Override
public void configure() throws Exception {

restConfiguration().component("servlet");

rest("/hello")
.get("/{first_name}")
.to("direct:helloworld");

from("direct:helloworld")
.transform()
.simple("Hi ${header.first_name}");
}
}
{code}
This works fine on Spring Boot 3.1.11 / Camel 4.0.5 . When we upgrade to Camel 
4.2.0 or later, it fails on startup with the following exception:
 
{code:java}
Caused by: java.util.regex.PatternSyntaxException: named capturing group is 
missing trailing '>' near index 17
\/hello\/(?[^\/]+)
 ^
at java.base/java.util.regex.Pattern.error(Pattern.java:2028) ~[na:na]
at java.base/java.util.regex.Pattern.groupname(Pattern.java:2945) 
~[na:na]
at java.base/java.util.regex.Pattern.group0(Pattern.java:2990) ~[na:na]
at java.base/java.util.regex.Pattern.sequence(Pattern.java:2124) 
~[na:na]
at java.base/java.util.regex.Pattern.expr(Pattern.java:2069) ~[na:na]
at java.base/java.util.regex.Pattern.compile(Pattern.java:1783) ~[na:na]
at java.base/java.util.regex.Pattern.(Pattern.java:1430) ~[na:na]
at java.base/java.util.regex.Pattern.compile(Pattern.java:1069) ~[na:na]
at 
org.apache.camel.support.RestConsumerContextPathMatcher.register(RestConsumerContextPathMatcher.java:255)
 ~[camel-support-4.2.0.jar:4.2.0]
at 
org.apache.camel.http.common.CamelServlet.connect(CamelServlet.java:424) 
~[camel-http-common-4.2.0.jar:4.2.0]
at 
org.apache.camel.component.servlet.CamelHttpTransportServlet.connect(CamelHttpTransportServlet.java:100)
 ~[camel-servlet-4.2.0.jar:4.2.0]

{code}
I believe this is due to a change introduced by 
https://issues.apache.org/jira/browse/CAMEL-8306 in which the following method:
{code:java}
/**
 * Pre-compiled consumer path for wildcard match
 *
 * @param consumerPath a consumer path
 */
public static void register(String consumerPath) {
// Convert URI template to a regex pattern
String regex = consumerPath
.replace("/", "\\/")
.replace("{", "(?<")
.replace("}", ">[^\\/]+)");

// Add support for wildcard * as path suffix
regex = regex.replace("*", ".*");

// Match the provided path against the regex pattern
Pattern pattern = Pattern.compile(regex);
PATH_PATTERN.put(consumerPath, pattern);
}
{code}
 
does not allow for underscore (and other regex special characters) in the 
parameter name. I could not find any documentation that describes limits on the 
characters that can be used in rest templates.

Our production code has many, many rest routes with many parameters with 
underscores in them.

I will prepare a PR with a proposed fix



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[dolphin] [Bug 487002] Text disappears

[Dave]

https://bugs.kde.org/show_bug.cgi?id=487002

--- Comment #1 from Dave  ---
Latest nightly build downloaded from
https://cdn.kde.org/ci-builds/system/dolphin/master/windows/
Build date 8/5/24

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 487002] New: Text disappears

[Dave]

https://bugs.kde.org/show_bug.cgi?id=487002

Bug ID: 487002
   Summary: Text disappears
Classification: Applications
   Product: dolphin
   Version: unspecified
  Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: dave.burbi...@catch.com.au
CC: kfm-de...@kde.org
  Target Milestone: ---

Created attachment 169468
  --> https://bugs.kde.org/attachment.cgi?id=169468=edit
Part of screen so you can see it

SUMMARY
I am running Windows 11 with a dark theme.
The the view pane (white background) showing files & folders the text is white.
It can be read if a select a file or folder.
One the hamburger menu text is dark grey on black - hard to read but not
impossible

STEPS TO REPRODUCE
1. Start Dolphin
2. 
3. 

OBSERVED RESULT
Can't read text

EXPECTED RESULT
Should be able to read text. Ideally the background should be black

SOFTWARE/OS VERSIONS
Windows: I'm at work - so this computer (Win 11)
macOS:  n/a
Linux/KDE Plasma: Runs fine at home (Arch Linux)

ADDITIONAL INFORMATION
If there is an option to swap to a dark theme, it is going to be difficult to
find due to this bug

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bug 2015017] Re: [SRU] scaling is wrong in SVG output

[Dave Jones]

** Changed in: graphviz (Ubuntu)
   Status: Confirmed => Fix Committed

** Changed in: graphviz (Ubuntu Jammy)
   Status: Confirmed => In Progress

** Changed in: graphviz (Ubuntu Mantic)
   Status: Confirmed => In Progress

** Changed in: graphviz (Ubuntu Noble)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015017

Title:
  [SRU] scaling is wrong in SVG output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/2015017/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[jira] [Closed] (DAFFODIL-2898) Compilation error with Java 21, add to CI

[Dave Thompson (Jira)]

 [ 
https://issues.apache.org/jira/browse/DAFFODIL-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Thompson closed DAFFODIL-2898.
---

Verified the specified commit (commit 01dded5b5a562b4f35f1123eb8f757face424a31) 
is included in the latest pull from the daffodil repository.

Verified, via review, changes identified in the commit comment were 
implemented. 

Verified that all daffodil subproject sbt test suites executed successfully 
using Java 21.

Verified the nightly test suite executes successfully with no unexpected 
failures using Java 21.

> Compilation error with Java 21, add to CI
> -
>
> Key: DAFFODIL-2898
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2898
> Project: Daffodil
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 3.7.0
>Reporter: Peter Katlic
>Assignee: Peter Katlic
>Priority: Major
> Fix For: 3.8.0
>
>
> Using JDK 21 there is are compilation errors in Misc.scala:
> {noformat}
> [error] 
> daffodil/daffodil-lib/src/main/scala/org/apache/daffodil/lib/util/Misc.scala:550:15:
>  ambiguous reference to overloaded definition,
> [error] both method position in class CharBuffer of type (x$1: 
> Int)java.nio.CharBuffer
> [error] and  method position in class Buffer of type ()Int
> [error] match expected type ?
> [error]     assert(cb.position == 0)
> [error]               ^
> [error] 
> daffodil/daffodil-lib/src/main/scala/org/apache/daffodil/lib/util/Misc.scala:551:15:
>  ambiguous reference to overloaded definition,
> [error] both method limit in class CharBuffer of type (x$1: 
> Int)java.nio.CharBuffer
> [error] and  method limit in class Buffer of type ()Int
> [error] match expected type ?
> [error]     assert(cb.limit == 256)
> [error]               ^
> [error] two errors found
> [error] (daffodil-lib / Compile / compileIncremental) Compilation 
> failed{noformat}
> Tasks:
>  * Add Java 21 to CI
>  * Fix compilation error



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache StormCrawler (Incubating) 3.0 Release Candidate 2

[Dave Fisher]

Caring over my +1 (Binding) from the dev list VOTE thread.

Best,
Dave

> On May 13, 2024, at 12:41 AM, Richard Zowalla  wrote:
> 
> Hi folks,
> 
> I have posted release candidate for the Apache StormCrawler
> (Incubating) 3.0 release and it is ready for testing.
> 
> This is our first release after joining the ASF incubator as a
> poddling. It is a breaking change with renamings in the group ids and
> the removal of the elasticsearch module.
> 
> Thank you to everyone who contributed to this release, including all of
> our users and the people who submitted bug reports,
> contributed code or documentation enhancements.
> 
> The release was made using the Apache StormCrawler (Incubating) release
> process, documented here:
> https://github.com/apache/incubator-stormcrawler/RELEASING.md
> 
> Here is the VOTE and VOTE Result on our dev@stormcrawler.a.o list
> 
> - https://lists.apache.org/thread/l66fyzf9ly7twmfz1vjw1x3sfl0jkzd3
> - https://lists.apache.org/thread/19txfl2ykmjzot8nb1mx6krh8ogzjhkp
> 
> 
> Source:
> 
> https://dist.apache.org/repos/dist/dev/incubator/stormcrawler/stormcrawler-3.0/
> 
> 
> Tag:
> 
> https://github.com/apache/incubator-stormcrawler/releases/tag/stormcrawler-3.0
> 
> Maven Repo:
> 
> https://repository.apache.org/content/repositories/orgapachestormcrawler-1001/
> 
> 
> 
> stormcrawler-3.0-rc2
> Testing StormCrawler 3.0 release candidate
> 
> 
> https://repository.apache.org/content/repositories/orgapachestormcrawler-1001/
> 
> 
> 
> 
> 
> Preview of website:
> 
> https://stormcrawler.staged.apache.org/download/index.html
> 
> Release notes:
> 
> https://github.com/apache/incubator-stormcrawler/releases/tag/stormcrawler-3.0
> 
> Reminder: The up-2-date KEYS file for signature verification can be
> found here:
> https://dist.apache.org/repos/dist/release/incubator/stormcrawler/KEYS
> 
> Please vote on releasing these packages as Apache StormCrawler
> (Incubating) 3.0
> 
> The vote is open for at least the next 72 hours.
> 
> Only votes from IPMC members are binding, but everyone is
> welcome to check the release candidate and vote.
> 
> The vote passes if at least three binding +1 votes are cast.
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> Please include your checklist in your vote:
> https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist
> 
> 
> Thanks!
> Richard
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Updated] (DAFFODIL-2898) Compilation error with Java 21, add to CI

[Dave Thompson (Jira)]

 [ 
https://issues.apache.org/jira/browse/DAFFODIL-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Thompson updated DAFFODIL-2898:

Fix Version/s: 3.8.0

> Compilation error with Java 21, add to CI
> -
>
> Key: DAFFODIL-2898
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2898
> Project: Daffodil
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 3.7.0
>Reporter: Peter Katlic
>Assignee: Peter Katlic
>Priority: Major
> Fix For: 3.8.0
>
>
> Using JDK 21 there is are compilation errors in Misc.scala:
> {noformat}
> [error] 
> daffodil/daffodil-lib/src/main/scala/org/apache/daffodil/lib/util/Misc.scala:550:15:
>  ambiguous reference to overloaded definition,
> [error] both method position in class CharBuffer of type (x$1: 
> Int)java.nio.CharBuffer
> [error] and  method position in class Buffer of type ()Int
> [error] match expected type ?
> [error]     assert(cb.position == 0)
> [error]               ^
> [error] 
> daffodil/daffodil-lib/src/main/scala/org/apache/daffodil/lib/util/Misc.scala:551:15:
>  ambiguous reference to overloaded definition,
> [error] both method limit in class CharBuffer of type (x$1: 
> Int)java.nio.CharBuffer
> [error] and  method limit in class Buffer of type ()Int
> [error] match expected type ?
> [error]     assert(cb.limit == 256)
> [error]               ^
> [error] two errors found
> [error] (daffodil-lib / Compile / compileIncremental) Compilation 
> failed{noformat}
> Tasks:
>  * Add Java 21 to CI
>  * Fix compilation error



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PATCH] nouveau/firmware: using dma non-coherent interfaces for fw loading.

[Dave Airlie]

From: Dave Airlie 

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:

kernel BUG at include/linux/scatterlist.h:187!
invalid opcode:  [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30
Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019
RIP: 0010:sg_init_one+0x85/0xa0
Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54
24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b
0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00
RSP: 0018:a776017bf6a0 EFLAGS: 00010246
RAX:  RBX: a77600d87000 RCX: 002b
RDX: 0001 RSI:  RDI: a77680d87000
RBP: e000 R08:  R09: 
R10: 98f4c46aa508 R11:  R12: 98f4c46aa508
R13: 98f4c46aa008 R14: a77600d4a000 R15: a77600d4a018
FS:  7feeb5aae980() GS:98f5c4dc() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f22cb9a4520 CR3: 0001043ba000 CR4: 003506f0
Call Trace:
 
 ? die+0x36/0x90
 ? do_trap+0xdd/0x100
 ? sg_init_one+0x85/0xa0
 ? do_error_trap+0x65/0x80
 ? sg_init_one+0x85/0xa0
 ? exc_invalid_op+0x50/0x70
 ? sg_init_one+0x85/0xa0
 ? asm_exc_invalid_op+0x1a/0x20
 ? sg_init_one+0x85/0xa0
 nvkm_firmware_ctor+0x14a/0x250 [nouveau]
 nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]
 ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]
 r535_gsp_oneinit+0xb3/0x15f0 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? nvkm_udevice_new+0x95/0x140 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? ktime_get+0x47/0xb0

Fix this by using the non-coherent allocator instead, I think there
might be a better answer to this, but it involve ripping up some of
APIs using sg lists.

Signed-off-by: Dave Airlie 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 11 ++-
 drivers/gpu/drm/nouveau/nvkm/falcon/fw.c |  6 ++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index adc60b25f8e6..c9bee980777c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -205,7 +205,8 @@ nvkm_firmware_dtor(struct nvkm_firmware *fw)
break;
case NVKM_FIRMWARE_IMG_DMA:
nvkm_memory_unref();
-   dma_free_coherent(fw->device->dev, sg_dma_len(>mem.sgl), 
fw->img, fw->phys);
+   dma_free_noncoherent(fw->device->dev, sg_dma_len(>mem.sgl),
+fw->img, fw->phys, DMA_TO_DEVICE);
break;
case NVKM_FIRMWARE_IMG_SGT:
nvkm_memory_unref();
@@ -235,14 +236,14 @@ nvkm_firmware_ctor(const struct nvkm_firmware_func *func, 
const char *name,
fw->img = kmemdup(src, fw->len, GFP_KERNEL);
break;
case NVKM_FIRMWARE_IMG_DMA: {
-   dma_addr_t addr;
-
len = ALIGN(fw->len, PAGE_SIZE);
 
-   fw->img = dma_alloc_coherent(fw->device->dev, len, , 
GFP_KERNEL);
+   fw->img = dma_alloc_noncoherent(fw->device->dev,
+   len, >phys,
+   DMA_TO_DEVICE,
+   GFP_KERNEL);
if (fw->img) {
memcpy(fw->img, src, fw->len);
-   fw->phys = addr;
}
 
sg_init_one(>mem.sgl, fw->img, len);
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c 
b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
index 80a480b12174..a1c8545f1249 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
@@ -89,6 +89,12 @@ nvkm_falcon_fw_boot(struct nvkm_falcon_fw *fw, struct 
nvkm_subdev *user,
nvkm_falcon_fw_dtor_sigs(fw);
}
 
+   /* after last write to the img, sync dma mappings */
+   dma_sync_single_for_device(fw->fw.device->dev,
+  fw->fw.phys,
+  sg_dma_len(>fw.mem.sgl),
+  DMA_TO_DEVICE);
+
FLCNFW_DBG(fw, "resetting");
fw->func->reset(fw);
 
-- 
2.43.2

[PATCH] nouveau/firmware: using dma non-coherent interfaces for fw loading.

[Dave Airlie]

From: Dave Airlie 

Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:

kernel BUG at include/linux/scatterlist.h:187!
invalid opcode:  [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30
Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019
RIP: 0010:sg_init_one+0x85/0xa0
Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54
24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b
0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00
RSP: 0018:a776017bf6a0 EFLAGS: 00010246
RAX:  RBX: a77600d87000 RCX: 002b
RDX: 0001 RSI:  RDI: a77680d87000
RBP: e000 R08:  R09: 
R10: 98f4c46aa508 R11:  R12: 98f4c46aa508
R13: 98f4c46aa008 R14: a77600d4a000 R15: a77600d4a018
FS:  7feeb5aae980() GS:98f5c4dc() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f22cb9a4520 CR3: 0001043ba000 CR4: 003506f0
Call Trace:
 
 ? die+0x36/0x90
 ? do_trap+0xdd/0x100
 ? sg_init_one+0x85/0xa0
 ? do_error_trap+0x65/0x80
 ? sg_init_one+0x85/0xa0
 ? exc_invalid_op+0x50/0x70
 ? sg_init_one+0x85/0xa0
 ? asm_exc_invalid_op+0x1a/0x20
 ? sg_init_one+0x85/0xa0
 nvkm_firmware_ctor+0x14a/0x250 [nouveau]
 nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]
 ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]
 r535_gsp_oneinit+0xb3/0x15f0 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? nvkm_udevice_new+0x95/0x140 [nouveau]
 ? srso_return_thunk+0x5/0x5f
 ? srso_return_thunk+0x5/0x5f
 ? ktime_get+0x47/0xb0

Fix this by using the non-coherent allocator instead, I think there
might be a better answer to this, but it involve ripping up some of
APIs using sg lists.

Signed-off-by: Dave Airlie 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 11 ++-
 drivers/gpu/drm/nouveau/nvkm/falcon/fw.c |  6 ++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index adc60b25f8e6..c9bee980777c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -205,7 +205,8 @@ nvkm_firmware_dtor(struct nvkm_firmware *fw)
break;
case NVKM_FIRMWARE_IMG_DMA:
nvkm_memory_unref();
-   dma_free_coherent(fw->device->dev, sg_dma_len(>mem.sgl), 
fw->img, fw->phys);
+   dma_free_noncoherent(fw->device->dev, sg_dma_len(>mem.sgl),
+fw->img, fw->phys, DMA_TO_DEVICE);
break;
case NVKM_FIRMWARE_IMG_SGT:
nvkm_memory_unref();
@@ -235,14 +236,14 @@ nvkm_firmware_ctor(const struct nvkm_firmware_func *func, 
const char *name,
fw->img = kmemdup(src, fw->len, GFP_KERNEL);
break;
case NVKM_FIRMWARE_IMG_DMA: {
-   dma_addr_t addr;
-
len = ALIGN(fw->len, PAGE_SIZE);
 
-   fw->img = dma_alloc_coherent(fw->device->dev, len, , 
GFP_KERNEL);
+   fw->img = dma_alloc_noncoherent(fw->device->dev,
+   len, >phys,
+   DMA_TO_DEVICE,
+   GFP_KERNEL);
if (fw->img) {
memcpy(fw->img, src, fw->len);
-   fw->phys = addr;
}
 
sg_init_one(>mem.sgl, fw->img, len);
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c 
b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
index 80a480b12174..a1c8545f1249 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/fw.c
@@ -89,6 +89,12 @@ nvkm_falcon_fw_boot(struct nvkm_falcon_fw *fw, struct 
nvkm_subdev *user,
nvkm_falcon_fw_dtor_sigs(fw);
}
 
+   /* after last write to the img, sync dma mappings */
+   dma_sync_single_for_device(fw->fw.device->dev,
+  fw->fw.phys,
+  sg_dma_len(>fw.mem.sgl),
+  DMA_TO_DEVICE);
+
FLCNFW_DBG(fw, "resetting");
fw->func->reset(fw);
 
-- 
2.43.2

[Bug 2015017] Re: [SRU] scaling is wrong in SVG output

[Dave Jones]

** Description changed:

+ [ Impact ]
+ 
+ graphivz output is incorrect for SVG output when the "size" attribute is
+ set, as it implicitly is in several circumstances.
+ 
+ [ Test Plan ]
+ 
+ * sudo apt install imagemagick graphviz
+ * Grab fst.dot attached to this bug
+ * dot -Tpng fst.dot | display png:-
+ * Observe correct scaling
+ * dot -Tsvg fst.dot | display svg:-
+ * Observe incorrect cropping of output
+ * Enable proposed (https://wiki.ubuntu.com/Testing/EnableProposed)
+ * Upgrade graphviz to version from proposed
+ * dot -Tsvg fst.dot | display svg:-
+ * Ensure output is not cropped
+ 
+ [ Regression Potential ]
+ 
+ Low; the patched applied is from upstream and has been part of the
+ official sources for many years now (Debian and Ubuntu are rather behind
+ on their versions of graphviz, but it looks like this may be corrected
+ in the oracular cycle). Nonetheless, the patch was first applied to our
+ current version, is minimal in nature, and fixes the issue in tests
+ without impacting other output.
+ 
+ There is a very small possibility someone may be relying on the
+ incorrect truncation of SVG output, but this is almost certainly
+ outweighed by the number of users impacted by incorrect truncation of
+ output in, e.g. jupyter notebooks, and by the consistency of having the
+ same (lack of) cropping in different output formats.
+ 
+ [ Original Description ]
+ 
  SVG output brutally truncates large (and even not so large) graphs when
  the "size" attribute is set.
  
  This was fixed *two years ago* upstream.  Any chance that we might get
  more recent graphviz packages in Ubuntu at some point?  Failing that, it
  is quite easy to fix this bug.
  
  See https://gitlab.com/graphviz/graphviz/-/issues/1605
  
  The fix is very simple, it seems:
  
https://gitlab.com/graphviz/graphviz/-/commit/a5606d101af1cc949908a6f0bc19caaa4eb31159
  
  Definitely present in 22.04, still present in the Lunar package
  (graphviz_2.42.2-7build3)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015017

Title:
  [SRU] scaling is wrong in SVG output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/2015017/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2015017] Re: [SRU] scaling is wrong in SVG output

[Dave Jones]

Brilliant, thanks very much for that -- I've upload the ocular version
to proposed, and I'll get the SRU uploads done later this morning.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015017

Title:
  [SRU] scaling is wrong in SVG output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/2015017/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #30, bug #63018 (group groff):

[comment #29 comment #29:]
> When it is a separate make target (bug #65698), if we wish to
> retain the epsilon kerns the make target must either re-apply
> the shell script after the font generation, or these "gold" AFMs
> should have the extra kerns added once before we pour aspic on them.

[s/epsilon/ellipsis]

Ah, I see.  In theory I can't see a reason it would matter which way it's done
(though my font knowledge is far smaller than yours).  In practice, the script
for fixing up the kernpairs section post-afmtodit already exists and has been
tested (bug #58897).

> As far as I can tell the "slant" parameter does nothing for
> composite (e.g. a glyph plus an accent glyph on top of each
> other) placement.

As far as I can tell, too, but the sentence in afmtodit(1) says otherwise. 
Perhaps it's erroneous.

> What it does do is affect both italic
> correction factors and the subscript correction,

That makes more sense to me.  But it still doesn't explain why, as you
observed in comment #26, TI should have such a significant adjustment to the
slant value (more than halving the original) but TBI have none.  The metrics
between the two shouldn't be that different.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Alien Waves

[Dave Cohen]

There are some single-market/regional providers that I'm aware of currently
offering spectrum, but I believe you'll be hard pressed to find others with
national footprints in the US that will. Zayo and Lumen both did a bit of a
will they/won't they with it for a long time, and my understanding is that
neither of them currently offer it, or at least will tell you that publicly.

On Sun, May 12, 2024 at 9:48 PM Mike Hammett  wrote:

> "a limited set of providers willing to sell it, if at all."
>
> I know of one (Windstream) that offers it on a portion of their footprint.
> I swore others did, but I couldn't find them. Does anyone know who else in
> the NANOG area who does this?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
> From: Mark Tinka 
> To: Dave Cohen 
> Cc: nanog@nanog.org, Mike Hammett 
> Sent: Sun, 12 May 2024 17:34:19 -0500 (CDT)
> Subject: Re: Alien Waves
>
>
>
> On 5/13/24 00:11, Dave Cohen wrote:
>
> > Mark,
> >
> > Many/all of these points are fair. My experience is purely terrestrial
> and obviously both the capacity and economic calculations are vastly
> different in those situations, which I should have called out.
>
> Actually, terrestrial economics are easier to consider because you have
> the one thing the subsea applications don't have in abundance... power.
>
> Fair point, terrestrial revenues are significantly lower than subsea
> revenues on a per-bit basis, but so are the deployment costs. That evens
> out, somewhat.
>
> > However, I don’t think that the optical vendor is really the challenge -
> I would agree that, generally, spectrum is going to be available through
> larger providers that are using “traditional carrier grade” platforms - but
> rather at the service provider level. When something invariably breaks at 3
> AM and the third shift Tier I NOC tech who hasn’t read the service playbook
> says “I don’t see any errors on your transponder, sorry, it’s not on our
> end” because they’re not aware that they actually don’t have access to the
> transponder and need to start looking elsewhere, that’s the sort of thing
> that creates systemic challenges for users regardless of whether the light
> is being shot across a Ciena 6500 or a Dave’s Box-o’-Lasers 1000.
>
> I think you are contradicting yourself a bit, unless I misunderstand
> your point.
>
> Legacy vendors who have spectrum controllers have made this concern less
> of an issue. But then again, to be fair, adopting spectrum controllers
> along with bandwidth expansions via things like gridless line systems
> and C+L backbone architectures that make spectrum sales a lot more
> viable at scale do come at a hefty $$ premium. So I can understand that
> offering spectrum independent of spectrum controllers is going to be
> more trouble than it is worth.
>
> Ultimately, what I'm saying is that technologically, this is now a
> solved problem, for the most part. That said, I don't think it will be
> the majority of DWDM operators offering spectrum services en masse, for
> at least a few more years. So even if you want to procure managed
> spectrum or spectrum sharing, you are likely to come up against a
> limited set of providers willing to sell it, if at all.
>
> Mark.
>


-- 
- Dave Cohen
craetd...@gmail.com

Re: Alien Waves

[Dave Cohen]

My point was that the technology has little to do with the operational
success of the service. Spectrum controllers better enabling providers to
get out of their own way in selling spectrum did not actually enable the
providers* to get out of their own way in selling spectrum. It *should* be
easier than it used to be, but it isn't, and the problem is not really
technical, but a question of 1) not having full-throated commitment to
wanting to sell spectrum and 2) not having the talent to support it, which
is really just a function of #1.

*Speaking specifically about the very largest CLEC wavelength providers in
North America

On Sun, May 12, 2024 at 6:34 PM Mark Tinka  wrote:

>
>
> On 5/13/24 00:11, Dave Cohen wrote:
>
> Mark,
>
> Many/all of these points are fair. My experience is purely terrestrial and 
> obviously both the capacity and economic calculations are vastly different in 
> those situations, which I should have called out.
>
>
> Actually, terrestrial economics are easier to consider because you have
> the one thing the subsea applications don't have in abundance... power.
>
> Fair point, terrestrial revenues are significantly lower than subsea
> revenues on a per-bit basis, but so are the deployment costs. That evens
> out, somewhat.
>
> However, I don’t think that the optical vendor is really the challenge - I 
> would agree that, generally, spectrum is going to be available through larger 
> providers that are using “traditional carrier grade” platforms - but rather 
> at the service provider level. When something invariably breaks at 3 AM and 
> the third shift Tier I NOC tech who hasn’t read the service playbook says “I 
> don’t see any errors on your transponder, sorry, it’s not on our end” because 
> they’re not aware that they actually don’t have access to the transponder and 
> need to start looking elsewhere, that’s the sort of thing that creates 
> systemic challenges for users regardless of whether the light is being shot 
> across a Ciena 6500 or a Dave’s Box-o’-Lasers 1000.
>
>
> I think you are contradicting yourself a bit, unless I misunderstand your
> point.
>
> Legacy vendors who have spectrum controllers have made this concern less
> of an issue. But then again, to be fair, adopting spectrum controllers
> along with bandwidth expansions via things like gridless line systems and
> C+L backbone architectures that make spectrum sales a lot more viable at
> scale do come at a hefty $$ premium. So I can understand that offering
> spectrum independent of spectrum controllers is going to be more trouble
> than it is worth.
>
> Ultimately, what I'm saying is that technologically, this is now a solved
> problem, for the most part. That said, I don't think it will be the
> majority of DWDM operators offering spectrum services en masse, for at
> least a few more years. So even if you want to procure managed spectrum or
> spectrum sharing, you are likely to come up against a limited set of
> providers willing to sell it, if at all.
>
> Mark.
>


-- 
- Dave Cohen
craetd...@gmail.com

[Elecraft] Elecraft 80M SSB Net Report

[Dave New, N8SBE]

3803 kHz, 9PM ET Sunday (0100Z Monday).

Thanks to the following check ins (w) and relays (rel):

   Call   State Radio/Amp Name
1  N8SBE  OHK4D   Dave
2  AK4TF  GAFlex 6400/KPA500  Tony   (w)
3  WB9JNZ ILFTdx101d/KPA1500  Eric   (rel),(w)
4  W9PCS  WIK4D/KPA500Paul   (rel),(w)
5  K1NW   RIK4D/KPA500Brian   (rel),(w)
6  K1DIH  CTK4D/Tokyo Hi-PowerBrian   (w)
7  K1ND   MIK4/KPA500 Jan   (w)
8  WM6P   GAK4D/KPA1500   Steve   (rel),(w)
9  K8NU   OHK4D/KPA1500   Carl   (w),(c/o)
10 WW4JF  TNK3S/KPA500John   (w)

(Entries with (c/o) indicate a 'one and done' station that checked out 
during the 1st round. (n/h) failed to respond during subsequent rounds.)


We had a total of 10 check ins this week (including the NCS). Very nice 
hearing from everyone tonight, in spite of the fact that the NCS was not 
audible to most of the net, since I was running 100W into a vertical 
from my RV in Ohio. I hope to see all of you again. The net concluded at 
09:26 PM ET.  Sorry for the abbreviated version of the net.


Conditions were poor this evening, as the band was recovering from a 
massive CME earlier in the weekend, and a solar flare that occurred 
earlier today.


We have a really great group of folks checking in, and I encourage 
everyone in the Midwest and adjoining areas to check in next week.


As a reminder, if you go to https://netlogger.org at the net starting 
time and look for the 80M Elecraft SSB Net, you should see the frequency 
we are using that evening, if we must QSY again due to busy frequencies.


73,

-- Dave, N8SBE
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: Alien Waves

[Dave Cohen]

Mark,

Many/all of these points are fair. My experience is purely terrestrial and 
obviously both the capacity and economic calculations are vastly different in 
those situations, which I should have called out. 

However, I don’t think that the optical vendor is really the challenge - I 
would agree that, generally, spectrum is going to be available through larger 
providers that are using “traditional carrier grade” platforms - but rather at 
the service provider level. When something invariably breaks at 3 AM and the 
third shift Tier I NOC tech who hasn’t read the service playbook says “I don’t 
see any errors on your transponder, sorry, it’s not on our end” because they’re 
not aware that they actually don’t have access to the transponder and need to 
start looking elsewhere, that’s the sort of thing that creates systemic 
challenges for users regardless of whether the light is being shot across a 
Ciena 6500 or a Dave’s Box-o’-Lasers 1000.

Dave Cohen
craetd...@gmail.com

> On May 12, 2024, at 5:34 PM, Mark Tinka  wrote:
> 
> 
> 
>> On 5/12/24 20:35, Dave Cohen wrote:
>> It’s one of those things that makes a lot more sense on paper than in 
>> practice.
> 
> Not anymore.
> 
> The majority of SDM subsea cables built with uncompensated fibre are using 
> managed spectrum and spectrum sharing as viable business models for a 
> not-so-insignificant population of their customer base.
> 
> 
>>  I’ve found it to be operationally difficult from the perspective the 
>> provider and the user, primarily but not solely because any “co-managed” 
>> system is going to lend itself to finger pointing when issues arise.
> 
> And there is a case to be made for that concern. However, if you are in a 
> position to be able to sell spectrum, it is very likely you are going to be 
> implementing a vendor of note. Since that is most likely to be the case, 
> those vendors have spectrum controllers that make this a viable business 
> model, albeit at a $$ premium.
> 
> This is not the type of service small DWDM operators using new-age DWDM 
> vendors would typically be looking to sell. Such operators have to deal with 
> keeping the lights on, never mind esoteric services like spectrum.
> 
> 
>>  Even if it makes more commercial sense at first blush to prefer a spectrum 
>> solution over dark or traditional waves, I suspect that factoring in “labor 
>> cost wasted over unproductive troubleshooting” changes the equation a bit.
> 
> Alien wave and spectrum services attract a very high income, mainly through a 
> capex-based upfront cost (IRU) that can be attractive to the host network. At 
> those levels, providing their vendor has decent support for spectrum 
> services, the revenue gain more-than makes up for all the logistical admin.
> 
> 
>>  I also suspect that continued price compression on optical hardware will 
>> lead to fewer and fewer situations where it might make commercial sense at 
>> first blush too.
> 
> Well, legacy DWDM vendors will continue to charge a premium even for what is 
> now standard electrical bandwidth services. Why? Because they still have all 
> that legacy stuff to support, all their R to recoup, and because the bulk 
> of their customers are no longer the telco, but content folk.
> 
> New-age DWDM vendors are focused on coherent optical networks, which are 
> primarily 100G and 400G. Why? Because that is where MSA and OpenROADM are 
> currently at re: commercial availability. The legacy vendors will develop 
> proprietary coherent pluggables that will support funky things such as 800G, 
> 1.2T and 1.6T, but those won't be industry standard for some time (800G is 
> getting there, though).
> 
> What all this means is that if you are a legacy operator that is careful 
> about spending money on newer DWDM technologies, a spectrum service from a 
> larger carrier is going to be more attractive than ripping out your entire 
> line system just so you can get from 10G or 40G to 400G. Of course, if you 
> are a monopoly and have no alternatives to lean on, this doesn't count.
> 
> 
> 
>> YMMV of course and there may be reasons beyond simple commercial models 
>> where spectrum might make sense for you, but I’d urge you to only consider 
>> it doing with a provider where you’ve had a track record of operational 
>> success working with them. 
> 
> New-age DWDM vendors are not the workhorse of most of the large DWDM operator 
> networks out there. That means that any operator of note you are likely to 
> run into is going to be a Ciena, Infinera, Nokia, Adva, e.t.c., house, or 
> something along those lines. Those vendors have reasonable spectrum-based 
> solutions that smaller DWDM operators or ISP's would be willing to spend 
>

[Elecraft] Elecraft 80M SSB Net Announcement

[Dave New, N8SBE]

Please join us on 3803kHz plus (not minus) QRM (see the Netlogger discussion, 
below), 9PM ET Sunday (0100Z Monday). Note that the net stays on the same local 
time, when we switch back and forth to/from Daylight time, so the UTC time 
changes, but not the local time.

As daylight persists more into the evening, we may find it more difficult to 
conduct the net at its regular time.  For the time being, let's keep it at 9PM 
ET, as that is getting late on a 'school night' for a lot of folks, as it is.

Your net control this week will be Dave, N8SBE. Note that I'm portable and 
running 100w this week, so relays will be much appreciated. 

The group that meets on 3803 kHz before us has been wrapping up operations 
promptly at or before 9PM ET.  There is also another group that normally comes 
on at 10PM ET, so we need to make sure to wrap up operations by 10PM ET.  If 
any stations wish to continue past that time, please QSY to a clear frequency.

If you are a US General class licensee, please ensure that your dial is 
accurately calibrated and that your transmitter/amplifier combination is clean 
and free of splatter, since we will be operating LSB within 3 kHz of the lower 
band edge of the 80M US General class band.

I'm using Netlogger, so if you go to netlogger.org and look for the 80M 
Elecraft SSB Net, you will be able to see the exact frequency we've settled on 
for the evening.  If we find 3803 kHz busy, we will move UP the band a few kHz, 
so we can stay in the 80M US General class band.

Hope to see you this evening on the net.

73,

-- Dave, N8SBE
__
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com 

Re: Alien Waves

[Dave Cohen]

It’s one of those things that makes a lot more sense on paper than in practice. 
I’ve found it to be operationally difficult from the perspective the provider 
and the user, primarily but not solely because any “co-managed” system is going 
to lend itself to finger pointing when issues arise. Even if it makes more 
commercial sense at first blush to prefer a spectrum solution over dark or 
traditional waves, I suspect that factoring in “labor cost wasted over 
unproductive troubleshooting” changes the equation a bit. I also suspect that 
continued price compression on optical hardware will lead to fewer and fewer 
situations where it might make commercial sense at first blush too. 

YMMV of course and there may be reasons beyond simple commercial models where 
spectrum might make sense for you, but I’d urge you to only consider it doing 
with a provider where you’ve had a track record of operational success working 
with them. 

Dave Cohen
craetd...@gmail.com

> On May 12, 2024, at 2:17 PM, Mike Hammett  wrote:
> 
> What are your experiences with alien waves, managed spectrum, spectrum as a 
> service, etc?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com

Re: Browsing Time Machine

[Dave Carlson]

Ian,

That may work, but I think first you need to select the backup file and open 
the image mounter to get it added to the desktop.

Dave Carlson
Farfar, Oregonian, Engineer, Woodworker, Musician
dgcarlson0...@gmail.com




On May 12, 2024, at 10:41 AM, Ian Robinson  wrote:

When I’ve checked my own Time Machine backups, the easiest way seems to be to 
open the drive and navigate the folders in Finder in the usual way.

My Time Machine drive is set to show up on the Desktop. 
After pressing Command+o on the drive, there was a list of folders named with 
the date of the various backups, with the newest at the bottom of the list.
Within each of the folders there was a Data folder.
The contents of the Data folder is the same as the SSD of the MacBook. I could 
navigate to my user folder and open Documents, Downloads, etc. I didn’t 
actually try copying anything from the backup at the time.

Ian




> On 12 May 2024, at 17:19, Dave Carlson  wrote:
> 
> E.T.
> 
> Here’s a text file I copied a few years back. Process seems a bit squirrely 
> but I think I’ve managed to use it a couple times.
> 
> Restore a File Using Time Machine
> 
> Position on desired folder
> Extras menu, Time Machine
> Enter Time Machine; wait until finished
> Control-Option F1
> Finder in Time Machine
> Control-Option F2 Twice (or for me, Opt-W) for window chooser
> Arrow down to Time Machine Controls
> Press Enter
> Gives a most recent date
> Control-Option LeftArrow
> Brings up Timeline
> Control-Option DownArrow
> Find a backup date of interest
> Ctrl-Option J to Jump to list
> Arrow to find desired file
> Ctrl-Opt F2 twice (Opt-w) to window list to find Time Machine Controls
> Ctrl-Opt UpArrow to dismiss backup list
> Ctrl-Option Right arrow to Restore button
> 
> 
> Dave Carlson
> Woodworker, Musician, Oregonian, Engineer,  Farfar
> dgcarlson0...@gmail.com
> 
> 
> 
> On May 11, 2024, at 2:54 PM, 'E.T.' via MacVisionaries 
>  wrote:
> 
> Hello,
>  When selecting this option from the status bar, how does one navigate the 
> backup? I was trying to find a particular folder in the Finder. Thanks.
> 
> From E.T.'s Keyboard...
> "Alone we can do so little; together we can do so much."
> -Helen Keller
> My e-Mail:
> ancient.ali...@icloud.com
> 
> -- 
> The following information is important for all members of the Mac Visionaries 
> list.
> 
> If you have any questions or concerns about the running of this list, or if 
> you feel that a member's post is inappropriate, please contact the owners or 
> moderators directly rather than posting on the list itself.
> 
> Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
> mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
> caraqu...@caraquinn.com
> 
> The archives for this list can be searched at:
> http://www.mail-archive.com/macvisionaries@googlegroups.com/
> --- You received this message because you are subscribed to the Google Groups 
> "MacVisionaries" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to macvisionaries+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/macvisionaries/db6d3af2-9e8b-4261-8bf5-bf5166a75bff%40icloud.com.
> 
> 
> -- 
> The following information is important for all members of the Mac Visionaries 
> list.
> 
> If you have any questions or concerns about the running of this list, or if 
> you feel that a member's post is inappropriate, please contact the owners or 
> moderators directly rather than posting on the list itself.
> 
> Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: 
> mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
> caraqu...@caraquinn.com
> 
> The archives for this list can be searched at:
> http://www.mail-archive.com/macvisionaries@googlegroups.com/
> --- 
> You received this message because you are subscribed to the Google Groups 
> "MacVisionaries" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to macvisionaries+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/macvisionaries/30DF650C-C508-4092-8839-FEA2151A1381%40gmail.com.

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you ca

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[Dave]

Update of bug #65702 (group groff):

  Status:   Need Info => None   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #28, bug #63018 (group groff):

[comment #27 comment #27:]
> And Dave just happens to be right here, ready for the spotlight. ;-)

Oh, heavens no, I still need at least 15 more minutes in makeup.  Have the
emcee stall!

[If there's a question for me here, I'm not sure what it is.]

> > Maybe some people on the list may know.
> 
> I'm afraid I don't have any insight into that decision.

Everything I know about it is in bug #57506.  It would help if afmtodit(1)'s
claim "the slant ("angle") parameter in the font description file...is used by
groff in the positioning of accents" were more forthcoming on just how groff
uses this value so.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63018>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Browsing Time Machine

[Dave Carlson]

E.T.

Here’s a text file I copied a few years back. Process seems a bit squirrely but 
I think I’ve managed to use it a couple times.

Restore a File Using Time Machine

Position on desired folder
Extras menu, Time Machine
Enter Time Machine; wait until finished
Control-Option F1
Finder in Time Machine
Control-Option F2 Twice (or for me, Opt-W) for window chooser
Arrow down to Time Machine Controls
Press Enter
Gives a most recent date
Control-Option LeftArrow
Brings up Timeline
Control-Option DownArrow
Find a backup date of interest
Ctrl-Option J to Jump to list
Arrow to find desired file
Ctrl-Opt F2 twice (Opt-w) to window list to find Time Machine Controls
Ctrl-Opt UpArrow to dismiss backup list
Ctrl-Option Right arrow to Restore button


Dave Carlson
Woodworker, Musician, Oregonian, Engineer,  Farfar
dgcarlson0...@gmail.com



On May 11, 2024, at 2:54 PM, 'E.T.' via MacVisionaries 
 wrote:

Hello,
  When selecting this option from the status bar, how does one navigate the 
backup? I was trying to find a particular folder in the Finder. Thanks.

>From E.T.'s Keyboard...
"Alone we can do so little; together we can do so much."
-Helen Keller
My e-Mail:
ancient.ali...@icloud.com

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/db6d3af2-9e8b-4261-8bf5-bf5166a75bff%40icloud.com.

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/30DF650C-C508-4092-8839-FEA2151A1381%40gmail.com.

[bug #65724] drop support for CCSID (code page) 1047 (EBCDIC)

[Dave]

Follow-up Comment #1, bug #65724 (group groff):

[comment #0 original submission:]
> See discussion with Mike Fulton of IBM on the _groff_ list a year ago.
> 
> https://lists.gnu.org/archive/html/groff/2023-03/msg00113.html

Discussion continues at http://lists.gnu.org/r/groff/2023-04/msg3.html
with more background on the affected OSes.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione edited 
https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione edited 
https://github.com/llvm/llvm-project/pull/91868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] lldb Support custom LLVM formatting for variables (PR #91868)

[Dave Lee via lldb-commits]

https://github.com/kastiglione created 
https://github.com/llvm/llvm-project/pull/91868

- **[lldb] Support custom LLVM formatting for variables (#81196)**
- **[lldb] Handle non-existent llvm_format**


>From 30a36018b9c96d7ddd969815ef850987d781338e Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Tue, 30 Apr 2024 10:45:10 -0700
Subject: [PATCH 1/2] [lldb] Support custom LLVM formatting for variables
 (#81196)

Adds support for applying LLVM formatting to variables.

The reason for this is to support cases such as the following.

Let's say you have two separate bytes that you want to print as a
combined hex value. Consider the following summary string:

```
${var.byte1%x}${var.byte2%x}
```

The output of this will be: `0x120x34`. That is, a `0x` prefix is
unconditionally applied to each byte. This is unlike printf formatting
where you must include the `0x` yourself.

Currently, there's no way to do this with summary strings, instead
you'll need a summary provider in python or c++.

This change introduces formatting support using LLVM's formatter system.
This allows users to achieve the desired custom formatting using:

```
${var.byte1:x-}${var.byte2:x-}
```

Here, each variable is suffixed with `:x-`. This is passed to the LLVM
formatter as `{0:x-}`. For integer values, `x` declares the output as
hex, and `-` declares that no `0x` prefix is to be used. Further, one
could write:

```
${var.byte1:x-2}${var.byte2:x-2}
```

Where the added `2` results in these bytes being written with a minimum
of 2 digits.

An alternative considered was to add a new format specifier that would
print hex values without the `0x` prefix. The reason that approach was
not taken is because in addition to forcing a `0x` prefix, hex values
are also forced to use leading zeros. This approach lets the user have
full control over formatting.
---
 lldb/docs/use/variable.rst|  9 +++
 lldb/source/Core/FormatEntity.cpp | 70 ---
 .../custom-printf-summary/Makefile|  2 +
 .../TestCustomSummaryLLVMFormat.py| 20 ++
 .../custom-printf-summary/main.c  | 13 
 5 files changed, 104 insertions(+), 10 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/TestCustomSummaryLLVMFormat.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/custom-printf-summary/main.c

diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index 8eaed6405315b..e9175b25336ba 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -460,6 +460,15 @@ summary strings, regardless of the format they have 
applied to their types. To
 do that, you can use %format inside an expression path, as in ${var.x->x%u},
 which would display the value of x as an unsigned integer.
 
+Additionally, custom output can be achieved by using an LLVM format string,
+commencing with the ``:`` marker. To illustrate, compare ``${var.byte%x}`` and
+``${var.byte:x-}``. The former uses lldb's builtin hex formatting (``x``),
+which unconditionally inserts a ``0x`` prefix, and also zero pads the value to
+match the size of the type. The latter uses ``llvm::formatv`` formatting
+(``:x-``), and will print only the hex value, with no ``0x`` prefix, and no
+padding. This raw control is useful when composing multiple pieces into a
+larger whole.
+
 You can also use some other special format markers, not available for formats
 themselves, but which carry a special meaning when used in this context:
 
diff --git a/lldb/source/Core/FormatEntity.cpp 
b/lldb/source/Core/FormatEntity.cpp
index ba62e26252591..da5b1cfce74ac 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -57,6 +57,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/Regex.h"
 #include "llvm/TargetParser/Triple.h"
 
 #include 
@@ -658,6 +659,38 @@ static char ConvertValueObjectStyleToChar(
   return '\0';
 }
 
+static llvm::Regex LLVMFormatPattern{"x[-+]?\\d*|n|d", 
llvm::Regex::IgnoreCase};
+
+static bool DumpValueWithLLVMFormat(Stream , llvm::StringRef options,
+ValueObject ) {
+  std::string formatted;
+  std::string llvm_format = ("{0:" + options + "}").str();
+
+  // Options supported by format_provider for integral arithmetic types.
+  // See table in FormatProviders.h.
+
+  auto type_info = valobj.GetTypeInfo();
+  if (type_info & eTypeIsInteger && LLVMFormatPattern.match(options)) {
+if (type_info & eTypeIsSigned) {
+  bool success = false;
+  int64_t integer = valobj.GetValueAsSigned(0, );
+  if (success)
+formatted = llvm::formatv(llvm_format.data(), integer);
+} else {
+  

[Bug 2015017] Re: [SRU] scaling is wrong in SVG output

[Dave Jones]

For SRU purposes, is there any chance I could ask you for a simple
reproducer case? It's okay if it uses jupyter, but I'm struggling to
come up with one without it and I've run out of time this evening.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015017

Title:
  [SRU] scaling is wrong in SVG output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/2015017/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2015017] Re: scaling is wrong in SVG output

[Dave Jones]

I quite understand the frustration with something that appears to be
abandoned. However, in this case it seems it was actually down to some
confusion over the versioning scheme which changed upstream from Debian
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980900 has the gory
details). It also seems that Debian's now got a new watch file and
version 11 is now in experimental, so I'm hoping that'll migrate to
unstable at some point and we'll pick up a modern version for oracular.

Anyway, back to the fix at hand -- this definitely needs patching in
oracular, noble, mantic, and jammy at the very least. Unfortunately your
branch appears to have diff-markers embedded in it, so I can't accept it
directly, but the patch is trivial enough I can just apply it to the
package directly. I'll target this to the affected releases and start
the SRU process once this is in oracular.

** Bug watch added: Debian Bug tracker #980900
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980900

** Also affects: graphviz (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Also affects: graphviz (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: graphviz (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Changed in: graphviz (Ubuntu)
   Status: New => Confirmed

** Changed in: graphviz (Ubuntu Jammy)
   Status: New => Confirmed

** Changed in: graphviz (Ubuntu Mantic)
   Status: New => Confirmed

** Changed in: graphviz (Ubuntu Noble)
   Status: New => Confirmed

** Summary changed:

- scaling is wrong in SVG output
+ [SRU] scaling is wrong in SVG output

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2015017

Title:
  [SRU] scaling is wrong in SVG output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/2015017/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Lldb-commits] [lldb] baffaf0 - [lldb] Add required skipIfLLVMTargetMissing for X86 (NFC)

[Dave Lee via lldb-commits]

Author: Dave Lee
Date: 2024-05-11T11:48:31-07:00
New Revision: baffaf000fd4667f33b3756d0d3b645b1d926b44

URL: 
https://github.com/llvm/llvm-project/commit/baffaf000fd4667f33b3756d0d3b645b1d926b44
DIFF: 
https://github.com/llvm/llvm-project/commit/baffaf000fd4667f33b3756d0d3b645b1d926b44.diff

LOG: [lldb] Add required skipIfLLVMTargetMissing for X86 (NFC)

Added: 


Modified: 
lldb/test/API/macosx/rosetta/TestRosetta.py
lldb/test/API/macosx/universal64/TestUniversal64.py

Removed: 




diff  --git a/lldb/test/API/macosx/rosetta/TestRosetta.py 
b/lldb/test/API/macosx/rosetta/TestRosetta.py
index ce40de475ef16..a812f558a8fc9 100644
--- a/lldb/test/API/macosx/rosetta/TestRosetta.py
+++ b/lldb/test/API/macosx/rosetta/TestRosetta.py
@@ -40,6 +40,7 @@ class TestRosetta(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @skipUnlessAppleSilicon
+@skipIfLLVMTargetMissing("X86")
 @skipIfDarwinEmbedded
 def test_rosetta(self):
 """There can be many tests in a test case - describe this test here."""

diff  --git a/lldb/test/API/macosx/universal64/TestUniversal64.py 
b/lldb/test/API/macosx/universal64/TestUniversal64.py
index 98661443086ef..893ff14d81138 100644
--- a/lldb/test/API/macosx/universal64/TestUniversal64.py
+++ b/lldb/test/API/macosx/universal64/TestUniversal64.py
@@ -17,6 +17,7 @@ def do_test(self):
 # actually launch them here.
 
 # The Makefile manually invokes clang.
+@skipIfLLVMTargetMissing("X86")
 @skipIfAsan
 @skipUnlessDarwin
 @skipIfDarwinEmbedded
@@ -26,6 +27,7 @@ def test_universal64_executable(self):
 self.do_test()
 
 # The Makefile manually invokes clang.
+@skipIfLLVMTargetMissing("X86")
 @skipIfAsan
 @skipUnlessDarwin
 @skipIfDarwinEmbedded



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Bug 2065493] [NEW] Please merge rpi-lgpio 0.6

[Dave Jones]

Public bug reported:

New upstream version fixes future re-numbering of the gpiochip device on
Pi 5.

** Affects: rpi-lgpio (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065493

Title:
  Please merge rpi-lgpio 0.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rpi-lgpio/+bug/2065493/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: Hungarumlauts in built-in fonts

[Dave Kemper]

On Fri, May 10, 2024 at 1:50 AM Gáspár Gergő  wrote:
> I realized, however, that the "hungarumlauts" on the ő Ő ű and Ű glyphs are 
> placed incorrectly in the built-in fonts of groff used for the pdf device.

Does this mean the problem doesn't happen for the ps device?  Or have
you not tried that?

[Bug 2060677] Re: Consistent (zfs?) errors at shutdown

[Dave Jones]

Yes, I'm afraid so. In fact I'm occasionally seeing it on boot as well
which seems to result in wayland crashing and the session falling back
to X11. Here's the backtrace from a crash on startup which resulted in
me starting an X11 session (and then wondering why the cursor

[   47.898381] spl: loading out-of-tree module taints kernel.
[   47.957978] zfs: module license 'CDDL' taints kernel.
[   47.957986] Disabling lock debugging due to kernel taint
[   47.958013] zfs: module license taints kernel.
[   47.986141] Initializing XFRM netlink socket
[   48.872585] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: 
{ 3- } 22 jiffies s: 921 root: 0x8/.
[   48.872601] rcu: blocking rcu_node structures (internal RCU debug):
[   48.872605] Sending NMI from CPU 0 to CPUs 3:
[   48.872610] NMI backtrace for cpu 3
[   48.872616] CPU: 3 PID: 2797 Comm: modprobe Tainted: P C OE  
6.8.0-1004-raspi #4-Ubuntu
[   48.872619] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[   48.872621] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   48.872625] pc : g+0x44/0x80 [zfs]
[   48.872998] lr : round_fn+0x124/0x1a8 [zfs]
[   48.873282] sp : 800083b3a9f0
[   48.873283] x29: 800083b3a9f0 x28: 0010 x27: 0001
[   48.873288] x26: 0002 x25: 0010 x24: 0040
[   48.873291] x23: 0010 x22: 3c6e x21: 800083b3aac8
[   48.873294] x20: a0001eeb1f08 x19: 800083b3aa38 x18: 
[   48.873298] x17:  x16: a00084e64e20 x15: daab804bbe5f084f
[   48.873301] x14: dda7b2c9fd2e0cf6 x13: 8ea05092eab4a56e x12: 7e3c7900fc64dbc7
[   48.873304] x11: 7e3c7900fc64dbc7 x10: a0001ea5ba80 x9 : 
[   48.873308] x8 : e60eea37 x7 : d00f75b3 x6 : fffd
[   48.873311] x5 : fc4d5ec9 x4 : 000c x3 : 000b
[   48.873314] x2 : 0006 x1 : 0001 x0 : 800083b3aac8
[   48.873317] Call trace:
[   48.873319]  g+0x44/0x80 [zfs]
[   48.873589]  compress_pre+0x1e4/0x270 [zfs]
[   48.873861]  blake3_compress_in_place_generic+0x4c/0xa8 [zfs]
[   48.874133]  hash_one_generic+0x78/0xf0 [zfs]
[   48.874402]  blake3_hash_many_generic+0x74/0xb0 [zfs]
[   48.874672]  compress_chunks_parallel+0xe8/0x1d8 [zfs]
[   48.874942]  blake3_compress_subtree_wide+0x1a4/0x1c8 [zfs]
[   48.875210]  blake3_compress_subtree_wide+0xd8/0x1c8 [zfs]
[   48.875477]  blake3_compress_subtree_wide+0xd8/0x1c8 [zfs]
[   48.875744]  blake3_compress_subtree_wide+0xb0/0x1c8 [zfs]
[   48.876009]  blake3_compress_subtree_wide+0xd8/0x1c8 [zfs]
[   48.876275]  compress_subtree_to_parent_node+0x50/0x110 [zfs]
[   48.876542]  Blake3_Update2+0x168/0x240 [zfs]
[   48.876809]  Blake3_Update+0x54/0x80 [zfs]
[   48.877074]  blake3_incremental+0x2c/0x40 [zfs]
[   48.877341]  abd_iterate_func+0x104/0x150 [zfs]
[   48.877608]  abd_checksum_blake3_native+0x7c/0xb8 [zfs]
[   48.877875]  chksum_run+0xac/0x160 [zfs]
[   48.878145]  chksum_benchit+0x140/0x198 [zfs]
[   48.878412]  chksum_benchmark+0x334/0x3a8 [zfs]
[   48.878681]  chksum_init+0x28/0xa8 [zfs]
[   48.878950]  spa_init+0x130/0x168 [zfs]
[   48.879221]  zfs_kmod_init+0x4c/0x108 [zfs]
[   48.879489]  openzfs_init_os+0x1c/0xc8 [zfs]
[   48.879755]  openzfs_init+0x70/0xcd0 [zfs]
[   48.880023]  do_one_initcall+0x4c/0x368
[   48.880029]  do_init_module+0xa0/0x260
[   48.880034]  load_module+0x790/0x8c8
[   48.880037]  init_module_from_file+0x94/0xf8
[   48.880040]  idempotent_init_module+0x178/0x2a8
[   48.880043]  __arm64_sys_finit_module+0x6c/0xd8
[   48.880047]  invoke_syscall+0x50/0x120
[   48.880049]  el0_svc_common.constprop.0+0x48/0xf0
[   48.880051]  do_el0_svc+0x24/0x38
[   48.880053]  el0_svc+0x48/0x178
[   48.880057]  el0t_64_sync_handler+0x120/0x130
[   48.880059]  el0t_64_sync+0x1a8/0x1b0
[   48.970724] ZFS: Loaded module v2.2.2-0ubuntu9, ZFS pool version 5000, ZFS 
filesystem version 5
[   49.798958] Key type psk registered

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2060677

Title:
  Consistent (zfs?) errors at shutdown

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2060677/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065180] Re: performance regression in dracut-install

[Dave Jones]

@viraniac well, you're absolutely right! Same SD card with a fresh noble
install, running on a Pi 4, first stock and second with a downgraded
dracut from mantic:

Pi 4B, stock -- 03:05
Pi 4B, downgrade -- 01:10

That is a pretty substantial regression, and diff'ing the initrds once
more showed they're basically identical in content (unsurprisingly), so
it's not writing any less. I wonder if it's added some sync points or
something similar.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065180

Title:
  performance regression in dracut-install

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dracut/+bug/2065180/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint)

[Dave Crocker]

On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
* Prior to accepting any Standards Track document for development, 
there must

be a commitment to implement the resulting proposed standard from at least
two independent parties, as recorded on a related IETF mailing list.

* When deciding to send any Standards Track work to the IESG, there must
first be produced a report documenting at least two (preferably more)
independent implementations with at least partial interoperation based 
on the

developed specification.



This imposes two, formal requirements for Standards Track that are 
dramatically higher barriers than is typical for IETF Standards Track 
specification.


What is the justification for this deviation from IETF norm?

And, obviously, if it is reasonable here, why is is not universally 
reasonable, as a basic barrier for all specifications going on Standards 
Track?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[git pull] drm fixes for 6.9 final

[Dave Airlie]

Hi Linus,

This should be the last set of fixes for 6.9, i915, xe and amdgpu are
the bulk here, one of the previous nouveau fixes turned up an issue,
so reverting it, otherwise one core and a couple of meson fixes.

drm-fixes-2024-05-11:
drm fixes for 6.9 final

core:
- fix connector debugging output

i915:
- Automate CCS Mode setting during engine resets
- Fix audio time stamp programming for DP
- Fix parsing backlight BDB data

xe:
- Fix use zero-length element array
- Move more from system wq to ordered private wq
- Do not ignore return for drmm_mutex_init

amdgpu:
- DCN 3.5 fix
- MST DSC fixes
- S0i3 fix
- S4 fix
- HDP MMIO mapping fix
- Fix a regression in visible vram handling

amdkfd:
- Spatial partition fix

meson:
- dw-hdmi: power-up fixes
- dw-hdmi: add badngap setting for g12

nouveau:
- revert SG_DEBUG fix that has a side effect
The following changes since commit dd5a440a31fae6e459c0d627162825505361:

  Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-05-11

for you to fetch changes up to a222a6470d7eea91193946e8162066fa88da64c2:

  Revert "drm/nouveau/firmware: Fix SG_DEBUG error with
nvkm_firmware_ctor()" (2024-05-11 07:04:10 +1000)


drm fixes for 6.9 final

core:
- fix connector debugging output

i915:
- Automate CCS Mode setting during engine resets
- Fix audio time stamp programming for DP
- Fix parsing backlight BDB data

xe:
- Fix use zero-length element array
- Move more from system wq to ordered private wq
- Do not ignore return for drmm_mutex_init

amdgpu:
- DCN 3.5 fix
- MST DSC fixes
- S0i3 fix
- S4 fix
- HDP MMIO mapping fix
- Fix a regression in visible vram handling

amdkfd:
- Spatial partition fix

meson:
- dw-hdmi: power-up fixes
- dw-hdmi: add badngap setting for g12

nouveau:
- revert SG_DEBUG fix that has a side effect


Agustin Gutierrez (2):
  drm/amd/display: Fix DSC-re-computing
  drm/amd/display: MST DSC check for older devices

Alex Deucher (1):
  drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

Andi Shyti (1):
  drm/i915/gt: Automate CCS Mode setting during engine resets

Chaitanya Kumar Borah (1):
  drm/i915/audio: Fix audio time stamp programming for DP

Daniele Ceraolo Spurio (1):
  drm/xe/guc: Check error code when initializing the CT mutex

Dave Airlie (5):
  Merge tag 'drm-intel-fixes-2024-05-08' of
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes
  Merge tag 'drm-xe-fixes-2024-05-09' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
  Merge tag 'amd-drm-fixes-6.9-2024-05-10' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2024-05-10' of
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
  Revert "drm/nouveau/firmware: Fix SG_DEBUG error with
nvkm_firmware_ctor()"

Douglas Anderson (1):
  drm/connector: Add \n to message about demoting connector force-probes

Jerome Brunet (2):
  drm/meson: dw-hdmi: power up phy on device init
  drm/meson: dw-hdmi: add bandgap setting for g12

Karthikeyan Ramasubramanian (1):
  drm/i915/bios: Fix parsing backlight BDB data

Lijo Lazar (1):
  Revert "drm/amdkfd: Add partition id field to location_id"

Lucas De Marchi (1):
  drm/xe/ads: Use flexible-array

Mario Limonciello (1):
  dm/amd/pm: Fix problems with reboot/shutdown for some SMU
13.0.4/13.0.11 users

Matthew Brost (1):
  drm/xe: Use ordered WQ for G2H handler

Michel Dänzer (1):
  drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible

Nicholas Kazlauskas (1):
  drm/amd/display: Fix idle optimization checks for multi-display
and dual eDP

Nicholas Susanto (1):
  drm/amd/display: Enable urgent latency adjustments for DCN35

 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   7 +-
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |   5 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  16 ++-
 .../gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c   |   4 +-
 .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c|  33 --
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c   |   2 +-
 drivers/gpu/drm/drm_connector.c|   2 +-
 drivers/gpu/drm/i915/display/intel_audio.c | 113 ++---
 drivers/gpu/drm/i915/display/intel_bios.c  |  19 +---
 drivers/gpu/drm/i915/display/intel_vbt_defs.h  |   5 -
 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c|   6 +-
 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h|   2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c|   4 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c  |  70 ++---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c   |  19 ++--
 d

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

[Dave Hansen]

On 5/10/24 12:06, Dongli Zhang wrote:
>   } else {
> + /*
> +  * This call borrows from the comments and implementation
> +  * of apic_update_vector(): "If the target CPU is offline
> +  * then the regular release mechanism via the cleanup
> +  * vector is not possible and the vector can be immediately
> +  * freed in the underlying matrix allocator.".
> +  */
> + irq_matrix_free(vector_matrix, apicd->prev_cpu,
> + apicd->prev_vector, apicd->is_managed);
>   apicd->prev_vector = 0;
>   }

I know it's just two sites, but I'd much rather spend the space on a
helper function than a copy-and-pasted comment.  Wouldn't something like
this make it like stupidly obvious what's going on:

if (cpu_online(cpu)) {
...
} else {
irq_matrix_free_offline(apicd->prev_cpu,
apicd->prev_vector,
apicd->is_managed);
apicd->prev_vector = 0;
}

/* Free a vector when the target CPU is offline */
static void irq_matrix_free_offline(...)
{
lockdep_assert_held(_lock);
WARN_ON_ONCE(!cpu_offline(apicd->prev_cpu));

/*
 * The regular release mechanism via the cleanup vector is not
 * possible.  Immediately free the vector in the underlying
 * matrix allocator.
 */
irq_matrix_free(, cpu, vector, managed);
}

It would also be rather hard to screw up even if someone called it on an
online CPU because you'd get a nice warning.

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Dave Taht via Nnagain]

I have not read this but I am pretty sure it does not ban fair queuing.

On Friday, May 10, 2024, Mike Conlow via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> I'm sure this was a difficult thing to write a regulation on. I'm glad the
> FCC took a swing. Here's why:
>
> If the Internet community wants to [continue] to develop technologies
> where applications (or users) can signal a need for low latency treatment
> and other networks in the path can honor that need -- great.
>
> But one of the networks in the chain -- the access network -- making the
> determination of what types of traffic get the low latency treatment, in my
> personal opinion is reasonably interpreted as throttling.
>
> I think it's also worth noting that these rules only apply to last-mile
> mass-market ISP plans. And any network is still free to offer "network
> slicing" as an enterprise offering, which I'm sure they will.
>
> On Fri, May 10, 2024 at 10:32 AM Frantisek Borsik via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
>
>> "Net neutrality proponents argued that these separate lanes for different
>> kinds of traffic would degrade performance of traffic that isn't favored.
>> The final FCC order released yesterday addresses that complaint.
>>
>> "We clarify that a BIAS [Broadband Internet Access Service] provider's
>> decision to speed up 'on the basis of Internet content, applications, or
>> services' would 'impair or degrade' other content, applications, or
>> services which are not given the same treatment," the FCC's final order
>> said.
>>
>> The "impair or degrade" clarification means that speeding up is banned
>> because the no-throttling rule says that ISPs "shall not impair or degrade
>> lawful Internet traffic on the basis of Internet content, application, or
>> service."
>>
>> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-
>> prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.bor...@gmail.com
>> ___
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>

-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg=1098s Waves Podcast
Dave Täht CSO, LibreQos
___
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

Re: [LibreQoS] Libreqos at battlemesh?

[Dave Taht via LibreQoS]

We don’t have hw in the eu. Basically a multi core x86 box with 4 or more
hardware network queues is needed. Does not need to be very high end but
the drivers need full bpf support.

Maybe the libreqos list has some low end suggestions

https://libreqos.readthedocs.io/en/latest/docs/SystemRequirements/Compute.html

On Thursday, May 9, 2024, Arınç ÜNAL  wrote:

> If you have the hardware, bring it!
>
> Arınç
>
> On 10/05/2024 07:43, Dave Taht via Battlemesh wrote:
>
>> It would be so cool to slam a libreqos box inline with either your uplink
>> or the testbed and show yall all thr cool stats.
>>
>>
>>
>> ___
>> Battlemesh mailing list
>> battlem...@ml.ninux.org
>> https://ml.ninux.org/mailman/listinfo/battlemesh
>>
>

-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg=1098s Waves Podcast
Dave Täht CSO, LibreQos
___
LibreQoS mailing list
LibreQoS@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos

Re: [VOTE] Apache StormCrawler (Incubating) 3.0 Release Candidate 2

[Dave Fisher]

> On May 9, 2024, at 9:50 PM, Richard Zowalla  wrote:
> 
> Noted, thx! 
> 
> I have created some issues to track the feedback received so far:
> 
> - (1) https://github.com/apache/incubator-stormcrawler/issues/1214
> - (2) https://github.com/apache/incubator-stormcrawler/issues/1215
> - (3) https://github.com/apache/incubator-stormcrawler/issues/1216
> - (4) https://github.com/apache/incubator-stormcrawler-site/issues/26
> 
> I think we can address (1),(2),(4) of them right now without doing a re-roll 
> of the release candidate. I would postpone the update of the RAT exclusions 
> after we have received additional thoughts on the general@ VOTE thread.
> 
> However, I am wondering about the following:
> 
> (a) Do you think we should address the difference between the tag and the 
> source artifact too? (In the sense of reproducible builds, it would make 
> sense imho - WDYT?)

The tag is just a GitHub thing and it is essentially everything in the branch 
automatically. If the project wishes to “release” GitHub workflows and 
templates then yes. I’m not sure if there is any value in releasing the 
.asf.yaml file. ASF Projects release a source package of what’s needed to 
build. Reproducible builds are about source builds producing identical binaries 
and I don’t see why these edge case files would ever be included in a binary.

IMO - the tag and the release don’t have to match. I think the main reason I 
mentioned the difference was to highlight that what’s important is the source 
release and not the tag on GitHub is the release.

> 
> (b) From your experience: would it make sense to just fix that and just do a 
> re-roll with fixed licenses for these files to avoid unnecessary cycles? 
> Personally, I don't mind adding them and if it saves cycles, we should just 
> fix that :-)

There is a third option here. We could create a LEGAL Jira and then discuss 
which file types absolutely require an Apache License header. I know that some 
are fine with a link in a comment at the top of a markdown file. I don’t know 
if there is a recent definitive answer.

The VP, Legal is responsible for licensing requirements and not the Incubator. 
The Incubator is responsible for teaching. So really the gap is in documenting 
acceptable choices.

I hope to find time to look into this more over the weekend.

Best,
Dave

> 
> Thx und Gruß 
> Richard 
> 
> Am 10. Mai 2024 03:36:13 MESZ schrieb Dave Fisher :
>> You are correct. When we go to general@incubator swap Source with Maven.
>> 
>>> On May 9, 2024, at 1:45 PM, Richard Zowalla  wrote:
>>> 
>>> https://dist.apache.org/repos/dist/dev/incubator/stormcrawler/stormcrawler-3.0/
>>>  is contained in the mail in the "Source" section? 
>>> 
>>> The Rat excludes are defined in the related plugin config, which can be 
>>> updated, if needed.
>>> 
>>> 
>>> Am 9. Mai 2024 22:04:40 MESZ schrieb Dave Fisher :
>>>> Once this VOTE passes here you must include the link to 
>>>> https://dist.apache.org/repos/dist/dev/incubator/stormcrawler/stormcrawler-3.0/
>>>>  artifacts in the IPMC VOTE. If you don’t then it will be a quick -1.
>>>> 
>>>> The artifacts in 
>>>> https://dist.apache.org/repos/dist/dev/incubator/stormcrawler/stormcrawler-3.0/
>>>>  are what we must check and vote on. We can compare this with GitHub tags 
>>>> to verify they have the same content.
>>>> 
>>>> On https://stormcrawler.staged.apache.org/download/index.html the sha and 
>>>> asc should use downloads.apache.org instead of closer.cgi. The source 
>>>> release should use closer.lua instead of closer.cgi.
>>>> 
>>>> Ask on #asfinfra slack if you want to confirm the proper use of downloads 
>>>> and closer.lua.
>>>> 
>>>> It is likely that the IPMC VOTE will discuss some of the yaml, md, sh, and 
>>>> txt requiring a License header if the format supports it. I know that json 
>>>> and ndjson (jsonl) files don’t support this. Files which do not support a 
>>>> License header ought to be listed in a .rat-excludes file.
>>>> 
>>>> It is up to you about fixing this now or going ahead with fixing this now.
>>>> 
>>>> I’m VOTING +1 (binding) for now.
>>>> 
>>>> I checked the signature and checksum and they are good. LICENSE and NOTICE 
>>>> are good for a source release. The GitHub tag include the .github 
>>>> directory and .asf.yaml while the source release adds DEPENDENCIES
>>>> 
>>>> Best,
>>>> Dave
>>>> 
>>>>&g

[Bug 2065408] [NEW] growroot-almost should be inhibitable from boot partition

[Dave Jones]

Public bug reported:

Some users wish to handle post-boot partitioning or fs configuration
themselves. For this use-case it is important that the rootfs is *not*
expanded on first boot. On the server images, this is relatively trivial
by appending "growpart: off", but on the desktop images it's handled by
the growroot-almost service and this is only capable of being inhibited
by touching /etc/growroot-grown. It should be possible to inhibit this
behaviour from the boot partition only which, being FAT, can be mounted
from other OS'.

** Affects: ubuntu-raspi-settings (Ubuntu)
 Importance: Undecided
 Assignee: Dave Jones (waveform)
 Status: Confirmed

** Changed in: ubuntu-raspi-settings (Ubuntu)
 Assignee: (unassigned) => Dave Jones (waveform)

** Changed in: ubuntu-raspi-settings (Ubuntu)
Milestone: None => ubuntu-24.10

** Changed in: ubuntu-raspi-settings (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065408

Title:
  growroot-almost should be inhibitable from boot partition

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-raspi-settings/+bug/2065408/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Wikimedia-boston] Re: Wiki bar: Drinks tomorrow @ 5pm at Wusong Road?

[Dave]

When you say “tommorow” is this Friday 5/10.

Devang Dave 

Sent from my iPhone

> On May 9, 2024, at 10:19 PM, Samuel Klein  wrote:
> 
> 
> Dear ones,
> 
> Wikimedia's lead counsel Chuck Roslof is in town this week, and it's been a 
> while since we had an in-person gathering.  A few of us met up today and 
> talked about getting drinks tomorrow at 5.  Give a shout if you're interested 
> in joining!  
> 
> Warmly,
> SJ
> 
> -- 
> Samuel Klein  @metasj   w:user:sj  +1 617 529 4266
> ___
> Wikimedia-boston mailing list -- wikimedia-boston@lists.wikimedia.org
> To unsubscribe send an email to wikimedia-boston-le...@lists.wikimedia.org
___
Wikimedia-boston mailing list -- wikimedia-boston@lists.wikimedia.org
To unsubscribe send an email to wikimedia-boston-le...@lists.wikimedia.org

[Bug c/115027] New: Missing warning: unused struct's with self-referential initialisers

[dave at treblig dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027

Bug ID: 115027
   Summary: Missing warning: unused struct's with self-referential
initialisers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dave at treblig dot org
  Target Milestone: ---

It would be nice to generate a warning in the following case, which I tripped
over in the Linux kernel:

#include 

struct foo {
  struct foo *a;
};

static struct foo f = {  };
int main()
{
  printf("Hello\n");
}

Here 'f' is unused outside of it's initialiser, pointing to itself.
So technically used, but practically not.

In the Linux kernel, this corresponds to it's LIST_HEAD :
(from include/linux/list.h)

#define LIST_HEAD_INIT(name) { &(name), &(name) }

#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)

and I've just gone through and posted patches to remove a handful of
LIST_HEADs, some of which had been unused for many years.
It would be nice if the compiler told people instead.