from:"Paul A"

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

Bug ID: 487055
   Summary: memcheck/tests/x86-linux/scalar fails runing in Docker
Classification: Developer tools
   Product: valgrind
   Version: 3.24 GIT
  Platform: Other
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: memcheck
  Assignee: jsew...@acm.org
  Reporter: pjfl...@wanadoo.fr
  Target Milestone: ---

The end of the unfiltered log is

-
 34:   __NR_nice 1s 0m
-
==263012== Syscall param nice(inc) contains uninitialised byte(s)
==263012==at 0x415AD57: syscall (in /usr/lib/libc-2.17.so)
==263012==by 0x8049EC2: main (scalar.c:193)
==263012== 
scalar: scalar.c:193: main: Assertion `-1 != res' failed.

That means that ftime is not failing.

Probably a difference in the Docker virtualization.

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

[Bug target/115102] New: [SH] GCC misunderstands swap.b instruction

2024-05-15 Thread paul at crapouillou dot net via Gcc-bugs

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

Bug ID: 115102
   Summary: [SH] GCC misunderstands swap.b instruction
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul at crapouillou dot net
  Target Milestone: ---

Given the following C code:

#include 

 uint32_t bswap8(uint32_t val) {
return (val & 0x) | ((val & 0xff00) >> 8) | ((val & 0xff) << 8);
}


GCC will generate (-m4 -Os):

_bswap8:
mov.l   .L2,r1
extu.w  r4,r0
swap.b  r0,r0
and r1,r4
rts
or  r4,r0
.L2:
.long   -65536

GCC understand that it can swap the two lower bytes using the swap.b
instruction. However, it seems to believe that it needs to clear up the upper
16 bits first, which is wrong, as those are simply copied over to the
destination register.

As a result, it will zero-extend to 16 bits first, swap the two low bytes, then
apply a high 16-bit mask to the original value, and OR the two results
together.

This is not optimal, and GCC could simply generate the following:

_bswap8:
rts
swap.b  r4,r0

Re: [ccp4bb] a dinosaur asks ... PDB format query

2024-05-15 Thread Paul Bond

It would also be good to check the monomer library (expanded with any
user-supplied dictionaries). Cases where an element in columns 77-78 exists
and it does not agree with the component definition should probably be
flagged up.

Cheers,
Paul

On Wed, 15 May 2024 at 12:39, Marcin Wojdyr  wrote:

> >
> > >  • Alignment of one-letter atom name such as C starts at column 14,
> while two-letter atom name such as FE starts at column 13.
> >
> > indicating a rule does exist.
>
> There are programs that don't read/write the element from columns
> 77-78, so this rule still matters, but using it is less reliable, as
> Robbie wrote. After I wrote a function that reads pdb files for gemmi,
> over the next few years I received feedback about cases in which the
> element columns are absent and the element determined from the atom
> name is incorrect. The problem is primarily with 4-character atom
> names that can't be aligned, because they use all the four columns
> anyway. I added such comments to the code [1] when trying to get it
> right:
>
>   // Atom names HXXX are ambiguous, but Hg, He, Hf, Ho and Hs (almost)
>   // never have 4-character names, so H is assumed.
>
>   // Similarly Deuterium (DXXX), but here alternatives are Dy, Db and
> Ds.
>   // Only Dysprosium is present in the PDB - in a single entry as of
> 2022.
>
>   // Old versions of the PDB format had hydrogen names such as "1HB ".
>   // Some MD files use similar names for other elements ("1C4A" -> C).
>
>   // ... or it can be "C210"
>
> [1]
> https://github.com/project-gemmi/gemmi/blob/148f37b7c6561c3a255a6a4dd75d6bae888e/include/gemmi/pdb.hpp#L302
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[Bug 2059074] Re: proposed-migration for krita 1:5.2.2+dfsg-2build5

An amrhf binary package is now available in oracular.

** Changed in: krita (Ubuntu)
   Status: New => Fix Released

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

Title:
  proposed-migration for krita 1:5.2.2+dfsg-2build5

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


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

[Bug 2059074] Re: proposed-migration for krita 1:5.2.2+dfsg-2build5

An amrhf binary package is now available in oracular.

** Changed in: krita (Ubuntu)
   Status: New => Fix Released

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

Title:
  proposed-migration for krita 1:5.2.2+dfsg-2build5

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


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

[Bug 2059074] Re: proposed-migration for krita 1:5.2.2+dfsg-2build5

** Changed in: krita (Ubuntu)
 Assignee: (unassigned) => Paul Mars (upils)

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

Title:
  proposed-migration for krita 1:5.2.2+dfsg-2build5

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


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

[Bug 2059074] Re: proposed-migration for krita 1:5.2.2+dfsg-2build5

** Changed in: krita (Ubuntu)
 Assignee: (unassigned) => Paul Mars (upils)

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

Title:
  proposed-migration for krita 1:5.2.2+dfsg-2build5

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


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

[slurm-users] Best practice for jobs resuming from suspended state

2024-05-15 Thread Paul Jones via slurm-users

Hi,

We use PreemptMode and PriorityTier within Slurm to suspend low priority jobs 
when more urgent work needs to be done. This generally works well, but on 
occasion resumed jobs fail to restart - which is to say Slurm sets the job 
status to running but the actual code doesn't recover from being suspended.

Technically everything is working as expected, but I wondered if there was any 
best practice to pass onto users about how to cope with this state? Obviously 
not a direct Slurm question, but wondered if others had experience with this 
and any advice on how best to limit the impact?

Thanks,
Paul


--

-- 
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com

[valgrind] [Bug 352021] Signals are ignored in OS X 10.10

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

--- Comment #7 from Paul Floyd  ---
Can't easily try this on 10.10.

I'll have a go with a 10.13 VM.

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

[valgrind] [Bug 352021] Signals are ignored in OS X 10.10

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

Paul Floyd  changed:

   What|Removed |Added

   Assignee|rhysk...@gmail.com  |pjfl...@wanadoo.fr

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

[valgrind] [Bug 372779] valgrind will hang on OSX 10.11

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

Paul Floyd  changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #4 from Paul Floyd  ---
10.11 is long in the tooth now. Can anyone provide a reproducer?

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

[valgrind] [Bug 462958] ARMv8: Unrecognised instruction: _armv8_sha512_probe

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

Paul Floyd  changed:

   What|Removed |Added

   Assignee|jsew...@acm.org |pjfl...@wanadoo.fr
 CC||pjfl...@wanadoo.fr

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

[valgrind] [Bug 447989] Support Armv8.2 SHA-512 instructions

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

Paul Floyd  changed:

   What|Removed |Added

   Assignee|jsew...@acm.org |pjfl...@wanadoo.fr

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

[valgrind] [Bug 447989] Support Armv8.2 SHA-512 instructions

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

--- Comment #5 from Paul Floyd  ---
This will also need a change in arm64g_dirtyhelper_MRS_ID_AA64ISAR0_EL1

This bit will need to be removed

   /* Degredate SHA2 from b0010 to b0001*/
   if ( (w >> 12) & 0x2 ) {
  w ^= (0x2 << 12);
  w |= (0x1 << 12);
   }

And at least one testcase would also be good!

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

[meteorite-list] Meteorite Picture of the Day

2024-05-15 Thread Paul Swartz via Meteorite-list

Wednesday, May 15 2024 Meteorite Picture of the Day: Grein 005

Contributed by: Matthias Baermann

http://www.tucsonmeteorites.com/mpodmain.asp?DD=05/15/2024
__
Meteorite-list mailing list
Meteorite-list@meteoritecentral.com
https://pairlist2.pair.net/mailman/listinfo/meteorite-list

[valgrind] [Bug 447989] Support Armv8.2 SHA-512 instructions

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

--- Comment #4 from Paul Floyd  ---
(In reply to Paul Floyd from comment #3)
> (In reply to David Benjamin from comment #2)
> > Anything needed before this patch is submittable?
> 
> Someone actively working on the ARM version of Valgrind?

^^^ well now that's me, time to look atthis again.

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

Bug#1071141: gnome-remote-desktop: `/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to resolve user 'gnome-remote-desktop': No such process`

2024-05-14 Thread Paul Menzel


Package: gnome-remote-desktop
Version: 46.1-3
Severity: normal


Dear Debian folks,


Upgrading to *gnome-shell* from the suite *experimental*

sudo apt install -t experimental gnome-shell

also upgrades *gnome-remote-desktop* from 44.2-8 to 46.1-3. The lines 
below were printed to the console:


gnome-remote-desktop (46.1-3) wird eingerichtet ...
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to 
resolve user 'gnome-remote-desktop': No such process
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to 
resolve user 'gnome-remote-desktop': No such process

Creating group 'gnome-remote-desktop' with GID 987.

The failure lines were printed in red.


Kind regards,

Paul

Re: [Intel-wired-lan] [PATCH iwl-net V3, 1/2] i40e: fractoring out i40e_suspend/i40e_resume

2024-05-14 Thread Paul Menzel


Dear Thinh,


Thank you for your patch. Two minor comments for the title: Please use 
imperative mood and fix a typo:


Factor out i40e_suspend/i40e_resume


Kind regards,

Paul

RE: [AI] My story covered in the news today

2024-05-14 Thread 'PAUL MUDDHA' via AccessIndia

Congratulation Ruhin on this mile stome achievement.
May you reach to greater heights in education and them good employment in 
future.
Best

From: accessindia@accessindia.org.in  On Behalf 
Of Prerna Sobti
Sent: 15 May 2024 09:24
To: accessindia@accessindia.org.in
Subject: Re: [AI] My story covered in the news today

CAUTION: This email is originated from outside Canara Bank. Do not click any 
links or open attachments unless you recognize the sender and know that the 
content is safe.
Heartiest congratulations. I am sure this is just the beginning of adding 
feathers to your heart of a success. Wishing you many more in future good luck
Heartiest congratulations. I am sure this is just the beginning of adding 
feathers to your heart of a success. Wishing you many more in future. Good 
luckPrerna Sobti

On May 15, 2024, at 6:27 AM, Ruhin Bhattasali 
mailto:ruhinbhattas...@gmail.com>> wrote:

Hi all

I have completed my class 12 in science stream from a Main Street school.
I am happy to share that I scored 98.2 percent in CBSE board exam and it got 
covered by The Hindu.
https://www.thehindu.com/news/national/telangana/several-schools-in-hyderabad-achieve-100-pass-rate-in-cbse-results/article68175380.ece

Kind regards
Ruhin
--
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..

Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
---
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CA%2BuHeKPLUw8nQya%2BwtNWjDVDYvxeZeVYm8tQ6c7ffzkKV%2BTzuA%40mail.gmail.com.
--
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..

Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
---
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/187E690C-EA08-4B8E-9580-10D8EBA70E37%40gmail.com.
[Logo]  [Logo]
"Azadi Ka Amrit Mahotsav"
DISCLAIMER:This email may contain privileged information and is intended solely 
for the addressee, and any disclosure of this information is strictly 
prohibited, and may be unlawful. If you have received this mail by mistake, 
please inform the sender immediately and delete this mail. Any information 
expressed in this mail does not necessarily reflect the views of CANARA BANK. 
Please note that any views or opinions presented in this email are solely those 
of the author and do not necessarily represent those of the Bank. The recipient 
should check this email and any attachments for the presence of viruses. The 
sender declares that no liability can be cast upon the sender for any error or 
omissions in the contents of the message that arise, as a result of e-mail 
transmission and further declares that the sender cannot be made liable for any 
loss suffered by any person, on account of having acted upon any messages which 
is vitiated by error, omissions or interception.

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..

Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit

Re: [Intel-wired-lan] [linus:master] [e1000e] 861e808602: suspend-stress.fail (e1000e: move force SMBUS from enable ulp function to avoid PHY loss issue)

2024-05-14 Thread Paul Menzel


Dear Oliver,


Thank you for the report.

Am 15.05.24 um 03:50 schrieb kernel test robot:


kernel test robot noticed "suspend-stress.fail" on:

commit: 861e8086029e003305750b4126ecd6617465f5c7 ("e1000e: move force SMBUS from 
enable ulp function to avoid PHY loss issue")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

[test failed on linus/master a7c840ba5fa78d7761b9fedc33d69cef44986d79]
[test failed on linux-next/master 6ba6c795dc73c22ce2c86006f17c4aa802db2a60]

in testcase: suspend-stress
version:
with following parameters:

mode: freeze
iterations: 10



compiler: gcc-13
test machine: 4 threads (Broadwell) with 8G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-lkp/202405150942.f9b873b1-oliver.s...@intel.com

test started

<--- but cannot really run suspend-stress tests successfully


as a contrast, for parent, we always noticed the jobs run smoothly

SUSPEND RESUME TEST STARTED
Suspend to freeze 1/10:
/usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 
http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/lkp-bdw-nuc1/suspend-stress-10-freeze-debian-x86_64-20180403.cgz-6dbdd4de0362-20240406-63993-p7cw6d-0.yaml_state=suspending-1/10
 -O /dev/null
Done
Sleep for 10 seconds

...

Suspend to freeze 10/10:
/usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 
http://internal-lkp-server:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/lkp-bdw-nuc1/suspend-stress-10-freeze-debian-x86_64-20180403.cgz-6dbdd4de0362-20240406-63993-p7cw6d-0.yaml_state=suspending-10/10
 -O /dev/null
Done
Sleep for 10 seconds
SUSPEND RESUME TEST SUCCESS

The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240515/202405150942.f9b873b1-oliver.s...@intel.com


if you need more information, please let us know. Thanks!


Can you please share on what test system this fails, and provide the 
hardware information?


Also, do you have Linux logs until starting the tests?


Kind regards,

Paul


PS: In the Cc: header field, your address misses an l in domain part 
intel.com.

[Standards] Re: Proposed XMPP Extension: Jingle Remote Control

2024-05-14 Thread Stephen Paul Weber


URL: https://xmpp.org/extensions/inbox/remote-control.html


I'm unclear on the benefits of this CBOR-over-Jingle approach vs a XML-based 
-based approach? Unlike audio/video this data is tiny and does not 
benefit nearly as much from direct transmission or binary packing.


If something over Jingle *is* desired, I'm a bit uncomfortable with 
specifying bespoke binary protocols in XEPs. Jingle can of course be used to 
send any data of any protocol and so any existing or future remote-control 
protocol can be used over Jingle. Do we really need something XMPP-specific 
for this purpose?


signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Hampshire] Portsmouth & SE Hants LUG - 18th May

2024-05-14 Thread Paul Tansom via Hampshire

The next meet is this Saturday (18th May) with the usual start time of 
1pmat Broad Oak Sports and Social Club.


As a heads up, I will be leaving a bit earlier than usual, by about 5pm 
to attend another event that starts at 4.30pm. Yes, I know that is after 
the other one starts, but it isn't a formal meeting, more a thank you 
event for those who helped in the local elections, and having won a seat 
I should be there even a bit late due to a prior engagement!


Many thanks,
Paul

Paul Tansom  |  Aptanet Ltd. | https://www.aptanet.com/ |  023 9238 0001
= 

Registered in England | Company No: 4905028 | Registered Office: Ralls 
House,
Parklands Business Park, Forrest Road, Denmead, Waterlooville, Hants, 
PO7 6XP-- 
Please post to: Hampshire@mailman.lug.org.uk
Manage subscription: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG website: http://www.hantslug.org.uk
--

Re: [LincolnTalk] state moving bear to Lincoln from Worcester - can they do that

2024-05-14 Thread Paul Shorb

Linda - Thank you for sharing the info from the state biologist -
interesting

LT - FYI, we had more frequent bear sightings when we lived in Mountain
Lakes, NJ, even though that town was more densely settled than Lincoln
(mostly quarter-acre lots). My understanding then was that when young bear
cubs reached a certain age, they were forced to leave their place or origin
and look for new territory, and thus tended to flow outwards from less
developed areas in the county (and perhaps beyond). I saw one on the street
in front of our house once or twice. Folks we know who still live there
just sent us a video of several bears wandering near their driveway, seen
as our friends drove back in.  I've linked that 33-second video here:
https://drive.google.com/file/d/16eufOrXWd1uobyhUilG8dFE2eMaubOb-/view?usp=sharing

- Paul Shorb

On Tue, May 14, 2024 at 5:57 PM Linda McMillan 
wrote:

> The Massachusetts bear biologist I spoke to said there are many bears in
> much more developed areas than Lincoln. The bear was not moved to Lincoln.
> It "wandered" into Lincoln after being moved out of Worcester to another
> town. Perhaps he will wander away.
>
> On Tue, May 14, 2024, 8:57 AM Anne Warner  wrote:
>
>> I am taken aback that the state “moved the bear from Worcester” to
>> Lincoln. Did we consent to that?  People are now having to supervise their
>> children playing outside and take down their bird feeders which, at least
>> in our house, are a source of real joy. I think we should call on our
>> Select Board to push back on this, and get the bear “moved” to an area
>> where there is much more unoccupied land for them to forage. The bear might
>> be cute, but these are wild animals and although this one has not attacked
>> anyone, I don’t think we should have to worry about our children playing
>> outside. Anne Warner
>> - Sent from iPhone. Typed by thumb. Excuse misspellings!
>>
>> On May 13, 2024, at 7:07 PM, Linda McMillan 
>> wrote:
>>
>> 
>> I talked with the Massachusetts bear biologist today. He said this bear
>> was moved from Worcester where he was wandering into a very developed area
>> not because he was aggressive or violent. He's about two years old and has
>> moved about 35 miles in the last week. They have no intention of moving him
>> out of Lincoln. He said we should get used to having bears in our town. The
>> likelihood is that we will see more.
>>
>> He said to take down your bird feeders and bring in your trash.
>>
>> Regarding dogs, he said there is more risk that your dog will be attacked
>> by a coyote than by a bear. However, he said if you have a dog that wanders
>> or does not come to you when called,  or who is aggressive,  he suggests
>> keeping it on a leash.
>>
>> He also said there is no need to notify them of the current location
>> because they have no plans to move the bear.
>>
>> I hope this is helpful.
>>
>> Linda
>>
>> On Mon, May 13, 2024, 5:12 PM Jennifer Saffran <
>> jennifer.saff...@gmail.com> wrote:
>>
>>> I’ve seen bear tags before, but “Dodger” appears to have both ears
>>> tagged. What’s up with that?
>>>
>>> On May 12, 2024, at 9:20 PM, Joanna Owen Schmergel via Lincoln <
>>> lincoln@lincolntalk.org> wrote:
>>>
>>> It’s Dodger!
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>> <https://mail.onelink.me/107872968?pid=nativeplacement=Global_Acquisition_YMktg_315_Internal_EmailSignature_sub1=Acquisition_sub2=Global_YMktg_sub3=_sub4=10604_sub5=EmailSignature__Static_>
>>>
>>> On Sunday, May 12, 2024, 9:16 PM, Lynne Smith  wrote:
>>>
>>> Looks like he has opposing thumbs ! And he clearly knows where to find
>>> seeds.
>>>
>>>
>>> Lynne Smith
>>> 5 Tabor Hill Road
>>> Lincoln, MA 01773
>>> 781-258-1175
>>> Sent from my iPhone
>>>
>>> > On 12 May 2024, at 6:14 PM, pspe...@gmail.com wrote:
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Sent from my iPhone--
>>> > The LincolnTalk mailing list.
>>> > To post, send mail to Lincoln@lincolntalk.org.
>>> > Browse the archives at
>>> https://pairlist9.pair.net/mailman/private/lincoln/.
>>> > Change your subscription settings at
>>> https://pairlist9.pair.net/mailman/listinfo/lincoln.
>>> >
>>> --
>>> The LincolnTalk mailing list.
>>> To post, send mail to Lincoln@lincolntalk.org.
>>> Browse the arch

[bug-diffutils] bug#70951: bug#70951: "make distcheck" regression due to DIFF_EXTERN

2024-05-14 Thread Paul Eggert


Thanks, I installed the attached.
From 62d075ad726e9a2a93c829873a63623284971c87 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 14 May 2024 15:46:48 -0700
Subject: [PATCH] maint: be less fancy when defining extern vars
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Bug reported by Bruno Haible in <https://bugs.gnu.org/70951>.
I never did like the XTERN macro and its descendants, as this
“extension” to C causes more confusion than it cures, so let’s
just get rid of it and use plain ‘extern’.
* cfg.mk (_gl_TS_extern): Remove XTERN, SYSTEM_EXTERN.
* src/Makefile.am (cmp_SOURCES, diff3_SOURCES, sdiff_SOURCES)
(diff_SOURCES): Add system.c.
* src/cmp.c, src/diff.c, src/diff3.c, src/sdiff.c (SYSTEM_INLINE):
Remove.
* src/diff.c: Define vars declared in diff.h.
* src/diff.h (DIFF_EXTERN): Remove.  All uses removed.
Just use ‘extern’ when declaring extern vars.
* src/system.h (SYSTEM_EXTERN): Likewise.
* src/system.c: New file.
---
 cfg.mk  |  5 +--
 src/Makefile.am |  8 ++---
 src/cmp.c   |  1 -
 src/diff.c  | 45 +-
 src/diff.h  | 85 -
 src/diff3.c |  1 -
 src/sdiff.c |  1 -
 src/system.c| 30 +
 src/system.h|  9 ++
 9 files changed, 125 insertions(+), 60 deletions(-)
 create mode 100644 src/system.c

diff --git a/cfg.mk b/cfg.mk
index 5efdc5a..3c0296f 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -79,5 +79,6 @@ exclude_file_name_regexp--sc_doubled_words = ^gl/lib/mcel\.h$$
 exclude_file_name_regexp--sc_prohibit_doubled_word = ^(gl/lib/mcel\.h|tests/y2038-vs-32bit)$$
 exclude_file_name_regexp--sc_prohibit_strcmp = ^gl/lib/
 
-# Tell gnulib's tight_scope rule that we mark externs with XTERN
-export _gl_TS_extern = extern|XTERN|DIFF_INLINE|SYSTEM_INLINE|SYSTEM_EXTERN
+# Tell gnulib's tight_scope rule that we mark extern inlines with
+# DIFF_INLINE and SYSTEM_INLINE.
+export _gl_TS_extern = extern|DIFF_INLINE|SYSTEM_INLINE
diff --git a/src/Makefile.am b/src/Makefile.am
index 8310923..01c6f1f 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -42,12 +42,12 @@ cmp_LDADD = $(LDADD)
 sdiff_LDADD = $(LDADD) $(GETRANDOM_LIB)
 diff3_LDADD = $(LDADD)
 
-cmp_SOURCES = cmp.c
-diff3_SOURCES = diff3.c
-sdiff_SOURCES = sdiff.c
+cmp_SOURCES = cmp.c system.c
+diff3_SOURCES = diff3.c system.c
+sdiff_SOURCES = sdiff.c system.c
 diff_SOURCES = \
   analyze.c context.c diff.c dir.c ed.c ifdef.c io.c \
-  normal.c side.c util.c
+  normal.c side.c system.c util.c
 noinst_HEADERS = diff.h system.h
 
 MOSTLYCLEANFILES = paths.h paths.ht
diff --git a/src/cmp.c b/src/cmp.c
index d2f65b5..9a8bfc4 100644
--- a/src/cmp.c
+++ b/src/cmp.c
@@ -16,7 +16,6 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
-#define SYSTEM_INLINE _GL_EXTERN_INLINE
 #include "system.h"
 #include "paths.h"
 
diff --git a/src/diff.c b/src/diff.c
index 74b03ae..76432ee 100644
--- a/src/diff.c
+++ b/src/diff.c
@@ -19,7 +19,6 @@
along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #define DIFF_INLINE _GL_EXTERN_INLINE
-#define SYSTEM_INLINE _GL_EXTERN_INLINE
 #include "diff.h"
 #include "paths.h"
 
@@ -1647,3 +1646,47 @@ compare_files (struct comparison const *parent, enum detype const detype[2],
 
   return status;
 }
+
+/* Define variables declared in diff.h (which see).  */
+FILE *outfile;
+bool brief;
+bool expand_tabs;
+bool files_can_be_treated_as_binary;
+bool ignore_blank_lines;
+bool ignore_case;
+bool ignore_file_name_case;
+bool initial_tab;
+bool left_column;
+bool minimal;
+bool no_dereference_symlinks;
+bool no_diff_means_no_output;
+bool paginate;
+bool presume_output_tty;
+bool sdiff_merge_assist;
+bool speed_large_files;
+bool strip_trailing_cr;
+bool suppress_blank_empty;
+bool suppress_common_lines;
+bool text;
+char *file_label[2];
+char *switch_string;
+char const *group_format[CHANGED + 1];
+char const *line_format[NEW + 1];
+char const *starting_file;
+char const *time_format;
+enum DIFF_white_space ignore_white_space;
+enum colors_style colors_style;
+enum output_style output_style;
+intmax_t sdiff_column2_offset;
+intmax_t sdiff_half_width;
+intmax_t tabsize;
+lin context;
+lin horizon_lines;
+struct comparison curr;
+struct comparison noparent;
+struct exclude *excluded;
+struct re_pattern_buffer function_regexp;
+struct re_pattern_buffer ignore_regexp;
+#ifndef localtz
+timezone_t localtz;
+#endif
diff --git a/src/diff.h b/src/diff.h
index 3944452..f0723ff 100644
--- a/src/diff.h
+++ b/src/diff.h
@@ -25,10 +25,7 @@
 
 _GL_INLINE_HEADER_BEGIN
 
-#ifdef DIFF_INLINE
-# define DIFF_EXTERN(decl) extern decl; decl
-#else
-# define DIFF_EXTERN(decl) extern decl
+#ifndef DIFF_INLINE
 # define DIFF_INLINE _GL_INLINE
 #endif
 
@@ -101,24 +98,24 @@ DIFF_INLINE bool robust_output_style (enum output_s

Re: [PATCH v18 16/21] fsverity: expose verified fsverity built-in signatures to LSMs

2024-05-14 Thread Paul Moore

On Fri, May 3, 2024 at 6:32 PM Fan Wu  wrote:
>
> This patch enhances fsverity's capabilities to support both integrity and
> authenticity protection by introducing the exposure of built-in
> signatures through a new LSM hook. This functionality allows LSMs,
> e.g. IPE, to enforce policies based on the authenticity and integrity of
> files, specifically focusing on built-in fsverity signatures. It enables
> a policy enforcement layer within LSMs for fsverity, offering granular
> control over the usage of authenticity claims. For instance, a policy
> could be established to permit the execution of all files with verified
> built-in fsverity signatures while restricting kernel module loading
> from specified fsverity files via fsverity digests.
>
> The introduction of a security_inode_setintegrity() hook call within
> fsverity's workflow ensures that the verified built-in signature of a file
> is exposed to LSMs. This enables LSMs to recognize and label fsverity files
> that contain a verified built-in fsverity signature. This hook is invoked
> subsequent to the fsverity_verify_signature() process, guaranteeing the
> signature's verification against fsverity's keyring. This mechanism is
> crucial for maintaining system security, as it operates in kernel space,
> effectively thwarting attempts by malicious binaries to bypass user space
> stack interactions.
>
> The second to last commit in this patch set will add a link to the IPE
> documentation in fsverity.rst.
>
> Signed-off-by: Deven Bowers 
> Signed-off-by: Fan Wu 

Eric, are you okay with the fs-verity patches in v18?  If so, it would
be nice to get your ACK on this patch at the very least.

While it looks like there may be a need for an additional respin to
address some new/different feedback from the device-mapper folks, that
shouldn't affect the fs-verity portions of the patchset.

-- 
paul-moore.com

[valgrind] [Bug 454346] [PATCH] ARM fixes from the Yocto project

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

--- Comment #11 from Paul Floyd  ---
(In reply to Khem Raj from comment #10)

> Hmm, I think we need to use -march=armv7ve instead of -mcpu=cortex-a8, I did
> realize that all distros
> will not tune the compiler like yocto does.

The build and tests need to run with just autogen.sh, configure (without
compiler options), make, make check and make regtest.

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

Re: [PATCH v18 20/21] Documentation: add ipe documentation

2024-05-14 Thread Paul Moore

On Sat, May 4, 2024 at 4:13 PM Fan Wu  wrote:
> On 5/4/2024 1:04 AM, Bagas Sanjaya wrote:
> > On Fri, May 03, 2024 at 03:32:30PM -0700, Fan Wu wrote:
> >> +IPE does not mitigate threats arising from malicious but authorized
> >> +developers (with access to a signing certificate), or compromised
> >> +developer tools used by them (i.e. return-oriented programming attacks).
> >> +Additionally, IPE draws hard security boundary between userspace and
> >> +kernelspace. As a result, IPE does not provide any protections against a
> >> +kernel level exploit, and a kernel-level exploit can disable or tamper
> >> +with IPE's protections.
> >
> > So how to mitigate kernel-level exploits then?
>
> One possible way is to use hypervisor to protect the kernel integrity.
> https://github.com/heki-linux is one project on this direction. Perhaps
> I should also add this link to the doc.

I wouldn't spend a lot of time on kernel exploits in the IPE
documentation as it is out of scope for IPE.  In face, I would say
just that in the last sentence in the paragraph above:

"As a result, kernel-level exploits are considered outside the scope
of IPE and mitigation is left to other mechanisms."

(or something similar)

-- 
paul-moore.com

[valgrind] [Bug 426798] 404 link in Valgrind website for valkyrie

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

Paul Floyd  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Paul Floyd  ---
commit 25e550574acc1e5c9f81956081797dc511950603 (HEAD -> main, origin/main,
origin/HEAD)
Author: Paul Floyd 
Date:   Tue May 14 20:02:36 2024 +0200

Bug 426798 - 404 link in Valgrind website for valkyrie

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

[DNSOP]Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

2024-05-14 Thread Paul Wouters via Datatracker

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bootstrapping-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/



--
DISCUSS:
--

I have a few items to discuss and some comments. I'm leaving out the discussion
of _signal as a name, as this discussion is taking place on dnsop. While I have
a preference, I'll abide by the consensus call of the dnsop wgchairs.

All Sections:

This document uses the term "bailiwick" a lot. The DNS Terminology series of
RFCs recommands to avoid this term and use "in-domain" or "not in-domain".

Section 1:

Readers are expected to be familiar with DNSSEC, including
[RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and
[RFC8078].

It should say:

Readers are expected to be familiar with DNSSEC [BCP237].

It includes the same RFCs but BCP237 will get updated in the future.

Section 2:

The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.

I find this to be inconsistent with the Update: 8078 clause, as without
"Section 3", you are basically obsoleting the entire 8078. I don't think
this document should obsolete it, it should augment it. I would rewrite
the above like:

The DS enrollment method described in this document provides more
security than the methods described in Section 3 of [RFC8078],
and are therefor RECOMMENDED in favour of the methods specified
in [RFC8078].

If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make references
to it, which it cannot do if it obsoletes the document.

Section 4.1.1:

It is not clear to me if the "signaling domain" really has to be
its own zone or not. eg:

_dsboot.example.co.uk._signal.ns1.example.net

Could this be signed using the DNSKEY of "example.net", or does the
document insist on a zone cut at _signal.ns1.example.net ?

I think zone cut should not be mandatory, in which case the language that
uses "signaling domain" should be cleaned up to make this clear.

That would also mean language like this is no longer needed:

The records are accompanied by RRSIG records created using the
key(s) of the respective signaling zone.

It could just state something like:

These records are signed with DNSSEC just like any other zone data.

Later on in the Operational Considerations, the issue is mentioned and
it states zone cuts are not mandatory. So I do think this needs some cleanup.

in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets
located at the signaling name under any signaling domain,
including failure of DNSSEC validation, or unauthenticated data
(AD bit not set);

I think it also needs to exclude signaling signatures made by any DNSSEC
keys upstream from the DNS hoster's zone. Eg if we have _signal.ns1.example.net
we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the root.

Section 5:

CDS/CDNSKEY records and corresponding signaling records MUST
NOT be published without the zone owner's consent.

This opens a can of worms. How is an implementer going to codify this
MUST? The only usable interpretation I can see is that the DNS hoster,
by being assigned the DNS hoster, has permissions to DNS host the zone
as it sees fit, and thus do DNSSEC. And especially not bother the zone
owner with techno-babble for permissions.

Likewise, the child DNS operator MUST enable the zone owner

Again, this wades into legalize and contractual matters best left
outside of RFC specifications.

a zone cut ensures that bootstrapping activities do not require
modifications of the zone containing the nameserver hostname.

Why does this matter?


--
COMMENT:
--

   If a child DNS operator implements the protocol

If a child DNS operator implements this specification


(i.e. have a valid DNSSEC chain of trust)

I would say:

(i.e. have a valid publicly resolvable DNSSEC chain of trust)

Otherwise one could argue the parent has to have some "special configuration"
(eg trusta

Re: Treat "Circular dependency...dropped" as a hard error instead?

2024-05-14 Thread Paul Smith

On Mon, 2024-05-13 at 22:05 -0400, Dmitry Goncharov wrote:
> On Wed, May 8, 2024 at 2:04 PM JZB  wrote:
> > 
> > I have a GNU make-based build system wherein I would like for
> > any/all
> > GNU make-detected circular dependencies to be treated as a hard
> > error,
> > i.e., fail [immediately], rather than a "dropped and we go on
> > without
> > it..." situation.
> > 
> > Is there a way to do this already?
> 
> I think, that's a good idea.
> i added two patches which implement this ability.
> You'll need to wait for make with the patches to be released or apply
> the patches yourself.

Thanks Dmitry that's exactly what I was going to suggest, I just have
an extremely frazzled week here.

Re: [PATCH 25/48] rcu: Mark writes to rcu_sync ->gp_count field

2024-05-14 Thread Paul E. McKenney

On Mon, May 13, 2024 at 04:13:35PM +0200, Marco Elver wrote:
> On Fri, 10 May 2024 at 16:11, Paul E. McKenney  wrote:
> [...]
> > > > Does this mean that KCSAN/etc treats the files in kernel/rcu/
> > > > differently than the "Rest of Kernel"? Or what?
> > > >
> > > > And how is it enforced?
> > >
> > > I can only find the strnstr(buf, "rcu") checks in skip_report(),
> > > but they only cover the KCSAN_REPORT_VALUE_CHANGE_ONLY case...
> >
> > Huh, new one on me!  When I run KCSAN, I set CONFIG_KCSAN_STRICT=y,
> > which implies CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n, which should
> > prevent skip_report() from even being invoked.
> 
> The strnstr hack goes back to the first version of KCSAN released in
> v5.8 [1]. It was added in response to Paul wanting the "stricter"
> treatment for RCU even while KCSAN was still in development, and back
> then syzbot was the first test system using KCSAN. Shortly after Paul
> added a KCSAN config for rcutorture with a laundry list of options to
> make KCSAN "strict" (before we eventually added CONFIG_KCSAN_STRICT
> which greatly simplified that).
> 
> While the strnstr(.., "rcu") rules are redundant when using the
> stricter rules (at least CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n is
> set), we're keeping the "rcu" special case around because there are
> test robots and fuzzers that use the default KCSAN config (unlike
> rcutorture). And because we know that RCU likes the stricter rules,
> the "value change only" filter is ignored in all KCSAN configs for
> rcu-related functions.
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/kcsan/report.c?id=v5.8

Thank you for the background information!

> Back then syzbot occasionally reported RCU data races, but these days
> rcutorture probably finds all of them before syzbot ever gets its
> hands on new code.

I do try my best.  ;-)

Thanx, Paul

Re: [PATCH] rcu/nocb: Fix using smp_processor_id() in preemptible warning

2024-05-14 Thread Paul E. McKenney

On Tue, May 14, 2024 at 05:18:12PM +0200, Frederic Weisbecker wrote:
> Le Tue, May 14, 2024 at 07:54:40AM -0700, Paul E. McKenney a écrit :
> > On Thu, May 09, 2024 at 03:40:46PM +0800, Zqiang wrote:
> > > Currently, the this_cpu_ptr(_data) in rcu_rdp_is_offloaded() is called
> > > before the condition "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && 
> > > preemptible())"
> > > is checked, and occurs in preemptible task context, this will trigger the
> > > following warning.
> > > 
> > > [ 4.106221][ T18] BUG: using smp_processor_id() in preemptible [] 
> > > code: rcuop/0/18
> > > [ 4.107796][ T18] caller is debug_smp_processor_id 
> > > (lib/smp_processor_id.c:61)
> > > [ 4.108547][ T18] CPU: 0 PID: 18 Comm: rcuop/0 Not tainted 
> > > 6.9.0-rc2-00079-g4c66bc7cacc0 #1
> > > [ 4.109667][ T18] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > > BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> > > [ 4.111064][ T18] Call Trace:
> > > [ 4.111064][ T18]  
> > > [ 4.111064][ T18] dump_stack_lvl (lib/dump_stack.c:116)
> > > [ 4.111064][ T18] dump_stack (lib/dump_stack.c:124)
> > > [ 4.111064][ T18] check_preemption_disabled 
> > > (arch/x86/include/asm/preempt.h:84 (discriminator 15) 
> > > lib/smp_processor_id.c:53 (discriminator 15))
> > > [ 4.111064][ T18] debug_smp_processor_id (lib/smp_processor_id.c:61)
> > > [ 4.111064][ T18] rcu_rdp_is_offloaded (kernel/rcu/tree_plugin.h:27 
> > > (discriminator 1))
> > > [ 4.111064][ T18] nocb_cb_wait (kernel/rcu/tree_nocb.h:936 (discriminator 
> > > 2))
> > > [ 4.111064][ T18] rcu_nocb_cb_kthread (kernel/rcu/tree_nocb.h:983 
> > > (discriminator 1))
> > > [ 4.111064][ T18] ? nocb_cb_wait (kernel/rcu/tree_nocb.h:976)
> > > [ 4.111064][ T18] kthread (kernel/kthread.c:388)
> > > [ 4.111064][ T18] ? kthread (kernel/kthread.c:373 (discriminator 2))
> > > [ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
> > > [ 4.111064][ T18] ret_from_fork (arch/x86/kernel/process.c:153)
> > > [ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
> > > [ 4.111064][ T18] ret_from_fork_asm (arch/x86/entry/entry_64.S:256)
> > > [ 4.111064][ T18]  
> > > 
> > > This commit fix this warning by priority check the condition 
> > > "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())" , to
> > > ensure whether the this_cpu_ptr(_data) can be executed in
> > > rcu_rdp_is_offloaded().
> > > 
> > > Fixes: 8feeeba60711 ("rcu/nocb: Use kthread parking instead of ad-hoc 
> > > implementation")
> > > Tested-by: kernel test robot 
> > > Signed-off-by: Zqiang 
> > 
> > Hearing no objections, I have queued this wordsmithed version.  As always,
> > please let me know if I have messed anything up.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > commit 5271ad1de0fbcf0bd9caebcf721670c164e5fa9c
> > Author: Zqiang 
> > Date:   Thu May 9 15:40:46 2024 +0800
> > 
> > rcu/nocb: Don't use smp_processor_id() in preemptible code
> > 
> > Currently, rcu_rdp_is_offloaded() invokes this_cpu_ptr(_data) before
> > the condition "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())"
> > is checked.  When invoked in preemptible context in preemptible kernels,
> > this will trigger the following warning:
> > 
> > [ 4.106221][ T18] BUG: using smp_processor_id() in preemptible 
> > [] code: rcuop/0/18
> > [ 4.107796][ T18] caller is debug_smp_processor_id 
> > (lib/smp_processor_id.c:61)
> > [ 4.108547][ T18] CPU: 0 PID: 18 Comm: rcuop/0 Not tainted 
> > 6.9.0-rc2-00079-g4c66bc7cacc0 #1
> > [ 4.109667][ T18] Hardware name: QEMU Standard PC (i440FX + PIIX, 
> > 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> > [ 4.111064][ T18] Call Trace:
> > [ 4.111064][ T18]  
> > [ 4.111064][ T18] dump_stack_lvl (lib/dump_stack.c:116)
> > [ 4.111064][ T18] dump_stack (lib/dump_stack.c:124)
> > [ 4.111064][ T18] check_preemption_disabled 
> > (arch/x86/include/asm/preempt.h:84 (discriminator 15) 
> > lib/smp_processor_id.c:53 (discriminator 15))
> > [ 4.111064][ T18] debug_smp_processor_id (lib/smp_processor_id.c:61)
> > [ 4.111064][ T18] rcu_rdp_is_offloaded (kernel/rcu/tree_plugin.h:27 
> > (discriminator 1))
> >

Re: [Koha-devel] REMINDER: Development IRC meeting 15 May 2024

2024-05-14 Thread Paul Derscheid via Koha-devel

Hi all (again),

the first time converter link I sent has an incorrect target.

Here’s the corrected one:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting=20240515T1400

Kind regards

Paul

> On 14. May 2024, at 16:03, Paul Derscheid  wrote:
> 
> Hi all,
>  
> We have a Development IRC/Jitsi meeting scheduled for tomorrow:
> https://wiki.koha-community.org/wiki/Development_IRC_meeting_15_May_2024
>  
> Time converter:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting=20240515T1400
>  
> <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting=20240403T1200>
>  
> Please feel free to add any topics you’d like to discuss to the agenda or let 
> me know and I am happy to add them for you.
> If you are lead or supporter of a roadmap project, we will be happy to get an 
> update on progress.
>  
> See you there!
>  
> Paul
> 

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: RFR: 8331940: ClassFile API ArrayIndexOutOfBoundsException with certain class files

2024-05-14 Thread Paul Sandoz

On Tue, 14 May 2024 13:18:51 GMT, Adam Sotona  wrote:

> Class file with `LineNumberTable` attribute element pointing behind the 
> bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws  expected `IllegalArgumentException` 
> instead.
> Relevant test is added.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 241:

> 239: int startPc = classReader.readU2(p);
> 240: if (startPc > codeLength) {
> 241: throw new 
> IllegalArgumentException(String.format("Line number out of range; 
> start_pc=%d, codeLength=%d",

It's the byte code index that is out of range, not the line number associated 
with it.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19230#discussion_r1600292689

[perpass] close the perpass list

2024-05-14 Thread Paul Wouters

Hi!

I observe that this list has seen almost no real posts in over 5 years.
The list appears to have served its intended purpose and is no longer in
use.  My intent is to close it in 4 weeks.  Closure of the list will mean
that no new post will be permitted.  However, the list archive will
continue to be available.

I think discussions related to pervasive monitoring can be sent to the saag
or ietf list, which would also see a larger exposure.

If you disagree, please voice your concern before 14 June 2024.

Regards,

Paul
___
perpass mailing list -- perpass@ietf.org
To unsubscribe send an email to perpass-le...@ietf.org

RE: Re: Apache ActiveMQ Classic 5.17.3; STOMP receipts

2024-05-14 Thread Bouscaren, Paul

Thank you for this.
I will retest and advise soon.

Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.

From: Timothy Bish 
Sent: Tuesday, May 14, 2024 10:52 AM
To: users@activemq.apache.org
Subject: [EXTERNAL] Re: Apache ActiveMQ Classic 5.17.3; STOMP receipts

On 5/14/24 10: 28, Bouscaren, Paul wrote: > Classic (per the subject line) > 
Stomp 1. 1 > > Among other issues, the STOMP specification suggests I will 
receive a receipt for my DISCONNECT frame, which I do not receive. The tests in
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
External Email


On 5/14/24 10:28, Bouscaren, Paul wrote:

> Classic (per the subject line)

> Stomp 1.1

>

> Among other issues, the STOMP specification suggests I will receive a receipt 
> for my DISCONNECT frame, which I do not receive.



The tests in the broker would imply that it works



https://urldefense.com/v3/__https://github.com/apache/activemq/blob/4cadbab76cc3d2d97e9be878ddc041fb036c69d6/activemq-stomp/src/test/java/org/apache/activemq/transport/stomp/StompTest.java*L394__;Iw!!Nhky1-KV!v0OmEwB2W5MLqj3u1tqQv8G9btUVmlrxE03-HrEcUeU1iMSnoNyhmmOr5j7dWRPWz9D-O-zqXVvhViLrcoM4Pw$<https://urldefense.com/v3/__https:/github.com/apache/activemq/blob/4cadbab76cc3d2d97e9be878ddc041fb036c69d6/activemq-stomp/src/test/java/org/apache/activemq/transport/stomp/StompTest.java*L394__;Iw!!Nhky1-KV!v0OmEwB2W5MLqj3u1tqQv8G9btUVmlrxE03-HrEcUeU1iMSnoNyhmmOr5j7dWRPWz9D-O-zqXVvhViLrcoM4Pw$>





>

> Honestly, it has been about 5 months since I started this inquiry, and have 
> not received any useful information yet.

>

> I wrote my own STOMP client, in Progress OpenEdge, with a starter project 
> from the OE Hive.

>

> So far, I have not hit any roadblock preventing me from using the ActiveMQ 
> Classic STOMP broker, but would like to have the necessary tooling in place 
> in case issues arise in the future.

>

> Regards,

>

> Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.

>

> From: Simon Lundström mailto:si...@su.se.INVALID>>

> Sent: Tuesday, May 14, 2024 10:19 AM

> To: users@activemq.apache.org<mailto:users@activemq.apache.org>

> Subject: [EXTERNAL] Re: Apache ActiveMQ Classic 5.17.3; STOMP receipts

>

> Hi Paul! While not an ActiveMQ dev we've used STOMP a lot (with receipts) 
> without any problems from Perl and Python. How are the receipts coming in and 
> what are you expecting? Which version of ActiveMQ are you using? Classic or 
> Artemis? Which

> ZjQcmQRYFpfptBannerStart

> This Message Is From an Untrusted Sender

> You have not previously corresponded with this sender.

> ZjQcmQRYFpfptBannerEnd

> External Email

> 

>

> Hi Paul!

>

>

>

> While not an ActiveMQ dev we've used STOMP a lot (with receipts) without

>

> any problems from Perl and Python.

>

>

>

> How are the receipts coming in and what are you expecting?

>

>

>

> Which version of ActiveMQ are you using? Classic or Artemis?

>

>

>

> Which STOMP version are you using?

>

>

>

> Which client library are you using?

>

>

>

> I suspect answers to these questions will help the devs answer faster.

>

>

>

> BR,

>

> - Simon

>

>

>

> On Tue, 2024-05-14 at 15:45:02 +0200, Bouscaren, Paul wrote:

>

>> The STOMP receipts are not coming in as the STOMP specification dictates 
>> they should.

>> The log4j troubleshooting page is of no help since the logger library has 
>> been updated.

>> Any help would be appreciated.

>> Regards,

>> Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.

>> 

>> This email and any attachments may contain confidential and proprietary 
>> information and must be treated as such. In addition, export or re-export of 
>> the information contained in or attached to this email may be prohibited 
>> under export control laws.

>> To review our Privacy Policy please visit: 
>> https://urldefense.com/v3/__http://www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$<https://urldefense.com/v3/__http:/www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$><https://urldefense.com/v3/__http:/www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$%3chttps:/urldefense.com/v3/__http:/www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$%3e%3e>

><http

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

2024-05-14 Thread Paul Eggert


On 2024-05-14 02:24, Bruno Haible wrote:

I can do the same in gnulib-tool.sh
if you would like since it should be pretty easy there too.

This is not needed. The Python implementation is already the default.
We haven't heard from anyone who needs to run the shell implementation.


I still need to run it.

I am still falling back on the shell implementation when I discover 
gnulib-tool.py bugs or issues, and that's still happening to me (as 
recently as yesterday). So Collin, if it's not too much trouble, please 
update gnulib-tool.sh for this mkdir issue. (I'll do it if you don't 
have the time.) Thanks.

Re: [PATCH] rcu/nocb: Fix using smp_processor_id() in preemptible warning

2024-05-14 Thread Paul E. McKenney

On Thu, May 09, 2024 at 03:40:46PM +0800, Zqiang wrote:
> Currently, the this_cpu_ptr(_data) in rcu_rdp_is_offloaded() is called
> before the condition "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())"
> is checked, and occurs in preemptible task context, this will trigger the
> following warning.
> 
> [ 4.106221][ T18] BUG: using smp_processor_id() in preemptible [] 
> code: rcuop/0/18
> [ 4.107796][ T18] caller is debug_smp_processor_id (lib/smp_processor_id.c:61)
> [ 4.108547][ T18] CPU: 0 PID: 18 Comm: rcuop/0 Not tainted 
> 6.9.0-rc2-00079-g4c66bc7cacc0 #1
> [ 4.109667][ T18] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.16.2-debian-1.16.2-1 04/01/2014
> [ 4.111064][ T18] Call Trace:
> [ 4.111064][ T18]  
> [ 4.111064][ T18] dump_stack_lvl (lib/dump_stack.c:116)
> [ 4.111064][ T18] dump_stack (lib/dump_stack.c:124)
> [ 4.111064][ T18] check_preemption_disabled 
> (arch/x86/include/asm/preempt.h:84 (discriminator 15) 
> lib/smp_processor_id.c:53 (discriminator 15))
> [ 4.111064][ T18] debug_smp_processor_id (lib/smp_processor_id.c:61)
> [ 4.111064][ T18] rcu_rdp_is_offloaded (kernel/rcu/tree_plugin.h:27 
> (discriminator 1))
> [ 4.111064][ T18] nocb_cb_wait (kernel/rcu/tree_nocb.h:936 (discriminator 2))
> [ 4.111064][ T18] rcu_nocb_cb_kthread (kernel/rcu/tree_nocb.h:983 
> (discriminator 1))
> [ 4.111064][ T18] ? nocb_cb_wait (kernel/rcu/tree_nocb.h:976)
> [ 4.111064][ T18] kthread (kernel/kthread.c:388)
> [ 4.111064][ T18] ? kthread (kernel/kthread.c:373 (discriminator 2))
> [ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
> [ 4.111064][ T18] ret_from_fork (arch/x86/kernel/process.c:153)
> [ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
> [ 4.111064][ T18] ret_from_fork_asm (arch/x86/entry/entry_64.S:256)
> [ 4.111064][ T18]  
> 
> This commit fix this warning by priority check the condition 
> "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())" , to
> ensure whether the this_cpu_ptr(_data) can be executed in
> rcu_rdp_is_offloaded().
> 
> Fixes: 8feeeba60711 ("rcu/nocb: Use kthread parking instead of ad-hoc 
> implementation")
> Tested-by: kernel test robot 
> Signed-off-by: Zqiang 

Hearing no objections, I have queued this wordsmithed version.  As always,
please let me know if I have messed anything up.

Thanx, Paul



commit 5271ad1de0fbcf0bd9caebcf721670c164e5fa9c
Author: Zqiang 
Date:   Thu May 9 15:40:46 2024 +0800

rcu/nocb: Don't use smp_processor_id() in preemptible code

Currently, rcu_rdp_is_offloaded() invokes this_cpu_ptr(_data) before
the condition "!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())"
is checked.  When invoked in preemptible context in preemptible kernels,
this will trigger the following warning:

[ 4.106221][ T18] BUG: using smp_processor_id() in preemptible [] 
code: rcuop/0/18
[ 4.107796][ T18] caller is debug_smp_processor_id 
(lib/smp_processor_id.c:61)
[ 4.108547][ T18] CPU: 0 PID: 18 Comm: rcuop/0 Not tainted 
6.9.0-rc2-00079-g4c66bc7cacc0 #1
[ 4.109667][ T18] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 4.111064][ T18] Call Trace:
[ 4.111064][ T18]  
[ 4.111064][ T18] dump_stack_lvl (lib/dump_stack.c:116)
[ 4.111064][ T18] dump_stack (lib/dump_stack.c:124)
[ 4.111064][ T18] check_preemption_disabled 
(arch/x86/include/asm/preempt.h:84 (discriminator 15) lib/smp_processor_id.c:53 
(discriminator 15))
[ 4.111064][ T18] debug_smp_processor_id (lib/smp_processor_id.c:61)
[ 4.111064][ T18] rcu_rdp_is_offloaded (kernel/rcu/tree_plugin.h:27 
(discriminator 1))
[ 4.111064][ T18] nocb_cb_wait (kernel/rcu/tree_nocb.h:936 (discriminator 
2))
[ 4.111064][ T18] rcu_nocb_cb_kthread (kernel/rcu/tree_nocb.h:983 
(discriminator 1))
[ 4.111064][ T18] ? nocb_cb_wait (kernel/rcu/tree_nocb.h:976)
[ 4.111064][ T18] kthread (kernel/kthread.c:388)
[ 4.111064][ T18] ? kthread (kernel/kthread.c:373 (discriminator 2))
[ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
[ 4.111064][ T18] ret_from_fork (arch/x86/kernel/process.c:153)
[ 4.111064][ T18] ? kthread_complete_and_exit (kernel/kthread.c:341)
[ 4.111064][ T18] ret_from_fork_asm (arch/x86/entry/entry_64.S:256)
[ 4.111064][ T18]  

This commit therefore fixes this warning by checking the condition
"!(IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible())" before invoking
this_cpu_ptr(), thus avoiding preemptible invocations.

Fixes: 8feeeba60711 ("rcu/nocb: Use kthread parking instead of ad-hoc 
implementation"

Re: [PATCH 3/4] stdbit: remove most module dependence

2024-05-14 Thread Paul Eggert


On 2024-05-13 14:08, Collin Funk wrote:

Shouldn't 'Depends-on' contain extern-inline?


Thanks, I fixed that.

RE: Re: Apache ActiveMQ Classic 5.17.3; STOMP receipts

2024-05-14 Thread Bouscaren, Paul

Classic (per the subject line)
Stomp 1.1

Among other issues, the STOMP specification suggests I will receive a receipt 
for my DISCONNECT frame, which I do not receive.

Honestly, it has been about 5 months since I started this inquiry, and have not 
received any useful information yet.

I wrote my own STOMP client, in Progress OpenEdge, with a starter project from 
the OE Hive.

So far, I have not hit any roadblock preventing me from using the ActiveMQ 
Classic STOMP broker, but would like to have the necessary tooling in place in 
case issues arise in the future.

Regards,

Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.

From: Simon Lundström 
Sent: Tuesday, May 14, 2024 10:19 AM
To: users@activemq.apache.org
Subject: [EXTERNAL] Re: Apache ActiveMQ Classic 5.17.3; STOMP receipts

Hi Paul! While not an ActiveMQ dev we've used STOMP a lot (with receipts) 
without any problems from Perl and Python. How are the receipts coming in and 
what are you expecting? Which version of ActiveMQ are you using? Classic or 
Artemis? Which
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd
External Email

Hi Paul!

While not an ActiveMQ dev we've used STOMP a lot (with receipts) without

any problems from Perl and Python.

How are the receipts coming in and what are you expecting?

Which version of ActiveMQ are you using? Classic or Artemis?

Which STOMP version are you using?

Which client library are you using?

I suspect answers to these questions will help the devs answer faster.

BR,

- Simon

On Tue, 2024-05-14 at 15:45:02 +0200, Bouscaren, Paul wrote:

> The STOMP receipts are not coming in as the STOMP specification dictates they 
> should.

>

> The log4j troubleshooting page is of no help since the logger library has 
> been updated.

>

> Any help would be appreciated.

>

> Regards,

>

> Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.

>

>

> 

>

> This email and any attachments may contain confidential and proprietary 
> information and must be treated as such. In addition, export or re-export of 
> the information contained in or attached to this email may be prohibited 
> under export control laws.

> To review our Privacy Policy please visit: 
> https://urldefense.com/v3/__http://www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$<https://urldefense.com/v3/__http:/www.precast.com__;!!Nhky1-KV!t9edV3LrrtqPK-GFkO2tMdkwzLsw95DoAaxTa40bcCVqC-4m_3ak4ive3raA5VNRxfTtqPD10ZfyFWcpIXaVVg$>

This email and any attachments may contain confidential and proprietary 
information and must be treated as such. In addition, export or re-export of 
the information contained in or attached to this email may be prohibited under 
export control laws.
To review our Privacy Policy please visit: www.precast.com

[Koha-devel] REMINDER: Development IRC meeting 15 May 2024

2024-05-14 Thread Paul Derscheid via Koha-devel

Hi all,
 
We have a Development IRC/Jitsi meeting scheduled for tomorrow:
https://wiki.koha-community.org/wiki/Development_IRC_meeting_15_May_2024
 
Time converter:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting=20240515T1400
 
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting=20240403T1200>
 
Please feel free to add any topics you’d like to discuss to the agenda or let 
me know and I am happy to add them for you.
If you are lead or supporter of a roadmap project, we will be happy to get an 
update on progress.
 
See you there!
 
Paul

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Apache ActiveMQ Classic 5.17.3; STOMP receipts

2024-05-14 Thread Bouscaren, Paul

The STOMP receipts are not coming in as the STOMP specification dictates they 
should.

The log4j troubleshooting page is of no help since the logger library has been 
updated.

Any help would be appreciated.

Regards,

Paul Bouscaren | Business Analyst | Wyman-Gordon Forgings, Inc.




This email and any attachments may contain confidential and proprietary 
information and must be treated as such. In addition, export or re-export of 
the information contained in or attached to this email may be prohibited under 
export control laws.
To review our Privacy Policy please visit: www.precast.com

[valgrind] [Bug 426798] 404 link in Valgrind website for valkyrie

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

Paul Floyd  changed:

   What|Removed |Added

   Assignee|jsew...@acm.org |pjfl...@wanadoo.fr
 CC||pjfl...@wanadoo.fr

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

Bug#1069329: fixed in diffoscope 266

2024-05-14 Thread Paul Wise

On Fri, 2024-05-10 at 14:49 +, Chris Lamb wrote:

>    * Use "xz --list" to supplement the output when comparing .xz archives;
>  essential when some underlying metadata differs. (Closes: #1069329)
>    * Actually append the xz --list after the container differences, as it
>  simplifies tests and the output.

Hmm, I still get a hex diff with the test case I posted in the bug:

$ echo foo > foo
$ xz -0 < foo > foo.0.xz
$ xz -9 < foo > foo.9.xz
$ diffoscope foo.0.xz foo.9.xz
--- foo.0.xz
+++ foo.9.xz
│┄ Format-specific differences are supported for XZ compressed files but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: XZ compressed data, checksum CRC64
@@ -1,4 +1,4 @@
 : fd37 7a58 5a00 0004 e6d6 b446 0200 2101  .7zXZ..F..!.
-0010: 0c00  8f98 419c 0100 0366 6f6f 0a00  ..Afoo..
+0010: 1c00  10cf 58cc 0100 0366 6f6f 0a00  ..Xfoo..
 0020: ffd7 ac5a 3031 9cf2 0001 1c04 6f2c 9cc1  ...Z01..o,..
 0030: 1fb6 f37d 0100  0004 595a...}..YZ

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds

Bug#1069329: fixed in diffoscope 266

2024-05-14 Thread Paul Wise

On Fri, 2024-05-10 at 14:49 +, Chris Lamb wrote:

>    * Use "xz --list" to supplement the output when comparing .xz archives;
>  essential when some underlying metadata differs. (Closes: #1069329)
>    * Actually append the xz --list after the container differences, as it
>  simplifies tests and the output.

Hmm, I still get a hex diff with the test case I posted in the bug:

$ echo foo > foo
$ xz -0 < foo > foo.0.xz
$ xz -9 < foo > foo.9.xz
$ diffoscope foo.0.xz foo.9.xz
--- foo.0.xz
+++ foo.9.xz
│┄ Format-specific differences are supported for XZ compressed files but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: XZ compressed data, checksum CRC64
@@ -1,4 +1,4 @@
 : fd37 7a58 5a00 0004 e6d6 b446 0200 2101  .7zXZ..F..!.
-0010: 0c00  8f98 419c 0100 0366 6f6f 0a00  ..Afoo..
+0010: 1c00  10cf 58cc 0100 0366 6f6f 0a00  ..Xfoo..
 0020: ffd7 ac5a 3031 9cf2 0001 1c04 6f2c 9cc1  ...Z01..o,..
 0030: 1fb6 f37d 0100  0004 595a...}..YZ

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Groovy Poster for Community Over Code EU

2024-05-14 Thread Paul King

Hi folks,

We have a poster that will be displayed at Community Over Code EU in
Bratislava in a few weeks.

Here is my current draft:

https://github.com/apache/apachecon-eu/blob/main/static/posters/CoCEU_WhyGroovyToday.pdf

There is a small window to make changes before they send the posters
off to the printers. It will be printed I think on A1 size paper,
about 594mm W x 841mm H (23.4 x 33.1 inches).

At the moment, it is rich in technical content - perhaps a little
light in marketing the benefits. If I was to make changes I'd prefer
to maybe reduce the first slightly and increase the latter. Let me
know if you have any feedback.

Thanks, Paul.

[Bug 2065670] Re: Everytime I close GIMP, I get a crash report

2024-05-14 Thread Paul White

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  Everytime I close GIMP, I get a crash report

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


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

[Bug 2065670] Re: Everytime I close GIMP, I get a crash report

2024-05-14 Thread Paul White

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  Everytime I close GIMP, I get a crash report

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


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

Bug#1071094: osc: SyntaxWarning: invalid escape sequence

2024-05-14 Thread Paul Wise

Package: osc
Version: 0.182.1-1
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Upgrading osc gives Python 3.12 warnings,
the fix for this is to use raw strings:

https://docs.python.org/3/library/re.html#raw-string-notation

   Preparing to unpack .../archives/osc_0.182.1-1_all.deb ...
   Unpacking osc (0.182.1-1) over (0.169.1-2) ...
   Setting up osc (0.182.1-1) ...
   /usr/lib/python3/dist-packages/osc/commandline.py:7931: SyntaxWarning: 
invalid escape sequence '\('
 if re.match('^perl\(\w+(::\w+)*\)$', search_term):
   /usr/lib/python3/dist-packages/osc/commandline.py:7932: SyntaxWarning: 
invalid escape sequence '\)'
 search_term = re.sub('\)', '', re.sub('(::|\()', '-', search_term))
   /usr/lib/python3/dist-packages/osc/commandline.py:7932: SyntaxWarning: 
invalid escape sequence '\('
 search_term = re.sub('\)', '', re.sub('(::|\()', '-', search_term))
   /usr/lib/python3/dist-packages/osc/commandline.py:7953: SyntaxWarning: 
invalid escape sequence '\ '
 'or \'--bugowner\' or \'--maintainer\' or \'--limit-to-attribute \ ' 
\
   /usr/lib/python3/dist-packages/osc/commandline.py:9201: SyntaxWarning: 
invalid escape sequence '\*'
 if re.match('^\*\W+(.+\W+\d{1,2}\W+20\d{2})\W+(.+)\W+<(.+)>\W+(.+)$', 
titleline):
   /usr/lib/python3/dist-packages/osc/core.py:4124: SyntaxWarning: invalid 
escape sequence '\s'
 tag_pat = '(?P^%s)\s*:\s*(?P.*)'
   /usr/lib/python3/dist-packages/osc/core.py:4130: SyntaxWarning: invalid 
escape sequence '\s'
 section_pat = '^%s\s*?$'
   /usr/lib/python3/dist-packages/osc/core.py:6321: SyntaxWarning: invalid 
escape sequence '\['
 time_regex = re.compile('^\[[^\]]*\] ', re.M)
   /usr/lib/python3/dist-packages/osc/core.py:6324: SyntaxWarning: invalid 
escape sequence '\['
 time_regex = re.compile(b'^\[[^\]]*\] ', re.M)
   /usr/lib/python3/dist-packages/osc/core.py:7762: SyntaxWarning: invalid 
escape sequence '\s'
 mo = re.search('^([adrl])(?:\s+(-f)?\s*-m\s+(.*))?$', repl)
   /usr/lib/python3/dist-packages/osc/fetch.py:80: SyntaxWarning: invalid 
escape sequence '\.'
 n = re.sub(b'\.pkg\.tar\.(zst|.z)$', b'.arch', hdr.filename)
   /usr/lib/python3/dist-packages/osc/fetch.py:82: SyntaxWarning: invalid 
escape sequence '\.'
 n = re.sub(b'\.tar\.(zst|.z)$', b'.tar', hdr.filename)
   /usr/lib/python3/dist-packages/osc/util/archquery.py:166: SyntaxWarning: 
invalid escape sequence '\d'
 mo1 = re.match(b'(\d+)', ver1)
   /usr/lib/python3/dist-packages/osc/util/archquery.py:167: SyntaxWarning: 
invalid escape sequence '\d'
 mo2 = re.match(b'(\d+)', ver2)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:94: SyntaxWarning: 
invalid escape sequence '\s'
 field, val = re.split(b':\s*', data.strip(), 1)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:96: SyntaxWarning: 
invalid escape sequence '\s'
 while data and re.match(b'\s+', data):
   /usr/lib/python3/dist-packages/osc/util/debquery.py:127: SyntaxWarning: 
invalid escape sequence '\s'
 def _split_field_value(self, field, delimeter=b',\s*'):
   /usr/lib/python3/dist-packages/osc/util/debquery.py:208: SyntaxWarning: 
invalid escape sequence '\d'
 ver1 = re.sub(b'(\d+)', lambda m: (32 * b'0' + m.group(1))[-32:], ver1)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:209: SyntaxWarning: 
invalid escape sequence '\d'
 ver2 = re.sub(b'(\d+)', lambda m: (32 * b'0' + m.group(1))[-32:], ver2)
   /usr/lib/python3/dist-packages/osc/util/rpmquery.py:344: SyntaxWarning: 
invalid escape sequence '\d'
 mo1 = re.match('(\d+)', ver1)
   /usr/lib/python3/dist-packages/osc/util/rpmquery.py:345: SyntaxWarning: 
invalid escape sequence '\d'
 mo2 = re.match('(\d+)', ver2)
   
-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), 
(790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), 
(690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages osc depends on:
ii  ca-certificates   20240203
ii  python3   3.11.8-1
ii  python3-m2crypto  0.40.1-3

Versions of packages osc recommends:
ii  bash-completion  1:2.13.0-1
ii  cpio 2.15+dfsg-1
pn  obs-build
ii  python3-keyring  25.2.0-1
ii  python3-rpm  4.19.1.1+dfsg-1
ii  rpm2cpio 4.19.1.1+dfsg-1
ii  sensible-utils   0.0.22

osc suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc

[meteorite-list] Meteorite Picture of the Day

2024-05-14 Thread Paul Swartz via Meteorite-list

Tuesday, May 14 2024 Meteorite Picture of the Day: Seymchan

Contributed by: Sue Spinnato

http://www.tucsonmeteorites.com/mpodmain.asp?DD=05/14/2024
__
Meteorite-list mailing list
Meteorite-list@meteoritecentral.com
https://pairlist2.pair.net/mailman/listinfo/meteorite-list

[valgrind] [Bug 454346] [PATCH] ARM fixes from the Yocto project

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

--- Comment #9 from Paul Floyd  ---
On my RPi 5 with Raspberry Pi OS
Linux raspberrypi 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1
(2024-01-25) aarch64 GNU/Linux

Build fails with

m_dispatch/dispatch-arm-linux.S:102: Error: selected processor does not support
`movw r1,#47' in ARM mode
m_dispatch/dispatch-arm-linux.S:103: Error: selected processor does not support
`movw r2,#0' in ARM mode
m_dispatch/dispatch-arm-linux.S:155: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_stats__n_xIndirs_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:156: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_stats__n_xIndirs_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:173: Error: selected processor does not support
`ubfx r6,r6,#0,#13' in ARM mode
m_dispatch/dispatch-arm-linux.S:176: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_tt_fast' in ARM mode
m_dispatch/dispatch-arm-linux.S:177: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_tt_fast' in ARM mode
m_dispatch/dispatch-arm-linux.S:204: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_stats__n_xIndir_hits1_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:205: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_stats__n_xIndir_hits1_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:226: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_stats__n_xIndir_hits2_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:227: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_stats__n_xIndir_hits2_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:248: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_stats__n_xIndir_hits3_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:249: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_stats__n_xIndir_hits3_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:258: Error: selected processor does not support
`movw r4,#:lower16:vgPlain_stats__n_xIndir_misses_32' in ARM mode
m_dispatch/dispatch-arm-linux.S:259: Error: selected processor does not support
`movt r4,#:upper16:vgPlain_stats__n_xIndir_misses_32' in ARM mode

and also

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1
-DVGPV_arm_linux_vanilla=1-O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
-Wwrite-strings -Wempty-body -Wformat -Wformat-signedness -Wformat-security
-Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wenum-conversion
-Wimplicit-fallthrough=2 -Wold-style-declaration -finline-functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin   -marm -O2  -MT
memcheck_arm_linux-mc_main.o -MD -MP -MF .deps/memcheck_arm_linux-mc_main.Tpo
-c -o memcheck_arm_linux-mc_main.o `test -f 'mc_main.c' || echo './'`mc_main.c
/tmp/ccY1NRlM.s: Assembler messages:
/tmp/ccY1NRlM.s:27: Error: selected processor does not support `movw
r3,#:lower16:primary_map' in ARM mode
/tmp/ccY1NRlM.s:29: Error: selected processor does not support `movt
r3,#:upper16:primary_map' in ARM mode
/tmp/ccY1NRlM.s:68: Error: selected processor does not support `movw
r3,#:lower16:primary_map' in ARM mode
/tmp/ccY1NRlM.s:70: Error: selected processor does not support `movt
r3,#:upper16:primary_map' in ARM mode

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1
-DVGPV_arm_linux_vanilla=1-O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
-Wwrite-strings -Wempty-body -Wformat -Wformat-signedness -Wformat-security
-Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wenum-conversion
-Wimplicit-fallthrough=2 -Wold-style-declaration -finline-functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin   -marm -O2  -MT
memcheck_arm_linux-mc_main_asm.o -MD -MP -MF
.deps/memcheck_arm_linux-mc_main_asm.Tpo -c -o memcheck_arm_linux-mc_main_asm.o
`test -f 'mc_main_asm.c' || echo './'`mc_main_asm.c
/tmp/cclkrIER.s: Assembler messages:
/tmp/cclkrIER.s:25: Error: selected processor does not support `movw
r3,#:lower16:primary_map' in ARM mode
/tmp/cclkrIER.s:28: Error: selected processor does not support `movt
r3,#:upper16:primary_map' in ARM mode
/tmp/cclkrIER.s:31: Error: selected processor does not support `movw
r3,#0x' in ARM mode
/tmp/cclkrIER.s:40: Error: selected processor does not support `movw
r3,#0x' in ARM mode
/tmp/cclkrIER.s:61: Error: selected processor does not support `movw
r3,#:lower16:primary_map' in ARM mode
/tmp/cclkrIER.s:64: Error: selected processor does not support `movt
r3,#:upper16:primary_map' in ARM mode

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

[bareos-users] Bareos 21.0.0 - missing "delete" command in console

2024-05-13 Thread Paul Chen

[image: Capture2.JPG]
[image: Capture.JPG]



-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/ccef7c38-3a7a-4815-98f9-a67973a9474cn%40googlegroups.com.

Re: Installing testing on Acer Aspire 315 [finished]

2024-05-13 Thread Paul Scott




On 5/12/24 21:30, David Wright wrote:

On Sun 12 May 2024 at 21:10:16 (-0700), Paul Scott wrote:

On 5/9/2024 1:59 PM, Charles Curley wrote:

On Thu, 9 May 2024 09:32:32 -0700 Paul Scott wrote:


The error I'm getting is during "Install base system."  The only way
I knew to save the log was with a camera. Even though I resized the
image this list apparently didn't allow the attachment. How else can
I save the log during install?

Installation logs are saved during installation to the target's
/var/log/installer/. You can save them to a USB stick after
installation is complete, or reboot and find them.

Is this possible if the base installation failed?  If so, how?

Depends on how it failed. The last three entries in the main menu
are:

   Save debug logs
   Execute a shell
   Abort the installation

You can use the first one and follow its instructions. You can use
the second, and type suitable mount/cp/umount commands to achieve
the same thing.

During the installation, if you get a shell, then

   # more /var/log/syslog

will allow you to pick over the logs, rather like less does, with
the disadvantage that you can't go backwards. If you overshoot the
lines of interest, you have to run the more command again.


This weeks version of the testing net install worked completely. Sending 
this from Thunderbird on the new system.


Thank you everyone who helped,

Paul




Cheers,
David.

bug#70503: [PATCH] Add function "TeX-master-output-file"

2024-05-13 Thread Paul Nelson

>
>
> @Paul: Do you have any other patches pending?  I think you're also
> waiting for 14.0.5 in order to start the ELPA release of your packages,
> right?
>
> Best, Arash
>

It looks like I've gone a solid week now without submitting any patches,
which suggests that things are now a "go" on my end for bumping the version.

Thanks, best,

Paul
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex

Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists


If I run this command twice, by mistake:

./gnulib-tool --create-testdir --dir foo -h stdbit
./gnulib-tool --create-testdir --dir foo -h stdbit

The second invocation eventually fails with:

  ...
  executing automake --add-missing --copy
  patching file build-aux/test-driver
  /home/eggert/src/gnu/gnulib/gnulib-tool.py: *** could not patch 
test-driver script

  /home/eggert/src/gnu/gnulib/gnulib-tool.py: *** Stop.

I messed up. However, the shell implementation of gnulib-tool diagnoses 
my mistake right away, before going on its slow way:


  $ GNULIB_TOOL_IMPL=sh ./gnulib-tool --create-testdir --dir foo -h stdbit
  mkdir: cannot create directory ‘foo’: File exists
  Module list with included dependencies (indented):
  absolute-header
  alignasof

and it'd be nice if the Python implementation was as fast as the shell 
implementation in this case.


Perhaps both implementations should quickly exit in this situation, come 
to think of it.

Re: *.m4 conventions


On 2024-05-13 13:23, Bruno Haible wrote:

   # stdio_h.m4 - Autoconf macros for the stdio module.
   # serial 42


Oh, I didn't know you could do that. Thanks, I'll keep it in mind.

Re: [Swan] Data sent in clear despite established tunnel

2024-05-13 Thread Paul Wouters via Swan


On Fri, 10 May 2024, Phil Nightowl wrote:


This was the case up until the last change (see above) - which I can
roll back right away - but that did not work for me. I ended up with the
public IP as source address in the xfrm policy installed by libreswan
anyway. What I can further try is to use rightsubnet instead of
rightaddresspool.


I do not understand how that could happen.

eg you should see something like:

src 100.64.13.3/32 dst 0.0.0.0/0
dir out priority 1753344 ptype main
tmpl src 192.168.6.23 dst 193.110.157.148
proto esp reqid 16397 mode tunnel

Where 100.64.13.3/32 is the IP I was assigned from their
rightaddrespool, 192.168.6.23 is my LAN IP and 193.110.157.148
is the public IP of the vpn server.


I assume that rightsubnet differs from rightaddresspool basically in the
fact that the IP is not assigned by the server/responder in the former case,
but set in the ipsec.conf. How do I set it on the initiator?


Yes. On the initiator you set it as leftsubnet= (assuming you use left
as local there)


Do I need to
explicitly set up a virtual interface on the roadwarrior/initiator with some
RFC1918 address, or does that libreswan take care of this itself?


You might have to configre the IP/32 on loopback yourself. It assumes
the subnet is either local or reachable via routing.


And do I need to put a static leftsubnet= on the roadwarrior, identical to
the rightsubnet= on the server?


Yes but isnt this the same question as above? because roadwarrior == initiator ?

Note if you want to ask further help, you will need to send logs and
config and not censor any IP addresses to make it possible for us to
really see what is happening.

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [ccp4bb] AlphaFold3 Transparency and Reproducibility

2024-05-13 Thread Paul Adams

the Editor in the coming days.
>> > 
>> > 
>> > 
>> >Please see the entire letter here. 
>> > <https://docs.google.com/forms/d/e/1FAIpQLSf6ioZPbxiDZy5h4qxo-bHa0XOTOxEYHObht0SX8EgwfPHY_g/viewform?usp=sf_link>
>> >  
>> > <https://urldefense.com/v3/__https://docs.google.com/forms/d/e/1FAIpQLSf6ioZPbxiDZy5h4qxo-bHa0XOTOxEYHObht0SX8EgwfPHY_g/viewform?usp=sf_link*3E__;JQ!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AqTp0-CX$>
>> >  If you want to endorse this letter, please fill out your name, 
>> > affiliation, and email in the form.
>> > 
>> > 
>> > 
>> >Additionally, a PDF version of the letter can be found here 
>> > <https://drive.google.com/file/d/1u1D3KzsllpI_6I0drA9RdIiENd9EK1Hz/view?usp=sharing>
>> >  
>> > <https://urldefense.com/v3/__https://drive.google.com/file/d/1u1D3KzsllpI_6I0drA9RdIiENd9EK1Hz/view?usp=sharing*3E__;JQ!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AmjNPgIH$>.
>> > 
>> > 
>> > 
>> >Thank you, 
>> > 
>> > 
>> > 
>> >Stephanie Wankowicz, UCSF 
>> > 
>> >Pedro Beltrao, ETH 
>> >Benjamin Cravatt, Scripps 
>> >Roland Dunbrack, FCCC 
>> >Anthony Gitter, UW Madison 
>> >Kresten Lindorff-Larsen, Copenhagen 
>> >Sergey Ovchinnikov, MIT 
>> >Nicholas Polizzi, DFCI/HMS 
>> >Brian Shoichet, UCSF 
>> >James Fraser, UCSF 
>> > 
>> > 
>> 
>>  
>> 
>> To unsubscribe from the CCP4BB list, click the following link: 
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
>> <https://urldefense.com/v3/__https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AoA8pumq$>
>> 
>> This message was issued to members of www.jiscmail.ac.uk/CCP4BB 
>> <https://urldefense.com/v3/__http://www.jiscmail.ac.uk/CCP4BB__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AgFZZaeK$>,
>>  a mailing list hosted by www.jiscmail.ac.uk 
>> <https://urldefense.com/v3/__http://www.jiscmail.ac.uk__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7An7YNOzL$>,
>>  terms & conditions are available at 
>> https://www.jiscmail.ac.uk/policyandsecurity/ 
>> <https://urldefense.com/v3/__https://www.jiscmail.ac.uk/policyandsecurity/__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7ApCXqJeM$>
>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
>> <https://urldefense.com/v3/__https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AoA8pumq$>
>> This communication is intended for the addressee only. It is confidential. 
>> If you have received this communication in error, please notify us 
>> immediately and destroy the original message. You may not copy or 
>> disseminate this communication without the permission of the University. 
>> Only authorised signatories are competent to enter into agreements on behalf 
>> of the University and recipients are thus advised that the content of this 
>> message may not be legally binding on the University and may contain the 
>> personal views and opinions of the author, which are not necessarily the 
>> views and opinions of The University of the Witwatersrand, Johannesburg. All 
>> agreements between the University and outsiders are subject to South African 
>> Law unless the University agrees in writing to the contrary.
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
>> <https://urldefense.com/v3/__https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NEnc9RG_drv9T5at5d7AoA8pumq$>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> <https://urldefense.com/v3/__https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1__;!!LQC6Cpwp!ojUwuRRzsCarUF-wwnVWIQtQbTonf10zBas4dHDOMDcNF3qWUSO99i3QLLB39nBZ8NE

[Bug 2065583] Re: package snapd 2.62+22.04 failed to install/upgrade: installed snapd package post-removal script subprocess returned error exit status 1

** Package changed: ubuntu => snapd (Ubuntu)

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

Title:
  package snapd 2.62+22.04 failed to install/upgrade: installed snapd
  package post-removal script subprocess returned error exit status 1

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


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

Re: SQL:2011 application time

2024-05-13 Thread Paul Jungwirth

On 5/13/24 03:11, Peter Eisentraut wrote:
It looks like we missed some of these fundamental design questions early on, and it might be too
late now to fix them for PG17.

For example, the discussion on unique constraints misses that the question of null values in unique
constraints itself is controversial and that there is now a way to change the behavior. So I
imagine there is also a selection of possible behaviors you might want for empty ranges.
Intuitively, I don't think empty ranges are sensible for temporal unique constraints. But anyway,
it's a bit late now to be discussing this.

I'm also concerned that if ranges have this fundamental incompatibility with periods, then the plan
to eventually evolve this patch set to support standard periods will also have as-yet-unknown problems.

Some of these issues might be design flaws in the underlying mechanisms, like range types and
exclusion constraints. Like, if you're supposed to use this for scheduling but you can use empty
ranges to bypass exclusion constraints, how is one supposed to use this? Yes, a check constraint
using isempty() might be the right answer. But I don't see this documented anywhere.

On the technical side, adding an implicit check constraint as part of a primary key constraint is
quite a difficult implementation task, as I think you are discovering. I'm just reminded about how
the patch for catalogued not-null constraints struggled with linking these not-null constraints to
primary keys correctly. This sounds a bit similar.

I'm afraid that these issues cannot be resolved in good time for this release, so we should revert
this patch set for now.

I think reverting is a good idea. I'm not really happy with the CHECK constraint solution either.
I'd be happy to have some more time to rework this for v18.

A couple alternatives I'd like to explore:

1. Domain constraints instead of a CHECK constraint. I think this is probably worse, and I don't
plan to spend much time on it, but I thought I'd mention it in case someone else thought otherwise.

2. A slightly different overlaps operator, say &&&, where 'empty' &&& 'empty' is true. But 'empty'
with anything else could still be false (or not). That operator would prevent duplicates in an
exclusion constraint. This also means we could support more types than just ranges & multiranges. I
need to think about whether this combines badly with existing operators, but if not it has a lot of
promise. If anything it might be *less* contradictory, because it fits better with 'empty' @>
'empty', which we say is true.

Another thing a revert would give me some time to consider: even though it's not standard syntax, I
wonder if we want to require syntax something like `PRIMARY KEY USING gist (id, valid_at WITHOUT
OVERLAPS)`. Everywhere else we default to btree, so defaulting to gist feels a little weird. In
theory we could even someday support WITHOUT OVERLAPS with btree, if we taught that AM to answer
that question. (I admit there is probably not a lot of desire for that though.)

Yours,

--
Paul ~{:-)
p...@illuminatedcomputing.com

Re: [LincolnTalk] Bear sighting just now at Fox Run Road

2024-05-13 Thread Lisa Paul

Linda, thanks so much for sharing! The information is very helpful. Best,Lisa PaulOn May 13, 2024, at 7:07 PM, Linda McMillan wrote:I talked with the Massachusetts bear biologist today. He said this bear was moved from Worcester where he was wandering into a very developed area not because he was aggressive or violent. He's about two years old and has moved about 35 miles in the last week. They have no intention of moving him out of Lincoln. He said we should get used to having bears in our town. The likelihood is that we will see more.He said to take down your bird feeders and bring in your trash.Regarding dogs, he said there is more risk that your dog will be attacked by a coyote than by a bear. However, he said if you have a dog that wanders or does not come to you when called, or who is aggressive, he suggests keeping it on a leash.He also said there is no need to notify them of the current location because they have no plans to move the bear.I hope this is helpful.Linda On Mon, May 13, 2024, 5:12 PM Jennifer Saffran wrote:I’ve seen bear tags before, but “Dodger” appears to have both ears tagged. What’s up with that?On May 12, 2024, at 9:20 PM, Joanna Owen Schmergel via Lincoln wrote:
It’s Dodger! Sent from Yahoo Mail for iPhoneOn Sunday, May 12, 2024, 9:16 PM, Lynne Smith wrote:Looks like he has opposing thumbs ! And he clearly knows where to find seeds.Lynne Smith5 Tabor Hill RoadLincoln, MA 01773781-258-1175Sent from my iPhone> On 12 May 2024, at 6:14 PM, pspe...@gmail.com wrote:> > > > > > > > Sent from my iPhone--> The LincolnTalk mailing list.> To post, send mail to Lincoln@lincolntalk.org.> Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.> Change your subscription settings at https://pairlist9.pair.net/mailman/listinfo/lincoln.> -- The LincolnTalk mailing list.To post, send mail to Lincoln@lincolntalk.org.Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.Change your subscription settings at https://pairlist9.pair.net/mailman/listinfo/lincoln.
-- The LincolnTalk mailing list.To post, send mail to Lincoln@lincolntalk.org.Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.Change your subscription settings at https://pairlist9.pair.net/mailman/listinfo/lincoln.--
The LincolnTalk mailing list.
To post, send mail to Lincoln@lincolntalk.org.
Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.
Change your subscription settings at https://pairlist9.pair.net/mailman/listinfo/lincoln.

-- The LincolnTalk mailing list.To post, send mail to Lincoln@lincolntalk.org.Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.Change your subscription settings at https://pairlist9.pair.net/mailman/listinfo/lincoln.--
The LincolnTalk mailing list.
To post, send mail to Lincoln@lincolntalk.org.
Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.
Change your subscription settings at
https://pairlist9.pair.net/mailman/listinfo/lincoln.

Re: considering L1 cache


On 5/13/24 09:17, Bruno Haible wrote:

The reason is that such a 256-bytes table will tend to occupy 256 bytes in the
CPU's L1 cache, and thus reduce the ability of other code to use the L1 cache.


Yes, it partly depends on whether the function is called a lot (so the 
256-byte table is in the cache) or rarely (so it's not). I had optimized 
for the former.


The code can be changed to not use an extern data table. I installed the 
attached. This probably a win (over de Bruijn too), at least for some 
apps and platforms, though I haven't benchmarked.From 1b7e82be9dd80fbb67a5567cdf1d60d36dd40db2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 13 May 2024 15:21:55 -0700
Subject: [PATCH] stdbit: redo clzll without lookcup table

* lib/stdbit.c (__gl_stdbit_clztab):
* lib/stdbit.in.h (__gl_stdbit_clzll):
[!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]: Rewrite to avoid the
need for a lookup table in memory, and remove the lookup table.
Do this by shrinking the table to 64 bits and puttiung in a 64-bit
constant.  Although this needs another round of shifts, it avoids
the need for a multiplication and memory access a la de Bruijn,
and is probably a win.
---
 ChangeLog   | 12 
 lib/stdbit.c| 24 
 lib/stdbit.in.h |  5 ++---
 3 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 18aab772fc..3e4eba3796 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2024-05-13  Paul Eggert  
+
+	stdbit: redo clzll without lookcup table
+	* lib/stdbit.c (__gl_stdbit_clztab):
+	* lib/stdbit.in.h (__gl_stdbit_clzll):
+	[!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]: Rewrite to avoid the
+	need for a lookup table in memory, and remove the lookup table.
+	Do this by shrinking the table to 64 bits and puttiung in a 64-bit
+	constant.  Although this needs another round of shifts, it avoids
+	the need for a multiplication and memory access a la de Bruijn,
+	and is probably a win.
+
 2024-05-13  Bruno Haible  
 
 	stdbit tests: Adhere better to Gnulib naming conventions.
diff --git a/lib/stdbit.c b/lib/stdbit.c
index f2a51b10f7..a9f0ef5074 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -22,30 +22,6 @@
 #define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
 #include 
 
-#if !defined _GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER
-/* __gl_stdbit_clztab[B] is the number of leading zeros in
-   the 8-bit byte with value B.  */
-char const __gl_stdbit_clztab[256] =
-  {
-8,
-7,
-6, 6,
-5, 5, 5, 5,
-4, 4, 4, 4, 4, 4, 4, 4,
-3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
-
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
-
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
-
-/* The rest is zero.  */
-  };
-#endif
-
 #if 1500 <= _MSC_VER && (defined _M_IX86 || defined _M_X64)
 signed char __gl_stdbit_popcount_support;
 #endif
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 15533dbbda..18efaf2d7c 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -122,8 +122,6 @@ __gl_stdbit_clzll (unsigned long long int n)
 
 #else /* !_MSC_VER */
 
-extern char const __gl_stdbit_clztab[256];
-
 _GL_STDBIT_INLINE int
 __gl_stdbit_clzll (unsigned long long int n)
 {
@@ -135,7 +133,8 @@ __gl_stdbit_clzll (unsigned long long int n)
   int a5 = (0x < n) << 5; n >>= a5; r += a5;
   int a4 = (0x < n) << 4; n >>= a4; r += a4;
   int a3 = (0x00ff < n) << 3; n >>= a3; r += a3;
-  return (8 * (sizeof n - 1) - r) + __gl_stdbit_clztab[n];
+  int a2 = (0x000f < n) << 2; n >>= a2; r += a2;
+  return (8 * sizeof n - (1 << 2) - r) + ((0x2234ull >> (n << 2)) & 0xf);
 }
 _GL_STDBIT_INLINE int
 __gl_stdbit_clz (unsigned int n)
-- 
2.45.0

[llvm-branch-commits] [llvm][misexpect] Update MisExpect to use provenance tracking metadata (PR #86610)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/86610


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

[llvm-branch-commits] [llvm][ProfDataUtils] provide getNumBranchWeights API (PR #90146)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/90146


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

[llvm-branch-commits] [llvm][ProfDataUtils] provide getNumBranchWeights API (PR #90146)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/90146


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

[llvm-branch-commits] [llvm][misexpect] Update MisExpect to use provenance tracking metadata (PR #86610)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/86610


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

[llvm-branch-commits] [llvm][IR] Extend BranchWeightMetadata to track provenance of weights (PR #86609)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/86609


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

[llvm-branch-commits] [llvm][IR] Extend BranchWeightMetadata to track provenance of weights (PR #86609)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/86609


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

[Bug 2065624] Re: GIMP crashes when exiting

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  GIMP crashes when exiting

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


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

[Bug 2065624] Re: GIMP crashes when exiting

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  GIMP crashes when exiting

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


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

[OPSAWG]Re: [Ie-doctors] Re: [IANA #1363823] Expert review for draft-ietf-opsawg-ipfix-tcpo-v6eh (ipfix)

2024-05-13 Thread Aitken, Paul

Med,


3.3.

  Extension headers observed in a Flow with varying extension header
  chain MAY be aggregated in one single ipv6ExtensionHeadersFull
  Information Element or be exported in separate
  ipv6ExtensionHeadersFull IEs, one for each extension header chain.

Seems to contradict these paragraphs:

3.4.

  Each header chain in Flow with varying extension header chain MUST
  be exported in a separate IE.


3.6
  Each header chain length of a Flow with varying extension header
  chain MUST be exported in a separate
  ipv6ExtensionHeadersChainLength IE.



6.1. remove ",and" :


   Figure 2 provides another example of reported values in an
   ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the Destination
   Options (0), IPv6 Hop-by-Hop Options (1), and Routing (5), and
   headers are observed.

P.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[valgrind] [Bug 353471] memcheck/tests/x86/xor-undef-x86 fails on OS X 10.11

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

Paul Floyd  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paul Floyd  ---
With the patch from 282910 this testcase now passes on 10.13. Can't easily test
this on 10.11.

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

[valgrind] [Bug 348909] Support OS X 10.11 (El Capitan)

https://bugs.kde.org/show_bug.cgi?id=348909
Bug 348909 depends on bug 353471, which changed state.

Bug 353471 Summary: memcheck/tests/x86/xor-undef-x86 fails on OS X 10.11
https://bugs.kde.org/show_bug.cgi?id=353471

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

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

[valgrind] [Bug 276780] An instruction in fftw (Fast Fourier Transform) is unhandled by valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x22

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

Paul Floyd  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

--- Comment #5 from Paul Floyd  ---
commit 92b6fa13d4ecf075c434d0316d493383edf7aa6d (HEAD -> master, origin/master,
origin/HEAD)
Author: Tom Hughes 
Date:   Mon May 13 20:40:19 2024 +0200

Bug 276780 - An instruction in fftw (Fast Fourier Transform) is unhandled
by valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x22

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

[Bug 2065621] Re: always happens, when I turn if off.

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  always happens, when I turn if off.

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


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

[Bug 2065621] Re: always happens, when I turn if off.

*** This bug is a duplicate of bug 2055044 ***
https://bugs.launchpad.net/bugs/2055044

** This bug has been marked a duplicate of bug 2055044
   GIMP crash at closure on systems with GLib 2.80.0 (and 2.79.x)

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

Title:
  always happens, when I turn if off.

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


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

[OPSAWG]Re: [Ie-doctors] [IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)

2024-05-13 Thread Aitken, Paul

Med,

In the new version:


4.1. The first 64 most-significant bits MUST be set to 0.

This seems to exclude reduced size encoding.

Also, "while Kind 255 corresponds to the most-significant bit of the IE." is 
nolonger accurate.


4.2 udpUnsfaeOptions

Typo: udpUnsafeOptions


4.1 and 4.2:

A bit is set to 1

should be "The bit is set to 1".


5.  Operational Considerations

The note about reduced-size encoding will not be seen in IANA's registry.
The note seems contrary to the statement in 4.1 that I quoted above.


Figure 4:

Repeating two points that I made previously:

The last 0x9858 (next to 0xC3D9) should be 0x9658. Else the figure does not 
correspond with the preceding text.

9658 and 9858 are unnecessarily similar values. I would urge you to choose a 
different example.

P.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Re: *.m4 conventions


On 2024-05-13 09:57, Bruno Haible wrote:

Note that in Gnulib, a human-readable comment
   # Autoconf macros for the stdio module.
is just as trivial as this comment:
   # stdio_h.m4


Although that's true for experts, it's not necessarily true for 
beginners who are the main audience for the first line. A beginner won't 
know whether stdio_h.m4 is for the entire stdio module, or just for 
configuring the stdio.h replacement, or just for configuring the stdio 
implementation, or something else.


In general the first line could be quite helpful for a brief explanation 
of file contents, for non experts. Yes, this information can be put 
elsewhere in the .m4 file, but the first line is a better place for it.

Re: [PATCH 2/4] stdbit-tests: new module


On 2024-05-13 10:47, Bruno Haible wrote:


I would propose to rename the files to 'test-*' in Gnulib. They are
not likely to be modified frequently in glibc, therefore the gnulib <--> glibc
merge effort is likely zero. And annotate the mapping in config/srclist.txt
accordingly.


Wouldn't we also need to change config/srclist-update to support file 
renaming? And even then it'd be confusing for the files to have 
different basenames in gnulib vs glibc.




If you have objections to that, I would instead
   - move the tst-* files to a subdirectory, say from-glibc/,
   - change the module descriptions so that
   tests/from-glibc/tst-stdc_trailing_zeros.c
 is compiled to an executable named
   ${tests_prefix}/test-stdc_trailing_zeros${EXEEXT}.
So that the autocompletion again works.


That should work, and I think it wouldn't need changes to 
config/srclist-update. Thanks.

Re: why __gl_ prefix?


On 2024-05-13 10:33, Bruno Haible wrote:

In the stdbit and binary-io modules, you have been introducing a number
of a symbols with prefix __gl_.

I would propose to remove the first underscore, that is, to rename them
to_gl_*.

Rationale:
* It is well understood that symbols prefixed with __ belong
   to the implementation of the system, that is, to the compiler and libc.
   Gnulib code is application code, from this perspective.
* I've seen gcc 14 warnings for '#undef __STDC_VERSION_STDDEF_H__' [1]
   and I don't know how the compilers will evolve in their handling of
   such symbols.


I take your point, but when Gnulib implements a standard C or POSIX 
feature the Gnulib code is arguably part of the implementation not the 
application.


For stdbit.h the issue was whether stdbit.h should be namespace clean as 
required by the standards, or whether it should avoid using identifiers 
reserved to the implementation. I saw no practical way to do both, and 
chose the former.


Gnulib defines many other "belong to the implementation" symbols such as 
__gl_error_call and _GL_EXTERN. Many of these symbols are inherited from 
Gnulib's copying of glibc code, e.g., __glibc_likely. So I figured there 
was a lot of precedent for this sort of thing.

[valgrind] [Bug 276780] An instruction in fftw (Fast Fourier Transform) is unhandled by valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x22

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

Paul Floyd  changed:

   What|Removed |Added

 CC||t...@compton.nu

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

[valgrind] [Bug 276780] An instruction in fftw (Fast Fourier Transform) is unhandled by valgrind: vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x22

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

--- Comment #4 from Paul Floyd  ---
Created attachment 169455
  --> https://bugs.kde.org/attachment.cgi?id=169455=edit
Added testcase NEWS and .gitignore

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

Bug#1071070: src:nbd: fails to migrate to testing for too long: autopkgtest failure


Source: nbd
Version: 1:3.25-1
Severity: serious
Control: close -1 1:3.26.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:nbd has been trying to migrate for 71 days 
[2]. Hence, I am filing this bug. You added an autopkgtest to your 
package (thank you for that), but it fails. This is blocking migration.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=nbd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071070: src:nbd: fails to migrate to testing for too long: autopkgtest failure


Source: nbd
Version: 1:3.25-1
Severity: serious
Control: close -1 1:3.26.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:nbd has been trying to migrate for 71 days 
[2]. Hence, I am filing this bug. You added an autopkgtest to your 
package (thank you for that), but it fails. This is blocking migration.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=nbd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: donation

2024-05-13 Thread Paul Brown

On Tuesday 16 April 2024 20:48:14 CEST PlusPl?ss Jo?l Pl?ss wrote:
> Hey there do you have some IBAN accounts I can use inside the EU / Swiss ?
> that would be easiest for me, thanks BR. joel

Have you tried this?:

https://kdenlive.org/en/fund/

In the second screen it allows you to pick "Bank transfer". Could that be what 
you are looking for?

Cheers

Paul
-- 
Promotion & Communication

www: https://kde.org
Mastodon: https://floss.social/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Bug#1069447: gpaw: FTBFS on armhf: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-pytest "--test-args=-v -m ci" returned exit code 13


Control: tags -1 moreinfo

Hi Lucas,

[Please CC me on replies, I'm not subscribed to the bug]

On Sat, 20 Apr 2024 15:09:56 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on armhf.


Do you have any idea why we don't see the same failure on 
reproducible-builds [1]?


Paul

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gpaw.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069447: gpaw: FTBFS on armhf: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-pytest "--test-args=-v -m ci" returned exit code 13


Control: tags -1 moreinfo

Hi Lucas,

[Please CC me on replies, I'm not subscribed to the bug]

On Sat, 20 Apr 2024 15:09:56 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on armhf.


Do you have any idea why we don't see the same failure on 
reproducible-builds [1]?


Paul

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gpaw.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071069: src:prettytable: fails to migrate to testing for too long: FTBFS


Source: prettytable
Version: 3.6.0-1
Severity: serious
Control: close -1 3.6.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066757

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:prettytable has been trying to migrate for 
72 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build as reported in bug 1066757.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=prettytable



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071069: src:prettytable: fails to migrate to testing for too long: FTBFS


Source: prettytable
Version: 3.6.0-1
Severity: serious
Control: close -1 3.6.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066757

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:prettytable has been trying to migrate for 
72 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build as reported in bug 1066757.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=prettytable



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071067: src:sqlmodel: fails to migrate to testing for too long: FTBFS


Source: sqlmodel
Version: 0.0.8-5
Severity: serious
Control: close -1 0.0.8-6
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066771

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sqlmodel has been trying to migrate for 72 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build as reported in bug 1066771.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sqlmodel



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071067: src:sqlmodel: fails to migrate to testing for too long: FTBFS


Source: sqlmodel
Version: 0.0.8-5
Severity: serious
Control: close -1 0.0.8-6
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066771

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sqlmodel has been trying to migrate for 72 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build as reported in bug 1066771.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sqlmodel



OpenPGP_signature.asc
Description: OpenPGP digital signature

[llvm-branch-commits] [lld] [llvm] release/18.x: [RISCV][lld] Set the type of TLSDESC relocation's referenced local symbol to STT_NOTYPE (PR #91678)

2024-05-13 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/91678

>From 9c6b3b2733a99543b19e3cd38752ebd99188bd6d Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Fri, 22 Mar 2024 12:27:41 -0700
Subject: [PATCH] [RISCV][lld] Set the type of TLSDESC relocation's referenced
 local symbol to STT_NOTYPE

When adding fixups for RISCV_TLSDESC_ADD_LO and RISCV_TLSDESC_LOAD_LO,
the local label added for RISCV TLSDESC relocations have STT_TLS set,
which is incorrect. Instead, these labels should have `STT_NOTYPE`.

This patch stops adding such fixups and avoid setting the STT_TLS on
these symbols. Failing to do so can cause LLD to emit an error `has an
STT_TLS symbol but doesn't have an SHF_TLS section`. We additionally,
adjust how LLD services these relocations to avoid errors with
incompatible relocation and symbol types.

Reviewers: topperc, MaskRay

Reviewed By: MaskRay

Pull Request: https://github.com/llvm/llvm-project/pull/85817

(cherry picked from commit dfe4ca9b7f4a422500d78280dc5eefd1979939e6)
---
 lld/ELF/Relocations.cpp   |  5 +++-
 lld/test/ELF/riscv-tlsdesc-relax.s|  8 ++
 lld/test/ELF/riscv-tlsdesc.s  | 27 +++
 .../Target/RISCV/MCTargetDesc/RISCVMCExpr.cpp |  2 --
 4 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/lld/ELF/Relocations.cpp b/lld/ELF/Relocations.cpp
index 619fbaf5dc545..92a1b9baaca3d 100644
--- a/lld/ELF/Relocations.cpp
+++ b/lld/ELF/Relocations.cpp
@@ -1480,7 +1480,10 @@ template  void 
RelocationScanner::scanOne(RelTy *) {
 
   // Process TLS relocations, including TLS optimizations. Note that
   // R_TPREL and R_TPREL_NEG relocations are resolved in processAux.
-  if (sym.isTls()) {
+  //
+  // Some RISCV TLSDESC relocations reference a local NOTYPE symbol,
+  // but we need to process them in handleTlsRelocation.
+  if (sym.isTls() || oneof(expr)) {
 if (unsigned processed =
 handleTlsRelocation(type, sym, *sec, offset, addend, expr)) {
   i += processed - 1;
diff --git a/lld/test/ELF/riscv-tlsdesc-relax.s 
b/lld/test/ELF/riscv-tlsdesc-relax.s
index fb24317e6535c..5718d4175be11 100644
--- a/lld/test/ELF/riscv-tlsdesc-relax.s
+++ b/lld/test/ELF/riscv-tlsdesc-relax.s
@@ -33,12 +33,14 @@
 # GD64-NEXT: c.add   a0, tp
 # GD64-NEXT: jal {{.*}} 
 ## &.got[c]-. = 0x20c0+8 - 0x1020 = 0x10a8
+# GD64-LABEL: <.Ltlsdesc_hi1>:
 # GD64-NEXT:   1020: auipc   a4, 0x1
 # GD64-NEXT: ld  a5, 0xa8(a4)
 # GD64-NEXT: addia0, a4, 0xa8
 # GD64-NEXT: jalrt0, 0x0(a5)
 # GD64-NEXT: c.add   a0, tp
 ## &.got[c]-. = 0x20c0+8 - 0x1032 = 0x1096
+# GD64-LABEL: <.Ltlsdesc_hi2>:
 # GD64-NEXT:   1032: auipc   a6, 0x1
 # GD64-NEXT: ld  a7, 0x96(a6)
 # GD64-NEXT: addia0, a6, 0x96
@@ -64,6 +66,7 @@
 # LE64-NEXT: jal {{.*}} 
 # LE64-NEXT: R_RISCV_JAL foo
 # LE64-NEXT: R_RISCV_RELAX *ABS*
+# LE64-LABEL: <.Ltlsdesc_hi1>:
 # LE64-NEXT: addia0, zero, 0x7ff
 # LE64-NEXT: R_RISCV_TLSDESC_HI20 b
 # LE64-NEXT: R_RISCV_RELAX *ABS*
@@ -71,6 +74,7 @@
 # LE64-NEXT: R_RISCV_TLSDESC_ADD_LO12 .Ltlsdesc_hi1
 # LE64-NEXT: R_RISCV_TLSDESC_CALL .Ltlsdesc_hi1
 # LE64-NEXT: c.add   a0, tp
+# LE64-LABEL: <.Ltlsdesc_hi2>:
 # LE64-NEXT: addizero, zero, 0x0
 # LE64-NEXT: R_RISCV_TLSDESC_HI20 b
 # LE64-NEXT: addizero, zero, 0x0
@@ -93,9 +97,11 @@
 # LE64A-NEXT: addia0, a0, -0x479
 # LE64A-NEXT: c.add   a0, tp
 # LE64A-NEXT: jal {{.*}} 
+# LE64A-LABEL: <.Ltlsdesc_hi1>:
 # LE64A-NEXT: lui a0, 0x2
 # LE64A-NEXT: addia0, a0, -0x479
 # LE64A-NEXT: c.add   a0, tp
+# LE64A-LABEL: <.Ltlsdesc_hi2>:
 # LE64A-NEXT: addizero, zero, 0x0
 # LE64A-NEXT: addizero, zero, 0x0
 # LE64A-NEXT: lui a0, 0x2
@@ -115,10 +121,12 @@
 # IE64-NEXT: c.add   a0, tp
 # IE64-NEXT: jal {{.*}} 
 ## &.got[c]-. = 0x120e0+8 - 0x11018 = 0x10d0
+# IE64-LABEL: <.Ltlsdesc_hi1>:
 # IE64-NEXT:  11018: auipc   a0, 0x1
 # IE64-NEXT: ld  a0, 0xd0(a0)
 # IE64-NEXT: c.add   a0, tp
 ## &.got[c]-. = 0x120e0+8 - 0x1102a = 0x10be
+# IE64-LABEL: <.Ltlsdesc_hi2>:
 # IE64-NEXT: addizero, zero, 0x0
 # IE64-NEXT: addizero, zero, 0x0
 # IE64-NEXT:  1102a: auipc   a0, 0x1
diff --git a/lld/test/ELF/riscv-tlsdesc.s b/lld/test/ELF/riscv-tlsdesc.s
index c583e15cf30ce..935ecbddfbfff 100644
--- a/lld/test/ELF/riscv-tlsdesc.s
+++ b/lld/test/ELF/riscv-tlsdesc.s
@@ -29,11 +29,13 @@
 # RUN: ld.lld -e 0 -z now a.32.o c.32.so -o a.32.ie
 # RUN: llvm-objdump --no-show-raw-insn -M no-aliases -h -d a.32.ie | FileCheck 
%s --check-prefix=IE32
 
-# RUN: llvm-mc -triple=riscv64 -filetype=obj d.s -o d.64.o
-# RUN: not ld

Re: endian: New module.