Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

November 10 2014

20:42

nlnog ring: BCH Network (BE) joined the RING

BCH Network – AS 35701 – joined the RING today. AS35701 is mainly a research testbed for new technologies in the systems & networking world. Although being a testbed it is a high performing and stable network that houses carrier-grade services and applications.

Users can connect to bchnetwork01.ring.nlnog.net, which is located in Belgium.

20:26

nlnog ring: Adix BV (NL) joined the RING

Adix BV – AS 31731 – joined the RING today. Adix was founded in 2004 and specializes in cloud services and managed hosting. Also services like domain registration, colocation and almost everything in between.

Users can connect to adix01.ring.nlnog.net, which is located in Netherlands.

20:25

nlnog ring: CESNET (CZ) joined the RING

CESNET – AS 2852 – joined the RING today. CESNET is Czech NREN operator connecting Czech universities and the Czech Academy of Science.

Users can connect to cesnet01.ring.nlnog.net, which is located in Czech Republic.

17:29
Reaper^: Lessons Learned from Deploying Multicast

November 08 2014

11:29

nlnog ring: Immense Networks, LLC (US) joined the RING

Immense Networks, LLC – AS 7954 – joined the RING today. Immense is a regional IT and managed hosting provider.

Users can connect to immense01.ring.nlnog.net, which is located in United States.

November 07 2014

17:22

RichiH: Release Critical Bug report for Week 45

WE ARE FROZEN!

Please note that Lucas hacked a "key packages" count into this list. If you have spare cycles, look at those first.

I hope to have a (somewhat) random bug of the week thingie by next week which picks stalled bugs for increased exposure.

As you can see, we are a bit worse than in the Squeeze cycle, but way ahead of Wheezy. Stats with proper diffs will also start next week.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1154 (Including 190 bugs affecting key packages)
    • Affecting Jessie: 295 (key packages: 150) That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 229 (key packages: 116) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 22 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 14 bugs are marked as done, but still affect unstable. (key packages: 8) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 193 bugs are neither tagged patch, nor marked done. (key packages: 96) Help make a first step towards resolution!
      • Affecting Jessie only: 66 (key packages: 34) Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 37 bugs are in packages that are unblocked by the release team. (key packages: 24)
        • 29 bugs are in packages that are not unblocked. (key packages: 10)

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 24 (19+5) +24 (+19/+5) 18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

November 04 2014

18:36

Marco d'Itri: My position on the "init system coupling" General Resolution

I first want to clarify for the people not intimately involved with Debian that the GR-2014-003 vote is not about choosing the default init system or deciding if sysvinit should still be supported: its outcome will not stop systemd from being Debian's default init system and will not prevent any interested developers from supporting sysvinit.

Some non-developers have recently threatened of "forking Debian" if this GR will not pass, apparently without understanding well the concept: Debian welcomes forks and I think that having more users working on free software would be great no matter which init system they favour.

The goal of Ian Jackson's proposal is to force the maintainers who want to use the superior features of systemd in their packages to spend their time on making them work with sysvinit as well. This is antisocial and also hard to reconcile it with the Debian Constitution, which states:

2.1.1 Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. [...]

As it has been patiently explained by many other people, this proposal is unrealistic: if the maintainers of some packages were not interested in working on support for sysvinit and nobody else submitted patches then we would probably still have to release them as is even if formally declared unsuitable for a release. On the other hand, if somebody is interested in working on sysvinit support then there is no need for a GR forcing them to do it.

The most elegant outcome of this GR would be a victory of choice 4 ("please do not waste everybody's time with pointless general resolutions"), but Ian Jackson has been clear enough in explaining how he sees the future of this debate:

If my GR passes we will only have to have this conversation if those who are outvoted do not respect the project's collective decision.

If my GR fails I expect a series of bitter rearguard battles over individual systemd dependencies.

There are no significant practical differences between choices 2 "support alternative init systems as much as possible" and 3 "packages may require specific init systems if maintainers decide", but choice 3 is more explicit in supporting the technical decisions of maintainers and upstream developers.

This is why I think that we need a stronger outcome to prevent discussing this over and over, no matter how each one of us feels about working personally on sysvinit support in the future. I will vote for choices 3, 2, 4, 1.

October 31 2014

23:35

RichiH: Release Critical Bug report for Week 44

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1168
    • Affecting Jessie: 274 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 224 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 30 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 12 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 182 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 50 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 2 bugs are in packages that are unblocked by the release team.
        • 48 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

October 28 2014

12:40
Reaper^: CCIE SP version 4 has been announced

October 27 2014

20:30
Reaper^: Checking community interest for a new kind of networking site

October 24 2014

19:42

RichiH: Release Critical Bug report for Week 43

Just a friendly reminder: If your package is not in unstable (and reasonably bug free) by Sunday, it's not in Jessie.

I am not doing full stats as I am unsure about the diff format at the moment, but in week 43, we had 284 bugs for Squeeze and 468 for Wheezy.

(282 + 468) / 2 = 376; so we are a bit better off than on average. Still, here's to hoping this freeze will be shorter.

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1193
    • Affecting Jessie: 319 That's the number we need to get down to zero before the release. They can be split in two big categories:
      • Affecting Jessie and unstable: 240 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 20 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 22 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
        • 198 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
      • Affecting Jessie only: 79 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
        • 0 bugs are in packages that are unblocked by the release team.
        • 79 bugs are in packages that are not unblocked.

October 15 2014

20:55

nlnog ring: Riseup Networks (US) joined the RING

Riseup Networks – AS 16652 – joined the RING today. Riseup provides online communication tools for people and groups working on liberatory social change. We are a project to create democratic alternatives and practice self-determination by controlling our own secure means of communications.

Users can connect to riseup01.ring.nlnog.net, which is located in Washington, United States.

October 14 2014

16:34

Marco d'Itri: The Italian peering ecosystem

I published the slides of my talk "An introduction to peering in Italy - Interconnections among the Italian networks" that I presented today at the MIX-IT (the Milano internet exchange) technical meeting.

October 13 2014

18:29

froztbyte: Keys, identity, etc

This post serves as a general notice of key update, as well as a short bit of history.

My new GPG key is a 4096 RSA. It’s available on the SKS keyservers already, and has the fingerprint 1A9260611F0D15319BE6465E474E16D0F70C7CC9. I have also updated my Keybase identity with this as appropriate, as well as updating my online pubkey store.

My old key was E5BB45ADAC20F87D8E5C2316D3C406A99ABE41AE, 1024 DSA. I’ll be pushing a revocation for this in about a week’s time.

The intention behind this is a general update, plus also just adding some clarity to my public key situation. I have some Older Keys which happened, in various states, from times when I had no clue to times where I had no ability to survive machine or disk failures. Aside from those conditions, I had another key which I also no longer wish to use (due to reasonable key size concerns etc).

October 12 2014

13:17

nlnog ring: Liquid Web (US) joined the RING

Liquid Web – AS 32244 – joined the RING today. Liquid Web Inc. is a privately held, managed web hosting company founded in 1997 with three wholly-owned data centers in Lansing, and a fourth location in Scottsdale, AZ. As a leader in the professional web hosting industry, we have an unwavering dedication to providing the best hosting products available and premium customer support.

Users can connect to liquidweb01.ring.nlnog.net, which is located in Arizona, United States.

13:17

nlnog ring: DFN (DE) joined the RING

DFN – AS 680 – joined the RING today. Germany’s national research network.

Users can connect to dfn01.ring.nlnog.net, which is located in Germany.

October 09 2014

07:38

nlnog ring: Globalways AG (DE) joined the RING

Globalways AG – AS 48918 – joined the RING today. Globalways stands for professional IT services with the highest standards of data security for demanding customer projects. They offer plain site interconnections, complex Enterprise-Hosting, or complete management of all internal IT infrastructure. With more than 10 years experience in the field, Globalways is one of the leading IT infrastructure providers in Germany. Globalways is located in Frankfurt, Berlin, Munich, Stuttgart, and Reutlingen.

Users can connect to globalways01.ring.nlnog.net, which is located in Germany.

October 04 2014

06:25
Reaper^: Cisco Adds New Routers In the ISR 4000 Family

October 03 2014

05:32

Marco d'Itri: 15 years of whois

Exactly 15 years ago I uploaded to Debian the first release of my whois client.

At the end of 1999 the United States Government forced Network Solutions, at the time the only registrar for the .com, .net and .org top level domains, to split their functions in a registry and a registrar and to and allow competing registrars to operate.

Since then, two whois queries are needed to access the data for a domain in a TLD operating with a thin registry model: first one to the registry to find out which registrar was used to register the domain, and then one the registrar to actually get the data.

Being as lazy as I am I tought that this was unacceptable, so I implemented a whois client that would know which whois server to query for all TLDs and then automatically follow the referrals to the registrars.

But the initial reason for writing this program was to replace the simplistic BSD-derived whois client that was shipped with Debian with one that would know which server to query for IP addresses and autonomous system numbers, a useful feature in a time when people still used to manually report all their spam to the originating ISPs.

Over the years I have spent countless hours searching for the right servers for the domains of far away countries (something that has often been incredibly instructive) and now the program database is usually more up to date than the official IANA one.

One of my goals for this program has always been wide portability, so I am happy that over the years it was adopted by other Linux distributions, made available by third parties to all common variants of UNIX and even to systems as alien as Windows and OS/2.

Now that whois is 15 years old I am happy to announce that I have recently achieved complete world domination and that all Linux distributions use it as their default whois client.

September 30 2014

22:26

nlnog ring: Blacknight (IE) joined the RING

Blacknight – AS 39122 – joined the RING today.

“Blacknight are one of the largest hosting providers in Ireland. We operate AS39122 and peer on a number of the largest IXPs in Europe.”

Users can connect to blacknight01.ring.nlnog.net, which is located in Ireland.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl