Bug#1036125: ITP: virtme-ng -- Build and run specific kernels inside a virtualized snapshot of your live system
Package: wnpp Severity: wishlist Owner: Ricardo Ribalda Delgado X-Debbugs-Cc: debian-de...@lists.debian.org, rica...@ribalda.com * Package name: virtme-ng Version : 1.6 Upstream Contact: Andrea Righi * URL : https://github.com/arighi/virtme-ng * License : GPL-2.0 Programming Lang: Python Description : Build and run specific kernels inside a virtualized snapshot of your live system virtme-ng is a tool that allows to setup a lab to experiment different kernel versions in a safe virtualized environment, re-using the entire filesystem of the running machine as a safe live-copy, without affecting the real filesystem of the host. virme-ng is a fork of virtme. It is more active than the legacy version. The original author has been contacted and they are ok with the fork and replacing the original virtme from Debian until he has time to maintain it again. Once this package lands I will ask for the removal of the old virtme.
Bug#1006978: closed by Debian FTP Masters (reply to Ricardo Ribalda Delgado ) (Bug#1006978: fixed in ugrep 3.7.5+dfsg-1)
Hi Peter The author of grep posted a version that they considered fixed the issue. I reviewed the diff and what they did seemed pretty reasonable and correct. The new version was packaged in less than 24 hours. Reporting bugs is highly appreciated, but putting deadlines to developers is not realistic. The great news is that due to the open-source nature of the project you can fix the code yourself (patches are welcome and Robert is incredibly good at picking them in good time) or you can find a local developer to do the code for you and then send the patches. You mentioned that open source work is not not paid and that is false, the time I work for Debian is time that I do not spend with my family, so basically my kids are paying for my volunteer work. Regards On Thu, Mar 17, 2022 at 1:19 AM Peter Mueller wrote: > > reopen 1006978 > found 1006978 3.7.5+dfsg-1 > thanks > > > No, the bug is still there. The same goes for > https://github.com/Genivia/ugrep/issues/193 . Ricardo, with all respect: if > I asked you a specific question, there was also a specific reason for this. > The developer seems to have produced a fix more or less blindly, without > having the same Debian amd64 installation as I do. The result is that the bug > still exists. So, you (or someone else) answering their question is crucial > (myself, I can't – I simply know nothing about /sys and apparmor and too > little about the Linux file system anyway). So, please, we all know how > open-source development works and it may be unpaid, but still, I would kindly > ask you to do it at your earliest convenience (if you technically can't, of > course, please forward the request to someone who can).
Bug#1006978: Plz update
Hi Peter I just pushed it to unstable. Let me know how it goes. Thanks! On Sun, Mar 13, 2022 at 10:35 PM Peter Mueller wrote: > > … the developer apparently has a new version with a fix. Could you please > test it yourself and put it into experimental? Thanks! > Peter
Bug#1006978: ugrepping /sys/kernel takes too long or grepping /sys/kernel is not thorough
Hi Peter Could you try to send this bug to: https://github.com/Genivia/ugrep/issues ? Right now there is no debian specific patch that modifies the behaviour of ugrep for sysfs On Wed, Mar 9, 2022 at 9:15 PM Peter Mueller wrote: > > Package: ugrep > Version: 3.3.3+dfsg-1 > > Searching for a string in /sys/kernel with grep terminates within 3 seconds > (and spits out many error messages, which is o.k.). Searching for the same > string with ugrep (and avoiding following references) doesn't terminate over > half an hour and spits out no error messages. Therefore, ugrep has a > deficiency somewhere, or grep doesn't do its job thoroughly. > > # time -p grep -i -r dvistyle /sys/kernel > … (error messages)… > real 2,75 > user 0,05 > sys 1,06 > # date && time -p ugrep -i -r -p dvistyle /sys/kernel > Mi 9. Mär 20:34:45 CET 2022 > ^Creal 2162,92 > user 0,04 > sys 0,28 > # date > Mi 9. Mär 21:10:49 CET 2022 > #
Bug#927408: novnc upstream 1.2
Hi, I have sent a merge request with the package version 1.2.0: https://salsa.debian.org/openstack-team/third-party/novnc/-/merge_requests/2 Regards! On Wed, 20 Oct 2021 16:48:24 +0900 Junichi Uekawa wrote: > Hi, > > It seems like the latest upstream version is 1.2. > https://github.com/novnc/noVNC/releases/tag/v1.2.0 > > Do you need help updating ? > > >
Bug#988523: ugrep: please backport to Buster
Hi Adam I tried uploading directly myself and as you predicted it didn't work. I uploaded the package to mentors: https://mentors.debian.net/debian/pool/main/u/ugrep/ugrep_3.2.0+dfsg-1~bpo10+1.dsc I guess you can fetch it from there and upload it yourself. Otherwise I can ping who sponsored me for ugrep. Thanks! On Mon, May 17, 2021 at 10:24 AM Ricardo Ribalda Delgado wrote: > > Hi Adam > > Thanks for your email. > > Since one of the conditions is that the version needs to be at least > in testing I think we should wait until Sunday to have version 3.2.0 > ported instead of 3.1.7. > > And thanks for your offer to help, I will probably need it ;P > > Best regards! > > > On Fri, May 14, 2021 at 8:45 PM Adam Borowski wrote: > > > > Package: ugrep > > Version: 3.2.0+dfsg-1 > > Severity: wishlist > > > > Hi! > > Could you please upload a version of ugrep to buster-bpo? > > > > To save you from having to RTFM, here's the procedure: > > * append ~bpo10+1 to version number (+2 on 2nd upload...) > > * set distribution in the new changelog entry to "buster-backports" > > * first upload of a backport needs to go through bpo-NEW, thus binaries > > need to be included > > * bpo uploads these days go to the same queue as regular uploads > > * a version to be backported needs to be already in testing > > > > I'm not certain if DMs can upload their own packages to bpo-NEW, I think > > they can't. As there's no requirement for a backporter to be an uploader, > > I can go through all the motions for +1 if you don't wish to bother with > > a sponsored upload the first time. > > > > > > Meow! > > -- System Information: > > Debian Release: 11.0 > > APT prefers testing-security > > APT policy: (500, 'testing-security'), (500, 'unstable'), (500, > > 'testing'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) > > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en > > Shell: /bin/sh linked to /usr/bin/dash > > Init: sysvinit (via /sbin/init) > > > > Versions of packages ugrep depends on: > > ii libbz2-1.01.0.8-4 > > ii libc6 2.31-12 > > ii libgcc-s1 11-20210319-1 > > ii liblz4-1 1.9.3-2 > > ii liblzma5 5.2.5-2 > > ii libpcre2-8-0 10.36-2 > > ii libstdc++611-20210319-1 > > ii libzstd1 1.4.8+dfsg-2.1 > > ii zlib1g1:1.2.11.dfsg-2 > > > > ugrep recommends no packages. > > > > ugrep suggests no packages. > > > > -- no debconf information > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
Bug#988523: ugrep: please backport to Buster
Hi Adam Thanks for your email. Since one of the conditions is that the version needs to be at least in testing I think we should wait until Sunday to have version 3.2.0 ported instead of 3.1.7. And thanks for your offer to help, I will probably need it ;P Best regards! On Fri, May 14, 2021 at 8:45 PM Adam Borowski wrote: > > Package: ugrep > Version: 3.2.0+dfsg-1 > Severity: wishlist > > Hi! > Could you please upload a version of ugrep to buster-bpo? > > To save you from having to RTFM, here's the procedure: > * append ~bpo10+1 to version number (+2 on 2nd upload...) > * set distribution in the new changelog entry to "buster-backports" > * first upload of a backport needs to go through bpo-NEW, thus binaries > need to be included > * bpo uploads these days go to the same queue as regular uploads > * a version to be backported needs to be already in testing > > I'm not certain if DMs can upload their own packages to bpo-NEW, I think > they can't. As there's no requirement for a backporter to be an uploader, > I can go through all the motions for +1 if you don't wish to bother with > a sponsored upload the first time. > > > Meow! > -- System Information: > Debian Release: 11.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), > (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages ugrep depends on: > ii libbz2-1.01.0.8-4 > ii libc6 2.31-12 > ii libgcc-s1 11-20210319-1 > ii liblz4-1 1.9.3-2 > ii liblzma5 5.2.5-2 > ii libpcre2-8-0 10.36-2 > ii libstdc++611-20210319-1 > ii libzstd1 1.4.8+dfsg-2.1 > ii zlib1g1:1.2.11.dfsg-2 > > ugrep recommends no packages. > > ugrep suggests no packages. > > -- no debconf information -- Ricardo Ribalda
Bug#964957: ugrep: Baseline violation on several architectures
Hi Adrian I am planning to send to my mentor this for his review: https://salsa.debian.org/ribalda-guest/ugrep/-/commit/9844a1fd02245d26f67173485e03ff99c16a1ec8 Please share any comment if you feel that is not correct. I am new here ;) Cheers On Sun, Jul 26, 2020 at 3:11 PM Ricardo Ribalda Delgado wrote: > > Hi Adrian > > Thanks for your message. I have been Out Of office the last two weeks, > let me take a look at this asap. > > Best regards > > On Mon, Jul 13, 2020 at 1:33 PM Adrian Bunk wrote: > > > > Source: ugrep > > Version: 2.1.1+dfsg-1 > > Severity: serious > > > > After looking at the build log and sources, there are several > > baseline violations due to the package being built for what > > is supported on the buildd instead of the architecture baseline: > > - -march=native is always wrong in a distribution build > > - SSE2 is part of the amd64 baseline, but not the i386 baseline > > - AVX is not part of the amd64 or i386 baseline > > - NEON is not part of the armhf baseline > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
Bug#964957: ugrep: Baseline violation on several architectures
Hi Adrian Thanks for your message. I have been Out Of office the last two weeks, let me take a look at this asap. Best regards On Mon, Jul 13, 2020 at 1:33 PM Adrian Bunk wrote: > > Source: ugrep > Version: 2.1.1+dfsg-1 > Severity: serious > > After looking at the build log and sources, there are several > baseline violations due to the package being built for what > is supported on the buildd instead of the architecture baseline: > - -march=native is always wrong in a distribution build > - SSE2 is part of the amd64 baseline, but not the i386 baseline > - AVX is not part of the amd64 or i386 baseline > - NEON is not part of the armhf baseline -- Ricardo Ribalda
Bug#964975: ugrep: Wrong synopsis line
Hi Joao Thanks for your mail. It is already fixed on salsa: https://salsa.debian.org/ribalda-guest/ugrep/-/blob/debian/debian/control The next release will have a compliant text. Best regards On Mon, Jul 13, 2020 at 7:00 PM Joao Eriberto Mota Filho wrote: > > Package: ugrep > Version: 2.1.1+dfsg-1 > Severity: normal > X-Debbugs-Cc: eribe...@debian.org > > Dear Maintainer, > > The synopsis in your package is not compliant with Debian Policy §3.4.1. Using > 'apt search ugrep' I can see: > > ugrep/unstable 2.1.1+dfsg-1 amd64 >Universal grep: ultra fast searcher of file systems, text and > > Please, use an informative line to describe your package. > > Regards, > > Eriberto > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) -- Ricardo Ribalda
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Hi Jonas Thanks a lot for your remarks! I am a newbie in Debian packaging. On Thu, Jun 4, 2020 at 10:18 PM Jonas Smedegaard wrote: > > Quoting Ricardo Ribalda Delgado (2020-06-04 19:53:10) > > I have just updated my salsa to 2.2.0 > > https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case > > that you want to give it a try. > > Great! > > A few remarks about the packaging: > > The autopkgtest failed: > > upstream-test-suite FAIL stderr: configure.ac:31: installing './ar-lib' How did you trigger the error?. I was relying on: https://salsa.debian.org/ribalda-guest/ugrep/-/jobs/785720 > > Seems you need to add the allow-stderr restriction - more info here: > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst Added, thanks > > Related to autopkgtest I (just earlier today in fact) noticed the > "build-needed" restriction which seems perfectly suitable for the kind > of test you've setup. Instead of that I am configuring with dh_ and then using the system installed ugrep. Seems to work ;) https://salsa.debian.org/ribalda-guest/ugrep/-/commit/f8b63f4430818f6414b354804c70037d70a328da > > The package short description is wrongly used as a first line of the > long description - check Debian Policy § 5.6.13 for the details on that. Fixed, Thanks! > > I also would have expected libreflex to be built as a shared library for > reuse by other future packages besides ugrep - but perhaps you've > discussed that with Zumbi already and there is some sensible reason for > embedding the library with ugrep. I decided to follow the upstream methodology. Also considering that there is no other use of libreflex today on Debian and the library belongs to the same author of the utility. > > Are you aware that you can use wildcards with lintian overrides? Seems > your 18 almost identical overrides can be shrunk to just one line. And > while at it, please consider adding a comment describing why those > warnings are overridden (it is easier to agree or disagree with your > reasoning without first reading your mind :-) ). No, I was not aware of that, thanks :) > > You've listed only copyright and licensing for main upstream author and > yourself - but there are also (at least) some autotools-originated files > licensed as Expat, FSFAP, FSFUL, FSFULLR, GPL-2+, and GPL-3+. Possibly > you are already aware and consider those irrelevant to track in > debian/copyright, but mentioning in case the omission wasn't deliberate, > as I suspect ftpmaster might disagree with doing that. If interested, > then I can guide you in using licensecheck to check that (and keep track > of changes for later updates). This case it was deliberate. But I have added a simple tracking of licensecheck, thanks for the hint :). > > Thanks a lot for packaging ugrep. I hadn't heard about it before I saw > your ITP, and it looks like an amazing tool, that I will sure spend some > time getting familiar with now. I started using it when I discover that I could not grep unicode files, since then I use it when I have to deal with edk2 development. Now I have less grey hair. All your suggested changes are in https://salsa.debian.org/ribalda-guest/ugrep/-/commit/22f76fa5cebb249ffcb62950a8a7fe11eb9d1959 Thanks again! Cheers! > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private -- Ricardo Ribalda
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Hi Jonas Thanks for the heads up. I have just updated my salsa to 2.2.0 https://salsa.debian.org/ribalda-guest/ugrep/-/tree/debian In case that you want to give it a try. When zumbi has some time it will be updated. Best regards On Thu, Jun 4, 2020 at 12:04 PM Jonas Smedegaard wrote: > > Quoting Ricardo Ribalda Delgado (2020-05-19 18:13:16) > > Package: wnpp > > Severity: wishlist > > Owner: Ricardo Ribalda Delgado > > > > * Package name: ugrep > > Version : 2.1.1 > > Upstream Author : Robert van Engelen > > * URL : https://github.com/Genivia/ugrep/wiki > > * License : BSD-3-Clause > > Programming Lang: C++ > > Description : Universal grep: ultra fast searcher of file systems, > > text and binary files, source code, archives, compressed files, documents, > > and more. > > > > > > NEW ultra fast grep with interactive query UI: search file systems, > > text, source code, binary files, archives (cpio/tar/pax/zip), compressed > > files (zip/gz/Z/bz2/lzma/xz), documents, and more. > > > > It is also very useful when grepping on codebase with unicode files. > > > > I plan to send with a sponsor (zumbi). Hopefuly I will be able to > > upload packages on my own ;). > > Thanks a lot for your work on this package, Ricardo! > > Zumbi just now told me that the package is in NEW queue - great! That's > not the newest upstream release, however: Please consider upgrading to > release 2.1.4 or newer, for its improved handling of large collections > of patterns with named capture, as discussed at > https://github.com/Genivia/ugrep/issues/35 > > Kind regards, > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private -- Ricardo Ribalda
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Hi Mo Thanks for your offer. I already packaged it, and have a mentor. https://salsa.debian.org/ribalda-guest/ugrep I think it is a package simple enough that does not need co-maintainer, but I keep you offer in mind in case I cannot maintain it in the future or if I fail to include the package in Debian. Thanks! On Wed, May 20, 2020 at 2:29 AM Mo Zhou wrote: > > Hi Ricardo, > > I tried it out and it looks quite interesting, since it has some more > features that the other grep implementations (including ripgrep) do not > have. I'm interested in co-maintaining this package if you need help. > > On Tue, May 19, 2020 at 06:13:16PM +0200, Ricardo Ribalda Delgado wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Ricardo Ribalda Delgado > > > > * Package name: ugrep > > Version : 2.1.1 > > Upstream Author : Robert van Engelen > > * URL : https://github.com/Genivia/ugrep/wiki > > * License : BSD-3-Clause > > Programming Lang: C++ > > Description : Universal grep: ultra fast searcher of file systems, > > text and binary files, source code, archives, compressed files, documents, > > and more. > > > > > > NEW ultra fast grep with interactive query UI: search file systems, > > text, source code, binary files, archives (cpio/tar/pax/zip), compressed > > files (zip/gz/Z/bz2/lzma/xz), documents, and more. > > > > It is also very useful when grepping on codebase with unicode files. > > > > I plan to send with a sponsor (zumbi). Hopefuly I will be able to > > upload packages on my own ;). > > -- Ricardo Ribalda
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Package: wnpp Severity: wishlist Owner: Ricardo Ribalda Delgado * Package name: ugrep Version : 2.1.1 Upstream Author : Robert van Engelen * URL : https://github.com/Genivia/ugrep/wiki * License : BSD-3-Clause Programming Lang: C++ Description : Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. NEW ultra fast grep with interactive query UI: search file systems, text, source code, binary files, archives (cpio/tar/pax/zip), compressed files (zip/gz/Z/bz2/lzma/xz), documents, and more. It is also very useful when grepping on codebase with unicode files. I plan to send with a sponsor (zumbi). Hopefuly I will be able to upload packages on my own ;).
Bug#958342: xc3sprog: reports incorrect device ID codes
Hi Kipp On my board, I managed to make it work with with this .hex and: ricardo@neopili:/tmp/$ sudo xc3sprog -c xpc XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop JTAG loc.: 0 IDCODE: 0x41c22093 Desc: XC3S500E Rev: E IR length: 6 JTAG loc.: 1 IDCODE: 0xf5046093 Desc: XCF04S Rev: O IR length: 8 JTAG loc.: 2 IDCODE: 0x06e5e093 Desc: XC2C64A-VQ44 Rev: A IR length: 8 If I use xpc_internal I get the same error as you. Seems like xpc_internal is for other type of cables. Can you give it a try? Thanks On Wed, Apr 22, 2020 at 9:35 AM Ricardo Ribalda Delgado wrote: > > Hi Kipp > > Thanks for the report. I havent used the embedded cable on S3 myself, > but I have asked a colleague to share a similar board than yours with > me so I can run some tests, and at least replicate the bug. > > Will ping to you when I give it a try > > Regards > > On Mon, Apr 20, 2020 at 8:15 PM Kipp Cannon > wrote: > > > > Package: xc3sprog > > Version: 0+svn795+dfsg-1+b1 > > Severity: important > > > > I am new to FPGA development, so I don't have the ability to test a variety > > of configurations. I have a Spartan-3E Starter Kit development board, > > which has a built-in Xilinx "platform cable" interface. I am using the > > Xilinx platform cable firmware that ships with ISE 14.7, specifically I am > > using the xusb_emb.hex file with md5sum 545ce982a72441822960fb66a28bde98. > > The information available online implies to me that xc3sprog should work > > with this development kit, but it does not. The device IDs is reports are > > nonsense, and without being able to identify the devices the software > > cannot interact with them rendering it effectively non-functional. > > > > What I get is > > > > $ xc3sprog -c xpc_internal > > XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux > > Free software: If you contribute nothing, expect nothing! > > Feedback on success/failure/enhancement requests: > > http://sourceforge.net/mail/?group_id=170565 > > Check Sourceforge for updates: > > http://sourceforge.net/projects/xc3sprog/develop > > > > Cannot find device having IDCODE=1070607 Revision A > > JTAG loc.: 0 IDCODE: 0x01070607 not found in 'built-in device list'. > > JTAG loc.: 1 IDCODE: 0x03030707 not found in 'built-in device list'. > > JTAG loc.: 2 IDCODE: 0x03070707 not found in 'built-in device list'. > > > > > > The board does have 3 devices in the jtag chain, so that much is correct. > > > > The "jtag" program from the urjtag package works correctly, it is > > able to scan the jtag chain and program devices on it. It reports the > > following for the board so you can see what the device IDs should be: > > > > jtag> cable xpc_int > > firmware version = 0x0404 (1028) > > cable CPLD version = 0x0006 (6) > > jtag> detect > > IR length: 22 > > Chain length: 3 > > Device Id: 01101110010010010011 (0x06E5E093) > > Manufacturer: Xilinx (0x093) > > Part(0): XC2C64-VQ44 (0x6E5E) > > Stepping: 0 > > Filename: > > /home/kipp/urjtag/share/urjtag/xilinx/xc2c64a-vq44/xc2c64a-vq44 > > Device Id: 01010100011010010011 (0x05046093) > > Manufacturer: Xilinx (0x093) > > Part(1): xcf04s (0x5046) > > Stepping: 0 > > Filename: /home/kipp/urjtag/share/urjtag/xilinx/xcf04s/xcf04s > > Device Id: 00011110001010010011 (0x01C22093) > > Manufacturer: Xilinx (0x093) > > Part(2): xc3s500e_fg320 (0x1C22) > > Stepping: 0 > > Filename: > > /home/kipp/urjtag/share/urjtag/xilinx/xc3s500e_fg320/xc3s500e_fg320 > > > > -Kipp > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers testing > > APT policy: (500, 'testing') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) > > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages xc3sprog depends on: > > ii libc62.30-4 > > ii libftdi1-2 1.4-2+b2 > > ii libgcc-s1 [libgcc1] 10-20200411-1 > > ii libgcc1 1:10-20200411-1 > > ii libstdc++6 10-20200411-1 > > ii libusb-0.1-4 2:0.1.12-32 > > ii libusb-1.0-0 2:1.0.23-2 > > > > xc3sprog recommends no packages. > > > > xc3sprog suggests no packages. > > > > -- no debconf information > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
Bug#958342: xc3sprog: reports incorrect device ID codes
Hi Kipp Thanks for the report. I havent used the embedded cable on S3 myself, but I have asked a colleague to share a similar board than yours with me so I can run some tests, and at least replicate the bug. Will ping to you when I give it a try Regards On Mon, Apr 20, 2020 at 8:15 PM Kipp Cannon wrote: > > Package: xc3sprog > Version: 0+svn795+dfsg-1+b1 > Severity: important > > I am new to FPGA development, so I don't have the ability to test a variety > of configurations. I have a Spartan-3E Starter Kit development board, > which has a built-in Xilinx "platform cable" interface. I am using the > Xilinx platform cable firmware that ships with ISE 14.7, specifically I am > using the xusb_emb.hex file with md5sum 545ce982a72441822960fb66a28bde98. > The information available online implies to me that xc3sprog should work > with this development kit, but it does not. The device IDs is reports are > nonsense, and without being able to identify the devices the software > cannot interact with them rendering it effectively non-functional. > > What I get is > > $ xc3sprog -c xpc_internal > XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux > Free software: If you contribute nothing, expect nothing! > Feedback on success/failure/enhancement requests: > http://sourceforge.net/mail/?group_id=170565 > Check Sourceforge for updates: > http://sourceforge.net/projects/xc3sprog/develop > > Cannot find device having IDCODE=1070607 Revision A > JTAG loc.: 0 IDCODE: 0x01070607 not found in 'built-in device list'. > JTAG loc.: 1 IDCODE: 0x03030707 not found in 'built-in device list'. > JTAG loc.: 2 IDCODE: 0x03070707 not found in 'built-in device list'. > > > The board does have 3 devices in the jtag chain, so that much is correct. > > The "jtag" program from the urjtag package works correctly, it is > able to scan the jtag chain and program devices on it. It reports the > following for the board so you can see what the device IDs should be: > > jtag> cable xpc_int > firmware version = 0x0404 (1028) > cable CPLD version = 0x0006 (6) > jtag> detect > IR length: 22 > Chain length: 3 > Device Id: 01101110010010010011 (0x06E5E093) > Manufacturer: Xilinx (0x093) > Part(0): XC2C64-VQ44 (0x6E5E) > Stepping: 0 > Filename: > /home/kipp/urjtag/share/urjtag/xilinx/xc2c64a-vq44/xc2c64a-vq44 > Device Id: 01010100011010010011 (0x05046093) > Manufacturer: Xilinx (0x093) > Part(1): xcf04s (0x5046) > Stepping: 0 > Filename: /home/kipp/urjtag/share/urjtag/xilinx/xcf04s/xcf04s > Device Id: 00011110001010010011 (0x01C22093) > Manufacturer: Xilinx (0x093) > Part(2): xc3s500e_fg320 (0x1C22) > Stepping: 0 > Filename: > /home/kipp/urjtag/share/urjtag/xilinx/xc3s500e_fg320/xc3s500e_fg320 > > -Kipp > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages xc3sprog depends on: > ii libc62.30-4 > ii libftdi1-2 1.4-2+b2 > ii libgcc-s1 [libgcc1] 10-20200411-1 > ii libgcc1 1:10-20200411-1 > ii libstdc++6 10-20200411-1 > ii libusb-0.1-4 2:0.1.12-32 > ii libusb-1.0-0 2:1.0.23-2 > > xc3sprog recommends no packages. > > xc3sprog suggests no packages. > > -- no debconf information -- Ricardo Ribalda
Bug#913235: ITP: yavta -- Yet Another V4L2 Test Application
Package: wnpp Severity: wishlist Owner: Ricardo Ribalda Delgado * Package name: yavta Version : 0.0~git20181108.487d395 Upstream Author : Laurent Pinchart * URL : http://git.ideasonboard.org/?p=yavta.git;a=summary * License : GPL-2 Programming Lang: C Description : Yet Another V4L2 Test Application Warning, newbie here :) Yavta is a simple but powerful to configure/test v4l2 devices. It is used, among other things to verify embedded systems and to test timing issues. I plan to maintain it on a git repository. I have already started it on: https://github.com/ribalda/yavta But it can be moved anywhere. It is a simple enough package to maintain it myself and hopefully, the first of other many others. I found zumbi as sponsor, but it someone is interested I can add the package in a team. Thanks!
Bug#908704:
Propossed patch
--
Ricardo Ribalda
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 3fcaa98..50a7c93 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -318,14 +318,23 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_DISABLE);
}
+#define N_TRIES 20
void
intel_dp_start_link_train(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ int tries;
- if (!intel_dp_link_training_clock_recovery(intel_dp))
- goto failure_handling;
- if (!intel_dp_link_training_channel_equalization(intel_dp))
+ for (tries = 0; tries < N_TRIES; tries++) {
+ if (!intel_dp_link_training_clock_recovery(intel_dp)){
+ msleep(10);
+ continue;
+ }
+ if (intel_dp_link_training_channel_equalization(intel_dp))
+ break;
+ }
+
+ if (tries == N_TRIES)
goto failure_handling;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training Passed at Link Rate = %d, Lane count = %d",
Bug#908704: linux-image-4.18.0-1-amd64: Fix downgraded resolutions for Display Port
Package: src:linux Version: 4.18.6-1 Severity: normal Dear Maintainer, Some High Resolution Screens are downgraded to full HD due to DP link training failures.This problem can be easily solved by allowing retries during DP link training. If the hardware is capable of running at high resolution the link will be properly calibrated after 2 o 3 attempts. If the hardware cannot run at that resolution the link will be downgraded in less than a second. The proposed patch is self contained and has been tested successfuly on 4 different kernels (4.15 - 4.18). This bug has been replicated on multiple devices and screens and notified to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=106223 Unfortunately it is considered low-priority for Intel (but high-annoying by the users). Hopefully this patch will allow users to make full use of their screens and I will spend less time rebuilding my kernel. -- Package-specific info: ** Version: Linux version 4.18.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.6-1 (2018-09-06) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 root=UUID=4ac4c7fd-7b0a-4fc0-a4aa-e063d18bfe9f ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [3.828853] usb 1-3.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.828854] usb 1-3.1.1: Product: Lenovo USB Optical Mouse [3.828855] usb 1-3.1.1: Manufacturer: PixArt [3.956542] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC255: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [3.956546] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [3.956549] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [3.956550] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [3.956552] snd_hda_codec_realtek hdaudioC0D0:inputs: [3.956554] snd_hda_codec_realtek hdaudioC0D0: Mic=0x12 [3.964026] usb 1-3.1.2: new low-speed USB device number 9 using xhci_hcd [4.122473] usb 1-3.1.2: New USB device found, idVendor=04b3, idProduct=3025, bcdDevice= 1.02 [4.122480] usb 1-3.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [4.122484] usb 1-3.1.2: Product: USB NetVista Full Width Keyboard [4.122488] usb 1-3.1.2: Manufacturer: CHICONY [4.233894] input: HDA Digital PCBeep as /devices/pci:00/:00:1f.3/sound/card0/input15 [4.234952] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1f.3/sound/card0/input16 [4.235066] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1f.3/sound/card0/input17 [4.235176] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input18 [4.235283] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input19 [4.235389] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input20 [4.235493] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci:00/:00:1f.3/sound/card0/input21 [4.436110] media: Linux media interface: v0.10 [4.446085] videodev: Linux video capture interface: v2.00 [4.453678] uvcvideo: Found UVC 1.00 device XiaoMi USB 2.0 Webcam (05c8:03a2) [4.462195] Bluetooth: Core ver 2.22 [4.462204] NET: Registered protocol family 31 [4.462205] Bluetooth: HCI device and connection manager initialized [4.462208] Bluetooth: HCI socket layer initialized [4.462209] Bluetooth: L2CAP socket layer initialized [4.462213] Bluetooth: SCO socket layer initialized [4.465409] usbcore: registered new interface driver btusb [4.466339] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015 [4.467345] Bluetooth: hci0: Device revision is 16 [4.467346] Bluetooth: hci0: Secure boot is enabled [4.467347] Bluetooth: hci0: OTP lock is enabled [4.467347] Bluetooth: hci0: API lock is enabled [4.467348] Bluetooth: hci0: Debug lock is disabled [4.467349] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [4.468378] bluetooth hci0: firmware: direct-loading firmware intel/ibt-12-16.sfi [4.468381] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi [4.471474] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not initialized! [4.471475] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not initialized! [4.471476] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not initialized! [4.471477] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not initialized! [4.471530] input: XiaoMi USB 2.0 Webcam: XiaoMi U as /devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input22 [4.471579] usbcore: registered new interface driver uvcvideo [4.471579] USB Video Class driver (1.1.1) [4.485825] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0xcc adj_req2_3:0x0 [4.485827] Clock recovery check failed, cannot continue
Bug#906328: bmap-tools: slow write: failed to enable I/O optimization, expect suboptimal speed
After talking to the kernel developer... https://www.mail-archive.com/linux-block@vger.kernel.org/msg23928.html The warning is shown because bmap-tools is trying to setup an io sched that is not available on blk-mq. But that is no excuse to be 5-8 times slower. The real culprint was a bug on uas, Fixed with the commit "block: really disable runtime-pm for blk-mq that fix is in: linux-image-4.17.0-3-amd644.17.17-1 After installing it. I still get the warning (that needs to be fixed by bmap-tools upstream), but the perfomance is comparable to as it used to be. Thans everyone for you help! On Fri, Aug 17, 2018 at 6:57 PM Ben Hutchings wrote: > > On Fri, 2018-08-17 at 13:00 +0200, Ricardo Ribalda Delgado wrote: > > Hi Ben > > > > I am experience some very bad performace with SCSI_MQ_DEFAULT, That > > was enabled on Debian 4.17.1 > > > > Please take a look to this > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906328 > > Talk to the upstream kernel developers (linux-bl...@vger.kernel.org). > > The old block layer is going to be removed in favour of blk-mq > eventually, so I don't see any point in changing the default back. > > Ben. > > -- > Ben Hutchings > It is impossible to make anything foolproof > because fools are so ingenious. > -- Ricardo Ribalda
Bug#906328: bmap-tools: slow write: failed to enable I/O optimization, expect suboptimal speed
Seems that on kernel 4.17 Debian decided to change the default configuration. Maybe we should ping the kernel group? ricardo@neopili:~/curro/kernel-cleanup$ cat /boot/config-4.17.0-1-amd64 | grep CONFIG_SCSI_MQ_DEFAULT CONFIG_SCSI_MQ_DEFAULT=y ricardo@neopili:~/curro/kernel-cleanup$ cat /boot/config-4.16.0-2-amd64 | grep CONFIG_SCSI_MQ_DEFAULT # CONFIG_SCSI_MQ_DEFAULT is not set >From Kernel sourcee: config SCSI_MQ_DEFAULT bool "SCSI: use blk-mq I/O path by default" depends on SCSI ---help--- This option enables the new blk-mq based I/O path for SCSI devices by default. With the option the scsi_mod.use_blk_mq module/boot option defaults to Y, without it to N, but it can still be overridden either way. If unsure say N. On Fri, Aug 17, 2018 at 12:21 PM Ricardo Ribalda Delgado wrote: > > Booting 4.17 with the kernel option scsi_mod.use_blk_mq=0 > > returns the write time to the original 25.8 sec > > On Fri, Aug 17, 2018 at 12:15 PM Ricardo Ribalda Delgado > wrote: > > > > It is a CFast connected via USB3 > > > > Digging a bit, seems to be related to the module option: > > > > scsi_mod.use_blk_mq > > > > which is true on the new kernel and false on the old kernel. > > > > > > On Fri, Aug 17, 2018 at 12:12 PM Simon McVittie wrote: > > > > > > On Fri, 17 Aug 2018 at 10:27:47 +0200, Ricardo Ribalda Delgado wrote: > > > > Current version of bmap on combination with the current debian kernel > > > > gives a > > > > terrible low performance: > > > ... > > > > $sudo bmaptool copy image.wic /dev/sdb > > > > > > What sort of hardware is /dev/sdb? I think recent kernels offer different > > > classes of scheduler for (rotating, magnetic) hard disks and for > > > solid-state storage, which might explain why you see none instead of noop. > > > > > > If you copy a raw image to the same device on each kernel (without using > > > bmaptool to skip unused blocks), how long does it take with the default > > > scheduler, and how long does it take with the noop or none scheduler > > > (whichever is available)? > > > > > > If there has been a general performance regression in the kernel for > > > this device type, there is unlikely to be anything that bmaptool can do > > > about it, but a refinement of the patch you suggested (checking which > > > schedulers are available, and selecting either noop or none, whichever > > > is available) would make sense. > > > > > > smcv > > > > > > > > -- > > Ricardo Ribalda > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
Bug#906328: bmap-tools: slow write: failed to enable I/O optimization, expect suboptimal speed
Booting 4.17 with the kernel option scsi_mod.use_blk_mq=0 returns the write time to the original 25.8 sec On Fri, Aug 17, 2018 at 12:15 PM Ricardo Ribalda Delgado wrote: > > It is a CFast connected via USB3 > > Digging a bit, seems to be related to the module option: > > scsi_mod.use_blk_mq > > which is true on the new kernel and false on the old kernel. > > > On Fri, Aug 17, 2018 at 12:12 PM Simon McVittie wrote: > > > > On Fri, 17 Aug 2018 at 10:27:47 +0200, Ricardo Ribalda Delgado wrote: > > > Current version of bmap on combination with the current debian kernel > > > gives a > > > terrible low performance: > > ... > > > $sudo bmaptool copy image.wic /dev/sdb > > > > What sort of hardware is /dev/sdb? I think recent kernels offer different > > classes of scheduler for (rotating, magnetic) hard disks and for > > solid-state storage, which might explain why you see none instead of noop. > > > > If you copy a raw image to the same device on each kernel (without using > > bmaptool to skip unused blocks), how long does it take with the default > > scheduler, and how long does it take with the noop or none scheduler > > (whichever is available)? > > > > If there has been a general performance regression in the kernel for > > this device type, there is unlikely to be anything that bmaptool can do > > about it, but a refinement of the patch you suggested (checking which > > schedulers are available, and selecting either noop or none, whichever > > is available) would make sense. > > > > smcv > > > > -- > Ricardo Ribalda -- Ricardo Ribalda
Bug#906328: bmap-tools: slow write: failed to enable I/O optimization, expect suboptimal speed
It is a CFast connected via USB3 Digging a bit, seems to be related to the module option: scsi_mod.use_blk_mq which is true on the new kernel and false on the old kernel. On Fri, Aug 17, 2018 at 12:12 PM Simon McVittie wrote: > > On Fri, 17 Aug 2018 at 10:27:47 +0200, Ricardo Ribalda Delgado wrote: > > Current version of bmap on combination with the current debian kernel gives > > a > > terrible low performance: > ... > > $sudo bmaptool copy image.wic /dev/sdb > > What sort of hardware is /dev/sdb? I think recent kernels offer different > classes of scheduler for (rotating, magnetic) hard disks and for > solid-state storage, which might explain why you see none instead of noop. > > If you copy a raw image to the same device on each kernel (without using > bmaptool to skip unused blocks), how long does it take with the default > scheduler, and how long does it take with the noop or none scheduler > (whichever is available)? > > If there has been a general performance regression in the kernel for > this device type, there is unlikely to be anything that bmaptool can do > about it, but a refinement of the patch you suggested (checking which > schedulers are available, and selecting either noop or none, whichever > is available) would make sense. > > smcv -- Ricardo Ribalda
Bug#906328:
Booting with the kernel Linux neopili 4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux Writing the same image only takes 25.7s: And these are the avilable schdulers $ cat /sys/block/sdb/queue/scheduler noop deadline [cfq] -- Ricardo Ribalda
Bug#906328: bmap-tools: slow write: failed to enable I/O optimization, expect suboptimal speed
Package: bmap-tools
Version: 3.4-2
Severity: normal
Dear Maintainer,
Current version of bmap on combination with the current debian kernel gives a
terrible low performance:
$uname -a
Linux neopili 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
GNU/Linux
$sudo bmaptool copy image.wic /dev/sdb
bmaptool: info: discovered bmap file 'image.wic.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 248474 blocks of size 4096 (970.6 MiB), mapped 143428 blocks
(560.3 MiB or 57.7%)
bmaptool: info: copying image 'image.wic' to block device '/dev/sdb' using bmap
file 'image.wic.bmap'
bmaptool: WARNING: failed to enable I/O optimization, expect suboptimal speed
(reason: cannot switch to the 'noop' I/O scheduler: [Errno 22] Invalid
argument)
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1m 57.6s, copying speed 4.8 MiB/sec
If I cat the scheduler file I get the following:
$ cat /sys/dev/block/8:16/queue/scheduler
[mq-deadline] none
The following patch fixes the warning, but not the performance issues:
diff --git a/bmaptools/BmapCopy.py b/bmaptools/BmapCopy.py
index c066828..d17e98b 100644
--- a/bmaptools/BmapCopy.py
+++ b/bmaptools/BmapCopy.py
@@ -715,12 +715,13 @@ class BmapBdevCopy(BmapCopy):
The old settings are saved in order to be able to restore them later.
"""
# Switch to the 'noop' I/O scheduler
try:
with open(self._sysfs_scheduler_path, "r+") as f_scheduler:
contents = f_scheduler.read()
f_scheduler.seek(0)
-f_scheduler.write("noop")
+f_scheduler.write("none")
except IOError as err:
_log.warning("failed to enable I/O optimization, expect "
"suboptimal speed (reason: cannot switch to the "
Weirdly enugh NOOP ioscheduler is enabled on the kernel config:
$ cat /boot/config-4.17.0-1-amd64 | grep NOOP
CONFIG_IOSCHED_NOOP=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_BRIDGE_IGMP_SNOOPING=y
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bmap-tools depends on:
ii python3 3.6.5-3
Versions of packages bmap-tools recommends:
ii bzip2 1.0.6-8.1
ii lzop 1.03-4+b1
ii xz-utils 5.2.2-1.3
Versions of packages bmap-tools suggests:
pn lz4
pn pbzip2
pn pigz
pn python3-gpgme
ii unzip 6.0-21
-- no debconf information
Bug#901701:
This patch[1] fixes the bug for me:
diff --git a/libglfork.cpp b/libglfork.cpp
index 03f514f..dda6e4c 100644
--- a/libglfork.cpp
+++ b/libglfork.cpp
@@ -359,7 +359,7 @@ static bool test_drawpixels_fast(Display *dpy,
GLXContext ctx, GLXFBConfig dconf
int iters = 0;
do {
primus.dfns.glBufferSubData(GL_PIXEL_UNPACK_BUFFER_EXT, 0,
width*height*4, pixeldata);
-primus.dfns.glDrawPixels(width, height, GL_BGRA, GL_UNSIGNED_BYTE, NULL);
+primus.dfns.glDrawPixels(width, height, GL_BGRA,
GL_UNSIGNED_BYTE, pixeldata);
primus.dfns.glXSwapBuffers(dpy, pbuffer);
iters++;
} while (end > Profiler::get_timestamp());
[1]
https://github.com/ribalda/primus/commit/1b6dbc56040a59b6b222ba40d7c2de8c6cf1fbba
--
Ricardo Ribalda
Bug#901563:
As suggested in https://github.com/amonakov/primus/issues/201 PRIMUS_UPLOAD=1 primusrun glxgears works for me -- Ricardo Ribalda
Bug#896182:
I have just sent a pull request upstream that fixes this bug for me: https://github.com/intel/bmap-tools/pull/42 -- Ricardo Ribalda
Bug#896182: bmap-tools: Bmaptools fails to copy images located on the internet
Package: bmap-tools Version: 3.4-1 Severity: normal Dear Maintainer, When trying to copy a image located on the internet I get the following error: bmaptool copy http://tftp.qtec.com/qtec/europa/images/qt5022/qimage-dev- qt5022.wic /dev/sdb bmaptool: info: discovered bmap file 'http://tftp.qtec.com/qtec/europa/images/qt5022/qimage-dev-qt5022.wic.bmap' Traceback (most recent call last): File "/usr/bin/bmaptool", line 11, in sys.exit(main()) File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 715, in main args.func(args) File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 423, in copy_command open_files(args) File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 365, in open_files (bmap_obj, bmap_path) = find_and_open_bmap(args) File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 335, in find_and_open_bmap shutil.copyfileobj(bmap_obj, tmp_obj) File "/usr/lib/python3.6/shutil.py", line 82, in copyfileobj fdst.write(buf) File "/usr/lib/python3.6/tempfile.py", line 622, in func_wrapper return func(*args, **kwargs) TypeError: write() argument must be str, not bytes Seems to be related to python3, since another installation of the same version using python2 works just fine :S -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bmap-tools depends on: ii python3 3.6.4-1 Versions of packages bmap-tools recommends: ii bzip2 1.0.6-8.1 ii lzop 1.03-4+b1 ii xz-utils 5.2.2-1.3 Versions of packages bmap-tools suggests: pn lz4 pn pbzip2 pn pigz pn python3-gpgme ii unzip 6.0-21 -- no debconf information
Bug#859701: srecord: Please update to newest version 1.64
Source: srecord Severity: wishlist Hi srecord is currently at version 1.64 (Since 2014-07-13). It would be highly appreciated if the version in Debian is updated to this version, since many Makefiles for microcontrollers expect this version of the tool. Thanks! -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#785786: efivar: Could not delete boot variable: Success
Hello Jared I guess it is not needed anymore but ricardo@neopili:~/curro/qt5022/kernel$ sudo efibootmgr -v BootCurrent: 001B Timeout: 0 seconds BootOrder: 001A,0006,0007,0008,0009,000A,000B,000C,000D,000E Boot Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9) Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850) Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380) Boot0003 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479) Boot0004 ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963) Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5) Boot0006* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55) Boot0007* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49) Boot0008* ATAPI CD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401) Boot0009* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602) Boot000A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600) Boot000B* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601) Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803) Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot000E* ATAPI CD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403) Boot000F* ATAPI CD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404) Boot0010 Other CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406) Boot0011* ATA HDD3 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603) Boot0012* ATA HDD4 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604) Boot0013 Other HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606) Boot0014* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0) Boot0015* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0) Boot0016* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6) Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354) Boot0018* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot0019 OEM Hot Key FvFile(0b5a75d0-2793-4efa-bfa7-74689122fa55) Boot001A* debian HD(1,800,10,803bdbcc-6e1b-4cbc-b509-3ea4cf882dba)File(\EFI\debian\grubx64.efi) Boot001B* debian HD(1,800,10,803bdbcc-6e1b-4cbc-b509-3ea4cf882dba)File(\EFI\debian\grubx64.efi) Thanks! On Wed, May 20, 2015 at 9:52 PM, D. Jared Dominguez jared_doming...@dell.com wrote: Ricardo, Okay, I've poked around some, and it seems like efibootmgr won't even *build* with the most recently released libefivar0. There are a bunch of changes to efibootmgr upstream (dp branch in the efibootmgr git repo) that look like they resolve this, but since those changes aren't merged into the master efibootmgr branch--and certainly not released--I would like to check with the upstream maintainer on where we're at. Peter, How complete are your efibootmgr changes in the dp branch? I know you're off at Plugfest this week, so probably won't get a fast response. Do you have any pointers on any gotchas? --Jared -- Jared Domínguez Infrastructure Software Engineering Dell | Enterprise Solutions Group -- Ricardo Ribalda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785786: efibootmgr: Could not delete boot variable: Success
Package: libefivar0 Version: 0.18-1 Severity: important Since updating to 0.18-1 root@neopili:/home/ricardo# grub-install Installing for x86_64-efi platform. efibootmgr: Boot entry 001A not found efibootmgr: Could not delete boot variable: Success ** Warning ** : Boot001A has same label debian efibootmgr: Could not add entry to BootOrder: No such file or directory Installation finished. No error reported. Reverting to 0.15-3 from stable fixes the issue efibootmgr version used: 0.11.0-3 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libefivar0 depends on: ii libc6 2.19-18 libefivar0 recommends no packages. libefivar0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762798: java.lang.ClassNotFoundException: hudson/matrix/MatrixBuild
Hello Maybe this is related to https://issues.jenkins-ci.org/browse/JENKINS-24864 ? On Thu, 25 Sep 2014 14:00:59 +0200 Emmanuel Bourg ebo...@apache.org wrote: This is the trace for the ClassNotFoundException, do you still have the one for the ClassCastException? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441068: qemu: Keyboard problems in DOS : Caps Lock not working, Extended key events doubled. in VNC:, Alt Gr not working, ntilde not working
Package: qemu
Version: 0.9.0+20070816-1
Severity: important
Tags: patch
In DOS:
-Caps lock events are doubled (so, no efect for caps lock)
-Extended keyboard events are doubled: double up, double down
In vnc mode:
-Alt Gr is not well captured
-ntilde does not work
A patch is attached to solve this problems. It also integrate a new
system to add extra keys without modifying the code (again)
Regards.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.20-1-686 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages qemu depends on:
ii bochsbios 2.3+20070705-2BIOS for the Bochs emulator
ii libasound2 1.0.14a-2 ALSA library
ii libc6 2.6.1-2 GNU C Library: Shared libraries
ii libncurses55.6+20070825-1Shared libraries for terminal hand
ii libsdl1.2debian1.2.11-9 Simple DirectMedia Layer
ii openbios-sparc 1.0~alpha2+20070816-1 SPARC Open Firmware
ii openhackware 0.4.1-2 OpenFirmware emulator for PowerPC
ii proll 18-2 JavaStation PROM 2.x compatible re
ii vgabios0.6a-2VGA BIOS software for the Bochs an
ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime
Versions of packages qemu recommends:
ii debootstrap 1.0.3 Bootstrap a basic Debian system
ii sharutils 1:4.6.3-1 shar, unshar, uuencode, uudecode
pn vde2 none (no description available)
-- no debconf information
? backup-082720072326-pre-qemu.tgz
? description-pak
? doc-pak
? qemu_20070827-1_i386.deb
Index: keymaps.c
===
RCS file: /sources/qemu/qemu/keymaps.c,v
retrieving revision 1.2
diff -u -r1.2 keymaps.c
--- keymaps.c 30 Apr 2006 21:28:35 - 1.2
+++ keymaps.c 28 Aug 2007 04:08:17 -
@@ -24,7 +24,14 @@
static int get_keysym(const char *name)
{
+unsigned int keysym;
name2keysym_t *p;
+
+//User numerical added keysyms
+if (1==sscanf(name,0x%x,keysym))
+return keysym;
+
+//Normal ones
for(p = name2keysym; p-name != NULL; p++) {
if (!strcmp(p-name, name))
return p-keysym;
Index: sdl.c
===
RCS file: /sources/qemu/qemu/sdl.c,v
retrieving revision 1.42
diff -u -r1.42 sdl.c
--- sdl.c 21 Jun 2007 21:08:02 - 1.42
+++ sdl.c 28 Aug 2007 04:09:19 -
@@ -201,9 +201,9 @@
break;
case 0x45: /* num lock */
case 0x3a: /* caps lock */
-/* SDL does not send the key up event, so we generate it */
-kbd_put_keycode(keycode);
-kbd_put_keycode(keycode | 0x80);
+ if (ev-type == SDL_KEYUP)
+ kbd_put_keycode(keycode | 0x80);
+ else kbd_put_keycode(keycode);
return;
}
Index: vnc_keysym.h
===
RCS file: /sources/qemu/qemu/vnc_keysym.h,v
retrieving revision 1.2
diff -u -r1.2 vnc_keysym.h
--- vnc_keysym.h 7 Jan 2007 17:12:41 - 1.2
+++ vnc_keysym.h 28 Aug 2007 04:10:12 -
@@ -215,6 +215,7 @@
{Shift_R, 0xffe2}, /* XK_Shift_R */
{Super_L, 0xffeb}, /* XK_Super_L */
{Super_R, 0xffec}, /* XK_Super_R */
+{ISO_Level3_Shift, 0xfe03}, /* ISO_Level3
/* special keys */
{BackSpace, 0xff08}, /* XK_BackSpace */
Index: hw/ps2.c
===
RCS file: /sources/qemu/qemu/hw/ps2.c,v
retrieving revision 1.6
diff -u -r1.6 ps2.c
--- hw/ps2.c 20 Mar 2007 16:45:27 - 1.6
+++ hw/ps2.c 28 Aug 2007 04:12:48 -
@@ -146,17 +146,24 @@
PS2State *s = (PS2State *)opaque;
PS2Queue *q;
int val, index;
+static int flag=0;
q = s-queue;
if (q-count == 0) {
+ if (!flag){
+ index=q-rptr - 1;
+ flag=1;
+ }
+ else index=q-rptr - 2;
/* NOTE: if no data left, we return the last keyboard one
(needed for EMM386) */
/* XXX: need a timer to do things correctly */
-index = q-rptr - 1;
if (index 0)
-index = PS2_QUEUE_SIZE - 1;
+index += PS2_QUEUE_SIZE;
+
val = q-data[index];
} else {
+ flag=0;
val = q-data[q-rptr];
if (++q-rptr == PS2_QUEUE_SIZE)
q-rptr = 0;
Index: keymaps/es
===
RCS file: /sources/qemu/qemu/keymaps/es,v
retrieving revision 1.1
diff -u -r1.1 es
--- keymaps/es 12 Dec 2004 16:56:30 - 1.1
+++ keymaps/es 28 Aug 2007 04:13:57 -
@@ -71,6 +71,8 @@
Lstroke 0x26 shift altgr
ntilde 0x27
Ntilde 0x27 shift
+0xfff1 0x27
+0xffd1 0x27 shift
dead_doubleacute 0x27 shift altgr
Bug#421039: vim-latexsuite: Latex indent doesn't work
Package: vim-latexsuite Version: 20060325-3 Severity: important If you try to indent a latex document, Vim don't indent it. This can be easily solved copying the indentation file to the global place cp /usr/share/vim/addons/indent/tex.vim /usr/share/vim/vim70/indent/ Thanks -- Package-specific info: Vim related packages installed on this system: - vim-latexsuite - vim-runtime -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.17-1-686 (SMP w/1 CPU core) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim-latexsuite depends on: ii python 2.4.4-2 An interactive high-level object-o ii vim 1:7.0-219+1 Vi IMproved - enhanced vi editor ii vim-common 1:7.0-219+1 Vi IMproved - Common files ii vim-gnome [gvim] 1:7.0-219+1 Vi IMproved - enhanced vi editor - Versions of packages vim-latexsuite recommends: ii tetex-bin 2007-4 TeX Live: teTeX transitional packa ii texlive-base-bin 2007-5 TeX Live: Essential binaries -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377453: The problem resides in filetype detection
VIM cant detect correctly the file untill you write the first lines (header) of the latex file. Once you write them. Everything works correctly -- Ricardo Ribalda http://www.ii.uam.es/~rribalda/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421045: vim: Automatic .spl download not working (spell checking)
Package: vim Version: 1:7.0-219+1 Severity: normal If you try to download the last version of .spl Spell checking automaticly it doesn't work if the ~/.vim/spell directory is not created and you have the ftp program installed -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.17-1-686 (SMP w/1 CPU core) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim depends on: ii libc62.5-4 GNU C Library: Shared libraries ii libgpmg1 1.19.6-25 General Purpose Mouse - shared lib ii libncurses5 5.5-5 Shared libraries for terminal hand ii vim-common 1:7.0-219+1 Vi IMproved - Common files ii vim-runtime 1:7.0-219+1 Vi IMproved - Runtime files vim recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
