Re: The Difference between debcheckout and dgit and what they try to accomplish
Hello Helmut, On Mon 17 Jun 2019 at 06:21pm +0200, Helmut Grohne wrote: > Presently, no. I attempted using it, but I feel that the extra > complexity did not help my use case. dgit solves a difficult problem and > that comes at a cost. Verification of source integrity is much more > difficult to understand with dgit (and it presently seems to have a > trust root in the ca business). The integrity checking performed by > apt-get source on the other hand is quite easily explained (if you > assume gpgv). Then, I'm not interested in commits that are not yet > uploaded. I want to reproduce the exact failure that QA saw. I > occasionally look into history of packages to figure something out. For > this case, dgit is not useful due to its low adoption and being young. > On the other hand, debian/changelog often suffices here. > > So it's not like dgit would be bad. It just seems to solve a different > problem than the one I have. This is good feedback, thank you. Can I ask whether you think it would help if dgit was more verbose about the verification it was doing? Telling you what the ftpmaster API was telling it, or something. The commercial SSL thing is indeed a problem (#790093). For the history thing, after you `dgit clone`, `git fetch vcs-git` will get you the maintainer's history for browsing. That's about as easy as debcheckout. -- Sean Whitton signature.asc Description: PGP signature
Re: AMDGPU+OpenCL with Debian?
On 17.06.19 22:16, Carsten Schoenert wrote: Am 17.06.19 um 21:15 schrieb PICCA Frederic-Emmanuel: Same here... with WXX100 cards. what about rocm packaging ? (I'm not using an AMD graphic card but ...) there was recently a new article added to the Debian wiki regarding this topic about using the official AMDGPU driver. Maybe this helps solving some questions? https://wiki.debian.org/How%20to%20install%20official%20AMDGPU%20linux%20driver%20with%20kernel%204.19.x%20on%20Stretch%20and%20Buster Thank you for that pointer, Carsten. I think that likely would have helped. Still, when working on a new system, would you follow these instructions or rather install Ubuntu? As helpful as such instructions are, most folks don't want to be bothered. They want their graphics card to work. When Debian describes tinkering with GPUs, then this should be something constructive, like for flashing some new bios with extra feats - not for the basics. Best, Steffen
Re: AMDGPU+OpenCL with Debian?
Hello, > Thank you for that pointer, Carsten. I think that likely would have > helped. Still, when working on a new system, would you follow these > instructions or rather install Ubuntu? As helpful as such instructions > are, most folks don't want to be bothered. I am a "regular" Debian user - not a developer. If Debian makes any attempt to move in the direction of the amount of hand-holding Ubuntu does, I am throwing my laptop out the window and going to live in the woods to eat berries and learn spear fishing or some shite. I do not need a 6 month bug cycle with patches applied on top of patches. I want the solid stable Debian system I have been using for over ten years that I have total control over and can fix with simple instructions like those provided for this AMD graphics issue. There are two other mainstream OS's out there specifically designed for people who don't want to learn how a computer works, and there is Ubunutu for the rest. Please leave Debian the way it is in this regard so that I can continue to have the joy of learning more about how my system works when minor issues like this come up. Thanks for listening and thank you very much for the work you all do. Very Best! Jason
Salsa CI Sprint - MiniDebConf Hamburg
Hi all ! The weekend is over and so it's the MiniDebConf (yeah, I started this draft last week and forgot to send it). I'd like to thank everyone who was there, we had a great time. It was my first Debian experience, and it won't be the last. To Holger and everyone involved on the organization: great job! I'd like to use this email to summarize the work we've done over the sprint and the new things that came up. - Finally managed to run the autopkgtest job as debci does. This closed a lot of issues related to these differences. There's still work to do, but we're on it :) Thanks terceiro and elbrus for the help. - Presented the 'Salsa CI - Debian Pipeline for Developers' talk introducing continuous integration and Salsa CI. We had amazing feedback, many were people interested on the project and more new projects adopted the pipeline. The video can be found in [0] and the slides in [1]. I strongly recommend everyone to watch all the talks [2]. - Invested some time helping developers to debug their pipelines (most of them successfully) and documented issues that appeared with features presumablymissing on the shared runners. - Many new ideas emerged, like interconnecting pipelines to test dependencies that aren't on the archive yet and having a way to deliver the salsa pipeline results to upstream on every change they submit (to allow developers to realize asap if the change breaks Debian packaging). - Still having problems with reprotest[3]. Now that autopkgtest is on good shape we might continue working on the reprotest job to make it more similar to reproducible-builds - Some people got really interested on supporting more architectures in the pipeline, so we're planning to add arm64 runners and expand the pipeline to run on both architectures. arm64 would be a good start but first we need to get sponsored cloud runners ;). We will continue working on this and everyone is welcome to use, report and contribute to the project :) Thank you all ! 0_ https://meetings-archive.debian.net/Public/debian-meetings/2019/miniconf-hamburg/salsaci.webm 1_ https://wiki.debian.org/DebianEvents/de/2019/MiniDebConfHamburg?action=AttachFile&do=view&target=salsa-ci-team-slides.pdf 2_ https://wiki.debian.org/DebianEvents/de/2019/MiniDebConfHamburg#talk_schedule_v1.0.1 3_ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928921#22 -- - ina signature.asc Description: OpenPGP digital signature
Re: AMDGPU+OpenCL with Debian?
Mo Zhou schrieb: > On 2019-06-18 03:15, PICCA Frederic-Emmanuel wrote: >> Same here... with WXX100 cards. >> what about rocm packaging ? > > Not easy. Involves a toolchain. > Is ROCm promising enough to challenge CUDA? > (Although ROCm has already beaten CUDA in > terms of license). You may find https://phabricator.wikimedia.org/T148843/#5078403 (and later) interesting, which describes some of the tests done with ROCm running on Buster with the 4.19 Buster kernel; aside from firmware-amd-graphics running entirely on free software (the only non-free package (hsa-ext-rocr-dev) is optional and was axed out in the tests). Cheers, Moritz
