Bug#1008164: RM: obfs4proxy/0.0.8-1
I think having a good version of obfs4proxy in bullseye-backports should be fine to remove it from bullseye. The development of obfs4proxy is stopped since a while, at Tor we have forked it into lyrebird[0]. At some point we should package lyrebird and deprecate obfs4proxy. [0] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/ -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#1071525: laminar: diff for NMU version 1.1-1.1
Hello, Quoting Chris Hofstaedtler (2024-06-12 21:02:17) > I've prepared an NMU for laminar (versioned as 1.1-1.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. Thank you for working on it. I'm ok with this NMU being uploaded to debian, it makes total sense. I clearly lack the time to work on this package, and I'll be happy to hand it over if you or someone else wants to maintain it. Sorry for the long delay to respond. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#1063423: obfs4proxy: adopt lyrebird to provide future obfs4proxy
Hello, I'm one of the maintainers of lyrebird at the Tor Project. I'm happy to help with the process of getting lyrebird in debian, debian is used by many bridge operators that will need an easy way to get lyrebird installed. I'm happy to help with this process. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#1038634: O: tudu -- Command line hierarchical ToDo list
Package: wnpp Severity: normal X-Debbugs-Cc: t...@packages.debian.org Control: affects -1 + src:tudu I intend to orphan the tudu package. The package description is: ToDo list manager in ncurses, with hierarchical representation of the tasks. Each task has: * Title * Long text description * Deadline (tudu warns you when the date is approaching) * Categories * Priorities
Bug#1038633: O: acr -- autoconf like tool
Package: wnpp Severity: normal X-Debbugs-Cc: a...@packages.debian.org Control: affects -1 + src:acr I intend to orphan the acr package. The package description is: ACR is an autoconf like tool that allows you to create configure scripts for your programs. The main aim of this tool is to teach developers how to create portable builds of their tools, just using generic functions wrapped by acr to generate portable shellscript. . Pros: * Easy to learn / implement. * Faster/smaller final configure script. * Own syntax, not complex m4 macros. * Reverse engineering tool to recover .acr files from the final configure script. * Good documentation and tutorials. * vim syntax highlighting for configure.acr files ($PREFIX/share/acr/vim/install.sh) * Debugging support (-d) * Integrated support for java, bash, perl, Tcl, c, c++, ruby and Python. * Recursive configure script calls. * Progress bar in generation stage. . Cons: * Not recommended for huge projects * Slow script generation parsing huge configuration files * No automake replace. (just type clean makefiles and acr substs) * Not enough tested (only on free operating systems (Open|Net|Free|Dfly)BSD, GNU systems, and Darwin).
Bug#1025297: libgl1-mesa-dri: qemu+vga virtio: segmentation fault after update to version 22.3.0-1
Package: libgl1-mesa-dri Followup-For: Bug #1025297 Dear Maintainer, I think I'm seeing the same issue using qubes (xen virtualization), when I upgraded to 22.3.0-1. Rolling back to 22.2.4-1 solved the problem. My stacktrace is a bit different: (==) Log file: "/home/user/.local/share/xorg/Xorg.0.log", Time: Thu Dec 1 21:18:02 2022 (++) Using config file: "/etc/X11/xorg-qubes.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5f8b336e3c59] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7b08c685af90] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7b08c7421029] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7b08c696de9a] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7b08c696df4f] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7b08c68a3dc7] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7b08c68a3b26] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7b08c2ee7f44] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7b08c2ee7190] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7b08c24aa179] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7b08c2ab5156] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7b08c2ab50c4] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7b08c24aaa34] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7b08c24b44b5] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7b08c64f9d77] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7b08c64f8b7f] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x5f8b33575a24] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) [0x5f8b336a1a9f] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x5f8b335e12a9] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x5f8b335744e8] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7b08c684618a] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7b08c6846245] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x5f8b3355db61] (EE) (EE) Segmentation fault at address 0x337 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/user/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. /usr/bin/xinit: giving up /usr/bin/xinit: unable to connect to X server: Connection refused /usr/bin/xinit: server error Let me know if I can provide any extra information to help here.
Bug#1024137: obfs4proxy: Restart tor process on update
Package: obfs4proxy Version: 0.0.14-1 Severity: important Dear Maintainer, obfs4proxy is normally used in comvination with tor either to connect to a bridge or to provide a bridge. The upgrade will not be taking into account unless tor is restarted. Many bridge operators will update automatically the package, but the update will not be really applied as tor will not be restarted. Can we restart the tor proces on obfs4proxy update? I'm not sure what are the rules in debian to restart other daemons not provided by the package (is not even a dependency). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.76-1.fc32.qubes.x86_64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_SOFTLOCKUP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obfs4proxy depends on: ii libc6 2.35-3 obfs4proxy recommends no packages. obfs4proxy suggests no packages. -- no debconf information
Bug#983645: laminard crashing: Fixed upstream
Quoting Jan-Benedict Glaw (2022-02-10 11:09:57) > I had a few tickets with Oliver upstream. There were a few cornercases > that my (quite large) setup triggered quickly. Seems that's all fixed > by now. These included: > [...] > > So it would be nice to update the laminard/laminarc packages to > current versions, and possibly trigger a rebuild when there's a new > capnproto available? (I'm not sure how much of their *headers* > actually end up in the binary...) Amazing, thank you for working the issues with upstream to fix them. I will update the package in the coming days. I see capnproto 0.9.1 is already in experimental[0], so hopefully it will get into sid soon. I'm not sure about the rebuild, but it looks like we might want to depend on capnproto >= 0.9.0. Let's check with capnproto maintainer to see their plans for it and if we should upload laminar to experimental or wait for it to be in sid. [0] https://packages.debian.org/experimental/capnproto -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#983645: plans for capnproto
Hello Tom, I'm the maintainer of the laminar[0] debian package, which uses capnproto. There are several fixes that we care about included in capnproto >= 0.9.0. I see 0.9.1 is already in experimental. What are your plans for it? Might it graduate to sid soon? Or will it take some time in experimental? I'm thinking if is worth it for me to upload the new version of laminar into experimental or wait for capnproto to get into sid. Thanks. [0] https://laminar.ohwg.net/ Quoting Jan-Benedict Glaw (2022-02-10 11:09:57) > * Under some circumstances, laminard didn't accept any further web > requests when a client shut down the connection kind of at the > wrong point. That was an issue with capnproto > (https://github.com/capnproto/capnproto/pull/1407), which has no > new release yet after that was merged. I hope Tom Lee will package > capnproto quickly with the next release. Right now, Debian's 0.7 > version is quite dated... -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#954176: WIP snowflake package
I'm working on the snowflake package. I have a package that works: https://gitlab.torproject.org/meskio/snowflake-debian Looking for a mentor to review it and a place to put it in salsa, I'm asking the go-team to see if it will fit under their umbrella. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#989180: golang-github-smartystreets-assertions-dev: ShouldContain doesn't support slices
Package: golang-github-smartystreets-assertions-dev Version: 1.10.1+ds-1 Severity: normal Dear Maintainer, The debian package of github.com/smartystreets/assertions does unvendor github.com/jacobsa/oglematchers, but the vendored version in the assertions library did include some improvements. The one I care about is adding support for slices in ShouldContain: https://github.com/smartystreets/assertions/commit/6acd0337655254c23e16aae1be5acaa36576faf4#diff-0542b9c1330ae7fd11c64fede96abc85d3c9d5274979545e8c253cbae0ed5940 I'm building a package wich tests fail because it uses this feature. Maybe this commit could be added as a patch in the debian package golang-github-jacobsa-oglematchers-dev, it looks pretty safe to add and should not break any existing code. Another option will be to remove the vendoring. oglematchers doesn't seem be maintained, last commit is from 2015. The vendored version in smartystreets repo seems to be more maintained. To me it looks like the only package that do depend on is the smartystreets/assertions, maybe all the golang-github-jacobsa-*-dev packages can be removed. What do you think? Can I help on anthing there? Thank you. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.12-3.pvops.qubes.x86_64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages golang-github-smartystreets-assertions-dev depends on: ii golang-github-jacobsa-oglematchers-dev 0.0~git20150320-3 ii golang-golang-x-net-dev 1:0.0+git20210119.5f4716e+dfsg-4 golang-github-smartystreets-assertions-dev recommends no packages. golang-github-smartystreets-assertions-dev suggests no packages. -- no debconf information
Bug#983645: laminard: SIGPIPE kills it
Quoting Jan-Benedict Glaw (2021-03-02 14:44:33) > I do not think that SysV init has something to do with the SIGPIPE. > It's probably being a close()d / shutdown()ed FD (at the browser side) > while it tries to chunk-send data. > > However, with systemd you'd probably get a restart of laminard. You > may observe a failed / missing run, but because daemon(1) won't do > a restart, laminard dies for me without getting a recovery by restart. At least on my case this is not the problem. I see the laminard hasn't being restarted in my server for the last 20 days, and I do run several jobs per day and some of them I do watch them while they play. But there might be something different on my setup. > > If you are able to test your laminar with systemd tell me if your problem > > persist there. > > I'll try to pin down in which circumstances this actually happens. Good luck with it. If you don't find anything we can open an issue upstream, Oliver is pretty responsive and helpful. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#983645: laminard: SIGPIPE kills it
Jan-Benedict, thanks for the report. Quoting Jan-Benedict Glaw (2021-02-27 23:31:57) > I gave laminar a try, but laminard dies on SIGPIPE: > > (gdb) bt > #0 0x7f7f95d53da3 in __GI___writev (fd=16, iov=0x7ffdebf13860, iovcnt=3) > at ../sysdeps/unix/sysv/linux/writev.c:26 > #1 0x7f7f963d8269 in non-virtual thunk to kj::(anonymous > namespace)::AsyncStreamFd::write(kj::ArrayPtr const> const>) () at src/kj/async-inl.h:403 > #2 0x7f7f96487dc6 in kj::(anonymous > namespace)::HttpOutputStreamoperator() > (__closure=0x56237a1a5410) at src/kj/compat/http.c++:1661 > #3 kj::_::MaybeVoidCaller > >::apply namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr kj::ArrayPtr >):: > (func=..., func=..., > in=...) at ./src/kj/async-prelude.h:148 > #4 kj::_::TransformPromiseNode, kj::_::Void, > kj::(anonymous namespace)::HttpOutputStream::writeBodyData(kj::ArrayPtr kj::ArrayPtr >)::, > kj::_::PropagateException>::getImpl(kj::_::ExceptionOrValue &) > (this=0x56237a1a53f0, output=...) at ./src/kj/async-inl.h:401 > #5 0x7f7f9638c502 in > kj::_::TransformPromiseNodeBaseoperator() > (__closure=0x7ffdebf14188, __closure=0x7ffdebf14188) at src/kj/async.c++:703 > #6 > kj::_::RunnableImpl > >::run(void) (this=0x7ffdebf14180) at src/kj/exception.h:302 > #7 0x7f7f96305f9b in kj::_::runCatchingExceptions (runnable=warning: > RTTI symbol not found for class > 'kj::_::RunnableImpl' > ...) at src/kj/exception.c++:1023 > #8 0x7f7f9638b6fa in > kj::runCatchingExceptions > > (func=...) at src/kj/common.h:514 > #9 kj::_::TransformPromiseNodeBase::get (this=, output=...) > at src/kj/async.c++:703 > #10 0x7f7f963901e9 in kj::_::ChainPromiseNode::fire (this=0x56237a1b2cd0) > at src/kj/async.c++:855 > #11 0x7f7f9638be3c in kj::EventLoop::turn (this=0x56237a17df98) at > src/kj/async.c++:373 > #12 0x7f7f963910c5 in kj::_::waitImpl (node=..., result=..., > waitScope=...) at src/kj/async.c++:440 > #13 0x562378dde1cc in kj::Promise::wait (waitScope=..., > this=0x7ffdebf14cf0) at /usr/include/kj/async-inl.h:902 > #14 Server::start (this=0x56237a17e1e0) at ./src/server.cpp:56 > #15 0x562378d9eeba in main (argc=, argv=) > at ./src/main.cpp:98 > > > This is while one job is running and I'm following it's build log on > the /jobs/xxx/nn page. Quite easy to reproduce. I'm using laminar myself and I haven't seeing this issue. Can you provide an example job that produces this issue for you? > (Another small issue: /var/log/laminar.log isn't pre-created and > daemon drops permissions before creating the file, so it fails > creating it altogether.) >From that report I guess you use sysv-init instead of systemd isn't it? Maybe the SIGPIPE error is also related to that. I have to say I didn't test it on any other setup than systemd. I don't have at hand a sysv-init system, I'll try to setup one. If you are able to test your laminar with systemd tell me if your problem persist there. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#919181: status of ITP: laminar
1.0 version of laminar has being released. Based on Dmitry's work I have a package that I believe it works fine. I'm now looking for a sponsor to add upload the package to debian: https://mentors.debian.net/package/laminar/ If a DD is reading this and wants to help I'll be happy to get some help here. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#976775: RFS: laminar/1.0-1 [ITP] -- lightweight and modular continuous integration service
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "laminar": * Package name: laminar Version : 1.0-1 Upstream Author : Oliver Giles * URL : https://laminar.ohwg.net * License : GPL-3+ * Vcs : https://salsa.debian.org/meskio-guest/laminar/ Section : devel It builds those binary packages: laminard - lightweight and modular continuous integration serviceu (server) laminarc - lightweight and modular continuous integration service (client) laminar - lightweight and modular continuous integration service (metapackage) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/laminar/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/laminar/laminar_1.0-1.dsc Changes for the initial release: laminar (1.0-1) experimental; urgency=medium . * Initial release (Closes: #919181) Regards, -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#946187: ITP: starship -- any news?
I'm a happy user of starship and I will love to see it in debian. Is there any news about this package? Any blockers? Thanks for working on it. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)
Quoting Paolo Greppi (2020-03-25 11:39:01) > The previous solution was not working anymore, and in the meantime upstream > updated to v3.1.6: > https://github.com/vuejs/vue-router/releases > > I have updated it, and changed again the approach. > There is no build error anymore, but I can't guarantee that the UMD build > will work in the browser because I have no time to test it (for example in > laminar UI). > > meskio, can you test laminar with the new build ? Thanks I have tried the new build from the salsa ci[0], but laminar package doesn't work. Both firefox and chromium display a similar error in the console: vue-router.min.js:6 Uncaught ReferenceError: require is not defined at e (vue-router.min.js:6) at vue-router.min.js:6 app.js:796 Uncaught ReferenceError: VueRouter is not defined at app.js:796 I have not much knowledge on the javascript environment. But tell me if I can help somehow. Thank you. [0] https://salsa.debian.org/js-team/vue-router.js/-/jobs/629069/artifacts/browse/debian/output/ -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#919181: status of ITP: laminar
Quoting Dmitry Bogatov (2020-03-12 01:26:10) > > [2020-02-27 11:40] meskio > > Dmitry, I see the issue on vue-router.js has being solved since some > > months. But > > no movement has being happening in this ITP. Are you still interested on > > packaging it? Do you need some help? Or someone to take it over? > > > > I have updated your package to the latest laminar release (0.8): > > https://salsa.debian.org/meskio-guest/laminar/ > > If you (or somebody else) wish, go ahead, take over it. I no longer work > on Debian. Thank you for all the work you have already done. I'll try to move it forward, let's see if we get the libjs-vue-router fix uploaded. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)
Hello Paolo, Quoting Paolo Greppi (2019-10-31 18:39:16) > Hi Dmitry, I have fixed the dangling symlink in libjs-vue-route. > > It now builds locally and on Salsa CI (I enabled it for master branch as > well): > https://salsa.debian.org/js-team/vue-router.js/-/jobs/393462 > > I then rebuilt laminar from the current version at > https://salsa.debian.org/debian/laminar against this unreleased > libjs-vue-route 3.0.7+ds-3 version. > After issuing: > systemctl start laminar.service > and checking that: > systemctl status laminar.service > returns success, > the laminar service dashboard can be reached from localhost:8080 and causes > no JavaScript error. Is there anything still blocking this fix from being uploaded to unstable? Can I do something to help here? Thank you for fixing the problem. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#919181: status of ITP: laminar
Dmitry, I see the issue on vue-router.js has being solved since some months. But no movement has being happening in this ITP. Are you still interested on packaging it? Do you need some help? Or someone to take it over? I have updated your package to the latest laminar release (0.8): https://salsa.debian.org/meskio-guest/laminar/ -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)
Quoting Paolo Greppi (2019-10-31 18:39:16)
> On Sat, 14 Sep 2019 09:53:18 + Dmitry Bogatov wrote:
> > ...
> > It does not build for me. Neither it builds on Salsa CI (I added
> > debian/.gitlab-ci.yml on branch `wip').
> >
> > https://salsa.debian.org/js-team/vue-router.js/-/jobs/321533
> > --
> > Note, that I send and fetch email in batch, once in a few days.
> > Please, mention in body of your reply when you add or remove recepients.
>
> Hi Dmitry, I have fixed the dangling symlink in libjs-vue-route.
>
> It now builds locally and on Salsa CI (I enabled it for master branch as
> well):
> https://salsa.debian.org/js-team/vue-router.js/-/jobs/393462
I'm trying to build it locally to test the laminar package but it fails to
build
from the master branch of the repo (I have to say is my first time using gbp):
'''
❯ gbp buildpackage
gbp:info: Performing the build
dpkg-buildpackage -us -uc -ui -i -I
[...]
make: 'build' is up to date.
fakeroot debian/rules binary
dh binary --with nodejs
dh_update_autotools_config
dh_autoreconf
dh_auto_configure --buildsystem=nodejs
debian/rules override_dh_auto_build
make[1]: Entering directory '/home/user/dev/laminar/vue-router.js'
dh_auto_build
mkdir node_modules
ln -s /usr/*/nodejs/path-to-regexp node_modules/
NODE_PATH=debian/node_modules node build/build.js
{ Error: 'default' is not exported by
../../../../../usr/share/nodejs/path-to-regexp/dist.es2015/index.js
at Object.error (/usr/share/nodejs/rollup/src/utils/error.js:10:30)
at Module.error (/usr/share/nodejs/rollup/src/Module.js:405:17)
at handleMissingExport (/usr/share/nodejs/rollup/src/Module.js:74:21)
at Module.traceVariable (/usr/share/nodejs/rollup/src/Module.js:506:17)
at ModuleScope.findVariable
(/usr/share/nodejs/rollup/src/ast/scopes/ModuleScope.js:80:29)
at FunctionScope.Scope.findVariable
(/usr/share/nodejs/rollup/src/ast/scopes/Scope.js:70:68)
at Scope.findVariable
(/usr/share/nodejs/rollup/src/ast/scopes/Scope.js:70:68)
at Identifier.bind
(/usr/share/nodejs/rollup/src/ast/nodes/Identifier.js:50:40)
at CallExpression.NodeBase.bind
(/usr/share/nodejs/rollup/src/ast/nodes/shared/Node.js:39:23)
at CallExpression.bind
(/usr/share/nodejs/rollup/src/ast/nodes/CallExpression.js:30:31)
code: 'MISSING_EXPORT',
url:
'https://rollupjs.org/guide/en#error-name-is-not-exported-by-module-',
pos: 15,
loc:
{ file:
'/home/user/dev/laminar/vue-router.js/src/create-route-map.js',
line: 3,
column: 7 },
frame:
'1: /* @flow */\n2: \n3: import Regexp from \'path-to-regexp\'\n
^\n4: import { cleanPath } from \'./util/path\'\n5: import { assert, warn }
from \'./util/warn\'' }
rm -rf node_modules
make[1]: Leaving directory '/home/user/dev/laminar/vue-router.js'
dh_auto_test --buildsystem=nodejs
/usr/bin/node -e require\(\"./.\"\)
internal/modules/cjs/loader.js:638
throw err;
^
Error: Cannot find module './.'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at [eval]:1:1
at Script.runInThisContext (vm.js:122:20)
at Object.runInThisContext (vm.js:329:38)
at Object. ([eval]-wrapper:6:22)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at evalScript (internal/bootstrap/node.js:590:27)
dh_auto_test: error: /usr/bin/node -e require\(\"./.\"\) returned exit code 1
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit
status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -I failed
gbp:error: 'debuild -i -I' failed: it exited with 29
'''
Any idea of what I might be doing wrong? How can I build the package?
Thanks in advance.
--
meskio | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
signature.asc
Description: signature
Bug#919181: status of ITP: laminar
Quoting Dmitry Bogatov (2019-06-08 12:09:35) > [2019-06-05 21:26] meskio > > I see you submitted this ITP for laminar in January. I was wondering > > what is the status of it and if I can help with it. > > Essentially, I stalled on #927254 (in libjs-vue-router dependency). > Since I am not capable of resolving it myself, I patiently wait for > someone (presumably, from JS team) to fix it. Your help would be very > valuable. > > Current debianization of laminar in https://salsa.debian.org/debian/laminar. > Patches (no pull-requests, please) are welcome. Great, I'm happy to see that it is slowly moving forward. I hope the JS team sort it out soon. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#919181: status of ITP: laminar
Hello Dimitry, I see you submitted this ITP for laminar in January. I was wondering what is the status of it and if I can help with it. Thanks for starting the process. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#810865: infinoted: Add init script and service file
Package: infinoted Version: 0.7.1-1 Followup-For: Bug #810865 Dear Maintainer, I agree it will be really nice if this patch get merged into infinoted. I applied the patch to the latest infinoted 0.7.1-1 (beside needing to update the patch to the new Build-Depends) it works nicely. Can I do something to help in the process of getting it merged? Cheers. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.35-1.pvops.qubes.x86_64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages infinoted depends on: ii dpkg 1.19.0.5+b1 ii libc6 2.27-5 ii libdaemon0 0.14-7 ii libglib2.0-0 2.56.1-2 ii libgnutls303.5.19-1 ii libgsasl7 1.8.0-8+b2 pn libinfinity-0.6-0 ii libinfinity-0.7-0 0.7.1-1 ii libpam0g 1.1.8-3.8 ii libxml22.9.4+dfsg1-7+b1 infinoted recommends no packages. infinoted suggests no packages.
Bug#897537: tudu: FTBFS: ./configure: 394: ./configure: rmtest.c: not found
Quoting Sven Joachim (2018-05-06 21:50:57) > It seems to me this is a bug in acr 1.6.1-1. The configure script > generated by it is clearly broken, and the same tudu version built > successfully with acr 1.2-1 back in June 2017. Maybe the acr > maintainer can find out what went wrong here. I submited the bug upstream: https://github.com/radare/acr/issues/15 I'll try to fix it myself. -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#860821: tudu: Crashes with segfault when adding deadline to item
Quoting Simon Heath (2017-04-20 17:54:57) > Steps to reproduce: > > * Start "tudu" > * Hit "S" to edit the schedule for the default example item > * Hit "Enter" to save the default date > * Program crashes with a segfault. > > Changing the date before saving it doesn't seem to change this behavior. > This seems to crash no matter what item you are setting the date for. I confirm I can reproduce it. I've opened an issue on tudu's bug tracker: https://gitlab.com/tudu/tudu/issues/8 Sadly I being failing on having time for tudu for a long time, not sure if this will change soon. But I'll wellcome patches ;) -- meskio | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature
Bug#793101: Yubikey core error: no yubikey present
Package: yubikey-personalization Followup-For: Bug #793101 I just found out that my yubikey is a U2F-only key and the yubikey-personalize tool can't be used with it: https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/#toggle-id-10 I'm not sure if is the same case for the original publisher of this bug, as his usb-id is not the same than mine. Sorry for the noise.
Bug#793101: Yubikey core error: no yubikey present
Package: yubikey-personalization Version: 1.17.2-1 Followup-For: Bug #793101 Dear Maintainer, I see the same issue in my system. U2F works fine in chromium (I did modify udev to give me rights no the device, but this is a different bug). I'm failing on making OTP to work. All the yk* tools tell me the same: # ykinfo -v Yubikey core error: no yubikey present I tryed to compile yubikey-personalization from the git repo (using libyubikey from debian) and I see the same problem. So I'm starting to think is not a debian specific issue. Might it be a problem on my system? Or a bug in upstream? My lsusb output: Bus 001 Device 069: ID 1050:0120 Yubico.com Yubikey Touch U2F Security Key Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1050 Yubico.com idProduct 0x0120 Yubikey Touch U2F Security Key bcdDevice4.18 iManufacturer 1 Yubico iProduct2 Security Key by Yubico iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 30mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 34 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 2 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages yubikey-personalization depends on: ii libc6 2.19-22 ii libjson-c2 0.11-4 ii libusb-1.0-0 2:1.0.20-1 ii libykpers-1-1 1.17.2-1 ii libyubikey01.13-1 yubikey-personalization recommends no packages. yubikey-personalization suggests no packages. -- no debconf information
