On Xuñ 04 2023, Martin-Éric Racine wrote:
> allow-auto br0
> allow-hotplug /en* /wl*
> iface br0 inet static
> bridge_ports regex (enp3s|enp2s|wl).*
> address 172.16.1.1
> iface br0 inet6 auto
> # IPv6-PD via /etc/dhcpcd.conf
> # Routing via
> In Bullseye, Ethernet cards did not have any IPv6 local-link, while Wifi
> adapters did. In Bookworm, it the opposite.
Wifi is very dependant on how you configure it, but as you say, now on
bookworm you are not getting IPv6 on them, so... let's go for ethernet
cards... on my machines I don't
; urgency=medium
+
+ * Add a couple of upstream picked patches to fix some issues on 5.7
+that upstream has fixed on 5.8.
+
+ -- Santiago Garcia Mantinan Fri, 28 Apr 2023 08:35:27
+0200
+
squid (5.7-1) unstable; urgency=medium
* Urgency high due to security fixes
diff -Nru
squid-5.7/debian
Hi!
> With that upgrade round bridge-utils went from 1.7-1 to 1.7.1-1.
> That server has an iKVM module so I could still access it and found that
> `brctl show` did not show any interfaces.
I'd say it is impossible that it was the bridge-utils change, could you have
a look at what had changed
Hi!
> It's possible that your machine can indeed be powered via USB C, new laptops
> usually can. Which leads to fun like laptop that wants to be charged by a
> phone -- and indeed negotiating it that way.
If it was like that... do you think that USB-C would be a real USB or just
for power
> The kernel using the MAC of a real device, if none is specified, is
> precisely what we wanna avoid. Systemd is not involed.
Like I said, if we don't specify the mac address systemd will set up a fake
one for us, so... systemd is involved and the kernel is not allowed to use a
real one, that's
Hi!
> It would be desirable for bridge_hw to be able to generate a random MAC
> address as per ifupdown's generic hwaddress syntax.
I don't know if I get this right or not... if you don't want to specify a
MAC or get it from an interface... then you better not assign any MAC and so
systemd will
Hi!
I'd like to sum this up.
The problem comes when we create a bridge with an IPv6 but without assigning
any ports to it.
What happens then is that DAD is triggered and ifupdown fails to bring the
interface up as DAD times out.
Waiting for DAD... Timed out
ifup: failed to bring up br1
We can
Hi!
On Set 06 2021, Pieter Hollander wrote:
> PS: Additionally, I forgot to mention that adding dad-attempts 0 to the br0
> inet6 config also solves the issues of networking failing.
> > Using a dummy port to perform DAD sounds like the best solution to me.
> > Back to the workaround: It also
It looks like the latest changes we did before Bullseye are working, so I'm
changing the interfaces man page removing the stp warning pointing to the
736336 bug report as that was no longer true.
With this change I'm marking this bug closed.
Regards.
--
Manty/BestiaTester -> http://manty.net
> > "AuthServerWhitelist": "*.internal.domain"
> You need to replace "Whitelist" with "Allowlist", the names were changed in
> Chromium 101.
That was it, AuthServerAllowlist is what I needed.
Thanks a lot for your quick reply, maybe we can close the bug, or maybe
close it after adding a
Hi!
This bug came in response for a proper fix in order for the problem we found
in squid after introducing the new squid-openssl flavour, that was:
https://bugs.debian.org/984880
At that time I spoke to Niels Thykier in order to fix this, but it was late
in the bullseye development cycle a fix
> This is NOT about addresses on bridge ports (and I agree those are not
> needed or desirable), but the case where the bridge port is a VLAN
Ok.
> interface. Then the current code prevents you from using not just the
> VLAN interface (e.g. eth0.3), but also the underlying physical interface
>
Hi!
We had spoken about this problem and the possible fix and by that time, so
close to Bullseye release... it was not a good timing.
I guess now would be the right timing, before bookworm gets us again in a
bad timing situation again.
Do you need any more info on this?
Regards.
--
On Xan 20 2022, Anton Khirnov wrote:
> Attaching a patch. I still couldn't think of a reason this code should
> ever disable IPv6 on the physical interface, so it's removed
> unconditionally. If anyone can think of such a reason, then I guess an
> option could be added?
Well, the thing here is
Hi!
Thanks Sascha for the pointer. I have tested it on bullseye and it really
works, great.
I don't know if we could add this patch for the next .release or something.
All I did was patch all the nodes, a ganeti force-reload and I was migrating
without problems (no need to reboot the guests or
Hi again!
I have just migrated another machine and I found out that it worked out
well.
The thing is exactly what you have descrived, here the order was (luckily)
the right one, so when systemd-timesyncd is configured, systemd had already
created the dpkg-bak file like we can see here:
Package: systemd-timesyncd
Version: 247.3-6
Severity: important
Hi!
On upgrade from Buster to Bullseye I have seen my machines, without Internet
ntp access, loose their time sync because of the upgrade.
On the upgrade to the new packages, the old /etc/systemd/timesyncd.conf file
which specifies
Hi!
I also got hit by the same warning on the logs that completelly misleaded me
(thinking it was the error stopping me). I wanted to comment just in case
some other people may also get hit by it.
After upgrading a cluster from buster to bullseye I couldn't bring the
guests back to my upgraded
Package: ganeti
Version: 3.0.1-2
Severity: important
Hi!
I tried to contact you through the ganeti at packages.d.o address but I'm
not sure that has arrived to any mailbox, so I'm opening a bug so that we
can comment this.
After having all the nodes of a ganeti cluster updated to bullseye and
Hi!
I wrote a mail to ganeti at packages.debian.org which I don't know if you
guys got, on it I commented over this problem and some others I had found
while upgrading.
The thing is that I also got this problem and the solution I found was to do
a:
apt install python-is-python2
And then
Hi!
I'm CCing Josué because this seems to be more on ifupdown's side than on
bridge-utils.
> > auto br0
> > iface br0 inet static
> > address 10.10.10.1
> > netmask 255.255.255.0
> > bridge_ports none
> > bridge_stp off
> > bridge_fd 0
> >
> > iface br0
> Thank you for your assistance. With hint for the relevant man
> page "bridge-utils-interfaces" I found the bridge setup working
> using the configuration
>
> auto br0
> iface br0 inet static
> address 192.168.1.1
> network 192.168.1.0
> netmask 255.255.255.0
> bridge_ports none
>
Hi!
First I'd like to thank Dennis for his good support, as always ;-)
> > $ ifup virtbr0
> > Cannot find device "virtbr0"
> > ifup: failed to bring up virtbr0
>
> It is because the "bridge_ports" directive is missing. From the
> manpage bridge-utils-interfaces(5):
>
>bridge_ports
> CVE-2021-31806[0], CVE-2021-31807[1], CVE-2021-31808[2], see the SuSE
> bug as well at [3].
Luigi are you around to take care about this?
Anybody else?
Regards.
--
Manty/BestiaTester -> http://manty.net
believe you can close this.
Regards.
El dom, 2 may 2021 a las 9:32, Salvatore Bonaccorso
() escribió:
>
> Control: tags -1 + moreinfo
>
> On Mon, Dec 31, 2018 at 12:15:35AM +0100, Santiago Garcia Mantinan wrote:
> > > > >> And could we have the patch I s
ipt that the debhelper code was put manually.
+ * Add README.Debian to squid-openssl.
+
+ -- Santiago Garcia Mantinan Tue, 23 Mar 2021 00:18:11
+0100
+
squid (4.13-8) unstable; urgency=medium
* Add SQUID-2020_11.patch to fix HTTP Request Smuggling.
diff -Nru squid-4.13/debian/NEWS squid-4.13/debian/N
I'm Ccing my fellows at the squid team in case they want to add something
here, for the full conversation, please see #985390.
I have finished testing the changes for -9, I don't know if I like it more
now or if it would be better to just leave the comment on the NEWS file and
don't echo anything
Hi again!
I have just pushed:
https://salsa.debian.org/squid-team/squid/-/commit/fe8a10ef8ec40411bb59bec7af2b179796d4f4ef
I think I'm addressing all your concerns there, if you like it I'll run
tests tomorrow and upload the -9 package.
Thanks in advance.
--
Manty/BestiaTester ->
> > Fixing a couple of nasty bugs discovered late,
> Yes, due to handling of a new binary package that you had migrated into
> bullseye the day before that wasn't allowed anymore exactly to avoid
> this class of bugs.
Agreed, this was something that several users had asked for and that we, the
Package: ftp.debian.org
Severity: normal
I'm both maintainer and upstream for this package, I haven't developped or
tested it for years, I'm possitive that it wouldn't work with current
versions of isc dhcp server.
Also, there are alternatives to it that should be better suited for the time
Hi!
While we were waiting for 4.13-7 to age and enter testing, we were filled a
security bug for CVE-2020-25097.
I decided to fix that security problem ASAP and that is what is on 4.13-8,
just that. 4.13-8 just adds the patch to fix the CVE as available at:
Hi!
Just to clarify a bit, as the changes on the sources may seem big, these are
the differences on resulting scripts (the only that was changed besides
changelogs and a note on NEWS).
>From -5 to -6:
diff -ru 5/control/postrm 6/control/postrm
--- 5/control/postrm2021-02-08
.0 +0100
+++ squid-4.13/debian/changelog 2021-03-10 09:19:32.0 +0100
@@ -1,3 +1,18 @@
+squid (4.13-7) unstable; urgency=medium
+
+ * Add full postrm scripts while we don't solve #984897 on debhelper.
+Closes: #984880.
+
+ -- Santiago Garcia Mantinan Wed, 10 Mar 2021 09:19
Package: debhelper
Version: 13.3.4
Severity: normal
Tags: patch
Recently we decided to ship two binary versions of squid, one compiled with
gnutls and the other with openssl, as the code provides different features
depending with what is compiled.
I decided to produce two binary packages
Package: squid
Version: 4.13-6
Severity: normal
Looks like we still have a problem, the postrm auto added hooks by debhelper
are disabling the service when you purge squid and squid-openssl is installed.
The problem lays here, but as I said, this is auto added code :-(
if [ "$1" = "purge" ];
Hi!
I'd like to receive comments on this one, I have already pushed a solution
to salsa that involves not removing the files and noting that on the comment
we echo on postrm so that it now tells you to remove both cache and logs.
I have also explained on the NEWS file that you must have at least
Package: squid
Version: 4.13-5
Severity: serious
File: /usr/sbin/squid
Hi!
Today I tried to move from squid to squid-nossl and clean up afterwards, it
all went ok when I did the installation of squid-openssl, squid got removed
and everything worked as expected, but when I purged squid with
> Looking at the debdiff, I notice that upstream considers this package
> as deprecated and recommends using the 'bridge' command from iproute2.
> Is there any plan to migrate bridge-utils-interfaces to use this?
Well, kind of, I mean, on some of the bugs, at least on #868220, we've
have talked
> Noted. There's indeed too many patches for me to keep track of. At
> some point, I lose track of what you need to validate each one.
Well, after some more testing I uploaded the latest versions to unstable, so
you don't need to access salsa as unstable is now in sync with the git
repository.
> Like I have just said on the other bug report (looks like we have the same
> setup on both bugs) I need to know how the system looks after the setup to
> find what is wrong or different to mine here, "ip a" output would solve some
> of my doubts.
I don't know if you could test all the patches I
Hi again, Sam!
> I suggest you do more testing whenever you can reach the equipment doing a
> tcpdump of the traffic so that we know where the problem is, also, take a
> look to the firewalling you have just in case igmp or other traffic is being
> cut somewhere.
I have recently uploaded
> Document the minimum and maximum values of all options, and tell which
> value is the strongest for each.
This will take a lot of time, and I don't know if this is worth the effort.
I'm going to try to go over all of this, as it seems that documentation is
wrong, the kernel guys have changed
> We wouldn't need hwaddress anymore with the new patch, right?
Nope, I have found another problem with the kind of setup that you have, on
this setups brctl addif fails because the interface needs to be configured
by hostapd, and as the code for setting the mac was conditionally tight to
the
> > auto br0
> > iface br0 inet dhcp
> > hwaddress enp4s0mac
> > bridge_hw enp4s0mac
> > bridge_ports regex (en|wl).*
> That would fail to raise enp4s0, and it also still has hwaddress. I
Wel... isn't enp4s0mac a fixed ethernet port? if it is it should be
available on
On Feb 18 2021, Martin-Éric Racine wrote:
> This indeed prevents the superfluous fe80 address from appearing when
> the dongle is plugged in after the bridge is already up. It doesn't
> seem to affect traffic connecting via the dongle either.
I don't get this last sentence, I'm guessing you mean
> > > Btw, the discrepancy in behavior explained in Bug#980752 remains. With
> > The problem is with neither, I believe.
> Oh? What would cause this then?
Like I have explained to you in other bugs, I could replicate the problem
and found that it was a problem with bridge-utils, I have assigned
Package: bridge-utils
Version: 1.5-10
Severity: important
Tags: patch
Hi!
When we tried to fix bug #779348 what we did was broke the code.
The since version 1.5-10 reads...
unset BREADY
unset TRANSITIONED
COUNT=0
# Use 0.1 delay if available
sleep 0.1 2>/dev/null &&
Hi!
It's been a long time since this bug entered the system, and now I have a
patch for it, I have to say it is a little dirty (I'm just adding the bridge
back on the stances that had it removed before them) so that way they won't
fail when trying to remove it.
This will work if you do:
ln -s
Hi!
I'm crossposting this to another bug because maybe the previous bug fix is
the one that is making the new bug fail.
Alexander, I hope you are still around so we can talk about this bug you had
sent.
I just came over to this bug but with the reverse feeling, after your patch
now the code
Hi!
While I'm still waiting for you "ip a" output to continue debugging this,
I'd like to to test the one line patch which I'm going to add on next
version, this should solve the hotplugged interfaces getting an IPv6 address
like you explained here and also on #980752 which I have now reassigned
Hi!
I have now assigned this bug to bridge-utils and I've got this patch that
should solve it, can you test it on your machine and let me know if it fixes
the problem?
--- /lib/udev/bridge-network-interface~ 2021-02-16 20:59:36.397579972 +0100
+++ /lib/udev/bridge-network-interface 2021-02-16
Hi!
I've installed a machine with NetworkManager, so I could do tests with this,
I have arrived to an example that does what I think you wanted.
The example would be this:
auto lo
iface lo inet loopback
iface enp2s0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports all
> > My current guess looking at things around the package is that it is ok on my
> > build to have it in etc/squid, plus is a good place for a config file, so...
> > everything looks ok.
>
> Yes. It is supposed to be a config file to tell Squid where to load static
> web content from (based on
> On current build we ship usr/share/squid/mime.conf on squid-common, but on
> my build it gets installed on etc/squid/mime.conf, which place is the right
> one?
My current guess looking at things around the package is that it is ok on my
build to have it in etc/squid, plus is a good place for a
Hi!
> There is also the GnuTLS ability to load multiple certificates for
> virtual-hosting HTTPS websites which OpenSSL simply cannot do itself. I
> know a few users are liking that.
I'm trying to make a double building like you suggested, but I don't think
we'll make it in time for Bullseye.
> To clarify one thing about my setup before someone points out it could
> cause problems.
> I talk about a wifi router. Note that I'm using an ethernet port on the
> wifi router, so I have no wifi bridging involved.
Well, exept for the part on my setup being free soft that I can play with...
> Was there any particular reason for not enabling hotplug out of the box?
This was like that to preserve things working like they used to (some years
ago, when we introduced hotplug)
> Btw, the discrepancy in behavior explained in Bug#980752 remains. With
> BRIDGE_HOTPLUG=yes, upon startup,
> 1) eno1 is connected directly to a wifi router.
> I get an IPv6 address using router advertizements.
>
> But if I insteade slave that interface to a bridge say
> iface brint inet dhcp
> bridge-ports eno1
> auto brint
>
> then I don't get a global v6 address on the bridge.
Well, this is
> I HAVE set bridge_hw to a static device. That's what I described.
Like I have just said on the other bug report (looks like we have the same
setup on both bugs) I need to know how the system looks after the setup to
find what is wrong or different to mine here, "ip a" output would solve some
of
> > What I need to be able to replicate this is more info on your setup, I mean,
> > I need your network/interfaces (you can change macs and IPs of course) and
> > the "ip a" output with everything plugged and up like you have it setup and
> > then the same but without hwaddress applied (I'm
Hi!
> Here's what I've found so far.
> https://askubuntu.com/questions/460405/ipv6-does-not-work-over-bridge
Ok, I see the problem the guy has but I don't get a clear setup definition,
also that was a long long time ago.
> This answer suggests that it's IGMP snooping *not* STP that is the
>
> On a host with a mixture of USB WiFi dongles and Ethernet cards, I have to
> specify the MAC address using both bridge_hw and ifup's generic hwaddress
> to ensure that the host fetches the correct IP address via DHCP.
> Nonetheless, the bridge picks up the IPv6 EUI64 local link (fe80) of one
>
Hi again!
> What I DO notice is that because the bridge is stupid enough to use the
> MAC address of a removable device to build the EUI64 address for fe80
> local link (despite bridge_hw specifying the MAC address of a fixed
> device), disconnecting that removable device collapses the bridge.
Hi!
I'm rereading this and I still don't know what kind of example are you
asking for, let's see...
> "# The primary network interface
> allow-hotplug eth0
> #iface eth0 inet dhcp
> iface eth0 inet manual
>
> auto br0
> iface br0 inet dhcp
> bridge_ports eth0
This is a problem, it shouldn't be
> > iface br0 inet dhcp
> > bridge_ports all
> > bridge_hw enp6s0
>
> This would obviously change the syntax of bridge_hw but it would
> accomplish what we need with a syntax that follows the Consistent
> Network Device Naming idea.
I think I didn't express myself well, I don't
Hi!
> I suggest a new option called bridge_via to specify the routing interface:
I've been thinking a bit on this as I didn't like the bridge_via naming as
this is just to specify the interface that we take the MAC address from, it
doesn't specify a via in the sense that the packages will go out
Hi!
It was Stephen who put some light on the original bug, as this is quite a
kernel thing...
> need both. The correct solution is to run DAD after the port has gone
> to forwarding.
I agree.
> Please document how to accomplish this on Linux where you document that
> it doesn't work with
Hi!
> Thus the regex for wireless seems to be wl* to catch all variants.
Adding wifi cards is problematic, you can only bridge cards if they are in
master mode, not if they are on client mode or similar, besides, naming of
wifi master devices can also be virtual and thus done by other software,
> That doesn't reflect what's happening here. The host in question has no
> firewalling whatsoever. This is the result of merely launching a bridge.
> Whatever commands bridge-utils issue as a result of reading the
> /etc/network/interfaces stanza for br0 is what produces this.
Like I said,
> Whenever I need to perform maintenance at the console, I have to remove the
> USB dongles, because their casings are wide enough to prevent access to the
> VGA connector. Removing the USB dongles tends to collapse the bridge.
> Restoring the bridge requires issuing the "sudo invoke-rc.d
Hi!
I believe that would be messy for everybody, I think we should stick with
just one brand, otherwise people will find it harder to know what to
install.
For what I know, the openssl enabled binary will have all the features, it
is only that some options are gnutls specific, and this options
Hi!
I'd like to know if there are any plans on having Bullseye version compiled
with --with-openssl, I'm currently running 4.13 with this option on Buster
and would love to stop having to compile with --with-openssl on Bullseye.
If anything is needed for this to happen on Bullseye please just
Package: ftp.debian.org
Severity: normal
The functionality of the package is not exactly covered by any other package
but similar functionality is achieved by other packages and this old one
hasn't been really tested on current software versions, even though it
should work, so if somebody wants
Hi!
On Xuñ 02 2020, Gianluigi Tiesi wrote:
> Looks like bridge-utils already does it in:
> /lib/bridge-utils/ifupdown.sh
>
> # Activate VLAN filtering on VLAN aware bridges
>
> if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
> ip link set dev $IFACE type
We still haven't talked about how to land bridge setup on ifupdown yet :-(
However recently Benedikt Spranger asked for us to enable vlan filtering
for vlan-aware switches, so next version of bridge-utils will allow enabling
this from the interfaces file.
Regards.
--
Manty/BestiaTester ->
Hi!
Looks like we are too fast if we change the hw address right after creating
the bridge... well, we could maybe fix this some other way, but the sleep of
1 second in the case where you are changing the hw address doesn't look like
a big issue to me and I'd rather be on the safe side.
If
Source: freerdp2
Severity: normal
Hi!
First, sorry about the almost empty mail to the list, I was trying to abort,
but somehow I managed to send :-(
The thing is that when I tested freerdp2-shadow-x11 I saw that auth was not
working when being run as a user, I couldn't authenticate with current
Hi!
> The attached patch adds the missing bridge_vlan_aware aka
> enable VLAN filtering support.
Great, thanks for the patch, I'll take a look at it and do some tests, if
everything looks ok I'll upload a new version soon.
Regards.
--
Manty/BestiaTester -> http://manty.net
Hi!
On Nov 25 2019, Boris Kolpackov wrote:
> After upgrading to the latest testing version of all the packages, I now
> observe what appears to be the bridge_hw address most of the time being
> ignored and some random address being used instead (76:95:e6:8c:c3:9e).
I have some questions, let's
Hi!
I arrived to this bug because of the --format error which I was seing when
trying to backport something for Jessie, it looked just like this bug but
this bug didn't solve anything and I had build previously from Buster for
Jessie, so I thought I had to have another look at the build.
It
Hi!
> Control: reassign -1 php7.3
Maybe assigning it to php is the right thing to do, but googling more
after sending the bug I found this bug on launchpad, it is dated 10
years ago, but seems similar:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/235070
And it points to a gcc related
Package: libgomp1
Version: 8.3.0-6
Severity: important
Hi!
I don't really know if libgcomp1 is the one to blame here, but when using
PHP based software lige nextcloud on top of Buster I'm seing this error:
PHP Startup: Unable to load dynamic library 'imagick.so' (tried:
Hi!
Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913765 leafpad has
been removed, it is no longer taking part on Buster.
I think it is time for lxde on Debian to remove the leafpad dependency.
Regards.
--
Manty/BestiaTester -> http://manty.net
I haven't received more info on this and it looks to me like a config
problem, I'm closing the bug.
Regards.
--
Manty/BestiaTester -> http://manty.net
> > >> And could we have the patch I sent on #856505 to enable sound on this
> > >> machines applied as well?
> >
> > i assume you are talking about:
> >
> > arm: bcm2835-audio: Document the device tree node to enable
> > bcm2835-audio driver
> >
> > This patch will not be accepted. For a
> I just added the commit from v4.20-rc7 that fixes this problem to the
> Linux package git repository. It will be part of the next upload of
> v4.19.x to unstable.
And could we have the patch I sent on #856505 to enable sound on this
machines applied as well?
I sent this to the lkml as you
Hi!
After mailing Michael Zoran to see if he would be willing to submit the
patch as it was on his TODO, and getting a reply encouraging me to do it...
I have submitted the patch to the lkml:
https://lkml.org/lkml/2018/12/12/835
Let's see if I did it Ok and gets accepted, meanwhile, I think it
Package: src:linux
Version: 4.18.20-2
Severity: normal
Tags: patch
Hi!
After kernel 4.17 the dtb for raspberry pi 3 b is not ok and thus the wifi
is not found and cannot be used.
Looking at the differences from 4.17 to 4.18 I have discovered that if you
revert this single patch affecting only
Hi!
Based on eHenry's instructions I have created this patch which I have tested
on Debian's 4.19 kernel now on experimental, where we have already enabled
the sound driver which was not working.
The result is that with this patch the sound is finally working, so, please
apply this to the 4.19
I've compiled a Debian 4.19 kernel with your sugested patch to enable audio
and reverting another one to fix the WiFi problem and I now have both audio
and WiFi working.
I'll send proper patches as soon as I have time, but it works.
Regards.
--
Santiago García Mantiñán
Hi!
While this bug is not fixed I came across it while doing a crosscompile of a
pi3 kernel, aplying Kevin's patch (thanks a lot) almost fixed compiling, but
I found another place whre it got stuck, so here is an addon for the patch
that Kevin had sent:
---
Hi!
I have tested vers=2.1 parameter on a current Buster installation and at
least if the server is a Samba (samba as in Buster with a standard setup)
the version of the protocol won't solve anything, the wget still breaks:
Saving to: 'STDOUT'
-16%[>
Hi!
This module is now included in the 4.19 kernel recently uploaded to
experimental (linux-image-4.19.0-trunk-arm64 4.19.5-1~exp1), you can add
experimental to your sources.list like this:
deb http://deb.debian.org/debian ../project/experimental main
However on my first tests this hasn't
Hi!
> I don't have an rpi3 to test, but I wonder if it is really necessary to
> enable CONFIG_SND_BCM2835 to get sound.
After our talk on irc I thought you had commited this change, but a
new version of the kernel has been uploaded and doesn't include this.
What has happened?
Regards.
Hi again.
I've tested latest update, working ok, config file got moved with all
the old stuff inside.
Regards.
--
Manty/BestiaTester -> http://manty.net
The only caveat I found was that on the raspi3-firmware package upgrade the
changes I had done to /etc/kernel/postinst.d/50-raspi3-firmware were not
copied to /etc/kernel/postinst.d/z50-raspi3-firmware.
I had modified the root fs, as I boot from /dev/md1 not from the mmc device,
and thus after
Hi!
I've built a package using your salsa fork and everything looks fine, I
always ended with the highest version on the firmware dir and on the
config.txt, so that is ok.
The only "weird" thing I found was when installing 4.18 having installed
4.19-rc7, thus installing a lower version, the
Package: src:linux
Version: 4.18.10-2
Severity: wishlist
Hi!
I'm currently running this kernel on Raspberry Pi 3b without much trouble,
however no sound devices are found, After reading and looking at raspbian
modules, it seems that sound is handled by this module, so if you would
please enable
Hi again!
After that install of the kernel I tried a reinstall via...
# apt-get install --reinstall linux-image-4.18.0-2-arm64
Lendo as listas de paquetes... Feito
Construindo a árbore de dependencias
Lendo a información do estado... Feito
0 anovados, 0 instalados, 1 reinstalados, Vanse retirar 0
1 - 100 of 431 matches
Mail list logo
