[19:35] <Miyavix3> Helloo
[19:36] <Miyavix3> Is anyone here...?
[19:36] <Flannel> Miyavix3: Yep
[19:37] <Miyavix3> ok :D!
[19:37] <Miyavix3> So I did the same thing
[19:37] <Miyavix3> and same results
[19:37] <Miyavix3> auto lo
[19:37] <Flannel> What same thing? and what same results?
[19:37] <Miyavix3> iface lo inet loopback
[19:37] <Miyavix3> sudo nano /etc/network/nterfaces
[19:38] <Flannel> right, you need to add "auto eth0" and "iface eth0 inet dhcp" to the end of that
[19:39] <Miyavix3> save and then try apt-gettig something/
[19:39] <Miyavix3> ?
[19:39] <Flannel> Save, then sudo /etc/init.d/networking restart
[19:40] <Flannel> and then verify you're online (w3m google.com, or ping or whatever)
[19:40] <Miyavix3> Tell me when I need internet
[19:40] <Miyavix3> Because 1 ethernet cord for 2 computers
[19:40] <Flannel> this is where you'd need internet.  We're connecting you to the......
[19:40] <Flannel> I see
[19:40] <Flannel> Did you boot this other box with the ethernet plugged in?
[19:40] <Miyavix3> I can't find my other cable
[19:40] <Miyavix3> I plug it in for apt-get
[19:40] <Miyavix3> I'm not completely stupid
[19:41] <Miyavix3> just, mostly stupid
[19:41] <Flannel> Well, without the GUI, automatic things like recognizing theres a new ethernet cable don't always happen
[19:41] <Miyavix3> So for the sudo etc/init.d ... I need internet?
[19:42] <Flannel> so, plug it in, sudo /etc/init.d/networking restart, try to get online, if that doesn't work, I imagine your stuff isn't broken at all, you just need to reboot with the cord plugged in.  And I'm leaning towards telling you to remove the stuff we just added.
[19:42] <Flannel> Miyavix3: yeah
[19:42] <Flannel> Miyavix3: We're trying to connect to the internet then
[19:42] <Miyavix3> ok, brb
[19:42] <Miyavix3> switching chords
[19:44] <Miyavix3> so askdlahsdlkajs
[19:44] <Miyavix3> Am I connected?
[19:44] <Flannel> Miyavix3: yes
[19:44] <Miyavix3> oh cool, lol
[19:44] <Miyavix3> erll uh
[19:44] <Miyavix3> [fail]
[19:45] <Miyavix3> interface lo declared allow-auto twice ifdown: couldn't real interfaces file "etc/network/interfaces"
[19:47] <Miyavix3> anything?
[19:48] <Miyavix3> read*
[19:48] <Miyavix3> >_>
[19:48] <Flannel> Well, I'm hesitant to think anything was wrong to begin with, so why don't you try removing the stuff we just added, and rebooting with the network cable plugged in
[19:49]  * Flannel hates the "reboot to fix it" option, but I'm obviously not familiar with whatever chnages they made in stuff after Dapper if theres no eth0 in there by default
[19:49] <Miyavix3> brb again
[19:49] <Miyavix3> What's the shutdown command?
[19:50] <Miyavix3> nvm
[19:51] <batsquid> shutdown now
[19:54] <Miyavix31> ok well
[19:54] <Miyavix31> I think I'm SOL
[19:54] <Flannel> Miyavix3: Nah, even if you can't get networking to work for some reason, you can grab an alternate CD and install the GUI from that
[19:55] <Miyavix31> I have the insall disk
[19:55] <Miyavix31> install
[19:56] <Miyavix31> So I can fix this and everything will be fine
[19:56] <Miyavix31> ?
[19:56] <Miyavix31> Or rather, I'll have my settings and files?
[19:59] <Miyavix31> I have the disk
[20:05] <Miyavix31> well uh...
[20:05] <Miyavix31> what do I do?
[20:07] <Miyavix31> Flannel... =\
[20:08] <Miyavix31> I'm just going to reinstall
[20:09] <Miyavix31> Seriously, this problem has lasted over 2 hours
[20:09] <Miyavix31> Thanks for your help man
[20:09] <Miyavix31> but I suck
[20:09] <Miyavix31> So see ya
[20:18] <Miyavix3> is anyone here...
[22:38] <nhandler> I have to ask you all a serious question. The package I was planning on demonstrating how to perform a merge on refuses to build in intrepid. I can either do the lesson as planned today, but you will be unable to build the package, or I can push the lesson back to next Tuesday and do the lesson then with a different package.
[22:39] <nhandler> What would you guys prefer I do?
[22:41] <Syntux> can't you find another package ?
[22:41] <nhandler> Syntux: Yes I can. And that is what I would do if I were to push the lesson back to Tuesday
[22:42] <Syntux> we can't find one now? in like 10 minutes?
[22:42] <Syntux> it's 1 am here and the only reason I'm awake is this session :-)
[22:44] <nhandler> I'm really sorry Syntux. Yes, I could find a new package, but the lesson would be significantly longer as I would be working on it as I am trying to teach
[22:46] <Syntux> you know what; picking a random package and seeing what would happen is better than picking a tested one
[22:46] <james_w> hey nhandler
[22:46] <nhandler> Hi james_w
[22:46] <Syntux> one of the things that we face as motu wannabes is that we always face problems that wasn't mentioned in wiki/video or by our mentor :D
[22:47] <Syntux> so it's good to see how things really work
[22:47] <james_w> I don't think having it build at the end is the most important bit, but if you're not happy doing the session then we shouldn't
[22:47] <james_w> Syntux makes a good point though, things never go to plan
[22:47] <nhandler> james_w: I am fine doing the session as is. The reason the package refuses to build has nothing to do with the merge.
[22:47] <james_w> nhandler: that's ok then
[22:47] <Syntux> the most important part about this session is to understand the difference between sync and merge; and the workflow
[22:47] <james_w> is anyone else here for the session, or is it just me and Syntux ?
[22:48] <Syntux> james_w, I'm here before you :p so it's syntux and me.
[22:48] <nhandler> Syntux: The session actually focuses more about HOW to perform a merge
[22:49] <Syntux> true but a wannabe wont merge without differentiating it from sync.
[22:50] <nhandler> Syntux: I do mention how you know the difference between a sync and a merge, but that is not the focus of the lesson
[22:50] <Syntux> sure
[22:51] <nhandler> It looks like people still want me to do the lesson. So I'll give it a try. If you plan on participating, please join #ubuntu-classroom-chat
[22:52] <james_w> thanks nhandler
[22:52] <james_w> would you like to give it a few minutes to allow people to arrive?
[22:52] <nhandler> We still have 8 minutes until it was scheduled to start. I'll wait until then.
[22:53] <james_w> great, thanks
[22:59] <Laney> Rawr
[23:00] <james_w> hey Laney, top showering
[23:00] <james_w> nhandler: you would like questions in #-chat?
[23:00] <nhandler> Yes james_w
[23:00] <Laney> I merged the shampoo with my hair, and built the soap into a lather
[23:01] <Laney> and in the end we got a working clean target
[23:01] <james_w> :-)
[23:01] <nhandler> I guess I'll start
[23:01] <james_w> nhandler: fair enough.
[23:01] <nhandler> Hello everyone, and thanks for joining me for my MOTU School session about merging packages from Debian.
[23:01] <nhandler> If you have any questions, please feel free to ask them in #ubuntu-classroom-chat at any time. Please be sure to prefix your questions with "QUESTION:".
[23:02] <nhandler> The wiki does an excellent job of explaining why we need to merge/sync packages from Debian.
[23:02] <nhandler> Here is an excerpt from https://wiki.ubuntu.com/UbuntuDevelopment/Merging.
[23:03] <nhandler> Ubuntu is based on the Debian GNU/Linux distribution and uses the same package management system. In the beginning of each Ubuntu development cycle the packages in Ubuntu are updated to those in Debian unstable. However, because Ubuntu is not the same as Debian, some of the packages need to be modified to work in Ubuntu. There might also be bug fixes that Ubuntu developers have introduced into the packages.
[23:03] <nhandler> You can determine whether this has taken place by noting the package version. If the package version includes ubuntu in it (an example would be gimp 2.2.9-3ubuntu2) then the Ubuntu developers have made some change and it is no longer the same as the Debian package. There are more than 1000 such packages in the Universe repository.
[23:03] <nhandler> At the start of the development cycle a decision has to be made with regard to these Ubuntu-versioned packages. Of course if the Debian version hasn't changed since the last Ubuntu release then nothing needs to be changed. However, if there is a newer version of the package in Debian then one of two things should happen.
[23:04] <nhandler> If all of the reasons that the Ubuntu version existed (bug fixes, dependencies, etc.) are fixed in the new Debian package then we can just take the Debian package directly. This is called a sync. However, if the new Debian version has the same issues that caused the Ubuntu version to be made, then those changes need to be applied to the new Debian version. This is called merging.
[23:04] <nhandler> The Ubuntu Merge-o-Matic (MoM), http://merges.ubuntu.com/universe.html, provides a list of packages that need to either be merged or synced from Debian.
[23:05] <nhandler> DaD, http://dad.dunnewind.net/universe.php, is another merge tool. Although we will be using MoM for our example today, you should always check DaD to make sure that someone isn't already working on merging the package you want to do. You also should ask the last Ubuntu uploader if they are planning on doing the merge.
[23:05] <nhandler> Today, we will be merging a package called "ksensors".
[23:05] <nhandler> Before we begin, please install: devscripts, build-essential, wget, fakeroot, quilt, patchutils, and debhelper from the repositories. You will need them in order to follow along with this lesson.
[23:06] <nhandler> All of these packages are available in the Ubuntu repositories.
[23:06] <nhandler> Start by creating a directory called "Merges" in your home folder. This folder will hold all of your merges.
[23:07] <nhandler> Next, download the grab-merge script, http://merges.ubuntu.com/grab-merge.sh, to the Merges folder, and make it executable with 'chmod +x ~/Merges/grab-merge.sh'.
[23:08] <nhandler> We will use grab-merge.sh to download all of the files that we need to perform the merge from MoM.
[23:08] <nhandler> Inside your Merges folder, create a new folder called "ksensors". This new folder will hold all the files related to merging ksensors.
[23:09] <nhandler> Now, open a terminal (Applications->Accessories->Terminal), and type 'cd ~/Merges/ksensors' to enter our new ksensors folder.
[23:09] <nhandler> We will now download the files we need to perform the merge. Type '../grab-merge.sh ksensors'. This will download all the files we need.
[23:11] <nhandler> Once the script finishes running, type 'less REPORT' to view the report file that MoM generated for us. This report will show us which files had changes that were unable to be merged automatically.
[23:11] <nhandler> Near the bottom of the REPORT file, you should see a line that looks like this:
[23:11] <nhandler> C  debian/control
[23:12] <nhandler> That means that MoM was unable to automatically merge the changes that were made in Ubuntu and Debian for that file.
[23:13] <nhandler> First, 'cd ksensors-0.7.3-16ubuntu1' to enter the source directory.
[23:13] <nhandler> The first thing you should do is look at the changelog file. This file shows all changes that were made in Ubuntu and in Debian. I prefer to just leave this file open so that I can refer to it later.
[23:14] <nhandler> When performing a merge, we need to focus on the most recent "batch" of Ubuntu changes. You will be able to recognize this "batch", because all of the Ubuntu changes in it will be against the same Debian revision. The debian revision is located after the '-' and before the 'ubuntu'. In ksensors, the batch of changes that we want to focus on includes versions 0.7.3-15ubuntu1 and 0.7.3-15ubuntu2. Do you notice that both of those versio
[23:14] <nhandler> ns have a Debian revision of 15?
[23:15] <medo_> nhandler: do you mean the upstream changelog file
[23:15] <medo_> or the /debian/changelog
[23:15] <nhandler> medo_: I mean debian/changelog
[23:16] <medo_> thank
[23:16] <medo_> :)
[23:16] <nhandler> Remember, please try and ask all questions in #ubuntu-classroom-chat
[23:16] <nhandler> Moving on, if you look at version 0.7.3-15ubuntu1, you will see that it had two changes. It modified the menu file, and it added dh_iconcache to debian/rules.
 QUESTIN where are we lookinh
[23:17] <Laney> looking* I think
[23:18] <m_newton> Laney, I found it thanks
[23:18] <nhandler> In 0.7.3-15ubuntu2, you will see that several changes were made. quilt was added as a Build-Depends in debian/control, debian/rules was updated, a patch was added in debian/patches, and dh_iconcache was changed to dh_icons in debian/rules.
[23:20] <nhandler> Now that we know what changes were made in Ubuntu, we need to look at the most recent Debian version, 0.7.3-16, to see if any of the Ubuntu changes were added upstream in Debian. As you can see from the changelog entry, Debian has not applied any of the Ubuntu changes.
 QUESTION: do we close the terminal where we did less REPORT
[23:21] <nhandler> m_newton: You can close the REPORT file if you wish. It does not matter.
[23:21] <Laney>  <Syntux> Laney, why we have to focus on the version before the last (15) and not the last (16)
[23:22] <Alan_M> Guys, please see nhandlers comment about questions.
[23:22] <nhandler> Syntux: The reason we are looking at the Ubuntu changes that had a Debian revision of 15 is because 0.7.3-16 is not currently in Ubuntu yet. As a result, no Ubuntu changes have been made for that Debian revision
[23:23] <nhandler> Did that answer your question Syntux ?
[23:23] <Syntux> sure.
[23:23] <Syntux> Thanks.
[23:23] <nhandler> Alright, now for the fun part. We are now able to perform the merge.
[23:23] <nhandler> Start by opening debian/control. You should see a section that looks like this: http://paste.ubuntu.com/37417/
[23:24] <norsetto> nhandler: I have a question before, who is telling us that we should carry over these changes?
[23:24] <nhandler> norsetto: What changes are you referring to?
[23:24] <norsetto> nhandler: the changes from the previous ubuntu versions
[23:25] <nhandler> norsetto: We don't always carry over the Ubuntu changes from previous versions. It depends if they are still needed and whether or not they have been applied upstream
[23:25] <norsetto> nhandler: right, I think this is a pretty important point
[23:26] <nhandler> Our goal is to get all of the Ubuntu changes applied upstream so that we can automatically sync the package when Debian releases a new version
[23:26] <nhandler> norsetto: I talk about this topic a little later in the lesson
[23:26] <norsetto> nhandler: in this particular case, seems like we have been carrying the wrong change for the last few years
[23:27] <nhandler> norsetto: You are probably right. Most of the changes in ksensors should have been sent upstream. However, I don't think we should simply drop them now.
[23:28] <Laney> (they can be sent upstrem as part of this merge!)
[23:28] <norsetto> nhandler: I think is a good idea always to check the bug report that originated a change, in this case bug 45675
[23:29] <norsetto> nhandler: so, seems like the change did exactly the opposite of what the bug report was about ... but anyhow, this is indeed off-topic, so, lets continue
[23:30] <nhandler> Back to debian/control...
[23:30] <nhandler> Start by opening debian/control. You should see a section that looks like this: http://paste.ubuntu.com/37417/
[23:30] <nhandler> The lines above the '[23:31] <nhandler> The first thing we will look at is the maintainer field. The Maintainer field should be set to 'Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>' for packages in Universe or Multiverse, and to Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> for packages in main or restricted. You can read more about this here: https://wiki.ubuntu.com/DebianMaintainerField
[23:31] <nhandler> An easy way to figure out what repository a package is in is to use: 'apt-cache madison <package>'
[23:32] <nhandler> The XSBC-Original-Maintainer field is used to store the information of the Debian maintainer.
[23:33] <nhandler> For ksensors, do you notice how the Ubuntu XSBC-Original-Maintainer field and the Debian Maintainer field both contain the same information? This means that the Debian maintainer has not changed since the last Ubuntu version. We can simply delete the Debian Maintainer field line from the control file. If the two fields had been different, we would have had to update the Ubuntu XSBC-Original-Maintainer field to contain the new Debian
[23:33] <nhandler> maintainer's information.
[23:34] <nhandler> Looking back at debian/changelog, you can see that the only change Ubuntu made to the Build-Depends field was adding 'quilt' in version 0.7.3-15ubuntu2. Since Debian has also modified the Build-Depends field, we have to merge the different changes together. In this case, all we need to do is add 'quilt' to the end of the Debian Build-Depends line. After doing that, we can remove the Ubuntu Build-Depends line.
 Question: apt-cache madison <package> <<< what does madison signify??
[23:36] <nhandler> m_newton: "apt-cache´s madison command attempts to mimic the output format and a subset of the functionality of the Debian archive management tool, madison." that is from the apt-cache man page
[23:36] <nhandler> Continuing with the lesson...
[23:36] <nhandler> Now that we have resolved all of the conflicting lines in debian/control, we can remove the '<<<<<<<', '[23:37] <nhandler> At this point, you should have a control file that has been successfully merged. If you would like to verify that your control file is correct, you can upload it to http://paste.ubuntu.com/, and paste the URL in #ubuntu-classroom-chat.
[23:41] <nhandler> You can view my control file here: http://paste.ubuntu.com/37304/
[23:43] <nhandler> MoM attempts to merge as many of the changes as possible from the Debian and Ubuntu versions of the package. However, you should always verify that this task was done correctly.
[23:44] <nhandler> The first change we will verify is the change to the menu file.
[23:45] <nhandler> Start by opening up debian/menu
[23:46] <nhandler> Notice how they have changed the section from Apps/System to Apps/Tools?
[23:46] <nhandler> This is the change norsetto and I were talking about earlier
[23:47] <nhandler> However, for the purposes of this lesson, just notice how the change made in Ubuntu has not been applied upstream in Debian. It is still needed, and MoM has successfully applied the change.
[23:49] <nhandler> I'm surprised nobody asked me how I knew it changed from Apps/System to Apps/Tools
[23:49] <m_newton> ya, how nhandler
[23:49] <m_newton> I just see Apps/Tools
[23:50] <nhandler> I knew this by opening up ~/Merges/ksensors/ksensors_0.7.3-15ubuntu2.patch
[23:50] <nhandler> This file is a diff that shows all of the Ubuntu changes that were made
[23:50] <nhandler> There is a similar file, ksensors_0.7.3-16.patch, that shows the changes that were made in the new Debian version of the package
[23:51] <nhandler> Now, I want you to look back at the changelog. Notice how in version 0.7.3-15ubuntu1 they added dh_iconcache to debian/rules, and in version 0.7.3-15ubuntu2 they replaced dh_iconcache with dh_icons?
[23:52] <medo_> yeah
[23:52] <nhandler> This means that our current debian/rules should have dh_icons, and not dh_iconcache. We can verify this by looking at debian/rules. You will notice that on line 99 is dh_icons.
[23:53] <nhandler> While we are looking at debian/rules, we should also verify that it includes 'patch' and 'upatch', which were added in version 0.7.3-15ubuntu2. You will find 'patch' on line 30, and 'unpatch' on line 45.
[23:54] <nhandler> While I've been presenting this lesson, james_w was kind enough to find a way to hopefully enable us to build this package.
[23:55] <nhandler> To apply this fix, locate this line "cp -f /usr/share/aclocal/libtool.m4 admin/libtool.m4.in". It should be line 33
[23:56] <nhandler> Right below it, paste these lines of text: http://paste.ubuntu.com/37565/
[23:56] <nhandler> Once you make those changes, you can save and quit the debian/rules file
[23:57] <nhandler> We are almost done. The only other Ubuntu change that we need to verify is still present is 01_kubuntu_fix_etc_sensors_conf.diff.
[23:59] <nhandler> You will find that patch in debian/patches. It is also listed in debian/patches/series.
[23:59] <nhandler> However, since the file that the patch modifies, src/lmsensors.cpp, has been changed in Debian, this patch will fail to apply if we were to try and build the package.
[23:59] <nhandler> Since working with patches is outside the scope of this lesson, I have made the needed changes to the patch. You can find my revised version here: http://paste.ubuntu.com/37450/