Re: Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]
On 22/4/24 21:29, Steve Langasek wrote: On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting ^^^ BS. It just doesn't work like this. A regular citizen can't communicate with a Court by email. You can't even interact with a case proceedings until you are a party to a particular lawsuit. it crystal clear that it was a long time ago the lawsuit to Universitat Oberta de Catalunya and British Council had to be solved. "Kinda or not" -- Parkinson's Law: Work expands to fill the time alloted to it.
Re: debian-policy: clarify requirement for use of Static-Built-Using
On Fri, Apr 19, 2024 at 07:59:19AM +0100, Sean Whitton wrote: > Hello Go and Rust packagers, > > On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > > > With the increasing amount of programs in Debian that Build-Depend and > > statically link with Golang and Rust libraries, it's important that > > the Debian Policy clearly sets out the requirements for declaring > > these statically-linked libraries. > > I think Maytham is right that updating Policy for this is a priority. > It has been bothering me that misunderstandings of Built-Using have been > proliferating somewhat among newer contributors. See also #999785. > > Could you take a look at his proposed changes to Policy in #1069256, > please, and confirm they successfully reconcile Debian Policy with your > team policies? Speaking for the Rust side - I'd say they match our expected usage of the field. A slight rephrasing of "linked to libraries in other packages" might match it even better, since in Rust's case, we are usually talking about linking to libraries compiled from sources shipped in other packages (librust-X-dev only contains the sources and possibly helper scripts needed to build them, but not the compiled library). But it also covers static linking of native libraries, so the current phrasing matches that. Might be bikeshedding/nitpicky though ;) > I think that we should also include an explanation of why we have chosen > to do this using a new field in d/control like Static-Built-Using. > Policy is meant to be a record of our lessons learned in building a > distribution, and the lessons learned in trying to handle these new > hyper-statically linked language ecosystems seem important. > > My immediate question is why the Haskell and OCaml team's approaches, > were not copied. They seem to work well and don't require a new field. > That seems worth writing down. I am not sure about the details of their approach... are those available somewhere? > Thank you Maytham for your work so far. Thanks to both of you! :)
Bug#1069735: general: atlantic driver doesn't work on thinkpad
Package: general Severity: important Dear Maintainer, I have a problem with atlantic driver on debian testing kernel 6.6.15. When I plug my device (Sonnet tech 10G adapter thunderbolt 3), the device will not appear in lspci but it detect from dmesg command. On an ubuntu, the device works. This is traces : ``` root@Elliot:~# lspci -tv -[:00]-+-00.0 Intel Corporation Coffee Lake HOST and DRAM Controller +-02.0 Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] +-04.0 Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem +-08.0 Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model +-12.0 Intel Corporation Cannon Point-LP Thermal Controller +-14.0 Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller +-14.2 Intel Corporation Cannon Point-LP Shared SRAM +-14.3 Intel Corporation Cannon Point-LP CNVi [Wireless-AC] +-15.0 Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 +-16.0 Intel Corporation Cannon Point-LP MEI Controller #1 +-1c.0-[01]00.0 Genesys Logic, Inc GL9750 SD Host Controller +-1c.4-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0 Intel Corporation JHL6240 Thunderbolt 3 NHI (Low Power) [Alpine Ridge LP 2016] | +-01.0-[05-39]-- | \-02.0-[3a]00.0 Intel Corporation JHL6240 Thunderbolt 3 USB 3.1 Controller (Low Power) [Alpine Ridge LP 2016] +-1d.0-[3c]-- +-1d.4-[3d]00.0 Micron/Crucial Technology P2 [Nick P2] / P3 / P3 Plus NVMe PCIe SSD (DRAM-less) +-1f.0 Intel Corporation Cannon Point-LP LPC Controller +-1f.3 Intel Corporation Cannon Point-LP High Definition Audio Controller +-1f.4 Intel Corporation Cannon Point-LP SMBus Controller +-1f.5 Intel Corporation Cannon Point-LP SPI Controller \-1f.6 Intel Corporation Ethernet Connection (6) I219-V root@Elliot:~# modinfo atlantic filename: /lib/modules/6.6.15-amd64/kernel/drivers/net/ethernet/aquantia/atlantic/atlantic.ko.xz description:Marvell (Aquantia) Corporation(R) Network Driver author: Marvell license:GPL v2 alias: pci:v1D6Ad11C0sv*sd*bc*sc*i* alias: pci:v1D6Ad34C0sv*sd*bc*sc*i* alias: pci:v1D6Ad12C0sv*sd*bc*sc*i* alias: pci:v1D6Ad14C0sv*sd*bc*sc*i* alias: pci:v1D6Ad04C0sv*sd*bc*sc*i* alias: pci:v1D6Ad93C0sv*sd*bc*sc*i* alias: pci:v1D6Ad94C0sv*sd*bc*sc*i* alias: pci:v1D6Ad00C0sv*sd*bc*sc*i* alias: pci:v1D6Ad92B1sv*sd*bc*sc*i* alias: pci:v1D6Ad91B1sv*sd*bc*sc*i* alias: pci:v1D6Ad89B1sv*sd*bc*sc*i* alias: pci:v1D6Ad88B1sv*sd*bc*sc*i* alias: pci:v1D6Ad87B1sv*sd*bc*sc*i* alias: pci:v1D6Ad80B1sv*sd*bc*sc*i* alias: pci:v1D6Ad12B1sv*sd*bc*sc*i* alias: pci:v1D6Ad11B1sv*sd*bc*sc*i* alias: pci:v1D6Ad09B1sv*sd*bc*sc*i* alias: pci:v1D6Ad08B1sv*sd*bc*sc*i* alias: pci:v1D6Ad07B1sv*sd*bc*sc*i* alias: pci:v1D6Ad00B1sv*sd*bc*sc*i* alias: pci:v1D6AdD109sv*sd*bc*sc*i* alias: pci:v1D6AdD108sv*sd*bc*sc*i* alias: pci:v1D6AdD107sv*sd*bc*sc*i* alias: pci:v1D6AdD100sv*sd*bc*sc*i* alias: pci:v1D6Ad0001sv*sd*bc*sc*i* depends:macsec retpoline: Y intree: Y name: atlantic vermagic: 6.6.15-amd64 SMP preempt mod_unload modversions sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key:21:EC:AB:7F:99:B0:2B:29:F0:14:9D:30:26:B6:2F:1B:F0:91:ED:13 sig_hashalgo: sha256 signature: 30:65:02:31:00:C5:7E:D8:EA:3A:0A:D9:65:E4:44:64:B7:AD:C6:58: 83:27:E6:87:BE:DB:4C:F8:17:68:D1:CE:CA:49:45:27:17:20:9A:67: 3B:0C:FC:77:A6:D1:DB:B8:C1:A0:1E:4D:CA:02:30:1A:43:B0:9C:14: 10:A3:A9:B7:A4:11:E6:69:4F:43:46:55:08:AF:9B:11:08:25:78:58: 68:E0:A4:32:CB:53:4E:7D:34:BF:7B:11:C8:E2:AA:46:C7:4F:96:CF: 55:94:73 parm: aq_itr:Interrupt throttling mode (uint) parm: aq_itr_tx:TX interrupt throttle rate (uint) parm: aq_itr_rx:RX interrupt throttle rate (uint) root@Elliot:~# lsmod Module Size Used by vmnet 77824 13 vmw_vsock_vmci_transport45056 0 vsock 61440 1 vmw_vsock_vmci_transport vmw_vmci 110592 1 vmw_vsock_vmci_transport vmmon 163840 0 ccm20480 6 rfcomm102400 16 snd_seq_dummy 12288 0 snd_hrtimer12288 1 snd_seq
Re: Status of the t64 transition
Hi, dpkg and gcc with t64 enabled migrated to trixie last night. The other packages will slowly migrate as we fix the remaining blockers (autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary removals from trixie may occur to get packages (especially key packages) unstuck as we work through all the packages hat need to migrate. Since the time_t bugs are now also RC in trixie, I will reraise the severity of all time_t bugs to serious in 1 week. If you wonder how you are able to help with the migration, here are some things to do: * Fix FTBFS bugs * Check the status of autopkgtests [1] and report or fix any issues related to failing tests. * Check if source-only uploads for Arch: all packages are missing. Cheers [1] Note that wecurrently ignore autopkgtest results on armel and armhf. -- Sebastian Ramacher
