Re: udevil (package) recommends udisks2?
On Tue, 10 May 2022 at 13:06, Jaime wrote: > According to https://packages.debian.org/bullseye/udevil, udevil > recommends udisks2. I've also just realised that udisks2 is not mentioned anywhere in the upstream build instructions: https://github.com/IgnorantGuru/udevil/blob/master/README
udevil (package) recommends udisks2?
According to https://packages.debian.org/bullseye/udevil, udevil recommends udisks2. Two questions: 1) Why? 2) What willI I lose by having udevil *without* udisks2? Many thanks, J
libgtk-3-0 dependency closure no longer includes librsvg2-common ∴ no more svg rendering
Hi all.
A recent change (1) to adwaita-icon-theme's debian/control.in altered
adwaita-icon-theme's relationship with librsvg2-common from a
"depends" to a "recommends".
libgtk-3-0's dependency closure *used* to include librsvg2-common via
that dependency (libgtk-3-0 -> adwaita-icon-theme -> librsvg2-common),
but that change removes librsvg2-common from libgtk-3-0's dependency
closure. As a result, installing libgtk-3-0 with
--no-install-recommends does not install librsvg2-common thus leaving
libgtk-3-0 unable to render svg, which in turn causes all kinds of
weird and wonderful rendering bugs.
The following info might help. There was a similar conversation over
on launchpad in 2006 (re gtk2 though):
https://bugs.launchpad.net/bugs/28507
("librsvg2-common not installed, breaks SVG rendering")
That launchpad bug, in turn, refers to:
https://metadata.ftp-master.debian.org/changelogs//main/libr/librsvg/librsvg_2.44.10-2.1_changelog
lines 960-962:
"* Break the dependency cycle, by making librsvg2-2 stop depending on
librsvg2-common. Packages will now have to depend on librsvg2-common
if they include SVG graphics."
Question: what should I do? If I should report a bug, which package
should it report it against?
TIA, Jaime
(1)
https://metadata.ftp-master.debian.org/changelogs/main/a/adwaita-icon-theme/adwaita-icon-theme_3.36.1-2_changelog
lines 12-20
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On 29/06/2020, Simon Richter wrote:
> Hi Jaime,
> Yes, that's a long-standing issue.
> A less portable or featureful client has a greater chance of supporting
> this directly.
>Simon
Timo, Simon and Simon,
Thank you all for your replies. Now that I understand the
issues/background, I'm happy to leave things the way they are and
stick with debian's ("built-in") ifupdown.
Thanks again, Jaime
isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
Hi all. I noticed that my debian wireless clients never get a DHCPOFFER from their first DHCPDISCOVER, and looking at the log shows why: journalctl output (very much shortened/redacted): 09:34:30 sudo[4373]: COMMAND=/usr/sbin/ifup wlp4s0 09:34:30 wpa_supplicant[4384]: Successfully initialized wpa_supplicant 09:34:30 dhclient[4395]: Internet Systems Consortium DHCP Client 4.4.1 09:34:30 dhclient[4395]: Copyright 2004-2018 Internet Systems Consortium. 09:34:30 dhclient[4395]: All rights reserved. 09:34:30 dhclient[4395]: For info, please visit https://www.isc.org/... 09:34:30 dhclient[4395]: 09:34:30 dhclient[4395]: Listening on LPF/wlp4s0/ab:cd:ab:cd:ab:cd 09:34:30 dhclient[4395]: Sending on LPF/wlp4s0/ab:cd:ab:cd:ab:cd 09:34:30 dhclient[4395]: Sending on Socket/fallback 09:34:30 dhclient[4395]: DHCPDISCOVER on wlp4s0 to 255.255.255.255... 09:34:31 kernel: wlp4s0: authenticate with 12:34:12:34:12:34 09:34:31 wpa_supplicant[4385]: wlp4s0: SME: Trying to authenticate... 09:34:31 kernel: wlp4s0: send auth to 12:34:12:34:12:34 (try 1/3) 09:34:31 kernel: wlp4s0: authenticated 09:34:31 wpa_supplicant[4385]: wlp4s0: Trying to associate with ... 09:34:31 kernel: wlp4s0: associate with 12:34:12:34:12:34 (try 1/3) 09:34:31 kernel: wlp4s0: RX AssocResp from 12:34:12:34:12:34... 09:34:31 kernel: wlp4s0: associated 09:34:31 wpa_supplicant[4385]: wlp4s0: Associated with 12:34:12:34:12:34 09:34:31 wpa_supplicant[4385]: wlp4s0: CTRL-EVENT-SUBNET-STATUS-UPDATE... 09:34:31 wpa_supplicant[4385]: wlp4s0: WPA: Key negotiation completed... 09:34:31 wpa_supplicant[4385]: wlp4s0: CTRL-EVENT-CONNECTED... 09:34:34 dhclient[4395]: DHCPDISCOVER on wlp4s0 to 255.255.255.255... 09:34:34 dhclient[4395]: DHCPOFFER of 192.168.0.6 from 192.168.0.1 09:34:34 dhclient[4395]: DHCPREQUEST for 192.168.0.6 on wlp4s0... 09:34:34 dhclient[4395]: DHCPACK of 192.168.0.6 from 192.168.0.1 So it's clear that dhclient is sending out the first DHCPDISCOVER *before* wpa_supplicant has authenticated/associated/connected to the AP. Given that this is guaranteed to fail, isn't it worth "not doing"? Is there anyway that I can get dhclient to wait for a successful connection *before* sending out any DHCPDISCOVERs? (In the wired world, it doesn't make sense to issue a DHCPDISCOVER before plugging the cable in.) (FWIW, I sent this same question to debian-user 18 months ago, but I didn't get anywhere so I thought I'd try again here). TIA, Jaime
Bug#196051: ITP: kwifimanager -- the wireless LAN client manager for KDE3
Package: wnpp Version: unavailable; reported 2003-06-05 Severity: wishlist * Package name: kwifimanager Version : 1.0.2 Upstream Author : Stefan Winter <[EMAIL PROTECTED]> * URL : http://kwifimanager.sourceforge.net * License : GPL Description : the wireless LAN client manager for KDE3 This application provides you a tool to configure and monitor your wireless LAN PC-Cards under Linux/KDE. The application uses the wireless extension from Jean Tourilhes. It should support any wireless LAN adapter that is in the current linux kernels and most of cards from the pcmcia-cs package. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux kha 2.4.20 #2 dom may 18 19:48:45 CEST 2003 i686 Locale: LANG=es_ES, LC_CTYPE=ISO-8859-1 (ignored: LC_ALL set)
Re: Quake 2 sources GPL'd
On Sun, Dec 23, 2001 at 11:06:21PM -0500, Ben Collins wrote: > On Sun, Dec 23, 2001 at 07:56:26PM -0800, Thomas Bushnell, BSG wrote: > > I'm entirely happy with putting it in contrib, but I'm entirely > > baffled by your position: what exactly do you think would be gained by > > putting it in main? > > Well I'm not. It's taking the easy route. Dropping it into contrib and > saying "you need to buy the data files from Id to use this" is a cop > out, IMNSHO. Put it out there as a game development platform, which is > _what it is_ and get the correct movement going. If you want to start a game development platform around it, then create a CVS repository where interested developers can contribute, and mailing lists where they can discuss. What good does it make to copy the source file into a Debian Package just for educational purposes?. People interested in that source file might as well download it from the original site; while those anxious to play Quake will get frustrated to see that quake2-engine, or whatever you call it, doesn't do anything. Merry Christmas, Jaime
Re: Web interface for Debian Description Translation Server
Hi, A month ago Michael Bramer (grisu) announced the DDTS project to translate packages descriptions, and asked me to make a similar announcement about the translation that we've been doing at "La Espiral" (a group of Spanish-speaking developers). We've been translating descriptions into Spanish since last year, using a web interface. We are already in a very advanced stage -- 5354 descriptions translated by 99 translators -- to start using the new method proposed by grisu, and he is to used to the e-mail method that he's been using for the debconf templates. Therefore, we agreed with grisu to keep using the two different methods for translations into different languages, and let other translation teams decide what they prefer. Both methods will accomplish the same: the creation of "Packages" files where the descriptions appear translated. Some people prefer to work using a web browser, while others would rather use a mail composing program. The discussion on what will be the best way to incorporate the translated descriptions into a Debian distribution is a separate issue, and while it gets resolved we can keep working on the translations. Our web interface can be accessed at the URL: http://www.laespiral.org/ddts/ Where you can find more information about it. At this moment we are translating descriptions into Spanish and Portuguese (as spoken in Portugal). Grisu is taking care of the translations into German, French, Italian and Brazilian Portuguese. If any other groups want to use our web interface, please let me know (it can be done in a couple of minutes). We will now try to unify the two methods so that the translation into any of these languages can be done using any of the two interfaces and ends up at the same central point. Cheers, Jaime Villate <[EMAIL PROTECTED]>
