You are here

Site në gjuhë të huaj

Wired Looks Back At 'Mondo 2000'

Slashdot.org - Dje, 05/07/2015 - 9:59md
destinyland writes: On a day when America looks back on those who came before, Wired is remembering a pioneering technology magazine named Mondo 2000 — and sharing video of its editors' legendary appearance on a mid-90s PBS series, "The Internet Cafe". When its host questioned them about cyberpunk, they turned the interview into an ironic media stunt by providing a live, sneering cyberpunk model named Malice (wearing a fake neural implant on his head), as the words "real cyberpunk" jokingly flashed on the bottom of the screen. "At a time when few people outside academia had access to the internet, Mondo 2000 was many a wannabe hacker's introduction to the online world," Wired remembers fondly, even acknowledging that they'd "borrowed" their own magazine's design motif from Mondo 2000, in those early years before ISPs started popularizing consumer internet access.

Read more of this story at Slashdot.

Jakub Brindza: Midterm minute of ponderation...

Planet GNOME - Dje, 05/07/2015 - 9:56md
...or the meaning of who you surround yourself with.

The past week has been full of adjustments to my PRs on github, endless discussions with my mentor about what would be the best solution, continuous PR reviews... well, it was a lesson and I'm happy to have undertaken it. Search and editor still need many refurbishments though.

For those of you expecting further technical description of what I managed to do over the past week in GTG, stop reading immediately. You will be disappointed at the end and I don't want to do that to you (not on purpose of course). STOP HERE!
Anyway, I warned you.
Now for the remaining (very few brave) ones. What is it that I'm about to compose here? I've been thinking. For a long time. What is this going to be? Hmm, maybe some ambitious (and unsuccessful) product development post aimed at best work practices? Or a sincere confession of my current moods and feelings? 
I'd say it's going to be a bit of both, judge it as you wish.
So in my thoughts, I came across an idea of how the people around influence me, primarily in the context of my work, that is, in the context of GSoC. I considered my family, girlfriend, friends... all in all not so many people honestly in my village, so it was not that difficult.
My statement is this: The environment I work in is quintessential if I want to be a good and efficient programmer. It is all about having conditions where I can be calm, without stress, and free from gazillion of (pretty much meaningless) information and obligations.
And after this weekend, being offered some time for cogitation, I realised that I've been lacking these gifts of calmness and convenience in my workplace.

At this point, I'm glad to thank my mentor Izidor for introducing me to Joel Spolsky's blog (or should I say programmer's bible?). In one of his articles, he mentions exactly what I've been describing above: the working conditions (point 8) And that reinforces my statement even more.

So what is up for me for the next week or even for the rest of the GSoC?
I believe that a significant change in how I organise my working place (a.k.a. my tiny room which is boiling during these summer days!) would give new energy to my activity.
Motivated by passing the midterm evaluation, I am about to try some of the proved work practices I've been brushing up on thanks to immense amounts of sources Izidor's been offering me (Currently it's the rigorous Code Complete book :) ). 

I'm not going to reveal to anyone yet what my plan is. 
However, the most general and primary goal is best expressed by an English adage:

Early to bed, early to rise, makes a man healthy, wealthy and wise.That's where I want to start, since I consider my lifestyle quite unsupportive towards what I want to do well and what I want to learn well. We'll see what happens, but in the meantime, if you got to this point in your reading, I'd just advise you not to stick to the current, but think outside the box constantly and search for how you can do better at what you do.
I'm trying again and I hope I become again a little bit more organised and effective :) This summer is an opportunity, so why not seize it!

Thorsten Alteholz: My Debian Activities in June 2015

Planet Debian - Dje, 05/07/2015 - 9:51md

FTP assistant

This month I marked 539 packages for accept, rejected 61 of them and had to send 24 emails to maintainers. This is a new personal record. Even in the month before the Jessie freeze I accepted only 407 packages. So, very well done (self-laudation has to happen from time to time ).

Another record was broken as well. After 19 month of doing this kind of work, I got my first insulting email. I would prefer to wait another 19 month before I get the next one …

Squeeze LTS

This was my twelfth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian.

This month I got assigned a workload of only 14.5h and I spent most of it to work on a new upload of php5. Unfortunately there have been so many CVEs comming in, that I didn’t do an upload yet.

Other stuff I uploaded was

  • [DLA 258-1] jqueryui security update
  • [DLA 262-1] libcrypto++ security update

This month I also had my first one and a half weeks of doing frontdesk work. As introduced in this email, every member of the LTS team should do some LTS CVE triage. Up to now it was mainly done by Raphael and he wants to share this task with everybody else. So I answered questions on the IRC channel, on the LTS list and looked for CVEs that are important for Squeeze LTS or could be ignored.

Other stuff

This month I also uploaded a new version of harminv and wondered why the package didn’t move to testing. Of course there is a document how to do a transition of a library properly. But hey, it is me, I know everything better and of course I can use a shortcut. Oh boy, I was wrong. So I also uploaded new versions of meep, meep-lam4, meep-openmpi, meep-mpi-default and meep-mpich2.

And the moral of the story: If you don’t understand why something should be done in a specific way, you shouldn’t try to do it different.

Donations

Again, thanks alot to all donors. I really appreciate this and hope that everybody is pleased with my commitment. Don’t hesitate to make suggestions for improvements.

Petter Reinholdtsen: New laptop - some more clues and ideas based on feedback

Planet Debian - Dje, 05/07/2015 - 9:40md

Several people contacted me after my previous blog post about my need for a new laptop, and provided very useful feedback. I wish to thank every one of these. Several pointed me to the possibility of fixing my X230, and I am already in the process of getting Lenovo to do so thanks to the on site, next day support contract covering the machine. But the battery is almost useless (I expect to replace it with a non-official battery) and I do not expect the machine to live for many more years, so it is time to plan its replacement. If I did not have a support contract, it was suggested to find replacement parts using FrancEcrans, but it might present a language barrier as I do not understand French.

One tip I got was to use the Skinflint web service to compare laptop models. It seem to have more models available than prisjakt.no. Another tip I got from someone I know have similar keyboard preferences was that the HP EliteBook 840 keyboard is not very good, and this matches my experience with earlier EliteBook keyboards I tested. Because of this, I will not consider it any further.

When I wrote my blog post, I was not aware of Thinkpad X250, the newest Thinkpad X model. The keyboard reintroduces mouse buttons (which is missing from the X240), and is working fairly well with Debian Sid/Unstable according to Corsac.net. The reports I got on the keyboard quality are not consistent. Some say the keyboard is good, others say it is ok, while others say it is not very good. Those with experience from X41 and and X60 agree that the X250 keyboard is not as good as those trusty old laptops, and suggest I keep and fix my X230 instead of upgrading, or get a used X230 to replace it. I'm also told that the X250 lack leds for caps lock, disk activity and battery status, which is very convenient on my X230. I'm also told that the CPU fan is running very often, making it a bit noisy. In any case, the X250 do not work out of the box with Debian Stable/Jessie, one of my requirements.

I have also gotten a few vendor proposals, one was Pro-Star, another was Libreboot. The latter look very attractive to me.

Again, thank you all for the very useful feedback. It help a lot as I keep looking for a replacement.

Bastian Ilsø Hougaard: irc link handling

Planet GNOME - Dje, 05/07/2015 - 9:16md

Back in 1996 the World Wide Web Consortium made a draft specification for how you can link to an IRC chatroom. The draft does not seem to have developed further, but it is regardless possible to stumble upon these links around the internet now and then. Many other IRC clients support the handling the links too and this week I have enabled Polari to open them.

The links typically take on the following shape:
irc://[server]/[room]

If I wanted to link to the #polari chatroom, the link could look like so:
irc://irc.gnome.org/polari

Polari can open these links regardless of whether it is running or not. Furthermore, if you open a link to a server you haven’t used before, then Polari will ask you to specify a username to use for that connection.

The bug in question is bug Bug 728593. I am keeping a solution to solving it inside the wip/bastianilso/irc-url-parsing branch. However, there’s a few things I am considering before calling the work in this area done:

  • It would be a good idea to show a notification if Polari is unable to parse the irc link.
  • It might be worth to also support corner cases of the irc link specification such URLs targeting nicknames, URLs containing a passphrase and so on.
  • It could be cool to have a “Copy link adress” menu item per room so you can copy/paste a room’s irc link to other people. The menu item could be placed in the room menu and/or in the right-click menu for each channel.
  • It could be cool if we parsed mentions of rooms (fx #polari) in chats as IRC links you could click or copy/paste.

I’ll be off for a small trip the next four days but will return in the weekend for more polari bug fixing. (:

Checking Mammoth DNA Against Elephants Hints At How They Got Hairy

Slashdot.org - Dje, 05/07/2015 - 8:43md
An anonymous reader writes: A new study on mammoth DNA comparing the hairy animals to their cousins, the Asian and African elephants, has isolated what genes separate it from its warm-weather cousins. The study found that genes controlling skin and hair development, fat metabolism, insulin signaling, and skull shape, differed from today's contemporary elephant species. "They have this weird hump on their back, which is thought to be something like a camel hump — sort of a fat deposit that stored water and energy for the cold, dark winters," says Vincent Lynch, an evolutionary biologist at the University of Chicago.

Read more of this story at Slashdot.

Julita Inca: Peruvian products: Quinoa, Causa Limeña, Pisco

Planet GNOME - Dje, 05/07/2015 - 8:36md

I decided to write this post because I think it is fair to let know the world that quinoa, Causa Limeña and Pisco are Peruvians products.

We have done efforts to promote our products around the world through the valuable work of one of the authorities of the Peruvian food: Gaston Acurio.

Moreover, we presented our products (to mention the last event): Peru Meet & Greet 2015books, receiptscampaigns and we had gotten recognitions from World Food Programme.  

Besides that, during the last Expo Milan 2015 world food event, these Peruvian products were being marketed by another country as if their products.

I am just clarifying this situation from my point of view, though it made me decided to organise the first edition of the GNOME America in Peru. This idea was in my mind years ago, but I did not dare to do it until I had the opportunity to talk with Max Chun-Hung Huang during the GNOME Asia. He encouraged me to do it!  It seems huge but not impossible, so one the challenge of the life might start now. 

Could Cuzco, one wonder of the world, be a good place to do it?


Filed under: Events, GNOME, Laikes & Dislaikes :: Entertainment Tagged: Causa Limeña, Julita Inca, Julita Inca Chiroque, Perú, Peruvian Pisco, peruvian products, Pisco, Quinoa, Quinua

Sjoerd Simons: Debian Jessie on Raspberry Pi 2

Planet Debian - Dje, 05/07/2015 - 8:06md

Apart from being somewhat slow, one of the downsides of the original Raspberry Pi SoC was that it had an old ARM11 core which implements the ARMv6 architecture. This was particularly unfortunate as most common distributions (Debian, Ubuntu, Fedora, etc) standardized on the ARMv7-A architecture as a minimum for their ARM hardfloat ports. Which is one of the reasons for Raspbian and the various other RPI specific distributions.

Happily, with the new Raspberry Pi 2 using Cortex-A7 Cores (which implement the ARMv7-A architecture) this issue is out of the way, which means that a a standard Debian hardfloat userland will run just fine. So the obvious first thing to do when an RPI 2 appeared on my desk was to put together a quick Debian Jessie image for it.

The result of which can be found at: https://images.collabora.co.uk/rpi2/

Login as root with password debian (Obviously do change the password and create a normal user after booting). The image is 3G, so should fit on any SD card marketed as 4G or bigger. Using bmap-tools for flashing is recommended, otherwise you'll be waiting for 2.5G of zeros to be written to the card, which tends to be rather boring. Note that the image is really basic and will just get you to a login prompt on either serial or hdmi, batteries are very much not included, but can be apt-getted :).

Technically, this image is simply a Debian Jessie debootstrap with a extra packages for hardware support. Unlike Raspbian the first partition (which contains the firmware & kernel files to boot the system) is mounted on /boot/firmware rather then on /boot. This is because the VideoCore expects the first partition to be a FAT filesystem, but mounting FAT on /boot really doesn't work right on Debian systems as it contains files managed by dpkg (e.g. the kernel package) which requires a POSIX compatible filesystem. Essentially the same reason why Debian is using /boot/efi for the ESP partition on Intel systems rather the mounting it on /boot directly.

For reference, the RPI2 specific packages in this image are from https://repositories.collabora.co.uk/debian/ in the jessie distribution and rpi2 component (this repository is enabled by default on the image). The relevant packages there are:

  • linux: Current 3.18 based package from Debian experimental (3.18.5-1~exp1 at the time of this writing) with a stack of patches on top from the raspberrypi github repository and tweaked to build an rpi2 flavour as the patchset isn't multiplatform capable
  • raspberrypi-firmware-nokernel: Firmware package and misc libraries packages taken from Raspbian, with a slight tweak to install in /boot/firmware rather then /boot.
  • flash-kernel: Current flash-kernel package from debian experimental, with a small addition to detect the RPI 2 and "flash" the kernel to /boot/firmware/kernel7.img (which is what the GPU will try to boot on this board).

For the future, it would be nice to see the Raspberry Pi 2 support out of the box on Debian. For that to happen, the most important thing would be to have some mainline kernel support for this board (supporting multiplatform!) so it can be build as part of debians armmp kernel flavour. And ideally, having the firmware load a bootloader (such as u-boot) rather than a kernel directly to allow for a much more flexible boot sequence and support for using an initramfs (u-boot has some support for the original Raspberry Pi, so adding Raspberry Pi 2 support should hopefully not be too tricky)

Update: An updated image (20150705) is available with the latest packages from Jessie and a GPG key that's not expired :).

Seahorse Tails Could Inspire New Generation of Robots

Slashdot.org - Dje, 05/07/2015 - 7:26md
An anonymous reader writes: Researchers at Clemson University have studied the makeup of seahorse tails and rendered its mechanics using 3D-printing in an effort to provide flexibility to stiff robots. Unlike most creatures, seahorse's tail is made of square prisms. Michael Porter, assistant professor in mechanical engineering at Clemson University said, "Almost all animal tails have circular or oval cross-sections—but not the seahorse's. We wondered why. We found that the squared-shaped tails are better when both grasping and armor functions are needed."

Read more of this story at Slashdot.

Army Exoskeleton Prototype Helps Soldiers Learn To Shoot

Slashdot.org - Dje, 05/07/2015 - 6:10md
An anonymous reader writes: Infantrymen live by their shooting skills, but becoming an expert marksman can take a long time. U.S. Army researchers are working on a way to improve these skills with the help of the MAXFAS, an arm exoskeleton that uses arm braces to correct involuntary arm shakes. Designed At the U.S. Army Research Laboratory by Dan Baechle, the MAXFAS has been shown to improve aim even after users have taken it off. "Soldiers need to be able to aim and shoot accurately and quickly in the chaos of the battlefield," Baechle said. "Training with MAXFAS could improve Soldiers' accuracy, and reduce current time and ammunition requirements in basic training."

Read more of this story at Slashdot.

Glitch Halts New Horizons Operations As It Nears Pluto

Slashdot.org - Dje, 05/07/2015 - 4:55md
An anonymous reader writes: NASA says their New Horizons probe suffered a temporary communication breakdown on Saturday, 10 days before it's supposed to fly past Pluto. The mission team is working to restore normal communications. "Full recovery is expected to take from one to several days," NASA wrote in a status report on Saturday. "New Horizons will be temporarily unable to collect science data during that time."

Read more of this story at Slashdot.

Russian Progress Cargo Ship Docks With Space Station

Slashdot.org - Dje, 05/07/2015 - 3:40md
An anonymous reader writes: An unmanned Russian cargo ship has successfully docked with the International Space Station. The successful launch, rendezvous and docking came after two resupply failures. A Progress launched in April spun out of control and a week ago, a SpaceX Falcon 9 rocket disintegrated, destroying a supply ship loaded with supplies and equipment. "Crew reports, 'feels like Christmas in July,'" the International Space Station tweeted.

Read more of this story at Slashdot.

How Apple Music Can Disrupt Users' iTunes Libraries

Slashdot.org - Dje, 05/07/2015 - 2:27md
An anonymous reader writes: Early adopters of Apple Music are warning others they could get more than they bargained for if they intend to download tracks for offline listening. Since Apple Music is primarily a streaming service, this functionality necessitates turning on iCloud Music for syncing purposes. The way Apple syncs files is to scan your library for known music files, and if it finds one, the service gives your account access to Apple's canonical copy. Unfortunately, this wipes out any custom edits you made to the file's metadata. For those who have put a lot of time into customizing their library, this can do a lot of damage to their organizational system. Apple's efforts to simplify and streamline the process have once again left advanced users with a difficult decision to make.

Read more of this story at Slashdot.

Jonathan Kang: Something in last month--Back home

Planet GNOME - Dje, 05/07/2015 - 12:07md
Two weeks ago, I received an Email from Gnome-Travel about application of sponsorship for GUADEC 2015. I talked with my mentor about things to do preparing the GUADEC 2015. I realized that I have many things to deal with. The most important one is to get a passport.

In China, we have to apply a passport where your household registration locates, not where you lived right now. My hometown is Shijiazhuang, China. But right now I live in Changchun, China to pursue my bachelor's degree. So I have to go back to my hometown to apply for the passport.

It takes me almost one day from leaving my university to getting back home. It's really a long time! I leaved Changchun at noon in 20th, June, and get back home in the morning the next day. Arriving the train station in Changchun, what surprised me a lot is the ad on the train. I was amazed because it never happened before.


The next day, in the very morning, just right before getting off the train, I opened Google Now to see some updates. Once again, I was surprised to see the cover on top of the application. It was Fathers' Day! Yep, I was Fathers' Day, and I was going back home. I felt so happy that I could get back home to be with my dad at Fathers' Day.


Finally, I was back to hometown! And I saw the scene below. What a day!


It was Dragon Boat Festival in China when I went back home. So it's not available for me to apply for the passport. I have to wait for 23th June, which is the day after the holiday. Finishing the application for the passport, I gotta get back to school the next day.

It was an amazing trip back home!

The passport will be available in 6th July. And I have to move on to finish something else that are required to attend GUADEC 2015. Good luck to myself.

Dominique Dumont: Major bug fix for cme update copyright command

Planet Debian - Dje, 05/07/2015 - 11:46pd

Hello

Previous version of libconfig-model-dpkg-perl had 2 bugs related to copyright update command :

  • Too many directory paragraphs (like src/foo/*) were removed during update.
  • Some file paragraph were not merged, leading to needless paragraphs in debian/copyright file. This bug is less severe as no information is lost

Version 2.067 of libconfig-model-dpkg-perl fixes both issues. This version is available in unstable.

To use cme update dpkg-copyright command, the following packages are required:

All the best


Scientists Look For Patterns In North Carolina Shark Attacks

Slashdot.org - Dje, 05/07/2015 - 11:20pd
HughPickens.com writes: The Washington Post reports that there have been seven recent shark attacks in North Carolina. Scientists are looking for what might be luring the usually shy sharks so close to shore and among the swimmers they usually avoid. It's an unusual number of attacks for a state that recorded 25 attacks between 2005 and 2014. Even with the recent incidents, researchers emphasize that sharks are a very low-level threat to humans, compared with other forms of wildlife. Bees, for example, are much more dangerous. And swimming itself is hazardous even without sharks around. George Burgess, director of the International Shark Attack File at the University of Florida's Florida Museum of Natural History, speculates that several environmental factors could be pushing sharks to congregate in the Outer Banks. It is a warm year, and the water has a higher level of salinity because of a low-level drought in the area. Also, a common species of forage fish — menhaden — has been abundant this year and might have attracted more sharks to the area. Burgess also says some fishermen put bait in the water near piers, which could lure the predators closer to shore; two of the encounters took place within 100 yards of a pier. "That's a formula for shark attacks," Burgess says of these conditions, taken together. "Now, does that explain seven attacks in three weeks? No, it doesn't."

Read more of this story at Slashdot.

Theresa May Named UK's Internet Villain of the Year

Slashdot.org - Dje, 05/07/2015 - 8:24pd
An anonymous reader writes with news that Theresa May, the UK's Secretary of State for the Home Department, has been named the UK internet industry's villain of the year. She won this dubious honor for pushing the UK's controversial "snooper's charter" legislation, which would require ISPs to retain massive amounts of data regarding their subscribers for no less than a year. May championed the legislation without consulting the internet industry. Conversely, "The MPs Tom Watson and David Davis were jointly named internet hero for their legal action against the Data Retention and Investigatory Powers Act. 'Surveillance has dominated both the hero and villain shortlists for number of years, and it was felt Davis and Watson were some of the best informed politicians on the subject,' the ISPA said."

Read more of this story at Slashdot.

Bitcoin Snafu Causes Miners To Generate Invalid Blocks

Slashdot.org - Dje, 05/07/2015 - 5:21pd
An anonymous reader writes: A notice at bitcoin.org warns users of the cryptocurrency that many miners are currently generating invalid blocks. The cause seems to be out-of-date software, and software that assumed blocks were valid instead of checking them. They explain further "For several months, an increasing amount of mining hash rate has been signaling its intent to begin enforcing BIP66 strict DER signatures. As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far."

Read more of this story at Slashdot.

Robert Edmonds: Git packaging workflow for py-lmdb

Planet Debian - Dje, 05/07/2015 - 2:56pd

Recently, I packaged the py-lmdb Python binding for the LMDB database library. This package is going to be team maintained by the pkg-db group, which is responsible for maintaining BerkeleyDB and LMDB packages. Below are my notes on (re-)Debianizing this package and how the Git repository for the source package is laid out.

The upstream py-lmdb developer has a Git-centric workflow. Development is done on the master branch, with regular releases done as fast-forward merges to the release branch. Release tags of the form py-lmdb_X.YZ are provided. The only tarballs provided are the ones that GitHub automatically generates from tags. Since these tarballs are synthetic and the content of these tarballs matches the content on the corresponding tag, we will ignore them in favor of using the release tags directly. (The --git-pristine-tar-commit option to gbp-buildpackage will be used so that .orig.tar.gz files can be replicated so that the Debian archive will accept subsequent uploads, but tarballs are otherwise irrelevant to our workflow.)

To make it clear that the release tags come from upstream's repository, they should be prefixed with upstream/, which would preferably result in a DEP-14 compliant scheme. (Unfortunately, since upstream's release tags begin with py-lmdb_, this doesn't quite match the pattern that DEP-14 recommends.)

Here is how the local packaging repository is initialized. Note that git clone isn't used, so that we can customize how the tags are fetched. Instead, we create an empty Git repository and add the upstream repository as the upstream remote. The --no-tags option is used, so that git fetch does not import the remote's tags. However, we also add a custom fetch refspec refs/tags/*:refs/tags/upstream/* so that the remote's tags are explicitly fetched, but with the upstream/ prefix.

$ mkdir py-lmdb $ cd py-lmdb $ git init Initialized empty Git repository in /home/edmonds/debian/py-lmdb/.git/ $ git remote add --no-tags upstream https://github.com/dw/py-lmdb $ git config --add remote.upstream.fetch 'refs/tags/*:refs/tags/upstream/*' $ git fetch upstream remote: Counting objects: 3336, done. remote: Total 3336 (delta 0), reused 0 (delta 0), pack-reused 3336 Receiving objects: 100% (3336/3336), 2.15 MiB | 0 bytes/s, done. Resolving deltas: 100% (1958/1958), done. From https://github.com/dw/py-lmdb * [new branch] master -> upstream/master * [new branch] release -> upstream/release * [new branch] win32-sparse-patch -> upstream/win32-sparse-patch * [new tag] last-cython-version -> upstream/last-cython-version * [new tag] py-lmdb_0.1 -> upstream/py-lmdb_0.1 * [new tag] py-lmdb_0.2 -> upstream/py-lmdb_0.2 * [new tag] py-lmdb_0.3 -> upstream/py-lmdb_0.3 * [new tag] py-lmdb_0.4 -> upstream/py-lmdb_0.4 * [new tag] py-lmdb_0.5 -> upstream/py-lmdb_0.5 * [new tag] py-lmdb_0.51 -> upstream/py-lmdb_0.51 * [new tag] py-lmdb_0.52 -> upstream/py-lmdb_0.52 * [new tag] py-lmdb_0.53 -> upstream/py-lmdb_0.53 * [new tag] py-lmdb_0.54 -> upstream/py-lmdb_0.54 * [new tag] py-lmdb_0.56 -> upstream/py-lmdb_0.56 * [new tag] py-lmdb_0.57 -> upstream/py-lmdb_0.57 * [new tag] py-lmdb_0.58 -> upstream/py-lmdb_0.58 * [new tag] py-lmdb_0.59 -> upstream/py-lmdb_0.59 * [new tag] py-lmdb_0.60 -> upstream/py-lmdb_0.60 * [new tag] py-lmdb_0.61 -> upstream/py-lmdb_0.61 * [new tag] py-lmdb_0.62 -> upstream/py-lmdb_0.62 * [new tag] py-lmdb_0.63 -> upstream/py-lmdb_0.63 * [new tag] py-lmdb_0.64 -> upstream/py-lmdb_0.64 * [new tag] py-lmdb_0.65 -> upstream/py-lmdb_0.65 * [new tag] py-lmdb_0.66 -> upstream/py-lmdb_0.66 * [new tag] py-lmdb_0.67 -> upstream/py-lmdb_0.67 * [new tag] py-lmdb_0.68 -> upstream/py-lmdb_0.68 * [new tag] py-lmdb_0.69 -> upstream/py-lmdb_0.69 * [new tag] py-lmdb_0.70 -> upstream/py-lmdb_0.70 * [new tag] py-lmdb_0.71 -> upstream/py-lmdb_0.71 * [new tag] py-lmdb_0.72 -> upstream/py-lmdb_0.72 * [new tag] py-lmdb_0.73 -> upstream/py-lmdb_0.73 * [new tag] py-lmdb_0.74 -> upstream/py-lmdb_0.74 * [new tag] py-lmdb_0.75 -> upstream/py-lmdb_0.75 * [new tag] py-lmdb_0.76 -> upstream/py-lmdb_0.76 * [new tag] py-lmdb_0.77 -> upstream/py-lmdb_0.77 * [new tag] py-lmdb_0.78 -> upstream/py-lmdb_0.78 * [new tag] py-lmdb_0.79 -> upstream/py-lmdb_0.79 * [new tag] py-lmdb_0.80 -> upstream/py-lmdb_0.80 * [new tag] py-lmdb_0.81 -> upstream/py-lmdb_0.81 * [new tag] py-lmdb_0.82 -> upstream/py-lmdb_0.82 * [new tag] py-lmdb_0.83 -> upstream/py-lmdb_0.83 * [new tag] py-lmdb_0.84 -> upstream/py-lmdb_0.84 * [new tag] py-lmdb_0.85 -> upstream/py-lmdb_0.85 * [new tag] py-lmdb_0.86 -> upstream/py-lmdb_0.86 $

Note that at this point we have content from the upstream remote in our local repository, but we don't have any local branches:

$ git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track) $ git branch -a remotes/upstream/master remotes/upstream/release remotes/upstream/win32-sparse-patch $

We will use the DEP-14 naming scheme for the packaging branches, so the branch for packages targeted at unstable will be called debian/sid. Since I already made an initial 0.84-1 upload, we need to start the debian/sid branch from the upstream 0.84 tag and import the original packaging content from that upload. The --no-track flag is passed to git checkout initially so that Git doesn't consider the upstream release tag upstream/py-lmdb_0.84 to be the upstream branch for our packaging branch.

$ git checkout --no-track -b debian/sid upstream/py-lmdb_0.84 Switched to a new branch 'debian/sid' $

At this point I imported the original packaging content for 0.84-1 with git am. Then, I signed the debian/0.84-1 tag:

$ git tag -s -m 'Debian release 0.84-1' debian/0.84-1 $ git verify-tag debian/0.84-1 gpg: Signature made Sat 04 Jul 2015 02:49:42 PM EDT using RSA key ID AAF6CDAE gpg: Good signature from "Robert Edmonds <edmonds@mycre.ws>" [ultimate] gpg: aka "Robert Edmonds <edmonds@fsi.io>" [ultimate] gpg: aka "Robert Edmonds <edmonds@debian.org>" [ultimate] $

New upstream releases are integrated by fetching new upstream tags and non-fast-forward merging into the packaging branch. The latest release is 0.86, so we merge from the upstream/py-lmdb_0.86 tag.

$ git fetch upstream --dry-run [...] $ git fetch upstream [...] $ git checkout debian/sid Already on 'debian/sid' $ git merge --no-ff --no-edit upstream/py-lmdb_0.86 Merge made by the 'recursive' strategy. ChangeLog | 46 ++++++++++++++ docs/index.rst | 46 +++++++++++++- docs/themes/acid/layout.html | 4 +- examples/dirtybench-gdbm.py | 6 ++ examples/dirtybench.py | 19 ++++++ examples/nastybench.py | 18 ++++-- examples/parabench.py | 6 ++ lib/lmdb.h | 37 ++++++----- lib/mdb.c | 281 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------- lib/midl.c | 2 +- lib/midl.h | 2 +- lib/py-lmdb/preload.h | 48 ++++++++++++++ lmdb/__init__.py | 2 +- lmdb/cffi.py | 120 ++++++++++++++++++++++++----------- lmdb/cpython.c | 86 +++++++++++++++++++------ lmdb/tool.py | 5 +- misc/gdb.commands | 21 ++++++ misc/runtests-travisci.sh | 3 +- misc/runtests-ubuntu-12-04.sh | 28 ++++---- setup.py | 2 + tests/crash_test.py | 22 +++++++ tests/cursor_test.py | 37 +++++++++++ tests/env_test.py | 73 +++++++++++++++++++++ tests/testlib.py | 14 +++- tests/txn_test.py | 20 ++++++ 25 files changed, 773 insertions(+), 175 deletions(-) create mode 100644 lib/py-lmdb/preload.h create mode 100644 misc/gdb.commands $

Here I did some additional development work like editing the debian/gbp.conf file and applying a fix for #790738 to make the package build reproducibly. The package is now ready for an 0.86-1 upload, so I ran the following gbp dch command:

$ gbp dch --release --auto --new-version=0.86-1 --commit gbp:info: Found tag for topmost changelog version '6bdbb56c04571fe2d5d22aa0287ab0dc83959de5' gbp:info: Continuing from commit '6bdbb56c04571fe2d5d22aa0287ab0dc83959de5' gbp:info: Changelog has been committed for version 0.86-1 $

This automatically generates a changelog entry for 0.86-1, but it includes commit summaries for all of the upstream commits since the last release, which I had to edit out.

Then, I used gbp buildpackage with BUILDER=pbuilder to build the package in a clean, up-to-date sid chroot. After checking the result, I signed the debian/0.86-1 tag:

$ git tag -s -m 'Debian release 0.86-1' debian/0.86-1 $

The package is now ready to be pushed to git.debian.org. First, a bare repository is initialized:

$ ssh git.debian.org edmonds@moszumanska:~$ cd /srv/git.debian.org/git/pkg-db/ edmonds@moszumanska:/srv/git.debian.org/git/pkg-db$ umask 002 edmonds@moszumanska:/srv/git.debian.org/git/pkg-db$ mkdir py-lmdb.git edmonds@moszumanska:/srv/git.debian.org/git/pkg-db$ cd py-lmdb.git/ edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ git --bare init --shared Initialized empty shared Git repository in /srv/git.debian.org/git/pkg-db/py-lmdb.git/ edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ echo 'py-lmdb Debian packaging' > description edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ mv hooks/post-update.sample hooks/post-update edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ chmod a+x hooks/post-update edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ logout Shared connection to git.debian.org closed.

Then, we add a new debian remote to our local packaging repository. Per our repository conventions, we need to ensure that only branch names matching debian/* and pristine-tar and tag names matching debian/* and upstream/* are pushed to the debian remote when we run git push debian, so we add a a set of remote.debian.push refspecs that correspond to these conventions. We also add an explicit remote.debian.fetch refspec to fetch tags.

$ git remote add debian ssh://git.debian.org/git/pkg-db/py-lmdb.git $ git config --add remote.debian.push 'refs/tags/debian/*' $ git config --add remote.debian.push 'refs/tags/upstream/*' $ git config --add remote.debian.push 'refs/heads/debian/*' $ git config --add remote.debian.push 'refs/heads/pristine-tar' $ git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*'

We now run the initial push to the remote Git repository. The --set-upstream option is used so that our local branches will be configured to track the corresponding remote branches. Also note that the debian/* and upstream/* tags are pushed as well.

$ git push debian --set-upstream Counting objects: 3333, done. Delta compression using up to 8 threads. Compressing objects: 100% (1083/1083), done. Writing objects: 100% (3333/3333), 1.37 MiB | 0 bytes/s, done. Total 3333 (delta 2231), reused 3314 (delta 2218) To ssh://git.debian.org/git/pkg-db/py-lmdb.git * [new branch] pristine-tar -> pristine-tar * [new branch] debian/sid -> debian/sid * [new tag] debian/0.84-1 -> debian/0.84-1 * [new tag] debian/0.86-1 -> debian/0.86-1 * [new tag] upstream/last-cython-version -> upstream/last-cython-version * [new tag] upstream/py-lmdb_0.1 -> upstream/py-lmdb_0.1 * [new tag] upstream/py-lmdb_0.2 -> upstream/py-lmdb_0.2 * [new tag] upstream/py-lmdb_0.3 -> upstream/py-lmdb_0.3 * [new tag] upstream/py-lmdb_0.4 -> upstream/py-lmdb_0.4 * [new tag] upstream/py-lmdb_0.5 -> upstream/py-lmdb_0.5 * [new tag] upstream/py-lmdb_0.51 -> upstream/py-lmdb_0.51 * [new tag] upstream/py-lmdb_0.52 -> upstream/py-lmdb_0.52 * [new tag] upstream/py-lmdb_0.53 -> upstream/py-lmdb_0.53 * [new tag] upstream/py-lmdb_0.54 -> upstream/py-lmdb_0.54 * [new tag] upstream/py-lmdb_0.56 -> upstream/py-lmdb_0.56 * [new tag] upstream/py-lmdb_0.57 -> upstream/py-lmdb_0.57 * [new tag] upstream/py-lmdb_0.58 -> upstream/py-lmdb_0.58 * [new tag] upstream/py-lmdb_0.59 -> upstream/py-lmdb_0.59 * [new tag] upstream/py-lmdb_0.60 -> upstream/py-lmdb_0.60 * [new tag] upstream/py-lmdb_0.61 -> upstream/py-lmdb_0.61 * [new tag] upstream/py-lmdb_0.62 -> upstream/py-lmdb_0.62 * [new tag] upstream/py-lmdb_0.63 -> upstream/py-lmdb_0.63 * [new tag] upstream/py-lmdb_0.64 -> upstream/py-lmdb_0.64 * [new tag] upstream/py-lmdb_0.65 -> upstream/py-lmdb_0.65 * [new tag] upstream/py-lmdb_0.66 -> upstream/py-lmdb_0.66 * [new tag] upstream/py-lmdb_0.67 -> upstream/py-lmdb_0.67 * [new tag] upstream/py-lmdb_0.68 -> upstream/py-lmdb_0.68 * [new tag] upstream/py-lmdb_0.69 -> upstream/py-lmdb_0.69 * [new tag] upstream/py-lmdb_0.70 -> upstream/py-lmdb_0.70 * [new tag] upstream/py-lmdb_0.71 -> upstream/py-lmdb_0.71 * [new tag] upstream/py-lmdb_0.72 -> upstream/py-lmdb_0.72 * [new tag] upstream/py-lmdb_0.73 -> upstream/py-lmdb_0.73 * [new tag] upstream/py-lmdb_0.74 -> upstream/py-lmdb_0.74 * [new tag] upstream/py-lmdb_0.75 -> upstream/py-lmdb_0.75 * [new tag] upstream/py-lmdb_0.76 -> upstream/py-lmdb_0.76 * [new tag] upstream/py-lmdb_0.77 -> upstream/py-lmdb_0.77 * [new tag] upstream/py-lmdb_0.78 -> upstream/py-lmdb_0.78 * [new tag] upstream/py-lmdb_0.79 -> upstream/py-lmdb_0.79 * [new tag] upstream/py-lmdb_0.80 -> upstream/py-lmdb_0.80 * [new tag] upstream/py-lmdb_0.81 -> upstream/py-lmdb_0.81 * [new tag] upstream/py-lmdb_0.82 -> upstream/py-lmdb_0.82 * [new tag] upstream/py-lmdb_0.83 -> upstream/py-lmdb_0.83 * [new tag] upstream/py-lmdb_0.84 -> upstream/py-lmdb_0.84 * [new tag] upstream/py-lmdb_0.85 -> upstream/py-lmdb_0.85 * [new tag] upstream/py-lmdb_0.86 -> upstream/py-lmdb_0.86 Branch pristine-tar set up to track remote branch pristine-tar from debian. Branch debian/sid set up to track remote branch debian/sid from debian. $

After the initial push, we need to configure the remote repository so that clones will checkout the debian/sid branch by default:

$ ssh git.debian.org edmonds@moszumanska:~$ cd /srv/git.debian.org/git/pkg-db/py-lmdb.git/ edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ git symbolic-ref HEAD refs/heads/debian/sid edmonds@moszumanska:/srv/git.debian.org/git/pkg-db/py-lmdb.git$ logout Shared connection to git.debian.org closed.

We can check if there are any updates in upstream's Git repository with the following command:

$ git fetch upstream --dry-run -v From https://github.com/dw/py-lmdb = [up to date] master -> upstream/master = [up to date] release -> upstream/release = [up to date] win32-sparse-patch -> upstream/win32-sparse-patch = [up to date] last-cython-version -> upstream/last-cython-version = [up to date] py-lmdb_0.1 -> upstream/py-lmdb_0.1 = [up to date] py-lmdb_0.2 -> upstream/py-lmdb_0.2 = [up to date] py-lmdb_0.3 -> upstream/py-lmdb_0.3 = [up to date] py-lmdb_0.4 -> upstream/py-lmdb_0.4 = [up to date] py-lmdb_0.5 -> upstream/py-lmdb_0.5 = [up to date] py-lmdb_0.51 -> upstream/py-lmdb_0.51 = [up to date] py-lmdb_0.52 -> upstream/py-lmdb_0.52 = [up to date] py-lmdb_0.53 -> upstream/py-lmdb_0.53 = [up to date] py-lmdb_0.54 -> upstream/py-lmdb_0.54 = [up to date] py-lmdb_0.56 -> upstream/py-lmdb_0.56 = [up to date] py-lmdb_0.57 -> upstream/py-lmdb_0.57 = [up to date] py-lmdb_0.58 -> upstream/py-lmdb_0.58 = [up to date] py-lmdb_0.59 -> upstream/py-lmdb_0.59 = [up to date] py-lmdb_0.60 -> upstream/py-lmdb_0.60 = [up to date] py-lmdb_0.61 -> upstream/py-lmdb_0.61 = [up to date] py-lmdb_0.62 -> upstream/py-lmdb_0.62 = [up to date] py-lmdb_0.63 -> upstream/py-lmdb_0.63 = [up to date] py-lmdb_0.64 -> upstream/py-lmdb_0.64 = [up to date] py-lmdb_0.65 -> upstream/py-lmdb_0.65 = [up to date] py-lmdb_0.66 -> upstream/py-lmdb_0.66 = [up to date] py-lmdb_0.67 -> upstream/py-lmdb_0.67 = [up to date] py-lmdb_0.68 -> upstream/py-lmdb_0.68 = [up to date] py-lmdb_0.69 -> upstream/py-lmdb_0.69 = [up to date] py-lmdb_0.70 -> upstream/py-lmdb_0.70 = [up to date] py-lmdb_0.71 -> upstream/py-lmdb_0.71 = [up to date] py-lmdb_0.72 -> upstream/py-lmdb_0.72 = [up to date] py-lmdb_0.73 -> upstream/py-lmdb_0.73 = [up to date] py-lmdb_0.74 -> upstream/py-lmdb_0.74 = [up to date] py-lmdb_0.75 -> upstream/py-lmdb_0.75 = [up to date] py-lmdb_0.76 -> upstream/py-lmdb_0.76 = [up to date] py-lmdb_0.77 -> upstream/py-lmdb_0.77 = [up to date] py-lmdb_0.78 -> upstream/py-lmdb_0.78 = [up to date] py-lmdb_0.79 -> upstream/py-lmdb_0.79 = [up to date] py-lmdb_0.80 -> upstream/py-lmdb_0.80 = [up to date] py-lmdb_0.81 -> upstream/py-lmdb_0.81 = [up to date] py-lmdb_0.82 -> upstream/py-lmdb_0.82 = [up to date] py-lmdb_0.83 -> upstream/py-lmdb_0.83 = [up to date] py-lmdb_0.84 -> upstream/py-lmdb_0.84 = [up to date] py-lmdb_0.85 -> upstream/py-lmdb_0.85 = [up to date] py-lmdb_0.86 -> upstream/py-lmdb_0.86

We can check if any co-maintainers have pushed updates to the git.debian.org repository with the following command:

$ git fetch debian --dry-run -v From ssh://git.debian.org/git/pkg-db/py-lmdb = [up to date] debian/sid -> debian/debian/sid = [up to date] pristine-tar -> debian/pristine-tar = [up to date] debian/0.84-1 -> debian/0.84-1 = [up to date] debian/0.86-1 -> debian/0.86-1 = [up to date] upstream/last-cython-version -> upstream/last-cython-version = [up to date] upstream/py-lmdb_0.1 -> upstream/py-lmdb_0.1 = [up to date] upstream/py-lmdb_0.2 -> upstream/py-lmdb_0.2 = [up to date] upstream/py-lmdb_0.3 -> upstream/py-lmdb_0.3 = [up to date] upstream/py-lmdb_0.4 -> upstream/py-lmdb_0.4 = [up to date] upstream/py-lmdb_0.5 -> upstream/py-lmdb_0.5 = [up to date] upstream/py-lmdb_0.51 -> upstream/py-lmdb_0.51 = [up to date] upstream/py-lmdb_0.52 -> upstream/py-lmdb_0.52 = [up to date] upstream/py-lmdb_0.53 -> upstream/py-lmdb_0.53 = [up to date] upstream/py-lmdb_0.54 -> upstream/py-lmdb_0.54 = [up to date] upstream/py-lmdb_0.56 -> upstream/py-lmdb_0.56 = [up to date] upstream/py-lmdb_0.57 -> upstream/py-lmdb_0.57 = [up to date] upstream/py-lmdb_0.58 -> upstream/py-lmdb_0.58 = [up to date] upstream/py-lmdb_0.59 -> upstream/py-lmdb_0.59 = [up to date] upstream/py-lmdb_0.60 -> upstream/py-lmdb_0.60 = [up to date] upstream/py-lmdb_0.61 -> upstream/py-lmdb_0.61 = [up to date] upstream/py-lmdb_0.62 -> upstream/py-lmdb_0.62 = [up to date] upstream/py-lmdb_0.63 -> upstream/py-lmdb_0.63 = [up to date] upstream/py-lmdb_0.64 -> upstream/py-lmdb_0.64 = [up to date] upstream/py-lmdb_0.65 -> upstream/py-lmdb_0.65 = [up to date] upstream/py-lmdb_0.66 -> upstream/py-lmdb_0.66 = [up to date] upstream/py-lmdb_0.67 -> upstream/py-lmdb_0.67 = [up to date] upstream/py-lmdb_0.68 -> upstream/py-lmdb_0.68 = [up to date] upstream/py-lmdb_0.69 -> upstream/py-lmdb_0.69 = [up to date] upstream/py-lmdb_0.70 -> upstream/py-lmdb_0.70 = [up to date] upstream/py-lmdb_0.71 -> upstream/py-lmdb_0.71 = [up to date] upstream/py-lmdb_0.72 -> upstream/py-lmdb_0.72 = [up to date] upstream/py-lmdb_0.73 -> upstream/py-lmdb_0.73 = [up to date] upstream/py-lmdb_0.74 -> upstream/py-lmdb_0.74 = [up to date] upstream/py-lmdb_0.75 -> upstream/py-lmdb_0.75 = [up to date] upstream/py-lmdb_0.76 -> upstream/py-lmdb_0.76 = [up to date] upstream/py-lmdb_0.77 -> upstream/py-lmdb_0.77 = [up to date] upstream/py-lmdb_0.78 -> upstream/py-lmdb_0.78 = [up to date] upstream/py-lmdb_0.79 -> upstream/py-lmdb_0.79 = [up to date] upstream/py-lmdb_0.80 -> upstream/py-lmdb_0.80 = [up to date] upstream/py-lmdb_0.81 -> upstream/py-lmdb_0.81 = [up to date] upstream/py-lmdb_0.82 -> upstream/py-lmdb_0.82 = [up to date] upstream/py-lmdb_0.83 -> upstream/py-lmdb_0.83 = [up to date] upstream/py-lmdb_0.84 -> upstream/py-lmdb_0.84 = [up to date] upstream/py-lmdb_0.85 -> upstream/py-lmdb_0.85 = [up to date] upstream/py-lmdb_0.86 -> upstream/py-lmdb_0.86 $

We can check if anything needs to be pushed from our local repository to the git.debian.org repository with the following command:

$ git push debian --dry-run -v Pushing to ssh://git.debian.org/git/pkg-db/py-lmdb.git To ssh://git.debian.org/git/pkg-db/py-lmdb.git = [up to date] debian/sid -> debian/sid = [up to date] pristine-tar -> pristine-tar = [up to date] debian/0.84-1 -> debian/0.84-1 = [up to date] debian/0.86-1 -> debian/0.86-1 = [up to date] upstream/last-cython-version -> upstream/last-cython-version = [up to date] upstream/py-lmdb_0.1 -> upstream/py-lmdb_0.1 = [up to date] upstream/py-lmdb_0.2 -> upstream/py-lmdb_0.2 = [up to date] upstream/py-lmdb_0.3 -> upstream/py-lmdb_0.3 = [up to date] upstream/py-lmdb_0.4 -> upstream/py-lmdb_0.4 = [up to date] upstream/py-lmdb_0.5 -> upstream/py-lmdb_0.5 = [up to date] upstream/py-lmdb_0.51 -> upstream/py-lmdb_0.51 = [up to date] upstream/py-lmdb_0.52 -> upstream/py-lmdb_0.52 = [up to date] upstream/py-lmdb_0.53 -> upstream/py-lmdb_0.53 = [up to date] upstream/py-lmdb_0.54 -> upstream/py-lmdb_0.54 = [up to date] upstream/py-lmdb_0.56 -> upstream/py-lmdb_0.56 = [up to date] upstream/py-lmdb_0.57 -> upstream/py-lmdb_0.57 = [up to date] upstream/py-lmdb_0.58 -> upstream/py-lmdb_0.58 = [up to date] upstream/py-lmdb_0.59 -> upstream/py-lmdb_0.59 = [up to date] upstream/py-lmdb_0.60 -> upstream/py-lmdb_0.60 = [up to date] upstream/py-lmdb_0.61 -> upstream/py-lmdb_0.61 = [up to date] upstream/py-lmdb_0.62 -> upstream/py-lmdb_0.62 = [up to date] upstream/py-lmdb_0.63 -> upstream/py-lmdb_0.63 = [up to date] upstream/py-lmdb_0.64 -> upstream/py-lmdb_0.64 = [up to date] upstream/py-lmdb_0.65 -> upstream/py-lmdb_0.65 = [up to date] upstream/py-lmdb_0.66 -> upstream/py-lmdb_0.66 = [up to date] upstream/py-lmdb_0.67 -> upstream/py-lmdb_0.67 = [up to date] upstream/py-lmdb_0.68 -> upstream/py-lmdb_0.68 = [up to date] upstream/py-lmdb_0.69 -> upstream/py-lmdb_0.69 = [up to date] upstream/py-lmdb_0.70 -> upstream/py-lmdb_0.70 = [up to date] upstream/py-lmdb_0.71 -> upstream/py-lmdb_0.71 = [up to date] upstream/py-lmdb_0.72 -> upstream/py-lmdb_0.72 = [up to date] upstream/py-lmdb_0.73 -> upstream/py-lmdb_0.73 = [up to date] upstream/py-lmdb_0.74 -> upstream/py-lmdb_0.74 = [up to date] upstream/py-lmdb_0.75 -> upstream/py-lmdb_0.75 = [up to date] upstream/py-lmdb_0.76 -> upstream/py-lmdb_0.76 = [up to date] upstream/py-lmdb_0.77 -> upstream/py-lmdb_0.77 = [up to date] upstream/py-lmdb_0.78 -> upstream/py-lmdb_0.78 = [up to date] upstream/py-lmdb_0.79 -> upstream/py-lmdb_0.79 = [up to date] upstream/py-lmdb_0.80 -> upstream/py-lmdb_0.80 = [up to date] upstream/py-lmdb_0.81 -> upstream/py-lmdb_0.81 = [up to date] upstream/py-lmdb_0.82 -> upstream/py-lmdb_0.82 = [up to date] upstream/py-lmdb_0.83 -> upstream/py-lmdb_0.83 = [up to date] upstream/py-lmdb_0.84 -> upstream/py-lmdb_0.84 = [up to date] upstream/py-lmdb_0.85 -> upstream/py-lmdb_0.85 = [up to date] upstream/py-lmdb_0.86 -> upstream/py-lmdb_0.86 Everything up-to-date

Finally, in order to set up a fresh local clone of the git.debian.org repository that's configured like the local repository created above, we have to do the following:

$ git clone --origin debian ssh://git.debian.org/git/pkg-db/py-lmdb.git Cloning into 'py-lmdb'... remote: Counting objects: 3333, done. remote: Compressing objects: 100% (1070/1070), done. remote: Total 3333 (delta 2231), reused 3333 (delta 2231) Receiving objects: 100% (3333/3333), 1.37 MiB | 1.11 MiB/s, done. Resolving deltas: 100% (2231/2231), done. Checking connectivity... done. $ cd py-lmdb $ git remote add --no-tags upstream https://github.com/dw/py-lmdb $ git config --add remote.upstream.fetch 'refs/tags/*:refs/tags/upstream/*' $ git fetch upstream remote: Counting objects: 56, done. remote: Total 56 (delta 25), reused 25 (delta 25), pack-reused 31 Unpacking objects: 100% (56/56), done. From https://github.com/dw/py-lmdb * [new branch] master -> upstream/master * [new branch] release -> upstream/release * [new branch] win32-sparse-patch -> upstream/win32-sparse-patch $ git branch --track pristine-tar debian/pristine-tar Branch pristine-tar set up to track remote branch pristine-tar from debian. $ git config --add remote.debian.push 'refs/tags/debian/*' $ git config --add remote.debian.push 'refs/tags/upstream/*' $ git config --add remote.debian.push 'refs/heads/debian/*' $ git config --add remote.debian.push 'refs/heads/pristine-tar' $ git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*' $

This is a fair amount of effort beyond a simple git clone, though, so I wonder if anything can be done to optimize this.

Brain-Inspired 'Memcomputer' Constructed

Slashdot.org - Dje, 05/07/2015 - 2:35pd
New submitter DorkFest writes: "Inspired by the human brain, UC San Diego scientists have constructed a new kind of computer that stores information and processes it in the same place. This prototype 'memcomputer' solves a problem involving a large dataset more quickly than conventional computers, while using far less energy. ... Such memcomputers could equal or surpass the potential of quantum computers, they say, but because they don't rely on exotic quantum effects are far more easily constructed." The team, led by UC San Diego physicist Massimiliano Di Ventra published their results in the journal Science Advances.

Read more of this story at Slashdot.

Faqet

Subscribe to AlbLinux agreguesi - Site në gjuhë të huaj