Bug#736384: openrc: does not umount filesystems during reboot/shutdown
Package: openrc Version: 0.12.4+20131230-7 Severity: normal Hey, OpenRC does not umount filesystems cleanly. There is only one /etc/init.d/transit which calls reboot/halt stop in start(), but umountfs, umountfsroot or umountnfs.sh are not handled at all. They are not even in the shutdown runlevel: $ rc-update | grep shutdown killprocs | recovery shutdown savecache | shutdown transit | shutdown umountfs, etc. cannot be added to the default runlevel, so that it get "start" with no-op and get stopped when leaving the runlevel. Because there are not enough dependency information in the LSB headers of these scripts. Therefore umountfs, etc. should be added to the shutdown runlevel. OpenRC needs to be patched so that upon "start" action from OpenRC, actually "stop" action in the LSB script is executed. Dependency tree of Required-Stop and Should-Stop also need to be handled (now ignored by lsb2rcconf of OpenRC). Or, alternatively, we could trick OpenRC into believing those scripts in shutdown runlevel are "started" (or by actually starting them, they are no-op anyway) and let it issue "stop" to all of them, in this case, no tweaking of the dependencies is needed. Benda -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) 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 Versions of packages openrc depends on: ii insserv1.14.0-5 ii libc6 2.17-0experimental2 ii libeinfo1 0.12.4+20131230-5 ii librc1 0.12.4+20131230-5 openrc recommends no packages. openrc 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#684396: /sbin/rc upstream renaming
Forworded: https://bugs.gentoo.org/show_bug.cgi?id=493958 zigo@d.o uploaded openrc once and it is rejected by ftpmaster for the name conflict of /sbin/rc with plan 9 rc[1]. Upstream is considering renaming rc to openrc: https://bugs.gentoo.org/show_bug.cgi?id=493958 1. http://packages.debian.org/wheezy/rc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684396: porting OpenRC to GNU/Hurd
Dear Marko, Thank you very much for your support. The packaging is mostly finished. We are working on the naming conflicts of /sbin/rc (with plan 9 rc) and /sbin/runscript (with minicom) with upstreams. One important item on our TODO list is porting OpenRC to GNU/Hurd. Bill Wang (freecnpro in the Cc list) had some unsuccessful trials last month. Are you interested in it? Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684396: runscript name conflict with minicom
Forwarded: https://alioth.debian.org/tracker/index.php?func=detail&aid=314541 FYI. I have raised the issue with minicom upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734371: lsb.pl not accessible?
Dear Klaus, Thank you for trying OpenRC out on Debian and sorry for the trouble. The bug is strange and I could not reproduce it on a box of single /. lsb.pl is used to convert from LSB init scripts to a set of shell declarations that OpenRC could understand, which is crucial in the second earliest boot stage of OpenRC. The error message indicates that lsb.pl is not accessible from /lib/rc/sh/gendepends.sh. Could you please paste the output of `dpkg -L openrc`, especially the location of lsb.pl? BTW, before the reboot, did openrc install well? If so, it has "rc-update -u" executed in postinst, which calls lsb.pl without a problem. I suspect /lib/rc/bin/lsb.pl is not yet mounted during early boot. But given /lib/rc/sh/gendepends.sh, at least /lib/rc is mounted. the source of the bug is out of my imagination now.. BTW++, the version 0.12.4+20131230-4 will soon be in the mirrors. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734371: perl is inside /usr/bin
Dear Klaus, I figured out the cause: perl, by which lsb.pl is written, is inside /usr. Roger has expressed this concern before. I did not take it seriously at that time. Now it bites us.. We should rewrite lsb.pl with POSIX shell or even C, or rely on functions from insserv (which has a LSB parser) to get rid of this extra dependency on perl. @Roger, is it easy to borrow the LSB parser from insserv? For the moment, you could have an ugly hack to copy a subsystem of perl over /. > I would like to see a working init (and rc) system in future debian as > an alternative to the broken design of upstart and systemd. So I have > a high interest in this package. Great, I have exactly the same motivation. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686924: Taking over the packaging
Hey Gijs, Gijs Molenaar writes: >>> you can give me access to your maintenance tree, but I don't know if >>> I'll do much - since we already have our solution for the short term. >> >> Alright, so I won't give you the access this time. Ole and I was >> discussing about moving the packaging repo back to alioth. You are >> welcomed to join at that time. It'll happen within a month. I have moved to casacore pkg repo under the umbrella of debian-astro project. https://alioth.debian.org/projects/debian-astro/ I see you are already in the member list, so access granted. Would you like to merge the repos into it also? https://github.com/ska-sa/casacore-debian could mostly be superseded by Ole's finer partition of sub-packages, IMHO. For https://github.com/ska-sa/casacore-data-debian, >>> One of the problems is the measures data package, which I name >>> casacore-data. There doesn't seem to be a central place where this data >>> is available in a consistent and versioned way. What we do now is just >>> update the package manually from time to time. I'm curious what your >>> approach is for tacking this problem. >> >> I am also worried about this piece of data. And what license is it? >> (hey, is it really LGPL?[2])I couldn't find any statements in the >> tarball. For packaging we may provide a script for the users to download >> by themselves, like how we dealt with the proprietary drivers in Debian. > > I’m not sure, but I believe I asked it and they said that. But I can’t > find the email. So let's pack it LGPL and put it into debian-astro, too? >> Another problem is that casacore needs to use this piece of data for its >> unittests, which is suspected to fail from the updates of measures >> data[1]. I have no idea right now. > > I prefer the packaged solution, I don’t trust the astron FTP > server. I’ve been in contact with the maintainers of the tarball, but > that discussion got sort of stuck also. They can’t really promis much. > > I think it is important that there is a good and trusted measures_data > archive somewhere, always, but that seems to be quite difficult. No problem. Once we get it packaged, the world will mirror it for us :) PS, casacore-1.7 gets release, and 2.0 soon http://code.google.com/p/casacore/issues/detail?id=58#c5 Cheers, Benda
Bug#739703: question about reverting
Dear Gabriele, Thanks for trouble shooting it and glad to see that you found the offending commit. For your revertion of d0ce84fa4a74d2d in the git repo, could you please explain how exactly the lsb-deps-on-"all" change caused this bug? Instead of simply reverting it, I would like to understand the underlying problem. The lsb-deps-on-"all" trick does good to all other arches, so I want to keep and refined it to let it work on Hurd, too. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686924: Taking over the packaging
Dear Ole Streicher, Thank you very much for the initial work! I managed to clone out the repo[1] before you decided to delete it. We are packaging casacore 1.6.0 [2] basing on your work, under the project of AireLinux[3], a working-in-progress debian-based distribution for astrophysics initiated by Tsinghua Center for Astrophysics[4]. If you canceled the packaging for lacking of manpower, we sincerely ask you to consider rejoining (or taking lead of) the effort. We have talented astrophysics students with *nix system administration experience getting recruited for packaging of the start-of-art tools. Also, feel free to mentor and review our progress if your time is limited. Besides, casacore is in the gentoo official tree brought by the gentoo-science team[5], from which many distribution-level patches could be borrowed. We are only a few steps away from the final upload. Let's give it a kick, shall we? Cheers, Benda 1. http://anonscm.debian.org/gitweb/?p=debian-science/packages/casacore.git 2. http://sourceforge.net/p/aire/casacore 3. http://www.airelinux.org 4. http://www.thca.tsinghua.edu.cn 5. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sci-astronomy/casacore/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579924: ITP: iptraf-ng -- Interactive Colorful IP LAN Monitor
Dear all, I'd like to vote for it. It would be very nice to have iptraf-ng, as we need statistics in ipv4 and ipv6 separately for an interface. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684396: ITP: openrc -- alternative boot mechanism
Dear Guys, Thanks a lot for the input from Marco d'Itri, Holger Levsen and Thomas Goirand, as well as Aron Xu off list. m...@linux.it (Marco d'Itri) writes: > openrc was recently discussed on debian-devel@ and there was a large > consensus that it is not a credible alternative to upstart and systemd. I think you are referring to this thread http://lists.debian.org/debian-devel/2012/04/msg00547.html > We do not need to be able to choose among multiple init > implementations. Holger Levsen writes: > while we (thankfully) have 42++ window managers in Debian, we only > have 5 (or so) init systems and certainly more alternatives will be > welcomed by many people, thriving to develop the best OS... whatever > that means ;-) The topic of if OpenRC suits Debian is still controvasial. That's understandable. Besides, even in Gentoo community, there is voice doubting if OpenRC suits Gentoo. Debian is about the freedom to choose. I am aware of systemd, upstart, and our good plain sysv-rc as well as file-rc. People in the last thread already debated about which is the best for Debian. Personally I like the unix way[1] of OpenRC to do things, and I want to let people understand my opinion by inviting Debian users to use, evaluate and criticize it. Cool jobs are done in Redhat community/enterprise, in Ubuntu community/enterprise. Thanks to them we have many choices to suit our needs. OpenRC from Gentoo community would like also serve as your choice, with a different styple: just do one thing and do it right, not about revolution to blow your mind. Thanks Marco d'Itri, I have carefully reflected whether introducing OpenRC to Debian really worth my time and effort. And I decided to do so. Let's have fun guys ;) Yours, Benda 1. http://en.wikipedia.org/wiki/Unix_philosophy pgpWkWshrC97b.pgp Description: PGP signature
Bug#679806: scim-pinyin: A patch to let scim-pinyin work for gtk3 and latest scim
Dear all, I have integrated the patch to the source in Squeeze. The updated package was uploaded to mentors[1]. Please consider readopt it by mentoring to process. Cheers, Benda 1. https://mentors.debian.net/package/scim-pinyin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679806: scim-pinyin-0.5.92 uploaded to mentors
Dear Ximin, Thanks a lot for your inputs. I have version bumped scim-pinyin to 0.5.92, which includes tzhuan's patch upstream. Lintian warnings were killed. Please have another look: https://mentors.debian.net/package/scim-pinyin @Ming Hua, are you still interested in maintaining this package? @Aoki-san and Anthony, would you like to help upload the revised package? If it is okay, I'd like to produce a patch against git://git.debian.org/collab-maint/scim-pinyin.git Thanks a lot dudes. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709965: package being reintroduced
Hi, scim-pinyin has been removed from Debian. There is ongoing effort to get this reintroduced (bug #679806). However it is unlikely to be found in wheezy soon. Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708483: RFS: scim-bridge-el/0.8.2-2 [ITP]
Package: sponsorship-requests Severity: normal Dear Maintainer, * scim-bridge-el was removed together with scim-bridge (bug #642371) At the same time, scim-bridge is integrated into scim upstream and appears as scim-im-agent: http://packages.debian.org/sid/scim-im-agent * I have updated the dependence, included a patch against newest scim-bridge-el 0.8.2. The resulting package is uploaded to mentors for reviewing: https://mentors.debian.net/package/scim-bridge-el And filed an ITP bug at #705978. * I am looking forward to getting this package included in Debian again. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708485: RFS: scim-pinyin/0.5.92-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scim-pinyin" Package name: scim-pinyin Version : 0.5.92-1 Upstream Author : Tz-Huan Huang , James Su URL : http://sourceforge.net/projects/scim/ License : GPLv2 Section : utils It builds those binary packages: scim-pinyin - smart pinyin IM engine for SCIM platform To access further information about this package, please visit the following URL: http://mentors.debian.net/package/scim-pinyin Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/scim-pinyin/scim-pinyin_0.5.92-1.dsc More information about scim-pinyin can be obtained from https://github.com/scim-im/scim-pinyin. Changes since the last upload: * Switch to dpkg-source 3.0 (quilt) format. * New upstream release. (Closes: #679806) Regards, Benda Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679806: scim-pinyin-0.5.92 uploaded to mentors
Hi Ximin, Ximin Luo writes: > Sorry, ignore this, I missed the fact that scim and scim-pinyin are separate > upstream packages. Your versioning is fine. Okay. >> 2. Please upload your PGP key 0xDFBE5F8B into the public keyservers. >> Otherwise >> I cannot verify your signature. Thanks. I'll do that later. >> Also note that I do not have Debian Developer / Maintainer access, so we will >> need to find someone else to sponsor your package. But I can do a >> code review. > > I have tested your package and it works well. Thanks! I looked over your > changes to debian/** and everything looks good - especially that you > simplified > debian/rules and formatted debian/copyright correctly. It's definitely a > significant improvement and follows the Debian standards well. :) > > I'll try to get a DD/DM to sponsor this over the coming days. I have joined pkg-ime team[1] and received sponsorship from Osasu-san. The package is already in the upload queue[2]. However not processed by ftp-masters for more than a month. I'll ping ftp-masters for it. Cheers, Benda 1. https://alioth.debian.org/projects/pkg-ime/ 2. http://ftp-master.debian.org/new/scim-pinyin_0.5.92-1.html pgpaknOHQTMtD.pgp Description: PGP signature
Bug#684396: openrc packaging status (Re: Survey answers part 3: systemd is not portable and what this means for our ports)
Dear Guys, Holger Levsen writes: > one which is at least installable with apt-get + sid sources. that's > still not the case, despite 684396 being announced here a year ago. (Replying generally) There seems to be some doubts concerning why #684396 has taken a whole year without being finished. This fact is quoted by people to infer OpenRC is not serious and not for production. They are two things and should not be mixed. I am only going to respond to the first question here. On my side, I am offering to package OpenRC. I did not have a deep understanding of Debian packaging and learnt as I went, although I myself had been a user for 10 years. (My servers are Debian and Gentoo, laptop/desktops are Debian.) I was not in a hurry. After composing a wiki page[1] and having all my Debian boxes with OpenRC, I just spent a bit more time to evaluate the solution by actually using it for my own daily life and production. And yeah, it's partially because of laziness. I haven't seen people ping this bug and thought there is not a wide audience so I took my own pace. I don't think we are in a race with systemd. It feels that people developing or supporting systemd are competing against the world, as if they can dominate the community by rolling out more modern features, advancing fast enough, pushing others hard and finally rendering everything alternative into the museum. This is a nice commercial strategy and is more likely to succeed in competition. But I don't care about it. Things changed when it evolves into a GSoC project, where we have a student actively working on it. It becomes my duty to co-mentor with Thomas to realize the ITP. We are gaining momentum after the student, Bill Wang, has digested the basics. I can visualize that within two months we will have a off-the-shelf OpenRC package working with initscripts/sysvinit vanilla offering modern features like cgroups, at users' choice. Voice from upstream, the OpenRC team is well aware of the effort and is eager to take patches necessary to support Debian, provided it can both benefit Debian and Gentoo, as is often the case when we come down to this level of OS. Relax fellows. let's see what we can get and have fun. Cheers, Benda 1. http://wiki.debian.org/OpenRC pgpdtcd0579E5.pgp Description: PGP signature
Bug#714039: [Pkg-sysvinit-devel] Bug#714039: initscripts: Require-Start problem
Dear Petter, Petter Reinholdtsen writes: > This seem to be the wrong approach to handle $all, at least the way I > understand $all. $all is the set of enabled init.d scripts except those > that depend on $all, not every file in /etc/init.d/. "enabled init.d scripts" in the same runlevel or all runlevels? Yeah, but do that will require more code than a sinple globbing :D > The approach you have selected will fail with scripts having a > dependency graph like this > > foo <- $all <- bar <- baz > > foo do not depend on $all, while bar do, and baz depend on bar. Note > that insserv also give a strange ordering on this setup, as $all is > taken to mean order script at current end sequence number +1, and > dependencies for scripts depending on scripts depending on $all are > really ignored. > > So the dependency ordering listed above will with insserv end up with > > S01foo > S03baz > S04bar > > Note that the sequence number 02 that bar would have used if it wasn't > for the $all dependency is empty. > It is the reason why I recommend not using the $all dependency at all. Excuse me, I fail to see the validity of this example. In, http://wiki.debian.org/LSBInitScripts, , | $all facility supported by insserv to start a script after all the | other scripts, at the end of the boot sequence. This only work for | start ordering, not stop ordering. It is not possible to depend on a | script which depend on $all. ` it is clearly said baz depending on bar is not possible. > It is the reason why I recommend not using the $all dependency at all. We have rc.local using it already. And we need to handle it. We can manually map Require-Start to Should-Start in OpenRC, while I do still think it should be written like that to be more logical. Anyway, we lose nothing in insserv by making this change, do we? > I assume systemd and upstart handle $all differently... :) not sure ;) Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679806: scim-pinyin-0.5.92 uploaded to mentors
Hi, Ximin Luo writes: > Some more obvious changes: > - the debian/copyright file in the upload queue is still in the old format. > - there are lintian warnings; there are no warnings for the mentors version > > I'd suggest you cancel the one in the current queue (if that's possible) and > have your sponsors upload from mentors directly. Thank you. The one in ftp queue was canceled. I have upload the correct version in http://anonscm.debian.org/gitweb/?p=collab-maint/scim-pinyin.git and waiting for Osamu-san to upload. Cheers, Benda pgpSxuIUqNoz3.pgp Description: PGP signature
Bug#679806: marked as done (ITP: scim-pinyin -- smart pinyin IM engine for SCIM)
Wow! Thank you Aoki-san! This is the first time I see a package on which I spent a lot of effort get included in Debian, after being a Debian user and administrator for 10 years. It feels marvellous! I am really encouraged :) Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714039: initscripts: Require-Start problem
Dear Petter, >[Bill Wang] >> I think that should be #Should-Start, because #Require-Start: $all >> will have a serious impact on OpenRC(maybe there are other init >> systems). > Can you explain a bit more? The way I understand $all, it is the set > of all the available scripts without a relationship on $all, thus the > dependency will always be available and there is no way it can fail to > have its dependency available. According to LSBInitScripts page[1], there is a definition of Should-Start being weak dependence along with a recommendation to be used with virtual facility names (e.g. $all). Required-Start states that a facility *must* be available. $all only means for start ordering, which is a weak dependence. Therefore using Should-Start instead of Required-Start is more logical. > Is OpenRC understanding it differently? What problem will OpenRC > users experience? In OpenRC we developped a method globbing /etc/init.d/* to construct $all, which results in /etc/init.d/README to be pulled in. A strong dependence will fail if README is not a init script, while a weak one will not. Considering the logical arguments above, we think the most straightforward fix would be replacing "Required-Start: $all" with "Should-Start: $all". Cheers, Benda 1. http://wiki.debian.org/LSBInitScripts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686924: [RFS] casacore-1.7.0 uploaded to mentors
Dear all, Casacore has been updated to 1.7.0 and tracked at https://anonscm.debian.org/cgit/debian-astro/packages/casacore.git It has also been uploaded to mentors at https://mentors.debian.net/package/casacore http://mentors.debian.net/debian/pool/main/c/casacore/casacore_1.7.0-1.dsc I would like to ask the astronomy team to review the package, especially the package names and descriptions, and the copyright part which I am not quite sure. Otherwise it is ready be uploaded together with casacore-data (ITP #761146, the other email). Thanks go to Ole Streicher for his early work and Chuan Peng for his documentation effort. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761146: casacore-data uploaded to mentors.debian.net
Dear all, I have adopted casacore-data from Gijs Molenaar's version and set up a git repo at debian-astro @ alioth. https://anonscm.debian.org/cgit/debian-astro/packages/casacore-data.git A built version is uploaded to mentors, http://mentors.debian.net/package/casacore-data http://mentors.debian.net/debian/pool/main/c/casacore-data/casacore-data_0+20140610-1.dsc This package is needed by casacore at build (for test) and run time. The main concern is the license. Gijs has contacted upstream and was told the data were released as LGPL. It would be nice if the email could be referred to. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768394: [Pkg-oss4-maintainers] Bug#768394: oss4-dkms: module FTBFS for Linux 3.16: endian.h: No such file or directory
Hello Andreas, Andreas Beckmann writes: > during a test with piuparts I noticed your package failed to build a > module for linux-3.16-3-amd64: > > DKMS make.log for oss4-4.2-build2010 for kernel 3.16-3-amd64 (x86_64) > Fri Nov 7 01:14:30 UTC 2014 > make: Entering directory '/usr/src/linux-headers-3.16-3-amd64' > Makefile:10: *** mixed implicit and normal rules: deprecated syntax > make[1]: Entering directory `/usr/src/linux-headers-3.16-3-amd64' > CC [M] /var/lib/dkms/oss4/4.2-build2010/build/core/oss_core.o > In file included from > /var/lib/dkms/oss4/4.2-build2010/build/core/oss_core.c:42:0: > /var/lib/dkms/oss4/4.2-build2010/build/core/audio_core.h:3:20: fatal error: > endian.h: No such file or directory > #include > ^ > compilation terminated. > /usr/src/linux-headers-3.16-3-common/scripts/Makefile.build:262: recipe for > target '/var/lib/dkms/oss4/4.2-build2010/build/core/oss_core.o' failed > make[3]: *** [/var/lib/dkms/oss4/4.2-build2010/build/core/oss_core.o] Error 1 > /usr/src/linux-headers-3.16-3-common/Makefile:1350: recipe for target > '_module_/var/lib/dkms/oss4/4.2-build2010/build/core' failed > make[2]: *** [_module_/var/lib/dkms/oss4/4.2-build2010/build/core] Error 2 > Makefile:181: recipe for target 'sub-make' failed > make[1]: *** [sub-make] Error 2 > Makefile:8: recipe for target 'all' failed > make: *** [all] Error 2 > make: Leaving directory '/usr/src/linux-headers-3.16-3-amd64' Thank you. I couldn't reproduce it on my amd64 box with linux-3.16-3. The error message suggests a missing header of endian.h, which is in libc6-dev:amd64: /usr/include/endian.h libc6-dev is pulled in by build-essential and dkms. It might turn out to be a bug of piuparts. I will set up a working piuparts to find it out. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766151: [PKG-OpenRC-Debian] Bug#766151: openrc: tor service fails to start
Ritesh Raj Sarraf writes: > On Tuesday 21 October 2014 01:35 PM, Ritesh Raj Sarraf wrote: >> tor |/lib/rc/sh/runscript.sh: 274: exec: /bin/bash: >> not found >> tor | * ERROR: tor failed to start > > The tor service works if the init script interpreter is changed from > /bin/bash to /bin/sh, with /bin/sh symlinking to /bin/dash This seems to be a bug of tor. Besides, do you have /bin/bash on your system? b pgpI6phGITlQ5.pgp Description: PGP signature
Bug#763041: "waiting for /dev to be fully populated." takes a long time
I can confirm these bugs with udev-215 and sysvinit-core in jessie. udev takes a long time to settle. It takes more than 20 seconds to probe the other partitions, like shown in the dmesg: [ 11.333067] Bluetooth: HCI device and connection manager initialized [ 11.333077] Bluetooth: HCI socket layer initialized [ 11.333079] Bluetooth: L2CAP socket layer initialized [ 11.333092] Bluetooth: SCO socket layer initialized [ 11.380806] usbcore: registered new interface driver btusb [ 11.426459] usb 2-1.4.3: New USB device found, idVendor=046d, idProduct=c246 [ 11.426465] usb 2-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 11.426469] usb 2-1.4.3: Product: Gaming Mouse G300 [ 11.426472] usb 2-1.4.3: Manufacturer: Logitech [ 11.428454] input: Logitech Gaming Mouse G300 as /devices/pci:00/:00:1d.7/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/0003:046D:C246.0005/input/input9 [ 11.428659] hid-generic 0003:046D:C246.0005: input,hidraw4: USB HID v1.10 Mouse [Logitech Gaming Mouse G300] on usb-:00:1d.7-1.4.3/input0 [ 11.433207] input: Logitech Gaming Mouse G300 as /devices/pci:00/:00:1d.7/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/0003:046D:C246.0006/input/input10 [ 11.433509] hid-generic 0003:046D:C246.0006: input,hiddev0,hidraw5: USB HID v1.10 Keyboard [Logitech Gaming Mouse G300] on usb-:00:1d.7-1.4.3/input1 [ 39.205197] Adding 7787104k swap on /dev/sda4. Priority:-1 extents:1 across:7787104k FS [ 39.234284] EXT4-fs (sda3): re-mounted. Opts: (null) [ 39.643669] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro [ 40.068194] lp: driver loaded but no devices found [ 40.148968] ppdev: user-space parallel port driver [ 40.431468] loop: module loaded changing udev log level to err "solves" the problem, as suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763041#30 diff --git a/udev/udev.conf b/udev/udev.conf index efe4ff4..61572a2 100644 --- a/udev/udev.conf +++ b/udev/udev.conf @@ -3,4 +3,4 @@ # udevd is started in the initramfs, so when this file is modified the # initramfs should be rebuilt. -#udev_log="info" +udev_log="err" I suppose it is because >=udev-208 assumes a systemd-driven log buffer to write into. Otherwise the log messages accumulate too fast at "info" level, resulting in a timeout. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765785: remove the dangling rc.d links
Hi Adam, Thank you for reporting the bug. Removing the dangling links could be done manually: find -L /etc -type l # to confirm the broken links to remove find -L /etc -type l -delete # to remove them OpenRC postint script should not exit with error in this case, though. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763681: [PKG-OpenRC-Debian] 2 RC bugs in openrc
Hello Ritesh, Ritesh Raj Sarraf writes: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763681 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765785 > > > We have 2 RC bugs in openrc at this time. Any plans on how we want these > fixed ? In the lastest commit 8a876c89a http://anonscm.debian.org/cgit/openrc/openrc.git/commit/?id=8a876c89a circumvented bug 763681, and got tested on armhf successfully. Would you please upload openrc_0.13.1-4? Because it is in a critical time window for jessie freeze. Anyone with an upload privilege, please, help upload this openrc_0.13.1-4 as soon as possible. To build from the git repository, $ git clone git://git.debian.org/git/openrc/openrc.git $ git-buildpackage $ ls ../build-area/openrc_0.13.1-4_amd64.changes $ (... upload ...) Cheers, Benda pgp7kYhmlYqNx.pgp Description: PGP signature
Bug#739703: question about reverting
Hey Gabriele, Any update on this? I will try to reproduce the bug by myself. Otherwise, I intend to cancel the revert if there is no definite reason. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763681: openrc: FTBFS[armel, armhf, ppc64el]
Thanks Julián, Julián Moreno Patiño writes: > Package: openrc > Version: 0.12.4+20131230-9 > Severity: serious > > openrc 0.12.4+20131230-9 FTBFS on armel,armhf and ppc64el: > https://buildd.debian.org/status/package.php?p=openrc > > * Checking hidden functions in librc.so ... * Checking trailing > whitespace in code ... [ ok ] > * Checking trailing newlines in code ... [ ok ] > * Checking for obsolete functions ... [ ok ] > * Checking for x* func usage ... [ ok ] > * Checking spacing style ... [ ok ] > * Running unit tests > * is_older_than ... [ ok ] > make[3]: *** [test] Error 1 > make[2]: *** [test] Error 2 > make[1]: *** [test] Error 2 > dh_auto_test: make -j1 test returned exit code 2 > make[3]: Leaving directory `/«BUILDDIR»/openrc-0.12.4+20131230/src/test' > make[2]: Leaving directory `/«BUILDDIR»/openrc-0.12.4+20131230/src' > make[1]: Leaving directory `/«BUILDDIR»/openrc-0.12.4+20131230' > make: *** [build-arch] Error 2 Interesting. Gentoo has OpenRC well tested for arm(hf,el,eb) and ppc(32,64). http://packages.gentoo.org/package/sys-apps/openrc I guess the build system could not recognize keywords like armel, armhf or ppc64el. Hmm, it fails with the unit tests, could be the loop solver also. Thomas, do you have time to take a look? I don't have an account for the porterboxes. Best, Benda
Bug#750559: another circular dependency
The following was what we had in a long IRC discussion.
This is another circular dependency caused by a difference between LSB
script and OpenRC counterpart:
LSB header defines Required-{Start,Stop}, but OpenRC has only one "need"
relation.
In this special case,
hwclock [Required-Stop $local_fs] umountfs
hwclock [X-Start-Before] checkroot
cryptdisks [X-Stop-After] umountfs
cryptdisks [Required-Start] checkroot
So by merging relations of start and stop during the interpretation from
LSB to OpenRC, as what we are doing now, introduces a circular
dependency.
hwclock uses> umountfs after> cryptdisks need> checkroot after> hwclock
hwclock is screwed by itself. It should be started before fsck, because
the latter needs a clock; It should be stoped before umount (from
$local_fs), because it needs to write the clock offset to local
disk. And $local_fs naturally depends on fsck.
Our present method of breaking dependency loops fails in cases like
this.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750559: [PKG-OpenRC-Debian] Installing openrc
Dear Ritesh, Ritesh Raj Sarraf writes: > I tried OpenRC some time ago and ran into some problems. I did file a > bug report here. > Bug#750559: openrc: breaks boot if extra crypto devices are present May I ask if you have time to test the set up again? On Jan 27, we have introduced an "off" runlevel, which handles umountfs better, so that hwclock works by default. http://metadata.ftp-master.debian.org/changelogs/main/o/openrc/unstable_changelog Thanks, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768394: NMU Upload of oss4
Dear Tobias, Thank you very much for the NMU. It really helps! Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563011: My iPod Touch can't be seen by ifuse
Hi, My iPod Touch is 3G 32GB (firmware 3.1.3). [ 1850.520066] usb 1-1: new high speed USB device using ehci_hcd and address 3 [ 1850.657886] usb 1-1: New USB device found, idVendor=05ac, idProduct=1299 [ 1850.657891] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1850.657895] usb 1-1: Product: iPod [ 1850.657898] usb 1-1: Manufacturer: Apple Inc. [ 1850.657901] usb 1-1: SerialNumber: 0f74cdea0974133d2e6a86f4815ad2df02733b1b [ 1850.658875] usb 1-1: configuration #1 chosen from 3 choices x2:~$ sudo ifuse /media/iPod/ --root No device found, is it connected? If it is make sure that your user has permissions to access the raw usb device. If you're still having issues try unplugging the device and reconnecting it. x2:~$ sudo ifuse /media/iPod/ --root -u 0f74cdea0974133d2e6a86f4815ad2df02733b1b No device found, is it connected? If it is make sure that your user has permissions to access the raw usb device. If you're still having issues try unplugging the device and reconnecting it. How can I further debug it? Yours, -- XU Benda Research Center for Neutrino Science Department of Physics Tohoku University JAPAN http://www.awa.tohoku.ac.jp/~benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#577793: libboost1.42-doc: System Jamfiles not strictly needed (duplicating #452410)
Package: libboost1.42-doc Version: 1.42.0-3 Severity: normal Now /usr/share/doc/libboost1.42-doc/examples/libs/python/example/tutorial/ cannot build because debian don't ship System Jamfile. However, this bug is fix in #432410[1] for libboost1.38-doc[2]. I don't know why the fix did not apply to libboost1.42-doc. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;bug=452410 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=452410 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core) 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/bash libboost1.42-doc depends on no packages. libboost1.42-doc recommends no packages. Versions of packages libboost1.42-doc suggests: ii libboost1.42-dev 1.42.0-3 Boost C++ Libraries development fi -- 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#567491: xterm randomly ignores input after this error
Hi, I am also facing this error. My xterm randomly ignores input after upgrade. I don't know if it is related to this. Yours, -- XU Benda Research Center for Neutrino Science Department of Physics Tohoku University JAPAN http://www.awa.tohoku.ac.jp/~benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567600: ghemical should depend on xfonts-75dpi
Hi Nicholas,
Thank you for your reply.
Nicholas Breen writes:
> Packages must not depend on any fonts package[1], it's a serious policy
> violation.
How about a recommend, according to the policy?
> xfonts-75dpi and -100dpi are part of the standard X installation ("xorg"
> metapackage); it's possible to uninstall them, but that should only be done if
> you're running a remote font server. Any X setup that doesn't provide those
> fonts is already broken.
This is kind of personal taste. Xorg metapackage is not clean enough.
Yours,
--
XU Benda
Research Center for Neutrino Science
Department of Physics
Tohoku University
JAPAN
http://www.awa.tohoku.ac.jp/~benda
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567637: I can confirm this bug
Hi, I can confirm this bug. After upgrading, my NTFS partition can not be recognized: # update-grub2 head: cannot open `/boot/grub/video.lst' for reading: No such file or directory Generating grub.cfg ... Found linux image: /boot/vmlinuz-2.6.32-trunk-686 Found initrd image: /boot/initrd.img-2.6.32-trunk-686 Found Microsoft Windows XP Professional on /dev/sda4 /usr/sbin/grub-probe: error: unknown filesystem. done Cheers, -- XU Benda Research Center for Neutrino Science Department of Physics Tohoku University JAPAN http://www.awa.tohoku.ac.jp/~benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
