Bug#925577: Intermediate fixup
As an intermediary fix for those that just want to listen to their music... (which does not fix the actual bug ;) ) Change the Service Type to 'simple' instead of forking and remove the '--daemon' argument from ExecStart, aka resulting file: /lib/systemd/system/shairport-sync.service ``` [Unit] Description=ShairportSync AirTunes receiver Documentation=man:shairport-sync(7) Documentation=file:///usr/share/doc/shairport-sync/README.md.gz Documentation=https://github.com/mikebrady/shairport-sync After=sound.target Requires=avahi-daemon.service After=avahi-daemon.service [Service] Type=simple Restart=on-failure EnvironmentFile=-/etc/default/shairport-sync ExecStart=/usr/bin/shairport-sync $DAEMON_ARGS User=shairport-sync Group=shairport-sync PIDFile=/run/shairport-sync/shairport-sync.pid [Install] WantedBy=multi-user.target ``` Then: systemctl daemon-reload and: /etc/init.d/shairport-sync start Voila, music works again ;) This works as apparently only daemon mode is affected. Greets, Jeroen
Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility
On 2016-10-10 00:13, Axel Beckert wrote: [..] > Probably Fiber7 by Init7 > which also already provides the SixXS PoP I'm using now, so I have an > idea of how their IPv6 connectivity is about. But iWay is also > thinking about offering static IPv6 on Fiber, so that would be another > choice. Did you call any of these? > The only one offering FTTH > connectivity there is Unitymedia (as carrier as well as ISP). That is not FIBER. That is DOCSIS link with "Fiber in the core network", you know, how most of the Internet is actually connected in the long haul. As long as there no ONT in your room, you are not getting actual Fiber, you are getting DOCSIS for getting it in the house. That is simply cable service. [..] > I explicitly asked, too, if they offer DS-Lite like UPC in Switzerland > does and they denied. Maybe you should check their website, or the user forums. You'll find lots of people who are forced to use it. >> How often did you really call? > > "Call" as in using the telephone you mean? Never. *g* But kidding > aside. I asked twice so far: The trick is that when you call you are talking to a person. When you are talking to a person, that costs the company support costs as they have to pay that person. That person then logs an item "customer asked for IPv6". The more people do that, the more often they know "oh, they really want IPv6". As long as people do not call, which you could have been doing in the last decade and more, they will not know that their customers want IPv6. Hence, you are part of the problem. Doing a 'chat' allows one person to handle 50 customers at the same time, they do not tally that as it does not matter in cost. Talking though, that consumes a telephone line and a person: costs more. Guess what is the biggest cost for an ISP moving to IPv6? People or upgrading hardware? We (SixXS) cannot keep on telling people to call their ISPs. We have done our task: we made it possible for well over 15 years to let people try and use IPv6, figure out how to transition, figure out what the problems are. That the users are lazy and never bothered to Call their ISP, is not something we can solve. And no, we are not going to be bigger annoyances about it to ask people to click on a link in an email every week or something else. People already hate it enough that we are shutting down something they have been receiving for free. Greets, Jeroen
Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility
On 2016-10-10 10:31, Mike Gabriel wrote: [..] > Furthermore, I quite like taking my IPv6 IP with me on mobile devices > (at the moment, I use VPN for that, though). Plus having a static IPv6 > IP at home (although my ISP assigns dynamic prefixes to my DSL landline > link). Sounds like you already found what you really need: a VPN. > And: I fully support the Call-your-ISP initiative. Did you Call Your ISP then? > But, as long as major providers e.g. like DigitalOcean are not capable > of managing IPv6 properly [1], a value like Sixxs is highly appreciated!!! Or you could chose with your money and find an ISP that properly provides the service that you are paying for. It is 2016. IPv6 testing and transition has been going on for too long and too many companies that are receiving your money won't be budging as they get away with it as long as you keep on using third party services. One really has to wonder what kind of reliability people want when they use a 3rd party for connectivity, while giving another lots of money while they do not provide the service they actually want. >>> It is 2016. SixXS won't be around for much longer to provide free >>> connectivity > > Can you give any info on estimated end of service? Please read https://www.sixxs.net/news/ All SixXS users got an email about this. There is a reason why we ask to Call Your ISP. You did not call, did you? Yeah, not a problem we cannot solve. >> Yes, but until SixXS closes down, we want and need aiccu maintained >> properly in Debian. >> >>> Hence, better to stop wasting your time: Go Get Native IPv6. >> >> I disagree that bringing the package back in shape is a waste of time, >> especially if getting native IPv6 is not yet possible everywhere at >> the moment. > > I fully disagree here, too. Then why did you not bother to do anything about the situation in the last decade? Why bother now? > I have seen several people using aiccu and > those people shall have a working Sixxs client that is well maintained > in Debian until the service finally gets removed from the internet. See above... soon. > @Axel: Please add me to the Uploaders: field, I'll see what I can do > from time to time to fix aiccu issues. I will not start the initial > fixing now, as I have too many things on my list, but I will join in > later on. And another one that promises things that will never happen. Please, just do not bother. Greets, Jeroen
Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility
On 2016-10-09 22:37, Axel Beckert wrote: > Hi Jeroen, > > Jeroen Massar wrote: >> On 2016-10-09 18:56, Axel Beckert wrote: >>> I'm yet another DD who's interested in having that package maintained >>> properly in Debian (and who NMUed it once in the past for that >>> reason). But I don't want to maintain that package alone. >> >> Please check the dates on the ticket. >> >> Then please read https://www.sixxs.net/news/ > > I'm very well aware of both. Are you sure? As the text provided there is quite clear about the situation. But maybe we need to re-iterate it again. >> Then finally Call Your ISP for Native IPv6. > > I already did. The answer so far was "We don't need that yet." :-( > They seem to think that owning enough IPv4 address suffices and maybe > also that there's no customer demand (yet). As your ISP apparently is UPC Cablecom, which is part of the European Cable Monopoly that is Liberty Global you should be aware that they are providing DS-Lite to all their new customers, and have been silently switching every cheap account to it to all around Europe. That their helpdesk does not know what they actually provide, just shows that you asked the wrong people. Indeed, they are correct they have enough IPv4, this as they have been telling RIPE for years that every customer needed 6 IPv4 IPs and have silently been taking them away by changing contract language and what is actually provided. Lots of people with Playstations are having a lot of fun because of that. > And in general: Just one person asking doesn't make them provide IPv6 > instantly. It needs enough people to nag them to realise the demand. How often did you really call? How often did you ask your friends, family, relatives, anybody you know to call? > Another issue is choice: At some locations, especially those with > fiber, you don't have a choice wrt. to ISPs, otherwise changing the > ISP towards one with native IPv6 connectivity is also an option. Sounds you have a monopoly problem. Read the news articles mentioned above, they mention what you could have been doing about that in the last 20 years. >> It is 2016. SixXS won't be around for much longer to provide free >> connectivity > > Yes, but until SixXS closes down, we want and need aiccu maintained > properly in Debian. AICCU has not been 'maintained properly' for well over a decade. And 'closing down' will be sooner than you will want or expect. PoPs are going to be dropping like flies soon. We do not have time for it anymore, and the ISPs providing them in many cases for over a decade have deployed native IPv6 for their customers and thus there is no need for them to provide them. >> Hence, better to stop wasting your time: Go Get Native IPv6. > > I disagree that bringing the package back in shape is a waste of time, > especially if getting native IPv6 is not yet possible everywhere at > the moment. I heavily suggest you spend your time more wisely. The package we build over a decade ago functioned quite fine. The changes made by various Debian "Developers" who never asked the upstream about anything did not do much good to that though. That we where cut off from Debian from maintaining it, is something we have not been able to solve due to lack of will from people who hold the ability to do so. We thus have no interest in further bothering with it either. Call Your ISP and get Native IPv6. And spend your time on something more worthy than this IPv6 thing, something we should have been doing: nobody will ever thank you for it. Greets, Jeroen
Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility
On 2016-10-09 18:56, Axel Beckert wrote: > Hi, > > I'm yet another DD who's interested in having that package maintained > properly in Debian (and who NMUed it once in the past for that > reason). But I don't want to maintain that package alone. Please check the dates on the ticket. Then please read https://www.sixxs.net/news/ Then finally Call Your ISP for Native IPv6. It is 2016. SixXS won't be around for much longer to provide free connectivity while you nor your ISP can't be bothered with it. Hence, better to stop wasting your time: Go Get Native IPv6. Greets, Jeroen
Bug#836846: Remove "Recommends: socklog-run" due to clash with systemd
Package: runit Version: 2.1.2-3 Severity: grave Reporting for a friend... Currently trying to install runit causes socklog-run to be 'suggested' and installed, which clashes with systemd which kinda removes your system when you don't pay attention. (Done on throw-away VM thus no harm came to it) Please remove the recommend of socklog-run (or make that work with systemd). Noting that socklog-run has: ``` Conflicts: linux-kernel-log-daemon, system-log-daemon ``` which is what clashes with systemd. As Debian chose to let systemd be the evil default well, no way to be suggesting socklog-run that conflicts then Indeed, setting APT::Install-Recommends "0"; or using -—no-install-recommands would avoid the system from breaking... but those are not Debian defaults (though they should be ;) Greets, Jeroen ``` root@box:~# apt-get install runit Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: fgetty runit sysvinit-core Suggested packages: socklog-run The following packages will be REMOVED: systemd systemd-sysv The following NEW packages will be installed: fgetty runit sysvinit-core 0 upgraded, 4 newly installed, 2 to remove and 0 not upgraded. Need to get 278 kB of archives. After this operation, 13.5 MB disk space will be freed. Do you want to continue? [Y/n] y Get:1 http://ftp.us.debian.org/debian/ jessie/main sysvinit-core amd64 2.88dsf-59 [132 kB] Get:2 http://ftp.us.debian.org/debian/ jessie/main fgetty amd64 0.6-5 [25.9 kB] Get:3 http://ftp.us.debian.org/debian/ jessie/main runit amd64 2.1.2-3 [117 kB] Fetched 278 kB in 0s (446 kB/s) Preconfiguring packages ... dpkg: systemd-sysv: dependency problems, but removing anyway as you requested: init depends on systemd-sysv | sysvinit-core | upstart; however: Package systemd-sysv is to be removed. Package sysvinit-core is not installed. Package upstart is not installed. (Reading database ... 30202 files and directories currently installed.) Removing systemd-sysv (215-17+deb8u4) ... Processing triggers for man-db (2.7.0.2-5) ... Selecting previously unselected package sysvinit-core. (Reading database ... 30185 files and directories currently installed.) Preparing to unpack .../sysvinit-core_2.88dsf-59_amd64.deb ... Unpacking sysvinit-core (2.88dsf-59) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up sysvinit-core (2.88dsf-59) ... Not restarting sysvinit (Reading database ... 30210 files and directories currently installed.) Removing systemd (215-17+deb8u4) ... systemd is the active init system, please switch to another before removing systemd. dpkg: error processing package systemd (--remove): subprocess installed pre-removal script returned error exit status 1 Failed to stop lib-init-rw.mount: Unit lib-init-rw.mount not loaded. addgroup: The group `systemd-journal' already exists as a system group. Exiting. Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) ```
Bug#824677: aiccu: please depend on iproute2 instead of iproute transitional package
On 2016-05-18 18:46, Andreas Henriksson wrote: > Package: aiccu > Version: 20070115-15.3 > Severity: normal > > Dear Maintainer, > > Please update the aiccu package dependencies to use 'iproute2' instead > of the transitional package 'iproute'. > > The transition from the old iproute package name to iproute2 happened in > Debian Jessie, so the transitional package are now ready to be removed. > If your package is not updated by then it'll become uninstallable (and > thus RC-buggy). Would love to update this, but unfortunately we do not get commit-alike access.. Thus please do a NMU for that simple fix, as no Debian Developer is currently assigned to the aiccu package... ;( If somebody can sponsor uploads though, we would love to know about that. Greets, Jeroen
Bug#689584: [Bug 1455097] Re: /etc/pm/sleep.d/ is no more processed
On 2016-04-06 17:46, ChristianEhrhardt wrote: > I did the task of identifying the remaining packages that are affected. > > $ apt-file search /etc/pm/sleep.d/ > > aiccu: /etc/pm/sleep.d/60aiccu There has been a bug out for this for 4 years already that this should never ever have existed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584 Short version: please remove any kind of trace from /etc/pm/sleep.d for aiccu. That should take care of your bug report for aiccu at least. Greets, Jeroen
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-26 14:56, Mark Brown wrote: > On Fri, Feb 26, 2016 at 02:17:46PM +0100, Jeroen Massar wrote: >> On 2016-02-26 13:55, Mark Brown wrote: >>> On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > >>>> No VPN-alike tool does such a thing. OpenVPN for instance also nicely >>>> aborts as it can't do anything with that situation. SSH tunnels also >>>> nicely state "no network". > >>> This is true for things intended to be used interactively from a UI but >>> not for everything, for example IPSEC tunnels establised with FreeS/WAN >>> can be started with just local configuration. > >> There is no external configuration for IPSEC. You just configure the >> parameters statically on both ends, and presto. > > Yes, everything is stored in local config files which does make things a > easier to implement. Thus, how would you do it when that is not the case? >>> The UI presented for >>> AICCU is much more that of a daemon than of a GUI or something designed >>> to tie into ifup/ifdown type scripting. It's really not obvious how to >>> robustly start AICCU in a way that fits well with the UI as it stands, >>> the constraints it has are pretty tight. > >> Which UI? > > The way it interacts with the rest of the system and hence the user is a > UI. (I think you want to rephrase that sentence ;) >>>> It is helping: it logs an error message stating you to fix your network. > >>> Compared to other system daemons this is highly unusual behaviour, I >>> think this is my main point - there's a conflict between the interface >>> presented and the error handling. > >> Since when is reporting an error in the logs unusual for a daemon? > >> Which "interface" are you exactly talking about? > > Reporting errors via logs is not unusual. Exiting when confronted with > transient runtime errors is much more unusual. AICCU does not know that the problem is 'transient' or 'persistent'. Only a human knows this is the case and how to resolve the problem. Make a typo in nginx, apache etc config, they will all bail out as they cannot resolve it either. Same situation: broken configuration -> log & exit. That is the model that AICCU operates under as it is one that makes sense. Keeping on retrying does not resolve anything and just makes things magic. >>>> Your logs will love being spammed with that amount of activity. > >>> If it tries and/or logs excessively then sure. This is a readily >>> solvable problem though. > >> How is such a thing solvable? Are you going to suppress some but not all >> messages? > > That's one option but I was more thinking of things like rate limiting > the activity being logged (which would be needed to avoid hammering on > the TIC, assuming we get far enough to even talk to it). Do you also rate limit these events on the other side and every hop in between of that connection? What about the router, DNS server and many other elements that are involved? As you do not know what the actual problem is, how do you know what to rate limit, or when that problem goes away? >>>> It is not a solution in any way: fix your network instead. > >>> ...and then manually kick AICCU. It's the manually kick that isn't >>> great, especially as IPv4 will recover by itself and most things will >>> fall back to IPv4 which makes the problem less obvious than it might >>> otherwise be. > >> Why is that "not great"? > > It's not a good user experience, the whole "see if the network came up > then try again" loop is something that everything else in my system > (mail, NTP, whatever) does without manual intervention. Those configurations you are talking about are static, there are no dynamic parts there. >> How would AICCU figure out otherwise that you fixed your network? > > By waiting some reasonable time period, trying again and finding things > work. You mean: keep on hammering on something, even though the real problem has not been resolved whatsoever... >> How will "IPv4 recover by itself"? > > In the case of my home network the cable modem, router and the network > end will decide they'll talk to each other again through a similar > process of monitoring links and retrying to the one I'm suggesting. All your hosts monitor all those links? How do they do that? Is that standard in Debian or for that matter any other OS? Also, every other VPN tool does that "Can't reach other side, bye bye". I am pretty sure that even more advanced UIs (Windows, OSX) towards users also nicely show "it is broken
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-26 13:55, Mark Brown wrote: > On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote: > >> No VPN-alike tool does such a thing. OpenVPN for instance also nicely >> aborts as it can't do anything with that situation. SSH tunnels also >> nicely state "no network". > > This is true for things intended to be used interactively from a UI but > not for everything, for example IPSEC tunnels establised with FreeS/WAN > can be started with just local configuration. There is no external configuration for IPSEC. You just configure the parameters statically on both ends, and presto. > The UI presented for > AICCU is much more that of a daemon than of a GUI or something designed > to tie into ifup/ifdown type scripting. It's really not obvious how to > robustly start AICCU in a way that fits well with the UI as it stands, > the constraints it has are pretty tight. Which UI? >>> I'd argue that AICCU can do things to help. > >> It is helping: it logs an error message stating you to fix your network. > > Compared to other system daemons this is highly unusual behaviour, I > think this is my main point - there's a conflict between the interface > presented and the error handling. Since when is reporting an error in the logs unusual for a daemon? Which "interface" are you exactly talking about? >>> I'd expect it to try indefinitely. I'd not expect it to hammer on >>> things but rather to try periodically. > >> Your logs will love being spammed with that amount of activity. > > If it tries and/or logs excessively then sure. This is a readily > solvable problem though. How is such a thing solvable? Are you going to suppress some but not all messages? Please note that people who do not look at logs, will never figure out that there is a statement in the logs. If there is 1 or thousands of messages. >> It is not a solution in any way: fix your network instead. > > ...and then manually kick AICCU. It's the manually kick that isn't > great, especially as IPv4 will recover by itself and most things will > fall back to IPv4 which makes the problem less obvious than it might > otherwise be. Why is that "not great"? How would AICCU figure out otherwise that you fixed your network? How will "IPv4 recover by itself"? Is the IPv4 connectivity also provided by a VPN-alike tool? >>> constantly) and to have options to control that behaviour for cases >>> where there are concerns about resource usage. > >> You, and many others, seem to not understand that we have been trying >> fight people from restarting AICCU for a long time now. > > No, I've seen the stuff about not hammering on the TIC. You might have seen it, but do you understand it? > The other way > of looking at this is that if there are very large numbers of users who > are trying to do this then probably there is some need that is not being > met. Very large numbers? Please remind yourself that if something gets built into something and then distributed that it automatically affects every single one of the people who automatically gets to run that code. > I think some of what might be happening is that there's some noticable > proportion of people who feel they need to restart AICCU a lot are doing > so to work around things like transient errors on startup and are doing > it in an unsophisticated way due to inexperience or thoughtlessness. No, those restarts are happening become some person in a distribution position (eg Debian, OpenWRT developers) made that decision. The user only notices it when they are locked out though. They typically do not read the logs... > Were the daemon to handle this in a less surprising fashion that'd most > likely greatly reduce the number of people doing this. Please elaborate how the daemon could handle what in what exact way. > Probably there are other people doing this for reasons I can't think of > right now of course but I'd not be surprised if they were in the > minority. Probably there are people who want to have a pony. Without actually describing what the problem is, and how something can be properly resolved, there is really little to state about things. >> If you notice that it is does not start properly: make sure that the >> environment is correct for starting it in the first place. > >> There is nothing AICCU can do about your network being broken when you >> try to start it. > > It can't fix the network by itself, no. It can recover when the network > is fixed though. How can it know that "the network is fixed"? Is there something magic that I am not aware of? Broken connectivity can be because of way too many reasons. >> And in the end.
Bug#678519: Close 678519 - NTP is a recommend
close 678519 thanks https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678519#99 As noted in the above comment, this is a timing issue on the host as the administrator decided to not run NTP which is required for proper usage of AICCU (and any other system involving crypto and replay protection). As the AICCU package contains a "recommends: ntp..." this can be closed. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#497211: close 497211
close 497211 thanks Closing due to no further replies on the issue, ~4 years ago. signature.asc Description: OpenPGP digital signature
Bug#686490: close 686490
close 686490 thanks Bug report does not actually contain any description of a bug. Thus unsure what to do with this, closing for lack of detail. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#612785: close 612785
close 612785 thanks Not enough details to look further in this bug report. Also as this was filed against Debian 6 and currently everything is systemd it likely changed completely in behavior. Also note that when the service is not started a service status check will show that, the interface won't be up and there will be an entry in the log file. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#499920: close 499920
close 499920 thanks No feedback from filer of ticket after ~4 years. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#497210: close 497210
close 497210 Fix upstream as noted in the bug report. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#497406: close 497406
close 497406 thanks Unable to be replicated. signature.asc Description: OpenPGP digital signature
Bug#678519: Close 678519 - NTP is a recommend
close 678519 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678519#99 As noted in the above comment, this is a timing issue on the host as the administrator decided to not run NTP which is required for proper usage of AICCU (and any other system involving crypto and replay protection). As the AICCU package contains a "recommends: ntp..." this can be closed. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-17 19:26, Mark Brown wrote: > On Wed, Feb 17, 2016 at 05:46:53PM +0100, Jeroen Massar wrote: >> On 2016-02-17 17:00, Mark Brown wrote: > >>> Right, but I do think AICCU can deal better with this situation. Not >>> dealing with it makes system integration much harder as there are a >>> range of options that users have for configuring their network in most >>> distributions > >> Which 'options' are not properly handled? What is the real actual >> problem you are trying to solve? > > The case that is most difficult for me to eliminate in my system is that > where both the router and the modem (which are separate devices) are > being started at the same time. AICCU is running on the router, it will > most likely have a connection to the modem prior to the modem uplink > being ready. I am particularly concerned about this for unattended > boots (for example, after power loss) but it'd be nice if it worked in > general. Sounds like you need to wait for the network to be operational before starting AICCU No VPN-alike tool does such a thing. OpenVPN for instance also nicely aborts as it can't do anything with that situation. SSH tunnels also nicely state "no network". >>> including off-system network connectivity like >>> routers which the distribution has little chance to integrate with). > >> You know this Internet thing, it is rather big, lots of routers are >> involved in a typical connection, only few a user has control over, let > > I am aware of this, thanks. > >> alone zero that AICCU can do anything about. > > I'd argue that AICCU can do things to help. It is helping: it logs an error message stating you to fix your network. It cannot guess what the problem is. Keeping on restarting is not the answer that will solve all the situations, and it cannot know what the situation is, or when it will be fixed. If you "only start it 5 times", it might be that your network is ready at attempt 6 or maybe very briefly at attempt 12. >>> I disagree here. While it is true that AICCU can not resolve this issue >>> for itself I think it can handle it more gracefully, it can sit and keep >>> trying so that when the situation is resolved then AICCU will recover. > >> How long should it keep on hammering on services for the situation to >> resolve itself? > > I'd expect it to try indefinitely. I'd not expect it to hammer on > things but rather to try periodically. Your logs will love being spammed with that amount of activity. It is not a solution in any way: fix your network instead. >>> This is more in line with what other services like mail servers > >> You mean a mail client (MUA) like Thunderbird I hope. > >> Guess what that does, indeed, it shows an error to the user that the >> connection fails. > >> Mail servers are a quite different kind of beast, they do not sit at a >> user end. > > I actually mean both (basically, anything that maintains a queue could > have such behaviour AICCU, nor any kind of VPN, has any kind of "queue". > - there are simple MTAs specifically designed for > centralizing the mail queue on a system, this is useful as it allows > utilities to do e-mail without requiring configuration duplication or > wheel reinvention). AICCU is not such a tool you are describing in any way or form. > The text mail clients I use use a central MTA and > just return as soon as they've handed over to it, Evolution just > silently queues things for sending at a later time unless you've started > an explicit sync operation (or did last time I checked anyway). A MUAs send directly to a MTA. That your MTA keeps on retrying is one thing, when your MUA can't reach the MTA though it will fail and state that by logging an error or presenting it. >>> or things like ypbind > >> ypbind also nicely bails out when there is no connectivity. No need to >> keep on trying something it cannot resolve. > > No, it doesn't - it will just sit there in in the background and retry > periodically. Distro init scripts will tend to wait for it to bind in > order to support other things that might want to use the binding but the > daemon itself will happily sit there. At least in the Debian case we > wait for a while and then just carry on, leaving ypbind running in the > background. The most important differentiator is that ypbind is contacting servers that you are controlling or are affiliated with. Hammering on that is fine, doing that to other people's servers is not acceptable though. >>> do - they start up, attempt to perform their >>> functions and retry if those fail. It's also more in line with what >>>
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-17 17:00, Mark Brown wrote: > On Wed, Feb 17, 2016 at 04:03:22PM +0100, Jeroen Massar wrote: >> On 2016-02-17 13:47, Mark Brown wrote: > >>> Let me try to provide that... We now no longer have the problems in the >>> original report with the boot hanging but we still don't have AICCU >>> coming up reliably at boot. > >> You should start AICCU when you have proper connectivity (time synced, >> DNS resolving works, and you can actually can make connections outbound). > >> Doing it to early is not the way to do it. > >> This is not something that AICCU can do, as it does not know when your >> system is "connected to the Internet", only the user behind the machine >> knows this. > > Right, but I do think AICCU can deal better with this situation. Not > dealing with it makes system integration much harder as there are a > range of options that users have for configuring their network in most > distributions Which 'options' are not properly handled? What is the real actual problem you are trying to solve? > (and of course network connectivity may appear and > disappear at any point Network connectivity disappearing and coming back is fine. AICCU only needs connectivity at the start to fetch the configuration from TIC, after that, connectivity can go and come again. > including off-system network connectivity like > routers which the distribution has little chance to integrate with). You know this Internet thing, it is rather big, lots of routers are involved in a typical connection, only few a user has control over, let alone zero that AICCU can do anything about. >>> There's probably some init based fix for this but I'd also expect AICCU >>> to handle this more gracefully by retrying resolver failures, it seems >>> like this is something that is reasonably likely to happen during the >>> startup process. > >> As AICCU cannot resolve your DNS issue and only an administrator of the >> machine, or the DNS service, or the connectivity provider etc can, AICCU >> cannot resolve this and thus restarting it or letting it retry does not >> resolve the problem. > > I disagree here. While it is true that AICCU can not resolve this issue > for itself I think it can handle it more gracefully, it can sit and keep > trying so that when the situation is resolved then AICCU will recover. How long should it keep on hammering on services for the situation to resolve itself? > If nothing changes the user is no worse off, and if the external factors > that were causing connectivity issues are resolved then things will > start working. There are MANY reasons why keeping on trying will not resolve anything and make things actually worse. Filling up a log with connection attempts will not solve it. Using CPU time that is not needed Making repeated DNS requests even though there is no connectivity (especially fun when people pay for connectivity) The user will finally notice that connectivity is not working and they will fix the real problem instead. > This is more in line with what other services like mail servers You mean a mail client (MUA) like Thunderbird I hope. Guess what that does, indeed, it shows an error to the user that the connection fails. Mail servers are a quite different kind of beast, they do not sit at a user end. > or things like ypbind ypbind also nicely bails out when there is no connectivity. No need to keep on trying something it cannot resolve. > do - they start up, attempt to perform their > functions and retry if those fail. It's also more in line with what > happens if there is a connectivity interruption after the daemon has > started. I'll repeat it again AICCU handles connectivity failures AFTER start (fetching the config from TIC) perfectly fine Greets, Jeroen (who loves it *ahum* how often he has to repeat these statements)
Bug#754121: AICCU not starting on boot in Debian
On 2016-02-17 13:47, Mark Brown wrote: > Hi, > > There's a bug open in Debian about AICCU not starting when used with > systemd (though it's most likely not that specifically). One of the > last things in the bug log is: > > | Actually, a concise problem statement would be a good thing to have, as > | it seems completely lost in the bug report. > > Let me try to provide that... We now no longer have the problems in the > original report with the boot hanging but we still don't have AICCU > coming up reliably at boot. You should start AICCU when you have proper connectivity (time synced, DNS resolving works, and you can actually can make connections outbound). Doing it to early is not the way to do it. This is not something that AICCU can do, as it does not know when your system is "connected to the Internet", only the user behind the machine knows this. > There's probably some init based fix for this but I'd also expect AICCU > to handle this more gracefully by retrying resolver failures, it seems > like this is something that is reasonably likely to happen during the > startup process. As AICCU cannot resolve your DNS issue and only an administrator of the machine, or the DNS service, or the connectivity provider etc can, AICCU cannot resolve this and thus restarting it or letting it retry does not resolve the problem. Greets, Jeroen
Bug#805975: bind9 complains about missing SPF record when TXT record is present
Package: bind9 Version: 1:9.9.5.dfsg-9+deb8u2 Severity: wishlist tag -1 patch thankyou As per the following Redhat bug, which includes a patch: https://bugzilla.redhat.com/show_bug.cgi?id=1215164 8<-- According to RFC 7208, section 3.1 SPF records need to be TXT records and not RR SPF records as previously recommended. When checking the syntax of a TXT RR SPF record an error message is displayed saying it should use RR SPF. --->8 Please apply that patch and bug upstream about this to remove this warning. Greets, Jeroen
Bug#805445: Static IPv6 Default Route not configured
On 2015-11-18 11:12, Guus Sliepen wrote: > severity 805445 important > thanks > > On Wed, Nov 18, 2015 at 10:16:29AM +0100, Jeroen Massar wrote: > >> Package: ifupdown >> Version: 0.7.53.1 >> Severity: critical >> >> Marking critical as it breaks IPv6 connectivity after a reboot, thus >> hope you got IPv4 still (or KVM :) if it is a remote machine ;) > > It's not dropping your SQL tables or blowing up your house, so: > > important > a bug which has a major effect on the usability of a package, > without rendering it completely unusable to everyone. Well actually there are folks with IPv6 only connectivity (or IPv4 behind NAT or worse CGN) and no KVM access (which is silly but still) thus they would lose access to the host if it would restart. There are then also people who manage their home heater system with it and thus won't be able to access that remotely thus it could blow up your house ;) Hence, why I think that it should be a priority to look at. But "important" works too. >> See Ubuntu bug report here: >> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1510098 > > Did you try this on a Debian system or on Ubuntu? Debian stable 0.7.53.1, I avoid Ubuntu like a plague :) $ apt-cache policy ifupdown ifupdown: Installed: 0.7.53.1 Candidate: 0.7.53.1 Version table: *** 0.7.53.1 0 500 http://mirror.switch.ch/ftp/pub/debian/ stable/main amd64 Packages 100 /var/lib/dpkg/status > And in either case, which version? See original version above and just the text above. > Then I can try it out in a VM and try to find the cause. Awesome, please do. I would btw not be surprised if this is related to having accept_ra set to 0 in sysctl as it should be for server systems. > It would also be helpful to see your full /etc/network/interfaces, > without any addresses censored if possible, so I can see if it might be > caused by any scoping issues. I am quite good with scoping issues, don't worry about that. Some of the boxes I had this problem on where running fine for over 10 years... It is a bog standard config, did not include it as the bog the same details for the ubuntu bug report apply. But let me give you a simple version: 8<- # The loopback interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.200.42 netmask 255.255.255.0 gateway 198.168.200.1 iface eth0 inet6 static address 2001:db8:ff:1234::42 netmask 64 gateway 2001:db8:ff:1234::1 ->8 Note that we zero out /etc/sysctl.d/10-ipv6-privacy.conf (empty file with just comments) to avoid privacy parameters to be set (Ubuntu actually does do that, not sure if Debian does, don't think so though) 8<- $ cat /etc/sysctl.d/99-custom.conf # Upgrade the TCP backlog quite a bit net.ipv4.tcp_max_syn_backlog=8192 # Disable Accept of Router Advertisements net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.default.accept_ra=0 # Disable source routing net.ipv4.conf.default.accept_source_route=0 net.ipv4.conf.all.accept_source_route=0 # Disable ICMP ratelimitting # There are so many people who seemingly need to monitor # SixXS boxes, that these limits are triggered all the time net.ipv4.icmp_ratelimit=0 net.ipv4.icmp_ratemask=0 net.ipv6.icmp.ratelimit=0 # Make sure that privacy addresses are disabled net.ipv6.conf.default.use_tempaddr=0 net.ipv6.conf.all.use_tempaddr=0 ->8 Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file mentioned above) and then when sysctl this custom file the setting is reverted and you lose your default... hmmm, that might actually be affecting this too now I think of it. But the sysctl stuff should run BEFORE ifupdown comes into play (hence setting default+all so that existing and new interfaces get that setting). That might thus be a kernel annoyance, thus just in case on that box the version of that: linux-image-3.16.0-4-686-pae 3.16.7-ckt11-1+deb8u6 i386 hm you are not toggling use_tempaddr I hope as that would cause default route to be cleared by the kernel (some kernels do that, others do not btw...)? Indeed using the accept_ra etc settings in /etc/network/interfaces would be a good thing, but the current sysctl method has worked for a long long time already and a static config should just work like that. >> Btw, >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ifupdown;dist=unstable >> mentions that Guus is the maintainer while the package field has Andrew >> listed... there is a LOT of wishlist bugs there that could just be >> closed even though they are from ~2001 > > Yes, I took over but Andrew is also still contributing. I have been > going through old bugs, most can indeed be closed, but there are also > some bugs worth fixing (even wishlist bugs from a decade ago). I saw the commit log, I am sure you'll fight through them :) Good luck and thanks for working on it! Greets, Jeroen
Bug#805445: Static IPv6 Default Route not configured
On 2015-11-18 11:46, Guus Sliepen wrote: [..] >> Indeed, Ubuntu sets use_tempaddr=2 in their sysctl (hence the empty file >> mentioned above) and then when sysctl this custom file the setting is >> reverted and you lose your default... >> >> hmmm, that might actually be affecting this too now I think of it. >> >> But the sysctl stuff should run BEFORE ifupdown comes into play (hence >> setting default+all so that existing and new interfaces get that setting). > > Yes. Maybe it could also have something to do with DAD. >From my POV DAD does not come into play there, and also the kernel would log it. > I'll try it out with the settings you have and poke around until I find the culprit, > then see how I can have ifupdown work around it. I did not check the code thus maybe it does it already but checking the setting if accept_ra is going to be toggled might be a good thing. Of course if is accept_ra toggle related (losing the default route) then that is clearly a kernel thing, not much ifupdown could do about. Greets, Jeroen
Bug#805445: Static IPv6 Default Route not configured
Package: ifupdown Version: 0.7.53.1 Severity: critical Marking critical as it breaks IPv6 connectivity after a reboot, thus hope you got IPv4 still (or KVM :) if it is a remote machine ;) See Ubuntu bug report here: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1510098 Btw, https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ifupdown;dist=unstable mentions that Guus is the maintainer while the package field has Andrew listed... there is a LOT of wishlist bugs there that could just be closed even though they are from ~2001 Greets, Jeroen
Bug#805445: Static IPv6 Default Route not configured
On 2015-11-18 13:54, Guus Sliepen wrote: [..] >> 8<- >> $ cat /etc/sysctl.d/99-custom.conf >> # Disable Accept of Router Advertisements >> net.ipv6.conf.all.accept_ra=0 >> net.ipv6.conf.default.accept_ra=0 >> >> # Make sure that privacy addresses are disabled >> net.ipv6.conf.default.use_tempaddr=0 >> net.ipv6.conf.all.use_tempaddr=0 >> ->8 > > Ok, tried it with and without these settings, but on a fresh install > setting the IPv6 address, netmask and gateway just works as expected, > both on Debian stable and unstable. Did you try at-boot or post-boot? >> That might thus be a kernel annoyance, thus just in case on that box the >> version of that: >> >> linux-image-3.16.0-4-686-pae 3.16.7-ckt11-1+deb8u6 i386 > > I have the exact same version. Well, running on amd64, but I would think > that this is not a 32 vs. 64 bits issue. I don't expect any issues there either. >> hm you are not toggling use_tempaddr I hope as that would cause >> default route to be cleared by the kernel (some kernels do that, others >> do not btw...)? >> >> Indeed using the accept_ra etc settings in /etc/network/interfaces would >> be a good thing, but the current sysctl method has worked for a long >> long time already and a static config should just work like that. > > Actually, even if you don't explicitly specify accept_ra in /e/n/i, ifup > will set accept_ra and autoconf to 0 before configuring the IPv6 part of > the interface. Before should be good as then the reset behavior of some version of the kernel don't happen. When was that behavior (setting accept_ra) introduced btw? > The output of ifup -v eth0 in my Debian stable vm is: Try it at boot. sysctl, especially with systemd, might mess up the order of things... doing DHCP also delays things btw. > modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure. Why is it still modprobing this, Debian has been IPv6 enabling kernels per default since long time ago, this thus would only affect people who built their own kernels with IPv6 as a module (is that still possible?), and then those folks will know that they need /etc/modules when the interface configuration fails. It does not hurt though, thus fine to keep it there. > sysctl -q -e -w net.ipv6.conf.eth0.accept_ra=0 > sysctl -q -e -w net.ipv6.conf.eth0.autoconf=0 > ip link set dev eth0 up The interface should already be up because of DHCP (or otherwise static config) > ip -6 addr add 2001:db8:ff:1234::42/64 dev eth0 > ip -6 route add default via 2001:db8:ff:1234::1 dev eth0 > /lib/ifupdown/settle-dad.sh > Waiting for DAD... Done > run-parts --exit-on-error --verbose /etc/network/if-up.d > run-parts: executing /etc/network/if-up.d/mountnfs > run-parts: executing /etc/network/if-up.d/upstart > > So the problem is elsewhere, I think. Or maybe you have more interfaces, No interfaces are there at boot. Just good old loopback and eth0. > and something might interfere with the default gateway set by a previous > one? Maybe you should try running ifdown -a; ifup -v -a; yourself and > see what the output is? You can send me a copy as well if you want. Doing ifdown/ifup works after boot I think a systemd/sysv kind of race might be involved actually. That specific box did not switch to systemd yet (just has the lib packages), and still is using sysv-rc. Greets, Jeroen
Bug#754121: Fwd: Re: aiccu fails to start with systemd
Severity: important Lowering again to important. Otherwise the package gets removed from testing and never fixed. Actually, a concise problem statement would be a good thing to have, as it seems completely lost in the bug report. Greets, Jeroen -- FYI: The status of the aiccu source package in Debian's testing distribution has changed. Previous version: 20070115-15.2 Current version: (not in testing) Hint: http://release.debian.org/britney/hints/auto-removals Bug #754121: aiccu fails to start with systemd The script that generates this mail tries to extract removal reasons from comments in the britney hint files. Those comments were not originally meant to be machine readable, so if the reason for removing your package seems to be nonsense, it is probably the reporting script that got confused. Please check the actual hints file before you complain about meaningless removals. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754121:
On 2015-05-06 12:29, Michael Biebl wrote: reassign: -1 aiccu Am 06.05.2015 um 04:43 schrieb Daniel Albers: This is a critical bug of either aiccu or systemd as explained by Pascal. Assigning also to systemd as the aiccu maintainer considers this a systemd bug, although I think message #26 546673f0.1040...@localhost.localdomain.org already points to the proper fix for aiccu. Jeroen Massar is not listed as maintainer of the aiccu package Apologies for not being able to get a DD-bit. I am only the person that designed and implemented aiccu, for the rest indeed, that is totally a useless thing in the Debian universe, why care about the original author of the code. and I don't see any explanation which would hint at a bug in systemd. Adding systemd to it all started causing problems. But that is indeed likely just a symptom. systemd is all magic as this bug shows. As you point out though the 'ifup.d' script might be the cause of the whole problem though. See also bug #689584 where I've noted that that script should not exist. Therefor re-assigning back to aiccu. I think it should be re-assigned to Debian then as the problem lies there as that is where the modifications where made and well, Debian is the entity that can really resolve this. From a quick look at the package, it seems to install a init script which depends on $network and an if-up.d hook which restarts the aiccu init script as part of /etc/init.d/networking. /etc/init.d/networking itself provides $network, so there is a dead lock, since systemd evaluates dependencies at runtime. Should such a dead lock at least not be clearly noted in a log or similar? Reinier, if you need help with getting this sorted out, please contact the pkg-systemd team. He does not want to maintain the package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692465 Thus all those problems will remain. And without a DD-bit, nobody can resolve this problem. Is there a reason, aiccu needs to be restarted on ifup? Absolutely not. There is no need to *EVER* restart AICCU. The protocols are made for handling dynamic networks. Unfortunately Debian package maintainers seem to think they know better hence instead of listening to the original author of the code and the persons who run the SixXS service (hint: same people :) things are changed anyway. Nothing we can do about these problems. That is a Debian issue. See also amongst others: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584 https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825 Note that Debian is not the only entity who does not get this, OpenWRT is another such entity, and heck even ZyXEL still does not understand the concept. Does it need that to pick up new network interfaces? No. The AYIYA protocol is made for handling network changes. The better fix is, to make aiccu network hotplug aware (e.g. via rtnetlink) [1]. Why would AICCU need to know about interfaces? This would also mean, aiccu would work better ootb with other networking tools or if the network is configured manually. It already works fine in those situations. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754121:
On 2015-05-06 13:26, Michael Biebl wrote: Hi Jeroen, Am 06.05.2015 um 13:06 schrieb Jeroen Massar: On 2015-05-06 12:29, Michael Biebl wrote: reassign: -1 aiccu Am 06.05.2015 um 04:43 schrieb Daniel Albers: This is a critical bug of either aiccu or systemd as explained by Pascal. Assigning also to systemd as the aiccu maintainer considers this a systemd bug, although I think message #26 546673f0.1040...@localhost.localdomain.org already points to the proper fix for aiccu. Jeroen Massar is not listed as maintainer of the aiccu package Apologies for not being able to get a DD-bit. I am only the person that designed and implemented aiccu, for the rest indeed, that is totally a useless thing in the Debian universe, why care about the original author of the code. Well, the currently listed maintainer is Reinier and he hasn't officially orphaned the package. This should probably be corrected, now that you pointed me to #692465 I wasn't aware of your role regarding this package/software when reading #754121, especially upstream. This was not meant as an offense. So my apologies if this came across the wrong way. No worries, it is an easy oversight to make. Unfortunately many distributions have the issue of not acknowledging upstream. For instance https://tracker.debian.org/pkg/aiccu has nowhere a note where the upstream is. There is a 'homepage' link, but there is no 'upstream contact' which would make things easier and might even enforce a better communication between a package maintainer and the actual authors of the code in where the maintainer would ask before making changing instead of just doing so and then causing more problems. But that is indeed likely just a symptom. systemd is all magic as this bug shows. As you point out though the 'ifup.d' script might be the cause of the whole problem though. See also bug #689584 where I've noted that that script should not exist. Therefor re-assigning back to aiccu. I think it should be re-assigned to Debian then as the problem lies there as that is where the modifications where made and well, Debian is the entity that can really resolve this. I think what should happen, is that the package is properly orphaned and then someone can pick it up. If you (or your team at SixXS) is interested in having aiccu properly maintained in Debian, you could try to adopt the package after it has been orphaned and get it uploaded to the archive via a sponsored upload. See http://mentors.debian.net/ I've suggested this before. Unfortunately it seems the politics are large; unfortunate side effect of large projects. Reinier, if you need help with getting this sorted out, please contact the pkg-systemd team. He does not want to maintain the package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692465 Thus all those problems will remain. Ok, understood, see above. And without a DD-bit, nobody can resolve this problem. Is there a reason, aiccu needs to be restarted on ifup? Absolutely not. There is no need to *EVER* restart AICCU. The protocols are made for handling dynamic networks. Thanks for the clarification. I just noticed, that aiccu actually no longer installs the ifup hook. But since the if-up hook is a conffile, it's not automatically removed on upgrades, so needs to be dealt with explicitly. See https://wiki.debian.org/DpkgConffileHandling I also noticed, that the aiccu package installs a pm-utils hook, which restarts the aiccu service on suspend/resume. I guess this one could go as well? As filed some 3 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584 As you can see, without DD-bit, little power one retains over the code one produces. Oh and of course, this carries to every distribution that derives from Debian including Ubuntu. Unfortunately Debian package maintainers seem to think they know better hence instead of listening to the original author of the code and the persons who run the SixXS service (hint: same people :) things are changed anyway. See above, if you feel like taking over maintainership of the package, this would be appreciated. Attempted that before. Failed. Please note that the fun part of this all is that we originally packaged AICCU and then somebody took all that work and just stuck it into Debian at one point (which was awesome, as then it worked, not so awesome when things get broken on purpose though...) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754121:
On 2015-05-06 13:47, Michael Biebl wrote: Am 06.05.2015 um 13:44 schrieb Jeroen Massar: On 2015-05-06 13:26, Michael Biebl wrote: See above, if you feel like taking over maintainership of the package, this would be appreciated. Attempted that before. Failed. Please note that the fun part of this all is that we originally packaged AICCU and then somebody took all that work and just stuck it into Debian at one point (which was awesome, as then it worked, not so awesome when things get broken on purpose though...) FYI: I just poked the MIA team [1], to get the package orphaned. Let's see what happens. Thx! Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754121: aiccu fails to start with systemd
Severity: important Lowering severity to important. Causing a package for removal because somebody decided on a new init system that is not backwards compatible is not a critical thing. Also, you can always start AICCU simply by typing 'aiccu start' which is what the init script does. I'll install a VM over the weekend and check what the heck is wrong with this and resolve it properly. It would be extremely useful if you can actually provide logs and other details btw. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754121: aiccu fails to start with systemd
On 2014-11-14 22:28, Pascal Volk wrote: On 11/14/2014 09:44 AM, Jeroen Massar wrote: [..] As mentioned in my message from yesterday, the system is unable to finish the boot process. The message `A start job is running for LSB: …' can't be interrupted. You are using a 'testing' branch of Debian. Problems are to be expected. Especially when changing init systems. You should be filing a critical bug with systemd for breaking your system in this way. The only workaround, known to me, is enabling systemd's debug shell. In the (INSECURE!) debug shell I'm able to find out the PID of the systemclt job, which tries to start aiccu. Then I'm able to kill that job. Definitely sounds like a systemd issue. AICCU does not cause that error, it is systemd causing you all that grief and no way out to simply solve it. Also, you can always start AICCU simply by typing 'aiccu start' which is what the init script does. This is what I've done within the last months, since I've reported the problem. Hence, AICCU works. It is just something messy in systemd that is causing this. I'll look into it this weekend, though diving into systemd will be 'fun'. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758691: RFS: profanity/0.4.3-1 [ITP]
On 2014-08-20 09:16, Dariusz Dwornikowski wrote: Package: sponsorship-requests Severity: wishlist * Package name: profanity Version : 0.4.3-1 Upstream Author : James Booth boot...@gmail.com * URL : http://profanity.im/ Without www that URL does not work[1]. http://www.profanity.im/ does work. Greets, Jeroen [1] $ dig profanity.im ; DiG 9.9.5-4-Debian profanity.im ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;profanity.im. IN A ;; AUTHORITY SECTION: profanity.im. 13173 IN SOA ns.123-reg.co.uk. hostmaster. 2012103101 86400 0 604800 14400 ;; Query time: 1 msec ;; SERVER: xxx ;; WHEN: Wed Aug 20 09:41:59 CEST 2014 ;; MSG SIZE rcvd: 103 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#306428: closed by Martín Ferrari tin...@tincho.org (closing)
Martín Ferrari tin...@tincho.org wrote: This is an ancient bug, It almost hit the 10 year mark ;) (kinda show how few folks interest in SCTP actually) but in any case, this is not something that Debian should be doing, it belongs to upstream (also, it is missing ipv6). Unless you meant upstream, IPv6 is supported by the Debian patch: debian/patches/CVS-20070316-netstat.c_sync.patch and causes amongst others: tcp6 0 0 :::113 :::*LISTEN tcp6 0 0 ::1:53 :::*LISTEN tcp6 0 0 :::22 :::*LISTEN tcp6 0 0 :::25 :::*LISTEN tcp6 0 0 ::1:8953:::*LISTEN ESTABLISHED is reported fine too. So, I am closing as wontfix. That is fine, if I find time (where would that come from ;), I'll try to create a patch and bug upstream about it. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
Note that there are a variety of forums that are a much better place than a Debian mtr package bug report for these kind of questions. On 2014-04-28 09:08, Rogier Wolff wrote: I personally have a good understanding of IPV4 and how I've secured my network against attacks from outside. I know what I'm doing. This means that I make decisions about what to protect against and what I won't protect against. I have decided that I will have fence security: I protect the outside, I do not put any effort into protecting my machines from an attacker who is able to access my network. (either by physically plugging in or by getting control over a machine on my network). If your assumption is that, then you are 'safe' with the default settings provided by Debian. Unless somebody sets up a router advertisement to announce a prefix (for which they need local access to the network), your host will only have a link-local (fe80::/10) address, which means the adversary has local access to your network. Now this fancy IPV6 comes along. I've been pusing my hosting provider for an IPV6 address so that I can gain some experience. Chose with your money. If they do not get the picture in 2014, they will never get it. The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. The part that 'masquerading' adds in your 'security strategy' is connection tracking. Not the actual act of translating addresses; they actually make your box wide open. I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. If you do not trust machines connection to your local network then you should fix that hole in the fence. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Instead of disabling IPv6, just firewall it: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT If you consider disabling IPv6, you should also disable all kinds of drivers, TCP/IP variants, etc. As that is then the same 'protection' you are asking for. More importantly though: it is 2014, IPv6 has been available to the general public for almost 20 years (6bone is from 1996-ish). Use it. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 10:45, Rogier Wolff wrote: On Mon, Apr 28, 2014 at 09:43:40AM +0200, Jeroen Massar wrote: Note that there are a variety of forums that are a much better place than a Debian mtr package bug report for these kind of questions. I'm not asking for help. I'm trying to communicate that I think that disabling IPV6 is a valid configuration. I fully agree with the decisions upstream in debian to enable IPV6. But you should respect those that may have reasons to disable it. But then you should not expect everything to 'just work'. In the same way, that some people want to disable IPv4, which in the current Linux kernel cannot work. [..] Unless somebody sets up a router advertisement to announce a prefix (for which they need local access to the network), your host will only have a link-local (fe80::/10) address, which means the adversary has local access to your network. I could look this up in under 60 seconds. But I haven't. You might want to; uninformed comments are not nicely accepted by most people and tend to get ignored. If you can't bother to spend time, then don't waste that of other people. See https://en.wikipedia.org/wiki/Link-local_address for the details about link-locals. So when my machine asks for an IPV6 address on the link it gets one. If I'd look it up I'd see it was a link-local address. I'm guessing similar to the 192.168.x.y that I'm using for IPV4 that they won't work outside my home network. Similar to 169.254.0.0/16 actually. Indeed, link-locals are not routable (and NATting them is in IPv6 quite tricky to, as some networks stacks really do not route them and set the TTL of packets to 1 to enforce that). So how do I know that when I boot tomorrow my machine won't get a routable IPV6 address? I don't. Not if you cannot trust your local network indeed. But the problem there is that you are trusting your local network. Simple solution to all of it: install a IPv6 firewall: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT ip6tables -A OUTPUT -j REJECT [..] The we need to switch to IPV6 NOW crowd lost credibility with me when they announced we'll have serious trouble in XXX time when we'll run out of IPV4 addresses. This was announced three years in a row, with XXX always less than 12 months. I haven't heard about the IPV4 addresses running out for about a year now. Is the new announcement going out soon, or did I miss one? Only this crucial one a few days ago: https://www.arin.net/announcements/2014/20140423.html Note that the other RIRs are already running on fumes for IPv4 for much longer... Those warnings are there to warn people to get their game up and finally do something. If you start now, you (or the companies/organisations/etc you hear from) are late. The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. The part that 'masquerading' adds in your 'security strategy' is connection tracking. Not the actual act of translating addresses; they actually make your box wide open. The masquerading part helps my security: My machine thinks its address is 192.168.x.y, and besides people on or very close to my network, nobody will be able to get packets with that addres to travel to my machine. You are oh so wrong. What is they referring to in they actually make...? they = The mechanism of NAT / masquerading You're saying that masquerading makes my machine wide open? Bingo. It is no more secure than putting it directly on the network. See amongst others http://samy.pl/pwnat/ Are you following the microsoft tactic that OUTgoing connections need to be firewalled? No. Because if something is able to make an outgoing connection the game is already lost as somebody is on the machine already. Sure. On my phone I install apps that should not be connecting to the internet on a whim. But on my PC I'm more afraid of the 4 billion internet-users out there, one of which might try to connect to a service on my machine. At the moment that try to connect they are now blocked because I don't have a routable internet address. As you perform NAT, it does have a *reachable* address though. See the pwnat above for the details. I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. If you do not trust machines connection to your local network then you should fix that hole in the fence. My provider will, at some time between 2010 and 2020 decide to enable IPV6 to their clients. I don't want to have to be there at the moment they decide to enable it. Then install a firewall. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Instead of disabling IPv6, just
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 13:07, Rogier Wolff wrote: On Mon, Apr 28, 2014 at 12:02:50PM +0200, Jeroen Massar wrote: You're saying that masquerading makes my machine wide open? Bingo. It is no more secure than putting it directly on the network. See amongst others http://samy.pl/pwnat/ If I run software on a server inside the NAT it can give away access to resources behind the NAT. #!/bin/sh while true ; do lynx -dump http://www.somedomain.com/lkjasdfkj | sh sleep 60 done This gives access to my machine to anyone who can register somedomain.com and install something on the link. [..] That is not giving access, that is providing full control. But the same can be achieved in various other ways and all of those are independent of a NAT existing. It indeed demonstrates that a NAT is in no way secure, especially if you have a user dumb enough to run something like the above on their machine. [..] That is what this ticket is about: you caused a problem, as the tool expects there to be IPv6 support, even if it won't use it. There is a bug in MTR that it will try to open IPV6 sockets for name server communication even when explcitly told to do IPV4 only. I disagree with closing the bug as user-error. It is only a user-error from the perspective of disabling a current protocol. If you disable IPv4 your host won't even boot, even if you want it to be IPv6 only. Using IPv6 support of the networking API (getaddrinfo() and friends) is a standard way of porting applications to support both IPv4 and IPv6. Disabling IPv6 in the kernel removes that functionality and thus applications that use it are 'broken'. The user decided this, against the defaults that work. Note that this also happens with various versions of Apache in combinations with newer glibc and older kernel editions for instance. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 14:26, Rogier Wolff wrote:
On Mon, Apr 28, 2014 at 02:00:47PM +0200, Jeroen Massar wrote:
It is only a user-error from the perspective of disabling a current
protocol. If you disable IPv4 your host won't even boot, even if you
want it to be IPv6 only.
Using IPv6 support of the networking API (getaddrinfo() and friends) is
a standard way of porting applications to support both IPv4 and IPv6.
mtr doesn't use getaddrinfo. For a reason. Not a good reason, but
for a reason.
Line ~418 of mtr.c (mtr-0.85 from a quick apt-get source mtr-tiny):
8---
#ifdef ENABLE_IPV6
/* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
bzero( hints, sizeof hints );
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo( Hostname, NULL, hints, res );
---8
also note that I stated getaddrinfo() and friends, to spell it out, I
mean: RFC3493 (http://www.ietf.org/rfc/rfc3493.txt) which contains a set
of functions to support IPv6 along with IPv4 in a mixed environment.
But to get back to the original bug report:
8-
void dns_open(void)
{
int option,i;
if (!dns) return;
MY_RES_INIT();
if (!myres.nscount) {
fprintf(stderr,No nameservers defined.\n);
exit(-1);
}
myres.options|= RES_RECURSE | RES_DEFNAMES | RES_DNSRCH;
resfd = socket(AF_INET, SOCK_DGRAM, 0);
if (resfd == -1) {
fprintf(stderr,
Unable to allocate IPv4 socket for nameserver
communication: %s\n,
strerror(errno));
exit(-1);
}
#ifdef ENABLE_IPV6
resfd6 = socket(AF_INET6, SOCK_DGRAM, 0);
if (resfd6 == -1) {
fprintf(stderr,
Unable to allocate IPv6 socket for nameserver
communication: %s\n,
strerror(errno));
exit(-1);
}
--8
As such, defining ENABLED_IPV6, causes unconditionally that IPv6 support
is compiled in, but also that that resolver socket is always enabled and
required.
Hence, when your kernel is IPv6 disabled, you do not get that socket and
mtr aborts.
The question to that code becomes:
a) is -4 intended only to indicate the target to be traced
b) does -4 also mean force reverse resolve through IPv4
Like other tools that do similar things, I suggest it is a), as one
could have IPv4 traffic, while doing DNS over IPv6.
As such, keep your kernel IPv6 enabled.
As stated above in this thread already: patches are welcome!
Greets,
Jeroen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
Klaus Ethgen wrote: But serious, I have no way to file a proper patch as I might accidental break IPv6 stuff as I have no real running IPv6. (My tunnel I have is broken everytime as init7, that provides it for sixxs, seems to not expect long running tunnels and breake it from time to time. So I do not know if the connection through init7 is a proper IPv6. To be true, I even care just a little about IPv6. ;-) This seems completely unrelated to mtr or let alone Debian... If your tunnel is broken, then report that to SixXS, there is a nice ticket system at https://www.sixxs.net/tickets/. Do provide actual details instead of making factless statements in the Debian bug system. I am one of the users of the chzrh02 PoP and is working like a charm. And the rare of chance that it does not, it typically gets reported by multiple users and also resolved very quickly. Init7 definitely does care. If you thus have issues, it definitely is something you have to look into. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745060: xbmc 13 does not render content while xbmc12 does (nvidia ION2)
Package: xbmc Version: 2:13.0~beta2+dfsg1-1 Severity: normal Hola, Just quickly tested XBMC 13 from unstable (2:13.0~beta2+dfsg1-1), on a Zotac ID41 (Intel Atom D525 / nvidia ION2). It starts, menus work etc, but playing videos with hardware acceleration (VDPAU/VAAPI) does not work. Disabling VDPAU/VAAPI in the XBMC settings allows playing the video, but of course on that platform anything with a little bit of resolution drops frames like crazy ;) Hence, this is mostly a note that there is a bug with XBMC13 on at least this platform and vdpau Thus for people who want to upgrade to xbmc13 on this platform, you might want to have this bug resolved first ;) This could be related to VDPAU, or just a regression in XBMC. Googling for the error does pop up some similar reports, but the typical answer is to disable VDPAU/VDAPI, this while XBMC12 works fine. See below the excerpt from the xbmc log what goes wrong with my langlauf movie. Note that XBMC does not crash, it just does not render the movie; Subtitles (having non-english speaking relatives is fun ;) do render btw. Hitting stop will nicely return one back to the menus so one can try another one. Greets, Jeroen -- Related packages: nvidia-* / nvidia-kernel-dkms etc 331.49-1 linux-image-3.13-1-amd643.13.10-1 vdpau-va-driver 0.7.3-2 libvdpau1 0.7-1 15:18:41 T:140329912658240 NOTICE: DVDPlayer: Opening: /archive/movies/2014-01-15-langlaufen.mkv 15:18:41 T:140329912658240 WARNING: CDVDMessageQueue(player)::Put MSGQ_NOT_INITIALIZED 15:18:41 T:140327696451328 NOTICE: Thread DVDPlayer start, auto delete: false 15:18:41 T:140327696451328 NOTICE: Creating InputStream 15:18:41 T:140327696451328 NOTICE: Creating Demuxer 15:18:41 T:140327696451328 NOTICE: Opening video stream: 0 source: 256 15:18:41 T:140327696451328 NOTICE: Creating video codec with codec id: 28 15:18:41 T:140327696451328 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 15:18:41 T:140327688058624 NOTICE: Thread VideoReferenceClock start, auto delete: false 15:18:42 T:140327696451328 NOTICE: Creating video thread 15:18:42 T:140327679665920 NOTICE: Thread DVDPlayerVideo start, auto delete: false 15:18:42 T:140327679665920 NOTICE: running thread: video_thread 15:18:42 T:140327696451328 NOTICE: Opening audio stream: 2 source: 256 15:18:42 T:140327696451328 NOTICE: Finding audio codec for: 86020 15:18:42 T:140327696451328 NOTICE: Creating audio thread 15:18:42 T:140327386085120 NOTICE: Thread DVDPlayerAudio start, auto delete: false 15:18:42 T:140327386085120 NOTICE: running thread: CDVDPlayerAudio::Process() 15:18:42 T:140327696451328 NOTICE: Opening Subtitle stream: 3 source: 256 15:18:42 T:140327386085120 NOTICE: Creating audio stream (codec id: 86020, channels: 2, sample rate: 48000, pass-through) 15:18:42 T:140327679665920 NOTICE: fps: 23.976024, pwidth: 1920, pheight: 1040, dwidth: 1920, dheight: 1040 15:18:42 T:140327679665920 NOTICE: Display resolution ADJUST : HDMI-0: 1920x1080 @ 23.97Hz (20) (weight: 0.000) 15:18:44 T:140327386085120 ERROR: CDVDAudio::AddPacketsRenderer - timeout adding data to renderer 15:18:44 T:140329912658240 ERROR: GLX: Same window as before, refreshing context 15:18:44 T:140329912658240 NOTICE: Using GL_TEXTURE_2D 15:18:44 T:140329912658240 NOTICE: GL: Using VAAPI render method 15:18:44 T:140329912658240 NOTICE: GL: NPOT texture support detected 15:18:44 T:140329912658240 NOTICE: GL: Using GL_ARB_pixel_buffer_object 15:18:44 T:140329912658240 ERROR: CLinuxRendererGL::UploadVAAPITexture - failed to copy surface to glx 2 - resource allocation failed 15:18:44 T:140329912658240 ERROR: Previous line repeats 1 times. 15:18:44 T:140329912658240 ERROR: CLinuxRendererGL::UploadVAAPITexture - failed to copy surface to glx -1 - unknown libva error 15:18:44 T:140329912658240 ERROR: Previous line repeats 2 times. 15:18:44 T:140329912658240 ERROR: CLinuxRendererGL::UploadVAAPITexture - failed to copy surface to glx 2 - resource allocation failed 15:18:44 T:140329912658240 ERROR: CLinuxRendererGL::UploadVAAPITexture - failed to copy surface to glx -1 - unknown libva error 15:19:42 T:140329912658240 ERROR: Previous line repeats 1363 times. 15:19:42 T:140329912658240 NOTICE: CDVDPlayer::CloseFile() 15:19:42 T:140329912658240 NOTICE: DVDPlayer: waiting for threads to exit 15:19:42 T:140327696451328 NOTICE: CDVDPlayer::OnExit() 15:19:42 T:140327696451328 NOTICE: DVDPlayer: closing audio stream 15:19:42 T:140327696451328 NOTICE: Closing audio stream 15:19:42 T:140327696451328 NOTICE: Waiting for audio thread to exit 15:19:42 T:140327386085120 NOTICE: thread end: CDVDPlayerAudio::OnExit() 15:19:42 T:140327696451328 NOTICE: Closing audio device 15:19:42 T:140327696451328 NOTICE: Deleting audio codec 15:19:42 T:140327696451328 NOTICE: DVDPlayer: closing video stream 15:19:42
Bug#745060: xbmc 13 does not render content while xbmc12 does (nvidia ION2)
On 2014-04-17 21:03, Bálint Réczey wrote: [..] Thus for people who want to upgrade to xbmc13 on this platform, you might want to have this bug resolved first ;) This could be related to VDPAU, or just a regression in XBMC. Googling for the error does pop up some similar reports, but the typical answer is to disable VDPAU/VDAPI, this while XBMC12 works fine. [..] This problem has been reported as #742896 , but using the radeon driver. I planned setting up an nVidia config, but thanks to you I don't have to. Hence, why filing a bug is a good thing ;) (also because google indexes them really well, and then people might find a solution easier or avoid upgrading as they can see there is a problem it is in the experimental branch for a reason ;) Upstream's position is that it is a Libav bug, since the video plays fine with the embedded ffmpeg copy shipped with vanilla XBMC. Makes sense; (I quite understand btw why they do not like maintaining multiple video libraries) I have to agree with them thus I hereby reassign both bugs to libav. If this is a result of API difference between FFmpeg and Libav, please help me out, too. I had not noticed that libav10 was being used; I checked and indeed it is libav10 that it is linked against. Is libav10 a requirement, as otherwise linking to libav9 might be an option that might just work ;) (and would exclude in a way if the fault is in xbmc or libav...) Reinhard Tartler wrote: I am having a hard time seeing from this report what the problem is. I guess that you mean what is causing it rather than the problem, as the problem is easy: no rendering as something fails (likely libav) With no crash dump or otherwise extended details that is indeed going to be hard. One would have to either modify xbmc to print out all the arguments passed to the API calls. At least, the good thing is that it is checking the results of the calls and hence reporting an error. What API is at fault here? can you provide a minimal example program that demonstrates what the problem is? I am just a user in this case, the minimal program would also be quite hard to do I think... as well video stuff is never minimal. Now... if you had a minimal example program, I would be quite willing to try that out of course and see if that exhibits the same problem. I don't seem to find a simple example in the libav sources. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740895: Can't configure both IPv4 + IPv6 with preseed
Package: netcfg The preseed options are: d-i netcfg/get_ipaddress string IP d-i netcfg/get_gateway string GW d-i netcfg/get_netmask string NM d-i netcfg/get_nameservers string NS This allows specifying either IPv4 or IPv6, but not both, hence you get an IPv4-only or an IPv6-only node. While that is pretty good already, the world will be IPv4 for a long long time to come and IPv6 is really great to preconfigure. Hence, one will at the moment need to fix this up with a preseed/late_command. Unfortunately, it seems that late_command runs before netcfg overwrites the interfaces file, hence, unless you trick it all with a very early init script, it won't work... Either late_command has to go after the netcfg writing of the interfaces file, or better we should have the option of multiple addresses. d-i netcfg/get_ipaddress string 192.0.2.2 2001:db8::2 d-i netcfg/get_gateway string 192.0.2.1 2001:db8::1 d-i netcfg/get_netmask string 24 64 d-i netcfg/get_nameservers string 192.0.2.1 2001:db8::1 would be a good start for that. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740896: Disable IPv6 autoconf completely from preseed/netcfg
Package: netcfg As one cannot easily update /etc/network/interfaces due to netcfg overwriting it after late_command (see also #740895) it would be useful if we can have something akin to: iface eth0 inet static ... pre-up echo 0 /proc/sys/net/ipv6/conf/eth0/autoconf pre-up echo 0 /proc/sys/net/ipv6/conf/eth0/accept_ra pre-up echo 0 /proc/sys/net/ipv6/conf/eth0/accept_ra_defrtr pre-up echo 0 /proc/sys/net/ipv6/conf/eth0/accept_ra_pinfo pre-up echo 0 /proc/sys/net/ipv6/conf/eth0/accept_ra_rtr_pref ... in the preseed. #740895 = https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740895 Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740895: Work-around for netcfg overwriting /etc/network/interfaces after preseed/late_command
As per http://comments.gmane.org/gmane.linux.debian.user/456234 a little work-around: 8-- d-i preseed/late_command string \ in-target *DOSTUFF*; \ cp /target/etc/network/interfaces /etc/network/interfaces; --8 That way it overwrites the netcfg generated one. Hence, a similar bug is reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709017 Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739594: FD_SET / FD_ISSET warning: signed and unsigned type in conditional expression [-Wsign-compare]
Package: libc6-dev Version: 2.17-96 Severity: wishlist Enabling HARDENING_FLAGS enables -Wsign-compare, this results in: warning: signed and unsigned type in conditional expression [-Wsign-compare] for the FD_SET and FD_ISSET macro as the include file forces 'int' computation on an array: current macro: #define __NFDBITS (8 * (int) sizeof (__fd_mask)) #define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp) replace it with: #define __NFDBITS (8 * (unsigned int) sizeof (__fd_mask)) #define FD_SET(fd, fdsetp) __FD_SET (((unsigned int)fd), fdsetp) And everything is fine. Changes to be made in: /usr/include/x86_64-linux-gnu/sys/select.h This might also be the case on i386 and similar platforms. Note that filedescriptors (fd) are typically defined as 'int', hence the cast to (unsigned int) for FD_SET to force that into alignment too. (yep, calling FD_SET with a -1/negative FD will cause strange issues, but you will get those anyway, and they should in theory get caught by the stack protectors) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734327: rss2email TypeError: sequence item 1: expected string or Unicode, NoneType found
Package: rss2email
Version: 1:2.71-2
Tags: patch
Ola Lindsey DebianBuggers,
I sometimes have a feed which generates:
-
=== rss2email encountered a problem with this feed ===
=== See the rss2email FAQ at http://www.allthingsrss.com/rss2email/ for
assistance ===
=== If this occurs repeatedly, send this to lind...@allthingsrss.com ===
E: could not parse http://soup.nibbler.tv/rss
Traceback (most recent call last):
File /usr/share/rss2email/rss2email.py, line 711, in run
tagline = ,.join(taglist)
TypeError: sequence item 1: expected string or Unicode, NoneType found
rss2email 2.71
feedparser 5.1.3
html2text 3.200.3
Python 2.7.6 (default, Dec 30 2013, 14:37:40)
[GCC 4.8.2]
=== END HERE ===
-
I don't know which exact line in the source RSS causes it, but it happens from
time to time; likely some parse going wrong.
Inserting at line 710 a 'print taglist' results in:
[u'image', None]
Hence the attached simple patch filters out the None and voila things keep on
working and I get my daily dose of silly pictures again thanks to nibbler ;)
Greets,
Jeroen
--- rss2email.py2014-01-06 00:35:13.652294000 +0100
+++ /usr/share/rss2email/rss2email.py 2014-01-06 00:34:10.056294000 +0100
@@ -707,7 +707,7 @@
for tag in tags:
taglist.append(tag['term'])
if taglist:
-tagline =
,.join(taglist)
+tagline =
,.join(filter(None, taglist))
extraheaders = {'Date': datehdr,
'User-Agent': useragenthdr, 'X-RSS-Feed': f.url, 'X-RSS-ID': id, 'X-RSS-URL':
link, 'X-RSS-TAGS' : tagline}
if BONUS_HEADER != '':
Bug#723699: Valgrind Bug 307082 - HG false positive: pthread_cond_destroy: destruction of unknown cond var
On 2013-09-24 12:44, Alessandro Ghedini wrote: Control: tags -1 pending On gio, set 19, 2013 at 01:39:11 +0200, Jeroen Massar wrote: Package: valgrind Tags: patch https://bugs.kde.org/show_bug.cgi?id=307082 Please apply the patch they have there, that fixes a tiny oversight in valgrind with respect to condition initialization tracking. I imported the patch in git, and will upload soon. Thanks! Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723699: Valgrind Bug 307082 - HG false positive: pthread_cond_destroy: destruction of unknown cond var
Package: valgrind Tags: patch https://bugs.kde.org/show_bug.cgi?id=307082 Please apply the patch they have there, that fixes a tiny oversight in valgrind with respect to condition initialization tracking. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717422: aiccu: let the init script be somewhat useful for NetworkManager users too
On 2013-07-20 20:32 , Maurizio Avogadro wrote: This makes the init script useless for NetworkManager users; by adding to it the LSB headers Should-Start: network-manager This sounds like something sane to do. Should-Stop: network-manager This does not entirely; stopping AICCU (thus giving up IPv6 connectivity) does not always mean you want to disconnect everything, there are networks where even AYIYA won't get out of. That said, tinc might benefit from the Should-Start addition too. OpenVPN already has this setup. [..] The soft dependency should leave the behaviorunchangedfor non-NM users; since the connection is established only once at startup, this behavior should be compatible with the strict policiesenforced by SixXS, which forbid automatic reconnections. Nothing strict about this policy, just think about if you would like it if your servers where connected to in a never ending repeating loop (at the rates of hundreds of connects per second from what we have seen) where the user of that automated restart does not realize that that is happening as something in the background is doing it; or because they think they are ubersmart and monitored some random unrelated thing on the Internet and think that restarting is needed... Please note that the policy is primarily there to protect the server from being overwhelmed with useless requests that would effectively also cause a DoS for other users of that service. The behaviour of too many restarts also indicates that the source of those requests is having a problem that should be properly resolved. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717499: Apache 2.4 changed remote_ip, use remote_host() instead
Package: netdisco-frontend /usr/share/netdisco/html/login.html line 50 will fail as Apache 2.4 does note have remote_ip anymore due to internal changes (hence 2.4 instead of 2.2). In that file instead of: my $userip= $r-connection-remote_ip; just have: my $userip= $r-connection-remote_host(); and everything will work again. This holds for netdisco 1.0 till the recently released 1.3. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692465: Interested in maintenance of aiccu
On 2013-06-08 16:16, Mike Gabriel wrote: Hi Jeroen, as a regular user of aiccu (and a DD) I will be happy to take over maintenance of the aiccu package. I will also be happy to place you guys from upstream into the Uploaders: field and train people from Sixxs in Debian packaging (and the distro workflow) if there is the need. There would be no need for that, as we know how Debian packaging works, noting that we have been 'playing' with Debian since 1.2 era (heck, I have a p200 which was upgraded from there to the current unstable ;) and that the original Debian packaging was performed by us, and then extended to support the debconf support by Gary Coady which we integrated into that packaging and then somewhere along the way it finally ended up in Debian. Please also see the note in the very bug referenced by your email: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692465#10 We still intend to do that and given some free time will come around to doing that including a full push of that work out to https://github.com/SixXS/aiccu but this all in due time, real life and work has to come first. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708416: Apache2 on 'older' kernels does not work in Debian stable
[Rolling up multiple replies into one to keep the ticket to what it is. Thanks for the very quick replies and keep up the good job! ] On 2013-05-15 20:29 , Axel Beckert wrote: Control: severity -1 important Hi Jeroen, Jeroen Massar wrote: Package: apache2 Severity: grave When upgrading to Debian stable (the one that is stable today, released recently ;) and when one still has an older kernel (2.6.26-2-686, linux-image-2.6.26-2-686 2.6.26-26lenny2) Apache fails to start mysteriously with: I'm sorry, but this is not of RC severity. Debian doesn't support dist-upgrades with skipping one release inbetween (at least not officially) and hence upgrading with kernels from oldoldstable isn't really supported either. Nevertheless thanks for reporting this issue. Understandable. I primarily filed this bug so that people can be aware of this situation when they google for this. Btw: I have a p200mmx that I once installed as Debian Bo and upgraded all the way up to the current unstable... yes, that box has been rebooted in the mean time a few times ;) I guess that truely demonstrates the power of Debian (dpkg/apt, and of course the many developers delivering high quality packages!) Please make Apache depend on a 'new' kernel. Apparently that is 2.6.30+ or better 3.2+ that provides a certain syscall that is being used. This will make the situation worse for many virtual machines where the kernel is hosted outside the virtual machine, namely on Xen DomUs which don't use pygrub or inside VServers as you cited yourself in the second mail: http://serverfault.com/questions/496989/apache-in-linux-vserver-wont-start-cant-create-socket seems such a case. And no, I don't have a better solution for that at the moment. udev for instance warns about this that one should reboot (which indeed I ignored). Apache did not warn. $ uptime 16:20:46 up 912 days, 3:38, 2 users, load average: 3.83, 2.59, 1.33 :-) Regards, Axel (sitting only a few kilometers away from you ;-) Are you sure about that? :) It depends on your definition of 'few', if 'few is 2000km, assuming you mean that you are in .ch, then it is few, otherwise it is not few :) On 2013-05-15 21:37 , Arno Töll wrote: Hi, On 15.05.2013 18:23, Jeroen Massar wrote: Package: apache2 Severity: grave sorry. No. I thought it was appropriate as: grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. As it does not start, does not have proper explanation why, I thought that correct. [..] this is bad luck, but expected. We do not support upgrades skipping a version in any way. If you are running a kernel from Lenny, you cannot (and should not) expect it is being able to run a much newer user land. I half-expected this (as it happened with a lot of other stuff before), but as apt/dpkg do not notify one that one has to reboot and the binary starts it is not expected. You noticed this problem for Apache, but in reality there are plenty of packages making use of syscalls introduced in later kernel versions. Some random examples include, but are not limited to lvm, udev, libc6 and by chance many, many more. Oh yes. Linux andromeda 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686 GNU/Linux $ uptime 16:20:46 up 912 days, 3:38, 2 users, load average: 3.83, 2.59, 1.33 I am not sure this is something to be proud of, or even more so telling to the public that you are running a kernel which saw no security upgrades for 3 years (and yes, there are issues). That would be proud of Debian allowing user-space upgrades to go forward and keep the box up and running all the way ;) There are definitely issues, but a box that works great typically does not get a reboot. It did so now though, and indeed it was about time. Note that that box is in an environment that it is really not reachable from the outside or anything untrusted, thus the risk of a remote or even local (if one could get access to it) kernel exploit was/is very low. There is also consensus in Debian not do depend on any particular kernel version. [That kind of contradicts the 'don't use an old kernel' version ;) but I assume you mean no particular semi-current version ] There is no reliable way to please everyone running Debian in every setup. Just to note some random examples, where dependencies against a kernel package would break: - chroots - virtual machine environments - self-built kernels And finally, as you noted yourself: Having a kernel INSTALLED and having that kernel BOOTED is a different kind of story. I fully agree, it is a very difficult thing to resolve properly. If you still believe this is something which should be addressed, try to find project-wide consensus. For example, I could imagine that libc6 maintainers provide a runtime check running in their maintainer scripts testing
Bug#708416: Apache2 on 'older' kernels does not work in Debian stable
Package: apache2 Severity: grave When upgrading to Debian stable (the one that is stable today, released recently ;) and when one still has an older kernel (2.6.26-2-686, linux-image-2.6.26-2-686 2.6.26-26lenny2) Apache fails to start mysteriously with: [Wed May 15 16:15:03 2013] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null) Syntax error on line 9 of /etc/apache2/ports.conf: Line 9 is simply the very good and old Listen 80. Please make Apache depend on a 'new' kernel. Apparently that is 2.6.30+ or better 3.2+ that provides a certain syscall that is being used. By depending on it, one does not get to upgrade and then in being forced to suddenly have to reboot a box which is just running fine: Linux andromeda 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686 GNU/Linux $ uptime 16:20:46 up 912 days, 3:38, 2 users, load average: 3.83, 2.59, 1.33 Oh yes, as you can see, it has load and is quite heavily used too even though at the moment Apache is down, but all redirected with courtesy of nginx. Will reboot tomorrow into a fresh 3.2 when people are on site to peek at it. For the record, this was the only issue that I had when upgrading that box from the older stable to the current one, thus great works folks! $ dpkg --list|grep apache ii apache2 2.2.22-13 i386 Apache HTTP Server metapackage ii apache2-mpm-prefork 2.2.22-13 i386 Apache HTTP Server - traditional non-threaded model ii apache2-utils2.2.22-13 i386 utility programs for webservers ii apache2.2-bin2.2.22-13 i386 Apache HTTP Server common binary files ii apache2.2-common 2.2.22-13 i386 Apache HTTP Server common files $ dpkg --list|grep linux-image ii linux-image-2.6.26-2-686 2.6.26-26lenny2 i386 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 ii linux-image-3.2.0-4-686-pae 3.2.41-2 i386 Linux 3.2 for modern PCs ii linux-image-686 3.2+46 i386 Linux for modern PCs (dummy package) ii linux-image-686-pae 3.2+46 i386 Linux for modern PCs (meta-package) Yes, 3.2 is ready to be rebooted into, but rebooting is for wussies and unstable things ;) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708416: Acknowledgement (Apache2 on 'older' kernels does not work in Debian stable)
Update, as stated here: http://serverfault.com/questions/496989/apache-in-linux-vserver-wont-start-cant-create-socket and thus in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=516331 The problem is the kernel you have (too old). It doesn't have accept4(), dup3() and epoll_create1() functions. Thus that means about 2.6.28 being the minimum as that is where accept4() was introduced. Re-building libapr on the box with the old kernel solves this issue. As such, a Pre-Depends on a linux-image = 2.6.28 is the minimal thing to do for this bug. Unfortunately that does mean that for instance my case with an old 2.6 kernel and a installed, but not in use, newer kernel would still be overseen... Possible alternative solutions: - fix apr to fall back to old versions of the function, at runtime not at build-time. - have an running kernel version check and notify the admin that the kernel is too old - enhance the error message to mention that the kernel is outdated. It is sort of annoying for people who upgrade their live boxes and then find out. (did not hurt in our case as they are all failovered anyway) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705320: lxc-start fails when config + rootfs dirs are read-only
On 2013-04-15 14:01 , Daniel Baumann wrote: lxc cannot know if the user wanted it ro or not before the container has been started into the system entirely, especially since there's a wild use of aufs or overlayfs with (shared) ro rootfs between containers. I agree that the *rootfs* might have that situation. But note that the config dir apparently has to be read/write too. The error/warning messages/notices that are shown when one starts with 'lxc -n name' are all related to the network interface. There is no warning to the effect that a read only filesystem is causing this failure as apparently some state cannot be properly written and one thus is looking at network errors but that is not the cause of this. Finding out that the ro flag is the problem is thus quite difficult and one just has to look in the right location for it to be found. As such, it would be really nice if there is an error/notice shown that the filesystem is read-only and that that causes the error. Hopefully this bug will be found by people who google for related issues though... Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705320: lxc-start fails when config + rootfs dirs are read-only
Package: lxc Version: 0.9.0~alpha3-2 Severity: wishlist lxc-start -n container fails to start when the filesystem is read-only. Yes, that is a stupid thing (hence wishlist :) to have it that way but it goes unnoticed as there is no error notice and the setup then fails silently... Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702374: Should be announced in /usr/share/doc/postfix/NEWS.Debian
IMHO, this is one of those changes that should be noted in NEWS.Debian.gz Automatically changing a configuration is IMHO not a good idea especially as configuration statements can be quite complex and also because there are these people who maintain their configurations in a repository... Greets, Jeroen (who just got bit by it too, fortunately it did not toss away mail in my case as it only hit sasl-users) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620756: Mail-Followup-To /
[1] http://lists.debian.org/debian-project/2011/03/msg00065.html Seems to point somewhere called DELL and does not seem to relate to the thread mentioned here. As Debian uses mailman for their mailinglists, are people aware that it is has a Receive your own posts to the list? option? If one would disable that (thus setting = No), you will not get a copy of a mail sent to the list and where your destination is already in the To/cc. Note that this can be set globally/per-list in mailman. One then does not even have to guess that somebody does or does not want to receive a direct copy. As mentioned in the ticket setting Mail-Followup-To: avoids getting a copy too. Additionally the current code of conduct: http://www.debian.org/MailingLists/#codeofconduct has the following line: Do not send automated out-of-office or vacation messages. While there are apparently some people sending automated 8-- I'm subscribed to the list, no need to CC me: http://www.debian.org/MailingLists/#codeofconduct No need to reply to this message. --8 I suggest that people who are able to automatically send that kind of things should at least do one of the above two things... Alternative option: is there a addon to Thunderbird which makes/forces Reply-All to behave like Reply-To-List for debian.org mailinglists? Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481898: RFS: zkt -- A tool to manage keys and signatures for DNSSEC-zones
reopen 481898 jer...@massar.ch reassign 481898 sponsorship-requests owner 481898 jer...@massar.ch retitle 481898 RFS: zkt -- A tool to manage keys and signatures for DNSSEC-zones severity wishlist tags 481898 + patch thanks Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for the package zkt: * Package name: zkt Version : 1.1.2d Upstream Author : Holger Zuleger holger.zule...@hznet.de * URL : http://www.hznet.de/dns/zkt/ * License : BSD-3-clause Section : net It builds these binary packages: zkt - DNSSEC Zone Key Tool To access further information about this package, please visit the following URL: http://mentors.debian.net/package/zkt Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/z/zkt/zkt_1.1.2c.dsc The source of this all, changelogs etc, can be found here: https://github.com/massar/zkt/ There is an old ITP bug report here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481898 But the intent was never fulfilled, thus, hereby, a fully working package ;) Looking forward to comments/questions etc. Regards, Jeroen Massar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636691: Balance board PATCH
As mentioned on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cwiid/+bug/509246 and: https://github.com/abstrakraft/cwiid/issues/2 The working fix: https://launchpadlibrarian.net/115501163/balanceboard.patch Apply it, recompile, happy balance board. Upgrading to a current version would also do the trick of course (now only to resolve the automatic connect portion) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698913: Quagga SEGV (possibly due to logrotate SIGUSR1)
Package: quagga Severity: high High severity as quagga gets killed, which it should not be doing... Stack trace below. I guess the below (and thus quagga dying) comes from the logrotate script, which sends a kill -SIGUSR1 every once in a while. /etc/logrotate.d/quagga has: kill -USR1 `cat /var/run/quagga/$i.pid` USR1 is 10 though, SIGSEGV is the 11 listed below It does not happen all the time, but it does happen often enough to be quite annoying. Hence having a /etc/cron.d/quagga_restarter with 8-- # /etc/cron.d/quagga_restarter: restart Quagga if is dead */1 * * * * root [ ! -e /var/run/quagga/bgpd.pid ] || [ ! -f /proc/`cat /var/run/quagga/bgpd.pid`/exe ] /etc/init.d/quagga restart ---8 to restart bgpd when it dies... Greets, Jeroen -- BGP: Received signal 11 at 1359074051 (si_addr 0x0); aborting... Backtrace for 13 stack frames: /usr/lib/libzebra.so.0(zlog_backtrace_sigsafe+0x3e)[0x7fccd8082b07] /usr/lib/libzebra.so.0(zlog_signal+0x234)[0x7fccd8083081] /usr/lib/libzebra.so.0(+0x364c9)[0x7fccd808b4c9] /lib/libc.so.6(+0x32230)[0x7fccd7460230] /usr/lib/libzebra.so.0(sockunion_cmp+0x1)[0x7fccd807683b] /usr/lib/quagga/bgpd(+0x442da)[0x7fccd85152da] /usr/lib/quagga/bgpd(+0x4473e)[0x7fccd851573e] /usr/lib/quagga/bgpd(+0x44a77)[0x7fccd8515a77] /usr/lib/libzebra.so.0(work_queue_run+0xb5)[0x7fccd808beec] /usr/lib/libzebra.so.0(thread_call+0x67)[0x7fccd807880b] /usr/lib/quagga/bgpd(main+0x3fc)[0x7fccd850192f] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fccd744cc8d] /usr/lib/quagga/bgpd(+0x30985)[0x7fccd8501985] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693409: git broken in combination with curl 7.28, please upgrade to curl's git version which fixes this
Package: curl Version: 7.28.0-1 Severity: important Control: affects -1 git (tagged important as most git users will be affected by this, patch is available, thus should be easy to fix and relieve lots of folks ;) Git cannot do proper authenticated smart-http as there is a bug in curl which causes it to not do re-authentication. SourceForge discussion of this issue: http://sourceforge.net/tracker/index.php?func=detailaid=3577557group_id=976atid=100976 The error will look like: 8- $ git push Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 759 bytes, done. Total 7 (delta 6), reused 0 (delta 0) error: RPC failed; result=22, HTTP code = 401 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date -8 Which will leave you puzzled and googling and trying to re-setup your server side while it really is the client side, or more importantly, curl and then the library version of it, which is the issue libcurl3-gnutls_7.27.0-1_amd64.deb works libcurl3-gnutls_7.28.0-1_amd64.deb does not. Please update to the current git version of curl. As a work-around for folks, installing the libcurl3-gnutls_7.27 or lower will work, thus check /var/cache/apt/archives/ if you still have it ;) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692465: Managing aiccu through mentors.debian.net
Daniel Echeverry wrote: To maintain a package, you must follow a set of step as described in this link [1] However, if you want, I could help you to maintain the package for debían, I'm not a DD but I have been packing for a long time. We could do it together because in debian, A package can have multiple maintainers :) Daniel, aiccu has Debian packaging information in the upstream (SixXS, our) source archives since it's inception and first releases[1], as well, we are heavy Debian users ourselves for a too long time, thus we know how to package things quite well ;) We also where informed that several DD's are very willing to mentor uploads of aiccu into Debian thus thanks for the offer, but that base is also covered. Thus the only (ahem, it is not that easy) thing to do now is to finalize the next aiccu version, go again through all the bug trackers to see what is left and resolve those matters and then to test it on all platforms, push it to github as we have stated and release the next version. Greets, Jeroen [1] http://www.sixxs.net/tools/aiccu/changelog in 2004-09-09-beta2a there where fixes for debian packaging and in 2005-08-14 debconf support was added. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692465: Managing aiccu through mentors.debian.net
Hi, We (SixXS), who are heavy Debian users ourselves for years and more importantly for this, the authors of aiccu, are very willing to take over the packaging details and bug tracking resolving portions for aiccu. We are in the process of finalizing the long long overdue of minor fixes but more importantly a lot of new features for AICCU that have been added since the last release and pushing our full repo to: https://github.com/SixXS/aiccu to make the AICCU development process a lot more open and transparent by making use of the various features that github offers (git repo, bug tracker, patch integration etc). From that repo we'll be releasing new versions of AICCU and the (Debian) packages associated with it. We'll also push these to mentors.debian.net so that those changes can directly be integrated into Debian and Ubuntu by a mentor who is willing to accept them. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689584: Please remove sleep patch which does not work and does not resolve any problem
Package: aiccu Severity: normal Creating a new bug as 531003 is archived and thus can't comment there any more unfortunately. Related links: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531003 https://bugs.launchpad.net/bugs/1058883 Original Message Subject: Please remove sleep patch which does not work and does not resolve any problem Date: Thu, 04 Oct 2012 00:52:26 +0200 From: Jeroen Massar jer...@unfix.org To: 531...@bugs.debian.org, 1058...@bugs.launchpad.net [Caleb: thanks for finding the origin of this fix] So it seems this sleep fix, by just restarting (I thought Debian was not an ancient Microsoft product where one just reboots all the time), which was not tested is now causing issues for people: https://bugs.launchpad.net/bugs/1058883 Would it not be prudent to revert such a patch, or better, never have applied it if the patch was not tested or proven working at all?!? It seems there are no logs or other details included about this issue, just a it does not work and I restart it now it works and then a patch for just restarting it. Would be great if there actually where logs for this issue or other details that would demonstrate the problem. Maybe time to remove this patch? As I have stated in various places: AICCU does not need to be restarted, the protocols used should handle it, that is why those protocols, exist. If the tunnel 'breaks', please provide details of what is broken so that the real problem can be addressed just restarting it does not resolve such a problem. Bigger note: If anybody has logs which demonstrate breakage please provide them, then I can take those situations along in the testing of the new AICCU. I've added to the to-check list to check with Virtualbox how a acpisleepbutton event affects the state of AICCU, thus lets see what the result of such a test is (best I can do, no Linux on a laptop anywhere near me at the moment... but this should be similar) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688511: Routing Table support
Hi, I'll handle this upstream in AICCU (I always wonder why folks ask for new features in distro bug reports and not at the source...) It should be possible to do this cleanly by having a special routingtable option as per (5). I'll add (2) too, I am actually a bit surprised myself that variables (local_ip and subnet prefix etc) are not exported yet. Then again setupscript is not really used that much yet. I'll see if (4) 'unsetup' script can be done. I do not get what you want to achieve with (3). Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687520: Current Debian 1.4.0-2, Official version: 2.1.0
Package: ndpmon The ndpmon project has been restarted and new features have been added. On http://ndpmon.sourceforge.net/ it is stated that it is in Debian, which technically is true, but not at all for the latest version, let alone that it is in anything but unstable. Can somebody update this to make it current in Debian and possibly available outside of unstable? Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497210: FYI: upstream aiccu addresses these bugs in next release
Just a FYI, upstream aiccu addresses this problem in the next release that we are preparing and then also releasing to github at: http://github.com/SixXS/aiccu As such, this matter can be closed by then. See http://www.sixxs.net/tools/aiccu/changelog for all the changes that have already been made. We'll be releasing the next version after proper testing of all changes have been made though which might take a bit more depending on time available. Btw, for #497210, the new version does caching of the TIC parameters, as such, only when those expire will a 'broken/non-responding tic server' be an issue. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497211: Unsure how to get these bugs 'resolved'
Hi, I was going to the bugs list for aiccu, and I am honestly unsure what is expected for these bugs to be resolved. 497211 - syslog logs multiple lines, the lines are logged, what else is expected? 499920 - very custom option used by very few people if any, very bad practice too as it mangles ICMP responses and other such things too which can magically start breaking things. = wontfix I think these bugs can be closed if there is no further/more information provided what is wished here. As noted in other bugs reports: Please see http://www.sixxs.net/tools/aiccu/changelog for all the changes that have already been made. We'll be releasing the next version into github at http://github.com/SixXS/aiccu after proper testing of all changes have been made though which might take a bit more depending on time available. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678519: Changing Recommands NTP to Depends NTP
Just a FYI, in upstream aiccu(*) we changed the recommends into a depends. The only problem with a depends like this is that when running AICCU inside a VM that does not have it's own clock and thus where the clock is managed by the dom0/host which might have ntp installed. As such, we might want to have a way install a 'vm-synced-by-host' package or something, thus a simple empty package that provides time-daemon functionality but actually does nothing to satisfy dependencies like this for software that requires accurate time (eg openssl, pgp and various crypto tools) and come into this situation. Greets, Jeroen * = see http://www.sixxs.net/tools/aiccu/changelog for all the changes that have already been made. We'll be releasing the next version after proper testing of all changes have been made though which might take a bit more depending on time available. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678519: AICCU should depend on 'ntp'
For both heartbeat and AYIYA tunnels a synchronized clock is a must. As such, changing the Recommends: ntpdate | ntp | time-daemon into a Depends: ... fixes the issue of clock-skew while running. I am actually surprised that it is just a recommends should really be a full dependency. Note that as AICCU is not a time-keeping tool it will not set the time based on external sources. This also as an adversary could replay packets and thus would be able to slow time down that way or otherwise impact it. There is no real solution to that it seems as NTP is typically not crypted either. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685550: Please update nsd3 to upstream 3.2.13 - fixes VU#517036 CVE-2012-2979 and segfault
On 2012-08-24 09:38, Julien Cristau wrote: Control: severity -1 wishlist On Tue, Aug 21, 2012 at 22:40:36 +0200, Jeroen Massar wrote: Package: nsd3 Severity: critical Without justification, not quite. From the initial message: Bugfix #461 (VU#517036 CVE-2012-2979): NSD denial of service vulnerability from DNS packet when using --enable-zone-stats. Bugfix #460: man page correction - identity. Fix for nsd-patch segfault if zone has been removed from nsd.conf (thanks Ilya Bakulin) One would think that is critical enough to take the 5 minutes to update the tar.gz from the vendor and roll a new Debian package. Anyway, in the meantime for our deployment we have done just that and put them in our private repo and deployed that on our servers. Thank you for your concern! Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685550: Please update nsd3 to upstream 3.2.13 - fixes VU#517036 CVE-2012-2979 and segfault
On 2012-08-24 11:04, Ondřej Surý wrote: [..] One would think that is critical enough to take the 5 minutes to update the tar.gz from the vendor and roll a new Debian package. But not when there is a freeze in place, since it wouldn't automatically transfer to testing and would need a manual review by release team. Aha another freeze. That explains it a bit. Note that I am never aware of these 'freezes' as we simply run unstable everywhere, as the newest tends to be the best and as long as you upgrade one box for testing first and then do the rest there are very few issues that I have had over the last 15+ years of Debian usage... Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685550: Please update nsd3 to upstream 3.2.13 - fixes VU#517036 CVE-2012-2979 and segfault
On 2012-08-22 00:50, Ondřej Surý wrote: Debian dind't enable bind9 stats so it's not vulnerable. There are people who build from the source package and who might enable this, from that perspective it would be good to upgrade to it. And there are also other fixes in that version note the segfault fix for when a zone is gone from nsd.conf. As such, it would be really nice to have a new version. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685550: Please update nsd3 to upstream 3.2.13 - fixes VU#517036 CVE-2012-2979 and segfault
Package: nsd3
Severity: critical
3.2.13 is out for a month already, might be nice to get an updated
package...
Greets,
Jeroen
--
https://www.nlnetlabs.nl/projects/nsd/
{{{
NSD 3.2.13
Jul 27, 2012
Bugfixes
Bugfix #461 (VU#517036 CVE-2012-2979): NSD denial of service
vulnerability from DNS packet when using --enable-zone-stats.
Bugfix #460: man page correction - identity.
Fix for nsd-patch segfault if zone has been removed from nsd.conf
(thanks Ilya Bakulin)
NSD 3.2.12
Jul 19, 2012
Bugfixes
Fix for VU#624931 CVE-2012-2978: NSD denial of service vulnerability
from non-standard DNS packet from any host on the internet.
NSD 3.2.11
Jul 9, 2012
Features
Fallback to AXFR if IXFR is unknown at the primary. NSD considers IXFR
unknown at the primary if there is a negative response for the IXFR
RRtype. This does not override the value for 'allow-axfr-fallback'.
Allow for reading in new DNSKEY algorithm mnemonics (RFC5155, RFC5702,
RFC5933, and RFC6605 (ECDSA)).
Zone statistics, enable with --enable-zone-stats. This stores the BIND8
stats per zone in a configurable statistics file. This option does not
scale and should therefore not be enabled when serving many zones.
Support for TLSA RRtype (DANE).
Bugfixes
Fix for qtype ANY for a wildcard domain in NSEC signed zone: Don't add
the wildcard domain NSEC into the answer section. Instead, put the
wildcard expanded NSEC into the answer section and keep the wildcard
domain NSEC in the authority section.
Fix for accept spinning reported by OpenBSD.
Fix restart failed due to bad ixfr packet because of zone removed from
nsd.conf.
Bugfix #453: typo in nsdc man page.
}}}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640528: libpam-modules /etc/security/access.conf uses live internet addresses, please replace with 2001:db8::/32
Package: libpam-modules Version: 1.1.3-2 /etc/security/access.conf contains addresses in the 2001:4ca0::/32 prefix, please per-use the official IPv6 Documentation Prefix as per RFC3849: The quick patch: s/2001:4ca0:/2001:db8:/g Similarly the RFC1918 addresses (192.168.0.0/16) should in theory also be replaced with 192.0.2.0/24, but as RFC1918 is private this is not too much of a concern. The 2001:4ca0::/32 prefix though is actually used by an organization on the Internet. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611458: softflowd 0.9.8-2 has broken NetFlow v9 support due to swapped first/last
On 2011-01-30 18:08, Adam D. Barratt wrote: [..] softflowd maintainer: given the closeness of the upcoming release, an upload fixing this in the next day or so would be appreciated; otherwise, given its a leaf package with relatively low popcon we may have to consider not including the package in Squeeze. As the 'fix' is to swap to variables in a structure as show in the buffer in the URL, then maybe a Non-Maintainer fix can resolv this issue very quickly instead of threatening with removing the package completely during a weekend? :) It is the only package in Debian that supports NetFlow v9 metering, thus that is definitely a nice feature to have. Greets, Jeroen (who is not a DD, otherwise I would have pushed those two lines in myself ) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611458: softflowd 0.9.8-2 has broken NetFlow v9 support due to swapped first/last
Package: softflowd Version: 0.9.8-2 Severity: grave softflowd 0.9.8-2 has broken NetFlow v9 support due to swapped first/last. The fix for this was applied on 3rd of May 2010: http://code.google.com/p/softflowd/source/detail?r=e416c63c4e019755387cb8fda76f562c66ceaace 8- Log message - (djm) Swap nf9 last/first switched. They were reversed in the struct vs our template flowset. Patch from stephen AT sfnelson.org. https://bugzilla.mindrot.org/show_bug.cgi?id=1760 -8 Please apply that patch so that NetFlow 9 support is functional again and does not confuse other possible users (apparently few in Debian otherwise they must have noticed this problem). I've locally swapped mine and rebuild the package and it works like a charm now. (Great for testing collectors ;) Of course, there are a few more changes, see http://code.google.com/p/softflowd/source/list for the full list, but they are mostly warning fixes, nothing that breaks actual functionality. Thanks! Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#607703: stmpver != smtpver
Package: tinyhoneypot Version: 0.4.6-8 /usr/share/thpot/lib/smtp.pl line 44 has 'stmpver' instead of 'smtpver': 8--- %smtphash = ( start = 220 $hostname.$domain $stmpver; $now\x0d\x0a, ---8 should be: 8--- %smtphash = ( start = 220 $hostname.$domain $smtpver; $now\x0d\x0a, ---8 and then one nicely gets a random header as per the intention of the thing. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497154: similar dd-wrt bug
This is related most likely to http://svn.dd-wrt.com:8000/dd-wrt/ticket/1128 The comment there which apparently 'fixes' this: 8- Maybe close the file *fp in upnp_osl_wan_uptime() -8 They have no patch there though thus might be something else of course, go dd-wrt for sharing fixes upstream and closing bugs properly. My upnpd is also running at 100M plus and growing daily several MBs Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574420: FYI folks getting stuck with 574420, please see 574476 for the fix
574...@bugs.debian.org + 574...@bugs.debian.org are dupes of each other. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574476 contains the diff on how to fix this. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#563801: zonecheck: Zonecheck compares SOA to 2010, which now breaks...
Package: zonecheck
Version: 2.0.4-13
Severity: important
/usr/share/zonecheck/test/soa.rb contains:
# DESC: recommanded format for serial is MMDDnn
def chk_soa_serial_fmt_MMDDnn(ns, ip)
serial = soa(ip).serial
return true if (serial 199900) (serial 201000)
{ 'serial' = serial }
end
It is past 2010 now, thus the above test fails. Yes, another 2010 bug!
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
Bug#534416: Just add 'umount /proc/fs/nfsd' to /etc/init.d/nfs-kernel-server 'stop' part
Can somebody please just add a 'umount /proc/fs/nfsd' for the 'stop' part in /etc/init.d/nfs-kernel-server? That fixes it perfectly fine and then you can close this bug. Thanks! Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#545163: How to add a password to grub-pc
It is not too hard to just have a password which blocks people from editing the grub options (and thus let them do init=/bin/sh). That in combo with a proper BIOS lock from booting from anything else but the main disk will at least deter people from quickly changing the disk. Of course as they have physical access they can do a lot of other things, but it helps a bit ;) (and can be very annoying if you forget your password though, but heck) To just add a password which thus doesn't allow editing of boot entries: 8--- jer...@purgatory:~$ cat /etc/grub.d/42_password #!/bin/sh exec tail -n +1 $0 # add a password so that grub entries can't be edited set superusers=jeroen password jeroen mypassword ---8 For having per-entry user limits though it will be a lot more complex. It would be good to have MD5 or actually better SHA256 hashing there, but then again if one can read the generated /boot/grub/grub.cfg then you already have root and you can just change it anyway... Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#481317: Bug in Lighttpd
Lighttpd doesn't properly support IPv6, it just listens on AF_INET6 and accepts both IPv4 and IPv6 on it. Instead it should be listening seperately on IPv4 and IPv6, then it would get IPv4 connections as 192.0.2.42 and IPv6 as 2001:db8::1 instead of the mapped addresses. Short-term solution for Lighttpd: 1) configure both an IPv4 and IPv6 socket 2) fix the thing to strip the ::: from the address when it is a mapped prefix. That :::x.x.x.x is used in a data structure, fine, but it should never be shown to the user. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#510870: Please add depend for libsocket6-perl to resolve redefinitions of AF_INET6
Package: cgiirc Version: 0.5.9-3 Apache logs fill up with things like: [Mon Jan 05 15:09:48 2009] [error] [client xx.xx.xx.xx] Constant subroutine AF_INET6 redefined at (eval 2) line 1., referer: http:///cgiirc/ Installing the libsocket6-perl package resolves this (the logic inside nph-irc.cgi for detecting it is broken and doesn't replace it properly it seems when the package is not present). It would IMHO be handy if cgiirc would depend on libsocket6-perl. libsocket6-perl is a small package (especially compared to the other depends ;), thus I guess it is not a problem for most people if it gets installed. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#509901: Also filed to upstream (https://savannah.nongnu.org/support/?106593)
I've also filed it to https://savannah.nongnu.org/support/?106593 in the hope that upstream also applies it directly. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#509901: Patch for spamass-milter to make a REJECT with Precedence: List into a DISCARD - Solves Debian List Spam Forwarding issue to people who do do spam checking
Package: spamass-milter
Version: 0.3.1-7
In reference to:
http://lists.debian.org/debian-project/2008/12/msg00151.html
8--
If you sign up for mail from mailing lists, just discard mail that you
don't want to read that comes in from us with Priority: bulk or List-*
headers instead of bouncing it. A mailing list is little more than a
glorified mail forwarder: bouncing forwarded mail is wrong.
--8
(Co-incidence that the author of that text is the package maintainer for
this package)
Find attached a patch which turns a REJECT into a DISCARD when a
Precedence: List header is present.
I took http://mit.edu/network/spam/examples/britney.txt and pre-pended a
Precendence: List header to it, telneted into the box on 25
EHLO,MAIL FROM,RCPT TO,DATA,paste and as result:
Dec 27 15:25:39 abaddon spamd[31168]: spamd: identified spam (11.7/5.0)
for jeroen:108 in 5.1 seconds, 1199 bytes.
Dec 27 15:25:39 abaddon spamd[31168]: spamd: result: Y 11 -
BAYES_60,DATE_IN_PAST_24_48,FH_FROMEML_NOTLD,HTML_MESSAGE,HTML_MISSING_CTYPE,HTML_TAG_BALANCE_BODY,INVALID_DATE,MISSING_MIME_HB_SEP,NORMAL_HTTP_TO_IP,RDNS_NONE
scantime=5.1,size=1199,user=jeroen,uid=108,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=9814,mid=200106110439.aaa06...@pacific-carrier-annex.mit.edu,bayes=0.790679,autolearn=no
Dec 27 15:25:39 abaddon postfix/cleanup[32588]: 99F0135A523:
milter-discard: END-OF-MESSAGE from
noc.sixxs.net[2001:838:1:1:210:dcff:fe20:7c7c]: milter triggers DISCARD
action; from=test...@unfix.org to=jer...@unfix.org proto=ESMTP
helo=noc.sixxs.net
Please apply this patch to spamass-milter so that I don't get unsubbed
anymore from Debian mailinglists because they are forwarding spam and spam.
Greets,
Jeroen
diff -u spamass-milter-0.3.1/spamass-milter.cpp
spamass-milter-0.3.1-precedence/spamass-milter.cpp
--- spamass-milter-0.3.1/spamass-milter.cpp 2007-10-02 00:06:23.0
+0200
+++ spamass-milter-0.3.1-precedence/spamass-milter.cpp 2008-12-27
16:20:04.0 +0100
@@ -455,10 +455,25 @@
do_reject = true;
}
}
+
if (do_reject)
{
- debug(D_MISC, Rejecting);
- smfi_setreply(ctx, 550, 5.7.1, Blocked by SpamAssassin);
+ // Change Reject into a DISCARD when the Precedence is List
+ // This stops us from bouncing towards mailing lists
+ // See bottom of
http://lists.debian.org/debian-project/2008/12/msg00151.html
+ // Added by Jeroen Massar
+ if (cmp_nocase_partial(List, assassin-precedence()) == 0)
do_reject = false;
+
+ if (do_reject)
+ {
+ debug(D_MISC, Rejecting);
+ smfi_setreply(ctx, 550, 5.7.1, Blocked by
SpamAssassin);
+ }
+ else
+ {
+ debug(D_MISC, Discarding);
+ /* No reply here, we just throw it out of the door */
+ }
if (flag_bucket)
@@ -521,7 +536,9 @@
free(buf);
#endif
}
- return SMFIS_REJECT;
+
+ /* To Reject or To Discard, that is the question */
+ return do_reject ? SMFIS_REJECT : SMFIS_DISCARD;
}
}
@@ -1085,6 +1102,12 @@
};
}
+ // Is it a Precedence header?
+ if ( cmp_nocase_partial(Precedence, headerf) == 0 )
+ {
+ assassin-set_precedence(headerv);
+ }
+
// Is it a X-Spam- header field?
if ( cmp_nocase_partial(X-Spam-, headerf) == 0 )
{
@@ -1644,6 +1667,12 @@
}
string
+SpamAssassin::precedence()
+{
+ return x_precedence;
+}
+
+string
SpamAssassin::spam_report()
{
return x_spam_report;
@@ -1776,6 +1805,14 @@
}
string::size_type
+SpamAssassin::set_precedence(const string val)
+{
+ string::size_type old = x_precedence.size();
+ x_precedence = val;
+ return (old);
+}
+
+string::size_type
SpamAssassin::set_spam_prev_content_type(const string val)
{
string::size_type old = x_spam_prev_content_type.size();
diff -u spamass-milter-0.3.1/spamass-milter.h
spamass-milter-0.3.1-precedence/spamass-milter.h
--- spamass-milter-0.3.1/spamass-milter.h 2007-08-22 06:14:58.0
+0200
+++ spamass-milter-0.3.1-precedence/spamass-milter.h2008-12-27
15:13:08.0 +0100
@@ -99,6 +99,7 @@
string spam_checker_version();
string spam_level();
string content_type();
+ string precedence();
string subject();
string rcpt(); /* first RCPT TO: recipient (raw) */
string from(); /* MAIL FROM: sender (raw) */
@@ -115,6 +116,7 @@
string::size_type set_spam_checker_version(const string);
string::size_type set_spam_level(const string);
string::size_type set_content_type(const string);
+ string
Bug#498490: phpicalendar auto installs Apache + Apache2 config snippets, which it should not do
Package: phpicalendar Version: 2.24-1 Severity: critical Justification: breaks unrelated software -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 phpicalendar automatically installs Apache + Apache2 config snippets even when those packages are not installed and especially even though the admin might not want every virtual host on their system to have a /phpicalendar I marked this as a 'critical' bug, as one will just have to guess that it installs itself as /phpicalendar in the main Apache config, and thus avaialable to every vhost. This could thus clash with other programs you might already have their, which is especially annoying in a hosting environment. It should per-default NOT install these links, solutions could be asking the user for which Webservers they want the snippet (this is done by some other modules), or just having people read the README. It is a simple alias link anyway, and people who want to enable this will be reading the README or other such file anyway. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-xen (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages phpicalendar depends on: ii php5 5.2.6-2server-side, HTML-embedded scripti Versions of packages phpicalendar recommends: ii apache2-mpm-prefork [apache2] 2.2.9-7Apache HTTP Server - traditional n Versions of packages phpicalendar suggests: pn korganizer | evolution | icea none (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjHwkYACgkQKaooUjM+fCOxZACff2Po/v3cFoJ98Zk9lPHZ201W 0LkAninqaXrTpPzO+6Ho/HoyQHdFVLjE =zJIy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484932: no IPv6 support in atftpd, but inetd setting is doing IPv6 thus failure
Package: atftpd Version: 0.7.dfsg-4 Severity: grave Justification: renders package unusable Config file edited into /etc/inetd.conf (which should actually be added to /etc/inetd.d/) is: #:BOOT: TFTP service is provided primarily for booting. Most sites # run this only on machines acting as boot servers. tftpdgram udpwaitnobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /var/lib/tftpboot Which results in: Jun 7 13:58:23 purgatory atftpd[20773]: Advanced Trivial FTP server started (0.7) Jun 7 13:58:23 purgatory atftpd[20773]: connect: Address family not supported by protocol Because atftpd doesn't support IPv6. Solution, use 'udp4' instead of 'udp' in inetd configuration, thus: #:BOOT: TFTP service is provided primarily for booting. Most sites # run this only on machines acting as boot servers. tftpdgram udp4waitnobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /var/lib/tftpboot When fixing this one, you might just want to move that config snipplet into /etc/inetd.d/ where it belongs, makes things much easier and doesn't mess up /etc/inetd.conf -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages atftpd depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii inetutils-inetd [inet-sup 2:1.5.dfsg.1-6 Internet super server ii libc6 2.7-12 GNU C Library: Shared libraries ii libpcre3 7.6-2 Perl 5 Compatible Regular Expressi ii libwrap0 7.6.q-15 Wietse Venema's TCP wrappers libra atftpd recommends no packages. -- debconf information: atftpd/port: 69 atftpd/tftpd-timeout: 300 atftpd/mcast_port: 1758 atftpd/verbosity: 5 (LOG_NOTICE) atftpd/timeout: true atftpd/tsize: true atftpd/retry-timeout: 5 atftpd/multicast: true atftpd/ttl: 1 atftpd/use_inetd: true atftpd/basedir: /var/lib/tftpboot atftpd/mcast_addr: 239.239.239.0-255 atftpd/logfile: /var/log/atftpd.log atftpd/blksize: true atftpd/logtofile: false atftpd/maxthread: 100 signature.asc Description: OpenPGP digital signature
Bug#481482: When no proxy is specified mpdscribble segfaults in libsoup
Package: mpdscribble Version: 0.2.12-10 Severity: grave Followup-For: Bug #481482 mpdscribble crashes because of this fix when no proxy is being used. I rebuild the package, but disabling dh_strip from the rules file so that I had symbols and then got: $ gdb mpdscribble GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu... (gdb) r Starting program: /usr/bin/mpdscribble [Thread debugging using libthread_db enabled] [New Thread 0x7f0aab968780 (LWP 11056)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f0aab968780 (LWP 11056)] 0x7f0aaa836920 in strchr () from /lib/libc.so.6 (gdb) bt #0 0x7f0aaa836920 in strchr () from /lib/libc.so.6 #1 0x7f0aaaf5db23 in soup_uri_new_with_base () from /usr/lib/libsoup-2.2.so.8 #2 0x7f0aaaf5e1fe in soup_uri_new () from /usr/lib/libsoup-2.2.so.8 #3 0x00403597 in conn_setup () at conn.c:91 #4 0x00401e5a in main (argc=1, argv=0x7fffb3a8b708) at mpdscribble.c:86 (gdb) quit Simple fix for me, on line 91: /*g.proxy = soup_uri_new(file_config.proxy);*/ Most likely easier fix: check if file_config.proxy is set or not. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mpdscribble depends on: ii adduser 3.107 add and remove users and groups ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 2.7-11 GNU C Library: Shared libraries ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libmpd0 0.15.0-3 High-level client library for acce ii libsoup2.2-8 2.2.105-4 an HTTP library implementation in ii logrotate 3.7.1-3Log rotation utility ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip mpdscribble recommends no packages. -- debconf information excluded signature.asc Description: OpenPGP digital signature
Bug#463638: Adding IPv6 addresses in the rootservers breaks Zonecheck completely
Severity: grave Actually, by having added the IPv6 addresses in the /etc/zonecheck/rootservers file zonecheck is now completely broken: /usr/share/zonecheck/lib/address.rb:57:in `create': can't interpret 192.5.5.241,2001:500:2f::f as address (Address::InvalidAddress) from /usr/share/zonecheck/lib/nresolv/config.rb:38:in `initialize' from /usr/share/zonecheck/lib/nresolv/config.rb:38:in `collect' from /usr/share/zonecheck/lib/nresolv/config.rb:38:in `initialize' from /usr/share/zonecheck/lib/nresolv/config.rb:36:in `each' from /usr/share/zonecheck/lib/nresolv/config.rb:36:in `initialize' from /usr/share/zonecheck/lib/nresolv/config.rb:48:in `new' from /usr/share/zonecheck/lib/nresolv/config.rb:48:in `from_hintfile' from /usr/share/zonecheck/lib/nresolv/config.rb:47:in `open' from /usr/share/zonecheck/lib/nresolv/config.rb:47:in `from_hintfile' from /usr/share/zonecheck/lib/nresolv/config.rb:70 from /usr/share/zonecheck/lib/nresolv/config.rb:66:in `call' from /usr/share/zonecheck/lib/nresolv/config.rb:66 from /usr/share/zonecheck/lib/nresolv.rb:25:in `require' from /usr/share/zonecheck/lib/nresolv.rb:25 from /usr/lib/cgi-bin/zc.cgi:192:in `require' from /usr/lib/cgi-bin/zc.cgi:192 The correct format is by adding a silly space it seems, like: a.root-servers.net.: [ 198.41.0.4, 2001:503:ba3e::2:30 ] b.root-servers.net.: [ 192.228.79.201 ] c.root-servers.net.: [ 192.33.4.12 ] d.root-servers.net.: [ 128.8.10.90 ] e.root-servers.net.: [ 192.203.230.10 ] f.root-servers.net.: [ 192.5.5.241, 2001:500:2f::f ] g.root-servers.net.: [ 192.112.36.4 ] h.root-servers.net.: [ 128.63.2.53, 2001:500:1::803f:235 ] i.root-servers.net.: [ 192.36.148.17 ] j.root-servers.net.: [ 192.58.128.30, 2001:503:c27::2:30 ] k.root-servers.net.: [ 193.0.14.129, 2001:7fd::1 ] l.root-servers.net.: [ 199.7.83.42 ] m.root-servers.net.: [ 202.12.27.33, 2001:dc3::35 ] As such the script at the top should be: # for ns in `dig +short . ns | tr 'A-Z' 'a-z' | sort` ; do #ips=`(dig +short $ns a; dig +short $ns ) | tr '\n' ', ' | sed 's/, $//'` #echo $ns: [ $ips ] # done # (See also: https://noc.sixxs.net/tickets/?msg=tickets-678198) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#463638: /etc/zonecheck/rootservers is out of date (wrong l.root-servers.net address + missing IPv6 addresses)
Package: zonecheck Version: 2.0.4-7 Severity: important Subject says it all, please update /etc/zonecheck/rootservers The file contains info on how to do this. It doesn't mention how to handle the upcoming IPv6 rootservers glue though. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zonecheck depends on: ii iputils-ping3:20071127-1 Tools to test the reachability of ii ruby4.1 An interpreter of object-oriented zonecheck recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#142661: #142661 - finger: should have a mode to resolve MXs
This bug can be closed, simply as an MX record is for a *MAIL EXCHANGER* and that thus doesn't not point to a host which supports the 'finger' service. Now, a feature to ask for SRV record support would be a good thing, but as no other clients support this and nobody has actually configured it that way, it will never ever be used anyway, thus also totally useless. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#427067: Supportive arguments for this bug report
For clarity I asked dnsop, which received the following two answers: Full posts: http://www1.ietf.org/mail-archive/web/dnsop/current/msg05542.html http://www1.ietf.org/mail-archive/web/dnsop/current/msg05541.html Mark Andrews Mark_Andrews at isc.org 8--- I suspect someone is worried about a application breaking if it tries to reach ::1. Mind you for the general health of the Internet such breakages should be found sooner rather than later. 8 Antonio Querubin tony at lava.net 8--- For consistency it should really have localhost defined and ip6-localhost be optional. However, the distinction is not likely to be visible to most end users anyway so it shouldn't matter too much. Anyone configuring an app to bind to 'localhost' explicitly should probably already be aware of what their system (or local DNS) considers 'localhost' to be and whether the local apps that are talking to each other can do so over IPv6 vs IPv4. 8 No other comments where received (yet) to this though. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#428211: Default route not enough for 2.6.20+ kernels
This bug should be filed against the kernel packages, not against aiccu as it will affect everything using IPv6 tunnels. Thus if it is filed against aiccu it also has to be filed against: openvpn, tinc, vtun, etc etc etc. Oh and iproute2 as that allows one to create those tunnels. I, as the AICCU upstream developer, do not support adding anything like a 'patch' for this to AICCU itself as that is not the problem. See for more information on the exact problem: http://bugzilla.kernel.org/show_bug.cgi?id=8382 Which also shows that even adding the 2000::/3 is a real hack which sometimes start failing again. Please fix the kernel instead as that has the problem. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#427067: '::1 localhost' is missing from /etc/hosts, thus affecting expected behaviour
Package: netbase Version: 4.29 Severity: normal Tags: patch /etc/hosts contains: 8- ::1 ip6-localhost ip6-loopback -8 One would expect though that a ping6 localhost would work, but because it is not in /etc/hosts it doesn't as there is no IPv6 address. Daemons, which support IPv6 might get configured to use localhost, this thus binds them only to 127.0.0.1, but not to the IPv6 equivalent, even though the daemon might implement getaddrinfo() and the loop correctly. As such, I propose that the above gets changed into: 8- 127.0.0.1 localhost ip4-localhost ip4-loopback ::1 localhost ip6-localhost ip6-loopback -8 This to make it consistent with IPv4. There is not a single RFC or draft that refers to ip6-localhost or ip6-loopback (verified by grepping to the ~3Gb of drafts I have). ::1 is always mentioned to be the Loopback address or as localhost. http://www.sixxs.net/archive/ietf/rfc4038.txt (Application Aspects of IPv6 Transition) contains: localhost. IN A127.0.0.1 IN ::1 to back that up. Please resolve this issue, as it avoids having to program a loop for 2 different kind of address families into programs, while getaddrinfo() should resolve that problem already. Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages netbase depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii ifupdown0.6.8high level tools to configure netw ii iputils-ping [ping] 3:20070202-1 Tools to test the reachability of ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii openbsd-inetd [inet-superse 0.20050402-6 The OpenBSD Internet Superserver netbase recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424208: module-init-tools: use of /usr/bin/{sort,uniq} before /usr is mounted
Marco d'Itri wrote: On May 15, Thorsten Glaser [EMAIL PROTECTED] wrote: Package: module-init-tools Version: 6.2-3 Why do I keep receiving bugs for a kfreebsd-i386 package which I do not maintain? Because of this: X-Original-To: [EMAIL PROTECTED] Received: from rietz.debian.org (rietz.debian.org [140.211.166.43]) by murphy.debian.org (Postfix) with ESMTP id 6F0BE359BC; Tue, 15 May 2007 16:48:24 -0500 (CDT) Received: from debbugs by rietz.debian.org with local (Exim 4.50) id 1Ho4jd-vQ-Eq; Tue, 15 May 2007 21:39:09 + Somebody/thing is assigning the debian-bsd list into the bug ;) Puzzled me for a while too Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#415573: libc6: uninitialised value in manager.c:128
Pierre HABOUZIT wrote: [..] Does it still apply to glibc2.5 currently in unstable ? It seems to be fine for glibc2.5, thanks for the fixup. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Bug#419485: mtr-tiny: --report cuts off IPv6 address
Package: mtr-tiny Version: 0.71-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 8--- [EMAIL PROTECTED]:~$ mtr -6 --raw -n -c 1 -r noc.sixxs.net HOST: purgatory Loss% Snt Last Avg Best Wrst StDev 1. 2001:7b8:5:10:74::1 0.0% 1 10.1 10.1 10.1 10.1 0.0 2. 2001:7b8:3:31:290:6900:31c6: 0.0% 1 10.1 10.1 10.1 10.1 0.0 3. 2001:7b8::290:6900:1c6:7c1f 0.0% 1 11.1 11.1 11.1 11.1 0.0 4. 2001:7f8:1::a501:2871:1 0.0% 1 11.1 11.1 11.1 11.1 0.0 5. 2001:838:0:10::2 0.0% 1 51.1 51.1 51.1 51.1 0.0 6. 2001:838:1:1:210:dcff:fe20:7 0.0% 1 13.1 13.1 13.1 13.1 0.0 - ---8 As known by quite some people that last hop, the destinatio, really is: 2001:838:1:1:210:dcff:fe20:7c7c As such 'c7c' is missing from this output. If one would have a full IPv6 address, then 10 nibbles would be missing. A patch where COLUMNS=100 is set to indicate the output width might remedy this, or hardcode it to +10 or make the output CSV which would also increase parsing capability. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mtr-tiny depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libncurses5 5.5-5Shared libraries for terminal hand mtr-tiny recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFGIr/hKaooUjM+fCMRAnwhAKCKp5fujU6fTxClpwtMAOMD+cx2DwCglhQx hbPwU44/N4Kqr6aQK53Lgbw= =a1KM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
