Re: debian-cd baking process
Dear Steve: Am 18.01.24 um 00:37 schrieb Steve McIntyre: > Kevin Price wrote: >> I'm not quite sure where to address this to, > Argh, that's my code in the debian-cd package. "reportbug debian-cd" > should do the right thing... Thank you for your help, I should have known. So I've now filed https://bugs.debian.org/1063858 . Please accept my apology for being slow in doing that. Cheers -- Kevin Price
debian-cd baking process
Hi all! I'm not quite sure where to address this to, but I'm certain this is a bug: If you download debian installer media, for instance debian-12.4.0-amd64-DLBD-2.iso, they prominenty include the files "README.txt" and "README.html". Those presumably somehow auto-generated README files say, in the case of former example: "this disc is number 2 of a set of 1 discs" Which is obviously false. Could anyone please help me find where to file this bug to? Any ideas much appreciated. Maybe there's a bug already that I didn't find. -- Kevin Price
Re: Debian 12.4.0
Am 14.12.23 um 23:01 schrieb David Sawyer: > I use the password that I wrote down it is not accepted. Keyboard layout? We've seen that with the kernel that comes with 12.4.0. -- Kevin Price
Re: The bug
Am 15.12.23 um 15:47 schrieb Stefan Monnier: > But that's always true: the GNU/Linux system, like all sufficiently > complex software systems, is chuck full of bugs, many of which can > indeed have disastrous effects if they manifest under the > "right" circumstances. Here are some foreseeable and preventable ones. > AFAICT the only thing really different about "the bug" > (#1057967/#1057969) is that it comes right after a bug that made a lot > of noise (bug#1057843), so people have temporarily lost faith. No faith lost on my part. And bugs are not evaluated in the amount of noise the preceding one made. -- Kevin Price
Re: The bug
I largely agree with Greg. Am 13.12.23 um 16:33 schrieb Greg Wooledge: > On Wed, Dec 13, 2023 at 04:13:44PM +0100, to...@tuxteam.de wrote: >> On Wed, Dec 13, 2023 at 10:10:37AM -0500, Greg Wooledge wrote: >>> On Wed, Dec 13, 2023 at 09:56:46AM -0500, Stefan Monnier wrote: >>>> If so, then IIUC the answer is a resounding "YES, it is safe!". Safe not to fry your ext4 by Bug#1057843, yes, Stefan. Safe in general, as originally asked by Rick? He might be lucky, or maybe less so. >>> Safety is subjective. A great deal will depend on what kind of system >>> is being upgraded. If it's a remote server to which you have limited >>> or no physical access, booting a kernel that may "just be unusable" >>> (enough to prevent editing GRUB menus and rebooting) could be a disaster. Absolutely, Greg. >> ...but that one most probably won't be attached via a Broadcom to the 'net. Tomas: Servers are most usually not connected through wifi alone. But "the bug" (#1057967/#1057969) won't only disable the wifi adapter, but would probably make the running computer largely unusable, even unable to shut down. That's confirmed. In that case you still might have access through LAN IOT possibly fix GRUB's configuration, if you find a way to do that without sudo, and working around whatever problems you'll encounter attempting that. But even then, that new GRUB configuration will never come into effect until you forcibly reboot/power cycle the computer. (which has always been a bad thing to do in the first place) Under these circumstances, "the bug" can become a huge problem. Maybe unlikely for many use cases, but then huge. > My superficial understanding, after skimming through the bug report, > is that problems could be triggered just by *loading* one of the > affected wifi driver modules. With less superficial understanding, I fully agree with Greg. > This would happen for any machine that > has one of the "right" kinds of wifi hardware, even if that hardware > isn't actively being used. Exactly. Mere presence of wifi adapters will cause debian to load their respective wifi driver modules, that in turn will invoke cfg80211, maybe or not triggering cfg80211's bug. > (Not just Broadcom either; at least one > person reported an issue with Realtek.) IIUC, that was Olivier's rtl88x2bu non-free wifi driver too, causing the bug, but not Alberto's r8169, which is for wired LAN. > Perhaps I'm reading it incorrectly, but I still feel it's wise to wait > a little while and see if any more problems pop up, if stability is > important to you. Yes. If you're up to gambling, throw in all the computers you're willing to spare. In case of solely remote controlled servers: I wouldn't. Risking to lose control of servers is too much of a bet for too little of a win, IMHO. > I also salute the courage of those who've tested > these recent changes. Thank you all. Appreciation for my small part (in pointing the problem out in the first place) accepted, but please send your muchos kudos to Salvatore Bonaccorso , who deserves credits for solving it. -- Kevin Price
Re: Is it safe to install Bookworm on a new machine now?
Rick: Am 13.12.23 um 02:47 schrieb Rick Thomas: > Is there a netinst iso that I can use to safely install Bookworm (stable) on > a new PC? Possibly yes, but please read on. > If so, where can I download it from? Please always use official sources: https://www.debian.org/CD/ > If not, how much longer is it likely to be before one exists? My worst guess is 12.5, in a few months from now. But 12.4 might likely work perfectly fine for you, out of the box. If not, you can make 12.4 work for you right now. Here are some of my findings, assumptions, and educated guesses for you regarding "the bug". Hoping to help you, no guarantees. Any risks are yours, as always. "The bug" (Bug#1057967 & Bug#1057969) occurs only in kernel version 6.1.66-1 (package -6.1.0-15, released with bookworm 12.4). No other debian kernel version has this bug. It might not affect you, and it can be remedied/worked around. If it does affect you, it won't fry your filesystem, but the computer won't run properly under this kernel, causing a lots of problems, making your computer largely unusable during this runtime. I don't see any great danger in giving it a shot, if you're reasonably careful to understand, and prepare for what might go wrong. (The much more dangerous kernel would be its predecessor, 6.1.64-1, package 6.1.0-14, which was briefly released in bookworm 12.3, and very quickly retracted. It might toast your ext4 filesystem. (Bug#1057843) For that very reason, no official 12.3 media were ever publically released. See the latest messages at https://www.debian.org/News/2023/ ) "The bug" (Bug#1057967, Bug#1057969) is within the kernel module cfg80211, which is used for Wifi in general, regardless of your adapter's specific WiFi driver. If your computer has WiFi, even if you don't intend to use it, debian (including installer) will by default try to load the appropriate driver modules, which will pull in cfg80211. In case of the non-free broadcom-sta driver, binary "wl.ko" is known to trigger the bug in cfg80211 in 6.1.66-1/6.1.0-15, which then causes lots of problems during runtime. Whether any other WiFi drivers trigger this bug as well, IDK. The _free_ broadcom driver (see https://wiki.debian.org/bcm43xx ) doesn't seem to trigger this for me, YMMV. Non-free drivers are not shipped in official bookworm media, but if you actively choose non-free during the installation process or later, broadcom-sta might then be installed, triggering "the bug". Don't confuse this with non-free firmware. This is indeed shipped in official bookworm media, but most likely won't trigger "the bug". In your case, I'd try the bookworm 12.4 installer straight. By chance, everything might turn out well. If promblems occur that look like "the bug", I'd try one or more of the following possible remedies/workarounds, each of which _might_ suffice, but might cause some error messages or other issues. As soon as you've updated to 6.1.67-1 (6.1.0-16, about to come), any remedies/workarounds should be safe to be reverted. Maybe try the least inconvenient ones first. I haven't tested all of them. * Avoid "non-free". "non-free-firmware" should be O. K. * Turn off your physical RF kill switch. * Physically remove your WiFi adapter. * Blacklist "cfg80211". * Blacklist "wl". * Use bookworm 12.2 installer media, but not netinst, without internet access. Do not allow kernel updates, until 6.1.67-1/6.1.0-16 is available. Presumably some of the folks in this list/thread might come up with even more possible remedies/workarounds. Again: no guarantees. Some of the above is not confirmed or tested. All you do is at your own risk. But I hope I could help you understand "the bug" and how to possibly avoid it, giving you more confidence in what you're attempting to do. Please feel free to ask any further questions to this list, and any reports I'd welcome here. -- Kevin Price
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
l. Always have one extra, really. This weekend that little extra carefulness paid for me. Another time, it will for you. Given all the above, in conjunction with autoremove, this might have made some people's computers stranded with only -14 and -15 to boot from. Out of which one might toast all their data, and the other one might go nuts if their computer has wifi, and by chance they're using a driver that cfg80211 can't cope with. Those users would be then out of luck. What a terrible mess. /o\ I strongly believe in debian's honesty, because debian is based upon its social contract.[2] Have you read and understood it? (It's a very pleasant read.) The debian project is designed to be free and open, and to be incapable of covering up anything that might have gone wrong. Much better than that: Debian will publish just that in most detail. Having screwed up twice in a row, debian will confess, big time. Had I mentioned blog posts? (We might need a word with the moon regarding its blue occurrence. Maybe don't do that twice in a weekend, please?) Debian is empowering users. That includes that debian will never accept liability for making anyone's computer unusable. If that ever happens, then it's the user who's done it. Debian focuses on providing a free operating system to anyone, enabling them to make best use of their computers. And debian goes great lengths to help users prevent screwing up. In order to get things straight (get kernels working), debian's Salvatore Bonaccorso has been wonderful in pinpointing the -15's bug to the cfg80211 module, and developing a remedy, which will hopefully be introduced with future 6.1.0-16 maybe, soon to come. Not again hastily: It's ready when it's ready. That's how debian's been excellent for 30 years. So please feel empowered, use debian as much as you like, and if you feel gratitude or appreciation, please feel free to express any of that. Maybe towards the release or kernel teams, who've been working unpaid nightshifts for 12.3, which suddenly became 12.4, and who still are, for the folks who need to solve that -15 wifi bug. What are they doing it for? For the good, expecting nothing in return. Just enjoy! (Since you'd explicitly asked for advice, I hope there was not too much mansplaining.) [1] (installed. or in other cases, not installed, or in a specific version, etc.) [2] https://www.debian.org/social_contract -- Kevin Price
Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?
Am 11.12.23 um 14:16 schrieb Stella Ashburne: > Suppose I wish to upgrade to linux-image-6.1.0-15-amd64. If that were the case, or maybe better to a newer one. > Should I do it after booting my device into > (1) linux-image-6.1.0-14-amd64 (the problematic kernel) NO. Don't ever boot that as it might then toast your ext4. > (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one) Yes. > (3) doesn't matter which kernel to upgrade from Yes, it largely doesn't matter, apart from the exception above. HTH -- Kevin Price
Re: Debian 12.3 image release delayed
Am 11.12.23 um 04:36 schrieb Stella Ashburne: > As for me, I won't be upgrading to the latest kernel just yet because a user, > Kevin Price, reported problems with the latest kernel version (cf. > https://lists.debian.org/debian-user/2023/12/msg00570.html) That _might_ be a good idea. Currently the prime suspect is cfg80211 (WiFi). So there _might_ be a debian 12.4.1 coming up, who knows. I'd _not_ universally recommend 12.4.0, which uses the faulty kernel 6.1.0-15. For now I'm holding on to 6.1.0-13 for general use, as well as 6.1.0-12 as a functioning backup. YMMV. See https://bugs.debian.org/1057967 for Follow-up, and possibly https://bugs.debian.org/1057967, which _might_ be the same bug, in which case they'll be merged. Time will tell. -- Kevin Price
Re: 6.1.0-15/6.1.66-1 broken too?
Please see https://bugs.debian.org/1057967 for follow-up. Am 11.12.23 um 06:21 schrieb Stephan Verbücheln: [...] > My hardware is a 2014 Macbook Pro (Intel CPU and graphics). Stephan and all, would you please post your information there? TIA -- Kevin Price
Re: 6.1.0-15/6.1.66-1 broken too?
I confirm that 6.1.66-1 (6.1.0-15) severely breaks my amd64/bookworm/gnome physical machine, which runs fine with 6.1.52-1 and 6.1.55-1. Am 10.12.23 um 20:24 schrieb Andrew M.A. Cater: > On Sun, Dec 10, 2023 at 08:02:03PM +0100, Kevin Price wrote: >> Am 09.12.23 um 19:09 schrieb Dan Ritter: >>> The new kernel release is reported to contain an ext4 data >>> corruption bug. It's prudent not to upgrade, or if you have >>> started to upgrade, not to reboot, until a new kernel release >>> is prepared. >> >> Thanks for your announcement. I'm running out of time to properly report >> a bug against 6.1.66-1. >> >> #1057843 states that it's fixed with 6.1.0-15/6.1.66-1. This I highly >> doubt. I handpicked that version from >> https://deb.debian.org/debian/pool/main/l/ , and installed the 6.1.66-1 >> packages[1]. That was totally messed up and made my amd64 system highly >> unresponsive and erratic to the point it would hang shutting down. So I >> booted back into 6.1.0-13, which still works fine, and purged 6.1.0-14 >> and 6.1.0-15, and IOT have two working options, I reinstalled 6.0.1-12, >> which had been autoremoved with the update. >> >> [1] Packages I used: >> >> [src:linux] >> linux-compiler-gcc-12-x86_6.1.55-1_amd64.deb >> linux-headers-6.1.0-13-amd64_6.1.55-1_amd64.deb >> linux-headers-6.1.0-13-common_6.1.55-1_all.deb >> linux-kbuild-6.1_6.1.55-1_amd64.deb >> linux-libc-dev_6.1.55-1_amd64.deb >> >> [src:linux-signed-amd64] >> linux-headers-amd64_6.1.55-1_amd64.deb (optional meta-pkg) >> linux-image-6.1.0-13-amd64_6.1.55-1_amd64.deb >> linux-image-amd64_6.1.55-1_amd64.deb (optional meta-pkg) >> >> Other versions I tried: >> 6.1.0-12/6.1.52-1 works >> 6.1.0-13/6.1.55-1 works >> 6.1.0-14/6.1.64-1 broken, according to #1057843 >> 6.1.0-15/6.1.66-1 broken as experienced >> >> For now, I've purged the broken ones, and put the working ones on hold >> with dpkg. >> >> Any ideas? >> -- >> Kevin Price >> > > If you hand-picked packages: I would suggest using apt to upgrade the whole > system . Done that, now that 6.1.0-15/6.1.66-1 is available through apt. > Kevin: Do you have any logs to show brokenness? Which ones? > For what it's worth, > there were other updates and fixes besides just #1057843 in the new > release. Some of that must be the culprit, breaking my system. What happens, at a first glance: 1. Bootup to the gdm greeter works, but there I get an unusal keyboard layout. And everything takes longer. 2. There seems to be no network connectivity. (no WiFi icon) 3. Launching Firefox apparently does nothing. 4. Launching gnome-teminal works, but many commands just stall, such as "sudo dmesg" or "ip a". 5. Shutting down takes ages, with systemd waiting for a bunch of services to terminate, most of which seem to be network-related. After much more that 10 min I used hard power-off. I'm uncertain whether such an unstable system is even capable of going through the reportbug script. Any ideas, which logfiles might be useful to debug this issue, and whom to address this to, IOT to prevent similar experiences from many more users? Also what kind of testing could I usefully perform? Any kernel parameters maybe? -- Kevin Price
6.1.0-15/6.1.66-1 broken too?
Am 09.12.23 um 19:09 schrieb Dan Ritter: > The new kernel release is reported to contain an ext4 data > corruption bug. It's prudent not to upgrade, or if you have > started to upgrade, not to reboot, until a new kernel release > is prepared. Thanks for your announcement. I'm running out of time to properly report a bug against 6.1.66-1. #1057843 states that it's fixed with 6.1.0-15/6.1.66-1. This I highly doubt. I handpicked that version from https://deb.debian.org/debian/pool/main/l/ , and installed the 6.1.66-1 packages[1]. That was totally messed up and made my amd64 system highly unresponsive and erratic to the point it would hang shutting down. So I booted back into 6.1.0-13, which still works fine, and purged 6.1.0-14 and 6.1.0-15, and IOT have two working options, I reinstalled 6.0.1-12, which had been autoremoved with the update. [1] Packages I used: [src:linux] linux-compiler-gcc-12-x86_6.1.55-1_amd64.deb linux-headers-6.1.0-13-amd64_6.1.55-1_amd64.deb linux-headers-6.1.0-13-common_6.1.55-1_all.deb linux-kbuild-6.1_6.1.55-1_amd64.deb linux-libc-dev_6.1.55-1_amd64.deb [src:linux-signed-amd64] linux-headers-amd64_6.1.55-1_amd64.deb (optional meta-pkg) linux-image-6.1.0-13-amd64_6.1.55-1_amd64.deb linux-image-amd64_6.1.55-1_amd64.deb (optional meta-pkg) Other versions I tried: 6.1.0-12/6.1.52-1 works 6.1.0-13/6.1.55-1 works 6.1.0-14/6.1.64-1 broken, according to #1057843 6.1.0-15/6.1.66-1 broken as experienced For now, I've purged the broken ones, and put the working ones on hold with dpkg. Any ideas? -- Kevin Price
Re: Download links do not work
Am 12.09.22 um 01:09 schrieb Tom Zarcone: > Debian.org/download does not work. Not a single link works. So double-check https://www.debian.org/download again. All it says is “unable to connect”. I get this issue on every browser I use Do you happen to be in a country whose government restricts Internet access? Your IPv4 address 17.58.6.50 is allocated to Apple Inc. -- Kevin
Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 03.09.22 um 06:32 schrieb Casey Deccio: >> On Sep 2, 2022, at 8:14 PM, Kevin Price wrote >> We got him. :) Casey, you file the bug report, Okay? > Done! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018999 > Thanks for all the help! You are very welcome. Thanks a lot for this conversation, which felt very pleasant to me, and kind, productive, and helpful, even though especially my initial reply was quite tight-lipped. Thanks to our well-working cooperation. We've successfully and quite quickly pinpointed the cause of a real-world problem that likely affects many others. ^5 IMHO, this is a good example of how I wish the Debian/FLOSS community to always be. Or any good community, for that matter. If I may: Very well done, Casey. *shoulder tap* What caught my initial attention was the possibility of the kernel broadly changing its behavior within a stable release, which in itself would pose a huge problem, which to prevent is the very purpose of stable. Glad that turned out to be false. Your appreciativeness encouraged me to follow up on this, which rewarded me with quite some fun in helping to solve this little puzzle with you, and with the bonus of a few decoys in our way. ;D Out of curiosity I've subscribed to your bug #1018999. Very well written. Its outcome we'll see. As to if, when, and how it might get fixed, I'm not all that optimistic, so you might want to stick with any workarounds for a while. (maybe a tailored deb package that _Conflicts_: connman and _Recommends_: network-manager, or else maybe a kernel boot command line parameter "ipv6.disable=1", which completely overrides sysctl, or whatever may suit your needs) Although connman is actively being maintained upstream and in Debian right now, it's far from granted this bug will be acknowledged as such at all, either in Debian or upstream. Otherwise it might be dismissed as connman's "expected behavior". Although I'm not in favor of that in this case, I do understand the argument that a program designed for the sole purpose of managing network interfaces, actually manages network interfaces. Maybe not in the way we'd like. Maybe it could manage them to more satisfaction by asking permission before overriding the user's preference to disable_ipv6, which it doesn't. Thus #1018999. In case your bug gets acknowledged, (which is a huge if) I'd expect any resolution to appear in stable no sooner than in Bookworm, whenever that may be released. (...very purpose of stable...) Also, in case bug #1018999 is not going to be fully resolved to your needs, we might consider filing a wishlist "bug report" against lxde to at least change their recommendation into something less troublesome, such as network-manager maybe. Which does not interfere with the user's preferences in the same way. Oh BTW, I ought to file another bug report against connman (if not already pending) for not being able to be installed via ssh in a DHCP environment. (because during postinst it reconfigures the network interfaces, failing to use the proper FQDN in DHCP requests, thus getting a new IP address assigned and cutting off the ssh session) Not quite certain, but I guess this violates some existing Debian policy, or else a new Debian policy to come into place rather soon. (bug report against debian-policy) Thank you Casey for being part of the Debian community. Your participation makes Debian a better place to be, so please keep it up! -- Kevin
Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 03.09.22 um 02:15 schrieb Kevin Price: > Let's double check whether our connman is in fact the culprit, and then > make arrest. (file bug report) We got him. :) Casey, you file the bug report, Okay? Blank debian, apt --no-install-recommends install connman will break "disable_ipv6" as you describe. Another conman bug: cannot be installed via ssh, because something in its installation process cuts the connection. (assigning new IP address) Maybe connman would be a good package to avoid altogether, until all those terrible bugs are resolved. How can such serious fuckup have made it into stable. I bet you reporting this will resolve more than what we've found. And maybe the LXDE maintainers should reconsider their recommendation. Your bug, Casey. You file it please. -- Kevin
Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 02.09.22 um 22:03 schrieb Casey Deccio: > Then I ran tasksel and add Debian desktop environment and LXDE and rebooted. > At that point, disable_ipv6 does *not* work. > > Now, this does seem to narrow it down--sort of. It does. And *now* I can reproduce. task-lxde-desktop requires lxde, lxde recommends connman-gtk (or others), connman-gtk requires connman. So connman's my prime suspect. (what a pun :D ) > But the confusing thing is that the system on which disable_ipv6 currently > *works* is also running LXDE. lxde might be installed without connman, either ignoring the recommendation, or having an alternative installed. Let's double check whether our connman is in fact the culprit, and then make arrest. (file bug report) Thank you Casey for this little quiz. :D Still please let us know in this list how it goes. :D -- Kevin
Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 02.09.22 um 15:46 schrieb Casey Deccio: >> On Sep 2, 2022, at 2:51 AM, Kevin Price wrote: > Thanks for the idea. I took your advice and booted my 5.10.0-17 system > (problem system) with 5.10.0-13. The problem persisted! Then I updated my > "old" (non-problem) system from Debian 11.3 to 11.4 and updated to kernel > 5.10.0-17, and I rebooted. Still no problems! So the kernel version is ruled out as culprit. > Note: the problem system is a brand new install of Debian with only a few > packages installed (they are also installed on the non-problem system) and > very little customization. I used the 11.3.0 netinst image to install, but > everything is up to date. I've confirmed the behavior independently on two > fresh installs. > > Another note: I'm running my tests on VMs in VirtualBox. However, they are > running on the same version of VirtualBox and even on the same machine. Even > the version of VBox Guest Additions is the same. I suspect your "very little customization" (since you're doing networking stuff) or the "VBox Guest Additions" (since they mess with network interfaces). In order to test this, I used debian-11.3.0-amd64-netinst.iso from the archive to install a vm, but in my case QEMU/KVM. German localization and no task selected but task-ssh-server. > Scratching my head... The behavior is good. (disable_ipv6=1 works for me as intended) That seems to confirm my original hunch. I'm curious about the outcome, so maybe follow-up to this list please? Any potential bugs should be reported. But probably I won't be able to spare time to test VirtualBox. HTH -- Kevin
Re: net.ipv6.conf.intf.disable_ipv6 behavior changes
Am 02.09.22 um 06:33 schrieb Casey Deccio: > 1) a sanity check (can others confirm the behavior discrepancy?); No. My 5.10.0-17 behaves like your 5.10.0-13. 2) an expectation of *correct* behavior (seems to me like the 5.10.0-13 behavior is "correct"); Yes. and 3) suggestions for next steps. FWIW, confirm by booting your 5.10.0-17 system with 5.10.0-13. Figure out what other difference might be causing this. -- Kevin
Re: Can I install Debian operating systems for money?
Am 09.08.22 um 20:53 schrieb Dan Ritter: > you > can charge the reasonable cost of the media with Debian on it, > if you are selling that. You may even charge huge money for debian itself, not just for the media. You are allowed to sell it for whatever your clients are willing to pay, and your jurisdiction permits. And nobody may ever take this freedom away from you. You might want to look up why that is: * DFSG #1 https://www.debian.org/social_contract#guidelines Further reading, two other attempts to define basically the same idea: * freedom 2. https://www.gnu.org/philosophy/free-sw.html * 1. https://opensource.org/osd -- Kevin
Upgrade from wheezy to testing and wine
I upgraded 64 bit wheezy to testing(Jessie) yesterday. 32 bit wine applications worked great until I ran apt-get autoremove. This broke quite a few 32 bit wine applications for me. I narrowed it down to two packages that were autoremoved: libxinerama1:i386 and libxrandr2:i386. Should I file a bug against a package suggesting including these as dependencies and if so how do I figure out which package should require them? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140415213637.ga6...@crazycoder.us
Re: is there a risk to program in java since sun is bought by oracle
No, there are several open implementations of the jdk, java is the recommended language for Android, and oracle has continued to support java well. Maybe someone knows something that I don't, but it seems like you should hack in the language you like best. On Wed, Apr 09, 2014 at 09:31:49PM +0100, abdelkader belahcene wrote: is there a risk to program in java since sun is bought by oracle ? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409215237.ga14...@crazycoder.us
BD-R and wheezy
Is there an easy way to burn BD-R on wheezy? I met a guy at a LUG that wanted to try linux but he lives out in the middle of nowhere and has 56k. Since I have cable, I downloaded the Blu Ray images using jigdo. I am having a lot of trouble burning them to disk. I tried basero, but that gives the error that the disk isn't supported. Is there a way to get this working? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409223201.ga14...@crazycoder.us
Re: BD-R and wheezy
On Wed, Apr 09, 2014 at 11:05:42PM +, Andrew M.A. Cater wrote: On Wed, Apr 09, 2014 at 06:32:01PM -0400, Kevin Price wrote: Is there an easy way to burn BD-R on wheezy? I met a guy at a LUG that wanted to try linux but he lives out in the middle of nowhere and has 56k. Since I have cable, I downloaded the Blu Ray images using jigdo. I am having a lot of trouble burning them to disk. I tried basero, but that gives the error that the disk isn't supported. Is there a way to get this working? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409223201.ga14...@crazycoder.us Get a large enough stick - a 16G should work - and dd the .iso image to the stick. That forms a bootable USB stick from which you can then install - I did this a while ago to prove the point and there are discussions around with Richard Owlett on the lists - he's doing something vaguely similar. If you _only_ want to install from the stick to start, skip using a network mirror then go back and reconfigure the /etc/apt/sources.list afterwards. Hope this helps, All the very best Andy Cater Andy, It would have to be a very large thumb drive, like 64gb. I'm also not sure how that would work with apt-cdrom. The advantage to the two blu ray set is that it contains the entire wheezy distribution, so he could install everything if he wanted to and never use his internet connection. I know I am in the extreme minority of users to even own a BD-R drive. I can't find any information as to wether burning BD-R is supported under wheezy. I'd rather not upgrade to Jessie as several x86 windows programs I run with wine don't run at all under Jessie ATM. If I have to, I have a windows install I can use to burn the images but this is something I'd like to get working on debian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409233307.ga15...@crazycoder.us
Wine not full screen
After installing lxde and gnome desktops on wheezy, wine no longer changes the resolution to be full screen. It instead opens in a little subsection of the display in the upper left corner. Switching between windowed mode and non windowed mode doesn't change the desktop resolution. I thought it might be something lightdm was doing, so I stopped lightdm and launched startx. Same deal. The game I am trying to run scrolls based on mouse position at the edge of the screen, so playing in a virtual desktop isn't optimal. Any Ideas? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405185239.ga17...@crazycoder.us
Re: Wine not full screen
I was futzing around with xrandr and noticed that the only resolution available was my monitor's native resolution. Installing amd's official driver fixed this. I had to install outside of apt, because the version included in the repos hard locked my machine. Everything works great now! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140405200350.ga18...@crazycoder.us
